On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote:
> Gregory Maxwell via bitcoin-dev
> writes:
> > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> > wrote:
> >> Hi all,
> >>
> >> I'd like to pick up the discussion from a few months ago, and
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood wrote:
> Hey everybody.
>
> Say that the last time we updated channel state, we assumed 40 satoshi/byte
> was enough to get confirmed, then I leave the channel for a few weeks, come
> back to find my partner fell off the face of the
On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote:
> On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote:
> > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> > about what the flag actually does.
>
> I believe that making the signat
On November 27, 2018 12:13:27 AM UTC, Matt Corallo
wrote:
>+100 for IRC meetings, though, really, I'd much much stronger prefer
>substantive discussion happen on GitHub or the mailing list. Doing
>finalization in a live meeting is really unfair to those who can't find
>the time to attend
On Wed, Sep 25, 2019 at 11:01:28AM +0200, Konstantin Ketterer wrote:
> *Disclaimer*: I have just finished Highschool and I'm only learning a bit
> in my free time.This may be fundamentally broken ;)
>
> *Motivation*: If I had to timestamp multiple messages I could simply
> aggregate them in a
On Sun, Oct 06, 2019 at 08:46:59AM +, ZmnSCPxj wrote:
> > Obviously with care you can get the computation right. But at that point
> > what's
> > the actual advantage over OP_CAT?
> >
> > We're limited by the size of the script anyway; if the OP_CAT output size
> > limit
> > is comparable to
On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote:
> Interesting point.
>
> The script is under your control, so you should be able to ensure that you
> are always using a correctly constructed midstate, e.g., something like:
>
> scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>
On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:
> Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> function to allow concatenation of an unlimited amount of data, provided
> the only
On Tue, Jun 01, 2021 at 10:18:42PM +, darosior via Lightning-dev wrote:
> Hi all,
>
> It's been almost 9 months since Tor v2 hidden services have been deprecated.
> The Tor project will drop v2 support in about a month in the latest release.
> It will then be entirely be dropped from all
On Mon, Dec 20, 2021 at 09:01:37AM +0100, Joost Jager wrote:
> On Sat, Dec 18, 2021 at 6:56 PM Peter Todd wrote:
>
> > Lightning already has sender authentication: you simply give someone a
> > pre-image hash over an authenticated channel, and the fact that the
> > pa
On Fri, Dec 17, 2021 at 11:37:12AM +0100, Joost Jager wrote:
> Hello list,
>
> In Lightning we have a great scheme to protect the identity of the sender
> of a payment. This is awesome, but there are also use cases where opt-in
> sender authentication is desired.
Lightning already has sender
On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:
> The multisig scheme is interesting. From my understanding of Single Use
> Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
> you would want to pick some common aggregation service provider ahead of
> time and
On Thu, Dec 09, 2021 at 09:49:11AM +, Christian Moss wrote:
> p...@petertodd.org, so single use seals require an onchain transaction to
> post the proof of publication to the ledger (assuming bitcoin is used as
> the ledger) when an asset is transferred, but it can scale because you can
>
On Mon, Dec 06, 2021 at 04:35:19PM +, Christian Moss via bitcoin-dev wrote:
> As far as I understand it, RGB doesn't scale NFTs as each
> transaction to transfer ownership of an NFT would require an onchain
> transaction
RGB intends to scale NFTs and similar things in the future via scalable
On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:
> That's not really pinning; painning usually refers to pinning something to
> the bottom of the mempool whereas these mechanisms make it easier to
> guarantee that progress can be made on confirming the transactions you're
> interested
On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > As I said, it's a new kind of pinning attack, distinct from other types
> of pinning attack.
>
> I think pinning is "formally defined" as sequences of transactions which
> prevent or make it less likely for you to make any progress
On Sat, Feb 19, 2022 at 05:20:19PM +, darosior wrote:
> > Necromancing might be a reasonable name for attacks that work by getting an
> > out-of-date version of a tx mined.
>
> It's not an "attack"? There is no such thing as an out-of-date transaction, if
> you signed and broadcasted it in
On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> Happy new years devs,
>
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space
On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > nonsense marketing
>
> I'm sure the people who are confused about "blockchain schemes as \"world
> computers\" and other nonsense
> marketing" are avid and regular readers of the bitcoin devs mailing list so
> I offer my sincerest
On Sat, Oct 21, 2023 at 09:05:35PM +0100, Antoine Riard via bitcoin-dev wrote:
> In the meanwhile, lightning experts have already deployed mitigations which
> are hardening the lightning ecosystem significantly in face of simple or
> medium attacks. More advanced attacks can only be mounted if you
On Thu, Nov 02, 2023 at 05:24:36AM +, Antoine Riard wrote:
> Hi Peter,
>
> > So, why can't we make the HTLC-preimage path expire? Traditionally, we've
> tried
> > to ensure that transactions - once valid - remain valid forever. We do
> this
> > because we don't want transactions to become
RYTIMEVERIFY` opcode, mostly similar in behavior to
> `OP_EXPIRE` proposed by Peter Todd:
Note that if we redefine an OP_SuccessX opcode, we do not need _Verify
behavior. We can produce a true/false stack element, making either OP_Expire
or OP_CheckExpiryTime better names for the opcode.
> * C
On Fri, Nov 03, 2023 at 05:25:24AM +, Antoine Riard wrote:
> > To be clear, are you talking about anchor channels or non-anchor channels?
> > Because in anchor channels, all outputs other than the anchor outputs
> provided
> > for fee bumping can't be spent until the commitment transaction is
On Fri, Oct 20, 2023 at 10:31:03AM +, Peter Todd via bitcoin-dev wrote:
> As I have suggested before, the correct way to do pre-signed transactions is
> to
> pre-sign enough *different* transactions to cover all reasonable needs for
> bumping fees. Even if you just increase the fe
On Tue, Oct 17, 2023 at 10:34:04AM +, ZmnSCPxj via bitcoin-dev wrote:
> Good morning Antoine et al.,
>
> Let me try to rephrase the core of the attack.
>
> There exists these nodes on the LN (letters `A`, `B`, and `C` are nodes, `==`
> are channels):
>
> A = B = C
>
> `A`
On Mon, Oct 16, 2023 at 05:57:36PM +0100, Antoine Riard via bitcoin-dev wrote:
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim
On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote:
> Sadly this only is really viable for pre-anchor channels. With anchor
> channels the attack can be performed by either side of the closure, as the
> HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you
> to add
On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote:
> > Quite the contrary. Schnorr signatures are 64 bytes, so in situations like
> > lightning where the transaction form is deterministically derived, signing
> > 100
> > extra transactions requires just 6400 extra bytes. Even a very
On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote:
> > What are anchor outputs used for other than increasing fees?
> >
> > Because if we've pre-signed the full fee range, there is simply no need for
> > anchor outputs. Under any circumstance we can broadcast a transaction with a
> >
On Fri, Oct 20, 2023 at 10:58:32PM -1000, David A. Harding wrote:
> On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote:
> > The basic problem here is after the HTLC-timeout path becomes spendable,
> > the
> > HTLC-preimage path remains spendable. That's bad, because in
On Sat, Aug 19, 2023 at 12:02:39AM +0100, Antoine Riard wrote:
> As a backup plan, I think we could consider countries like Morocco or
> Algeria, which given current composition of the organization committee is
> straightforward due to the french-speaking communities, or South Africa,
> which is
On Mon, Aug 14, 2023 at 02:59:16PM +0200, Thomas Voegtlin wrote:
> Resumable channels using OP_CHECKSIGFROMSTACK
> =
>
>
> In order to resume the activity of a Lightning channel, one needs a
> backup that contains all the information about the current
e backup" oracle scheme that might be useful for applications
outside of Lightning. It might be wortwhile to forward it to bitcoin-dev,
pointing that out, so it sees a wider audience. I can't recall anyone else
coming up with that precise mechanism before.
> I agree with Peter Todd that si
On Thu, Aug 17, 2023 at 11:36:58AM +0200, Thomas Voegtlin wrote:
> Hello Peter,
>
> I have to disagree with both your reasoning and the numerical values
> you are proposing. Let us first look at the equations:
>
> > Suppose that Alice goes a few days without connecting to Bob 10
> > times per
On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote:
> > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > > As I said, it's a new kind of pinning attack, distinct from other types
> > > of pinning attack.
> > >
> > > I think pinning is "formally defined" as sequences of
On Tue, Jun 28, 2022 at 11:31:54AM -0400, Matt Corallo wrote:
> On 6/28/22 9:05 AM, Christian Decker wrote:
> > It is worth mentioning here that the LN protocol is generally not very
> > latency sensitive, and from my experience can easily handle very slow
> > signers (3-5 seconds delay) without
On Mon, May 02, 2022 at 08:59:49AM -0700, Jeremy Rubin wrote:
> Ok, got it. Won't waste anyone's time on terminology pedantism.
>
>
> The model that I proposed above is simply what *any* correct timestamping
> service must do. If OTS does not follow that model, then I suspect whatever
> OTS is,
On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote:
> the 'lots of people' stuff (get confused, can't figure out what i'm
> quoting, actually are reading this conversation) is an appeal to an
> authority that doesn't exist. If something is unclear to you, let me know.
> If it's unclear
On Thu, Aug 03, 2023 at 10:54:06AM +0200, Elias Rohrer wrote:
> As surrendering this kind of data therefore requires a good level of trust
> in the researchers, it might be helpful (and best practise) if you could
> clarify upfront whether you intend to time-box the collection period, where
> the
As per BOLT #3,
https://github.com/lightning/bolts/blob/8a64c6a1cef979b3f0cecb00ba7a48c2d28b3588/03-transactions.md#commitment-transaction-construction
9) If option_anchors applies to the commitment transaction:
* if to_local exists or there are untrimmed HTLCs, add a
On Wed, Dec 13, 2023 at 02:27:13PM +0100, Bastien TEINTURIER wrote:
> Hi Peter,
>
> No, we currently cannot get rid of the remote anchor in favor of the
> main remote output. That was considered during the design of anchor
> outputs, but that would create the following vulnerability.
>
> Alice
On Wed, Dec 13, 2023 at 04:41:46PM +0100, Bastien TEINTURIER wrote:
> Hi Peter,
>
> > it is more efficient to just open the channel with a dust-sized
> > balance on the to_remote output.
>
> Yes, that would work, basically whenever the `to_remote` output would
> disappear, then you add an anchor
On Mon, Dec 04, 2023 at 07:19:41PM -0500, James O'Beirne wrote:
> Please see https://github.com/jamesob/delving-bitcoin-archive, which anyone
> can run an instance of themselves.
Looks like that's missing images unfortunately, which are being frequently
used. Do you know of a way to fix that?
On Mon, Dec 04, 2023 at 12:35:32PM -0800, Matt Corallo wrote:
> Ah, there was also some concern over archiving of a discourse, which we'd
> hoped was trivial through "mailing list mode", but apparently that may not
> be the case. Further thoughts on that are welcome.
You mean archiving of
On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote:
> Peter Todd proposes to sign multiple versions of offchain transactions at
> varying feerates.
> However, this proposal has the issue that if you are not the counterparty
> paying for onchain fees (e.g. the origi
On Tue, Jan 30, 2024 at 05:07:16AM +, ZmnSCPxj wrote:
> Sent with Proton Mail secure email.
>
> On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd
> wrote:
>
> > On Tue, Jan 30, 2024 at 04:12:07AM +, ZmnSCPxj wrote:
> >
> > > Peter Tod
On Mon, Nov 13, 2023 at 02:18:16AM +, Antoine Riard wrote:
> Your two latest mails.
>
> > The problem that OP_Expire aims to solve is the fact that Carol could
> prevent
> > Bob from learning about the preimage in time, while still getting a
> chance to
> > use the preimage herself. OP_Expire
On Mon, Nov 06, 2023 at 06:45:21PM +, Antoine Riard wrote:
> > I think you are misunderstanding a key point to my OP_Expire proposal:
> because
> > the ability to spend the preimage branch of the HTLC goes away when the
> refund
> > branch becomes available, replacing cycling or any similar
On Wed, Nov 08, 2023 at 12:51:31AM +, Peter Todd via bitcoin-dev wrote:
> > In a post-package relay world, I think this is possible. And that
> > replacement cycling attacks are breaking future dynamic fee-bumping of
> > pre-signed transactions concerns me a lot.
>
&
49 matches
Mail list logo
