Hi,
I think if Gleb Naumenko and myself allocate our research time on this
issue, we should (hopefully) be able to come with a strong sustainable fix
to the lightning network, both systematically solving pinnings and
replacement cycling attacks (and maybe other mempools issues or things
related
Hi,
As I've been shown offline Twitter posts misrepresenting my previous mail,
I think it's good to correct them. The security flaws are not "intentional
backdoor" or whatever misrepresentation that would question the competence
and know-how of the Bitcoin and Lightning development community.
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 this case
we want
spending the HTLC-preimage - if possible - to have an urgency attached
to it to
Could this be addressed with an OP_CSV_ALLINPUTS, a covenant opcode that
requires *all* inputs to have a matching nSequence, and using `1
OP_CSV_ALLINPUTS` in the HTLC preimage branch?
This would prevent using unconfirmed outputs in the HTLC-preimage-spending
transaction entirely, which IIUC
On 10/20/23 8:15 PM, Peter Todd wrote:
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
> By redefining a bit of the nVersion field, eg the most significant bit, we
> can apply coinbase-like txout handling to arbitrary transactions.
We already have that in OP_CHECKSEQUENCEVERIFY. You can have a system with no
coinbase transactions at all, and use only OP_CHECKSEQUENCEVERIFY on
> Let's say you have Alice, Bob and Caroll all "honest" routing hops
> targeted by an attacker. They all have 3 independent 10 000 sats HTLC
> in-flight on their outbound channels.
> It is replaced by Mallory at T+2 with a HTLC-preimage X of 200 000 sats (+
> rbf penalty 1 sat / vb rule 4).
On 10/20/23 9:25 PM, Peter Todd wrote:
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
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
I think if we apply this presigned fee multiplier idea to HTLC spends,
we can prevent replacement cycles from happening.
We could modify HTLC scripts so that *both* parties can only spend the
HTLC via presigned second-stage transactions, and we can always sign
those with SIGHASH_ALL. This will
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 more inputs and perform this attack even as the
broadcaster.
I
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 this case
> > we want
> >
15 matches
Mail list logo
