* [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
@ 2020-07-09 21:40 Anthony Towns
2020-07-09 22:30 ` Anthony Towns
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Anthony Towns @ 2020-07-09 21:40 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hello world,
After talking with Christina ages ago, we came to the conclusion that
it made more sense to update BIP 118 to the latest thinking than have
a new BIP number, so I've (finally) opened a (draft) PR to update BIP
118 with the ANYPREVOUT bip I've passed around to a few people,
https://github.com/bitcoin/bips/pull/943
Probably easiest to just read the new BIP text on github:
https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
It doesn't come with tested code at this point, but I figure better to
have the text available for discussion than nothing.
Some significant changes since previous discussion include complete lack
of chaperone signatures or anything like it (if you want them, you can
always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
longer commits to the value (details/rationale in the text).
Cheers,
aj
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 21:40 [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
@ 2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-04 4:02 ` lf-lists
2 siblings, 1 reply; 14+ messages in thread
From: Anthony Towns @ 2020-07-09 22:30 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev wrote:
> After talking with Christina
Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke.
Cheers,
aj, hoping he typed one of those right, at least...
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 21:40 [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
2020-07-09 22:30 ` Anthony Towns
@ 2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 4:02 ` lf-lists
2 siblings, 1 reply; 14+ messages in thread
From: ZmnSCPxj @ 2020-07-10 3:29 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
Good morning aj,
It seems okay to me.
--
Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction could, in theory, have only a single internal taproot pubkey, `P = MuSig(A, B)` for a channel between A and B.
So the funding outpoint would be spent with a taprooted P + a single tapscript `<1> OP_CHECKSIG`.
Update transactions would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUTANYSCRIPT`.
The update transaction output would be spendable with a taprooted P + a single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1> OP_CHECKSIG`.
Each update transaction would have a monotonically-increasing `nLockTime`, i.e. the above `index`.
Then a state transaction would be signed with the internal taproot pubkey using `SIGHASH_ANYPREVOUT`, which commits to the exact script including `<index + 1>`, which is unique for each update transaction.
Thus a state transaction can only spend the specific update transaction, but the update transaction can spend the funding outpoint or any update transaction outpoint.
State transaction input would have an `nSequence` requiring a relative locktime of the agreed-upon unilateral close delay.
The above assumes MuSig signing, which requires 1.5 round trips for a channel, or three broadcast rounds for a multiparticipant (n >= 3) construction.
Regards,
ZmnSCPxj
> Hello world,
>
> After talking with Christina ages ago, we came to the conclusion that
> it made more sense to update BIP 118 to the latest thinking than have
> a new BIP number, so I've (finally) opened a (draft) PR to update BIP
> 118 with the ANYPREVOUT bip I've passed around to a few people,
>
> https://github.com/bitcoin/bips/pull/943
>
> Probably easiest to just read the new BIP text on github:
>
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>
> It doesn't come with tested code at this point, but I figure better to
> have the text available for discussion than nothing.
>
> Some significant changes since previous discussion include complete lack
> of chaperone signatures or anything like it (if you want them, you can
> always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
> longer commits to the value (details/rationale in the text).
>
> Cheers,
> aj
>
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 22:30 ` Anthony Towns
@ 2020-07-10 7:46 ` Christian Decker
0 siblings, 0 replies; 14+ messages in thread
From: Christian Decker @ 2020-07-10 7:46 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
No worries, it's a common character twist I find myself doing from time to
time :-)
Cheers,
Christina
On Fri, 10 Jul 2020, 00:31 Anthony Towns via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Fri, Jul 10, 2020 at 07:40:48AM +1000, Anthony Towns via bitcoin-dev
> wrote:
> > After talking with Christina
>
> Christian. Dr Christian Decker, PhD. Dr Bitcoin. cdecker. Snyke.
>
> Cheers,
> aj, hoping he typed one of those right, at least...
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 1247 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-10 3:29 ` ZmnSCPxj
@ 2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj
0 siblings, 1 reply; 14+ messages in thread
From: Richard Myers @ 2020-08-03 19:27 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 4255 bytes --]
Thanks AJ for the updated BIP - very exciting!
I'm also interested in this in the context of a Taproot version of
Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your
thoughts on how this would work. I have had some difficulty understanding
when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this
is a clever demonstration of how the differences can be exploited.
I sketched out the protocol you described to help my understand it (below)
and some questions came to mind:
1) If you do a collaborative close, would you need to use script-path
spending, or could you use key-path spending instead to improve privacy?
2) You mention 1.5 round trips for the (two party) MuSig signing session.
Must there be separate 1.5 round trips for each of the two signatures
produced (update, settlement) for each state update?
3) A related question: can the 1.5 round trips for signing be combined with
the 1.5 round trips required to update the channel (ie. A signs settlement
tx, B signs settlement & update txs, A signs update tx)?
Perhaps something like this:
-> A provides partial signature for settlement tx
<- B provides complete signature for settlement tx and partial signature
for update tx
-> A provides complete signature for update tx
4) I'm not sure why AJ's formulation included an addition sig(X), but
otherwise is it similar to what you're suggesting?
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
All the best,
-- Richard
------- my interpretation of your scheme ----
[Fund Channel]
|
|
|
v
P=Musig(A,B)+scripts (Taproot internal key, aka script path key?)
Q=Musig(A,B) (Taproot output key, aka root key?)
OR ----------- [Cooperative Close]
||| Sig(Q) -----+
||| |----> Sig(A)...
||| |
||| |----> Sig(B)...
|||
|||
||+-->[Update(n)]
|| nlocktime/state > n
|| Sig(P)+ANYPREVOUTANYSCRIPT
||
|| OR ---------->[Settle(n)] [Uncooperative Close @
state n]
|| | Sig(P)+ANYPREVOUT
|| | csv [delay] --------+---> Sig(A)... [HTLCs
& Settled
|| | |
Outputs ]
|| | |---> Sig(B)...
|| v
|+---->[Update(n+1)]
| nlocktime/state > n+1
| Sig(P)+ANYPREVOUTANYSCRIPT
|
| OR ----------->[Settle(n+1)] [Uncooperative Close @
state n+1]
| | Sig(P)+ANYPREVOUT
| | csv [delay] -------+---> Sig(A)... [HTLCs
& Settled
| | |
Outputs ]
v v |---> Sig(B)...
On Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
...
> Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction
> could, in theory, have only a single internal taproot pubkey, `P = MuSig(A,
> B)` for a channel between A and B.
>
> So the funding outpoint would be spent with a taprooted P + a single
> tapscript `<1> OP_CHECKSIG`.
>
> Update transactions would be signed with the internal taproot pubkey using
> `SIGHASH_ANYPREVOUTANYSCRIPT`.
> The update transaction output would be spendable with a taprooted P + a
> single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1>
> OP_CHECKSIG`.
> Each update transaction would have a monotonically-increasing `nLockTime`,
> i.e. the above `index`.
>
> Then a state transaction would be signed with the internal taproot pubkey
> using `SIGHASH_ANYPREVOUT`, which commits to the exact script including
> `<index + 1>`, which is unique for each update transaction.
> Thus a state transaction can only spend the specific update transaction,
> but the update transaction can spend the funding outpoint or any update
> transaction outpoint.
> State transaction input would have an `nSequence` requiring a relative
> locktime of the agreed-upon unilateral close delay.
>
> The above assumes MuSig signing, which requires 1.5 round trips for a
> channel, or three broadcast rounds for a multiparticipant (n >= 3)
> construction.
>
>
> Regards,
> ZmnSCPxj
>
>
[-- Attachment #2: Type: text/html, Size: 8137 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-03 19:27 ` Richard Myers
@ 2020-08-04 1:38 ` ZmnSCPxj
0 siblings, 0 replies; 14+ messages in thread
From: ZmnSCPxj @ 2020-08-04 1:38 UTC (permalink / raw)
To: Richard Myers; +Cc: Bitcoin Protocol Discussion
Good morning Richard,
> Thanks AJ for the updated BIP - very exciting!
>
> I'm also interested in this in the context of a Taproot version of Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your thoughts on how this would work. I have had some difficulty understanding when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is a clever demonstration of how the differences can be exploited.
>
> I sketched out the protocol you described to help my understand it (below) and some questions came to mind:
>
> 1) If you do a collaborative close, would you need to use script-path spending, or could you use key-path spending instead to improve privacy?
It can (and should) use key-path, yes.
>
> 2) You mention 1.5 round trips for the (two party) MuSig signing session. Must there be separate 1.5 round trips for each of the two signatures produced (update, settlement) for each state update?
I believe we can amortize this slightly by providing the `R` commitments for the *next* signing session with the `s` for the *current* signing session, reducing to 1.0 round trips.
However, I believe a provably-safe 2-round MuSig (with composable MuSig even!) is being worked on and should be released in a week or two, and if it is safe to provide the first round of the *next* session with the final round of the *current* session then we could reduce it to just one (large) message send per update.
>
> 3) A related question: can the 1.5 round trips for signing be combined with the 1.5 round trips required to update the channel (ie. A signs settlement tx, B signs settlement & update txs, A signs update tx)?
>
> Perhaps something like this:
> -> A provides partial signature for settlement tx
> <- B provides complete signature for settlement tx and partial signature for update tx
> -> A provides complete signature for update tx
My understanding (which might be incorrect!) is that it should be safe to perform the signing sessions for the settlement and update txes simultaneously, i.e.
* round 1: send `R` commitments for both update and settlement tx (can be sent with round 3 of previous signing session).
* round 2: send `R` for both update and settlement tx.
* round 3: send `s` for both update and settlement tx.
Depending on how we do the HTLCs / PTLCs, we might also need to send signatures for all HTLCs, in parallel with the update+settlement tx signatures, as well.
> 4) I'm not sure why AJ's formulation included an addition sig(X), but otherwise is it similar to what you're suggesting?
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html
This might have been the "chaperone signatures" proposed for `SIGHASH_NOINPUT` / `SIGHASH_ANYPREVOUT` back then.
This was supposed to protect against replaying a `SIGHASH_ANYPREVOUT` signature in case of address reuse.
I pointed out that it would be much simpler for a Lightning spec to provide a privkey for a common `X` used by all Lightning nodes, and thus would not really provide much better security in practice.
I believe what we intend now is a form of hidden output tagging to protect against signature replay.
An output has to have a special taproot version in order to be spent with `SIGHASH_ANYPREVOUT` or `SIGHASH_ANYPREVOUTANYSCRIPT` in the script path, and `SIGHASH_ANYPREVOUT`/`SIGHASH_ANYPREVOUTANYSCRIPT` is not usable with key path spends.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-07-09 21:40 [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 3:29 ` ZmnSCPxj
@ 2020-08-04 4:02 ` lf-lists
2020-08-04 4:23 ` ZmnSCPxj
2 siblings, 1 reply; 14+ messages in thread
From: lf-lists @ 2020-08-04 4:02 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
Matt
> On Jul 9, 2020, at 17:46, Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hello world,
>
> After talking with Christina ages ago, we came to the conclusion that
> it made more sense to update BIP 118 to the latest thinking than have
> a new BIP number, so I've (finally) opened a (draft) PR to update BIP
> 118 with the ANYPREVOUT bip I've passed around to a few people,
>
> https://github.com/bitcoin/bips/pull/943
>
> Probably easiest to just read the new BIP text on github:
>
> https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki
>
> It doesn't come with tested code at this point, but I figure better to
> have the text available for discussion than nothing.
>
> Some significant changes since previous discussion include complete lack
> of chaperone signatures or anything like it (if you want them, you can
> always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no
> longer commits to the value (details/rationale in the text).
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-04 4:02 ` lf-lists
@ 2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
0 siblings, 2 replies; 14+ messages in thread
From: ZmnSCPxj @ 2020-08-04 4:23 UTC (permalink / raw)
To: lf-lists, Bitcoin Protocol Discussion
Good morning Matt,
> While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
>
> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
>
> This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
>
> The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
Ah, right.
A feasible attack, without the above, would be to connect to the fullnode of the victim, and connect to miners separately.
Then you broadcast to the victim one of the old txes, call it tx A, but you broadcast to the miners a *different* old tx, call it B.
The victim reacts only to tA, but does not react to B since it does not see B in the mempool.
On the other hand --- what the victim needs to react to is *onchain* confirmed transactions.
So I think all the victim needs to do, in a Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and ignore mempool events.
So if we give fairly long timeouts for our mechanisms, it should be enough, I think, since once a transaction is confirmed its txid does not malleate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, unless a reorg unconfirms the transaction.
We only need to be aware of deep reorgs and re-broadcast with a malleated prevout until the tx being spent is deeply confirmed.
In addition, we want to implement scorch-the-earth, keep-bumping-the-fee strategies anyway, so we would keep rebroadcasting new versions of the spending transaction, and spending from a transaction that is confirmed.
Or are there other attack vectors you can see that I do not?
I think this is fixed by looking at the blockchain.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-04 4:23 ` ZmnSCPxj
@ 2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
1 sibling, 0 replies; 14+ messages in thread
From: Christian Decker @ 2020-08-04 10:38 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion, lf-lists,
Bitcoin Protocol Discussion
> Ah, right.
>
> A feasible attack, without the above, would be to connect to the
> fullnode of the victim, and connect to miners separately. Then you
> broadcast to the victim one of the old txes, call it tx A, but you
> broadcast to the miners a *different* old tx, call it B. The victim
> reacts only to tA, but does not react to B since it does not see B in
> the mempool.
>
> On the other hand --- what the victim needs to react to is *onchain*
> confirmed transactions. So I think all the victim needs to do, in a
> Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based
> mechanisms, is to monitor onchain events and ignore mempool events.
>
> So if we give fairly long timeouts for our mechanisms, it should be
> enough, I think, since once a transaction is confirmed its txid does
> not malleate without a reorg and a `SIGHASH_NOINPUT` signature can
> then be "locked" to that txid, unless a reorg unconfirms the
> transaction. We only need to be aware of deep reorgs and re-broadcast
> with a malleated prevout until the tx being spent is deeply confirmed.
This is indeed part of the reason why we chose to describe the protocol
on-chain first in the paper and lift it off-chain after showing the
basic functionality. This means that the protocol is still correct even
if executed solely on information derived from blocks and confirmed
transactions in those blocks. The timeouts have to be chosen carefully
to allow reacting in a timely fashion, however that is true for all
off-chain protocols.
> In addition, we want to implement scorch-the-earth,
> keep-bumping-the-fee strategies anyway, so we would keep
> rebroadcasting new versions of the spending transaction, and spending
> from a transaction that is confirmed.
Correct, it might be desirable to give a misbehaving node a papercut by
letting their update transaction confirm (taking their fee along with
it) and then reacting to the outdated update by overriding the effects
with a new update-settlement pair.
So, while being able to react to a transaction in the memory pool early
might be a nice addition, it is not strictly required for safety of the
protocol. I say nice addition, because it can allow replacing the
outdated transaction directly, thus saving the misbehaving node from the
fee papercut, but also save a bit of blockspace which that fee would
have paid for, and leave it available for other transactions.
Cheers,
Christian
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
@ 2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
1 sibling, 1 reply; 14+ messages in thread
From: Matt Corallo @ 2020-08-04 13:10 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Hmm, apologies that little context was provided - this was meant in the context of the current crop of relay-based attacks that have been discovered. As we learned in those contexts, “just handle it when it confirms” doesn’t provide the types of guarantees we were hoping for as placing commitment transactions in mempools can be used to prevent honest nodes from broadcasting the latest state. This implies that HTLC security may be at risk.
> On Aug 4, 2020, at 00:23, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Matt,
>
>> While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
>>
>> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
>>
>> This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
>>
>> The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
>
> Ah, right.
>
> A feasible attack, without the above, would be to connect to the fullnode of the victim, and connect to miners separately.
> Then you broadcast to the victim one of the old txes, call it tx A, but you broadcast to the miners a *different* old tx, call it B.
> The victim reacts only to tA, but does not react to B since it does not see B in the mempool.
>
> On the other hand --- what the victim needs to react to is *onchain* confirmed transactions.
> So I think all the victim needs to do, in a Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and ignore mempool events.
>
> So if we give fairly long timeouts for our mechanisms, it should be enough, I think, since once a transaction is confirmed its txid does not malleate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, unless a reorg unconfirms the transaction.
> We only need to be aware of deep reorgs and re-broadcast with a malleated prevout until the tx being spent is deeply confirmed.
>
> In addition, we want to implement scorch-the-earth, keep-bumping-the-fee strategies anyway, so we would keep rebroadcasting new versions of the spending transaction, and spending from a transaction that is confirmed.
>
> Or are there other attack vectors you can see that I do not?
> I think this is fixed by looking at the blockchain.
>
> Regards,
> ZmnSCPxj
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-04 13:10 ` Matt Corallo
@ 2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
0 siblings, 1 reply; 14+ messages in thread
From: ZmnSCPxj @ 2020-08-04 14:59 UTC (permalink / raw)
To: Matt Corallo; +Cc: Bitcoin Protocol Discussion
Good morning Matt,
> Hmm, apologies that little context was provided - this was meant in the context of the current crop of relay-based attacks that have been discovered. As we learned in those contexts, “just handle it when it confirms” doesn’t provide the types of guarantees we were hoping for as placing commitment transactions in mempools can be used to prevent honest nodes from broadcasting the latest state. This implies that HTLC security may be at risk.
>
Ah, okay.
So the attack is this:
* Attacker connects twice to the LN: one to any node near the victim, one to the victim.
* Attacker arranges for the attacker-victim channel to have most funds in the side of the victim.
* The attacker routes a circular payment terminating in the victim-attacker channel.
* The victim accepts some incoming HTLC, and provides an outgoing HTLC to the attacker via the victim-attacker channel.
* The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel, one that is too low-fee to practically get confirmed, just before the HTLC timeout.
* The victim-outgoing HTLC times out, making the victim broadcast a unilateral close attempt for the victim-attacker channel in order to enforce the HTLC onchain.
* Unfortunately for the victim, relay shenanigans prevent the latest commitment from being broadcast.
* The attacker waits for the victim-incoming HTLC to timeout, which forces the victim to `update_htlc_failed` the incoming HTLC or risk having that channel closed (and losing future routing fees).
* The attacker now gets back its outgoing funds.
* The attacker lets the old-state transaction get relayed, and then re-seats the latest update transaction to that.
* Once the latest transaction allows the HTLCs to be published, the attacker claims the victim-outgoing HTLC with the hashlock branch.
* The attacker now gets its incoming funds, doubling its money, because that is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works right?
Hmmm.
The only thing I can imagine helping here is for the forwarding node to drop channels onchain "early", i.e. if the HTLC will time out in say 14 blocks we drop the channel onchain, so we have a little leeway in bumping up fees for the commitment transaction.
Maybe.
I am sure Matt can find yet another relay attack that prevents that, at this point, haha.
"Are we *still* talking about onchain fees....?" - Adelaide 2018
Regards,
ZmnSCPxj
> > On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail•com wrote:
> > Good morning Matt,
> >
> > > While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
> > > Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
> > > This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
> > > The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
> >
> > Ah, right.
> > A feasible attack, without the above, would be to connect to the fullnode of the victim, and connect to miners separately.
> > Then you broadcast to the victim one of the old txes, call it tx A, but you broadcast to the miners a different old tx, call it B.
> > The victim reacts only to tA, but does not react to B since it does not see B in the mempool.
> > On the other hand --- what the victim needs to react to is onchain confirmed transactions.
> > So I think all the victim needs to do, in a Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and ignore mempool events.
> > So if we give fairly long timeouts for our mechanisms, it should be enough, I think, since once a transaction is confirmed its txid does not malleate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, unless a reorg unconfirms the transaction.
> > We only need to be aware of deep reorgs and re-broadcast with a malleated prevout until the tx being spent is deeply confirmed.
> > In addition, we want to implement scorch-the-earth, keep-bumping-the-fee strategies anyway, so we would keep rebroadcasting new versions of the spending transaction, and spending from a transaction that is confirmed.
> > Or are there other attack vectors you can see that I do not?
> > I think this is fixed by looking at the blockchain.
> > Regards,
> > ZmnSCPxj
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-04 14:59 ` ZmnSCPxj
@ 2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers
0 siblings, 1 reply; 14+ messages in thread
From: Matt Corallo @ 2020-08-06 15:58 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: Bitcoin Protocol Discussion
Yep! That is the attack I had in mind - just in general any time you have a non-relative time limit (ie an HTLC) for
confirmation, relay attacks become critical and its no longer just about revocation (which is fine when your time limit
is CSV-based).
In general, SIGHASH_NOINPUT makes these issues much, much simpler to address, but only if we assume that nodes can
somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else
in the mempool already spends (potentially a different input than the relaying node thinks the transaction should
spend). While ideally we'd be able to shove that (significant) complexity into the Bitcoin P2P network, that may not be
feasible, but we could imagine a relay network of lightning nodes doing that calculation and then passing the
transactions to their local full nodes.
Given such an overlay network would represent an increase in local mempool fees, it is not unreasonable to expect at
least some miners to run a local node which can submit such transactions to their template-generating nodes.
Matt
On 8/4/20 10:59 AM, ZmnSCPxj wrote:
> Good morning Matt,
>
>> Hmm, apologies that little context was provided - this was meant in the context of the current crop of relay-based attacks that have been discovered. As we learned in those contexts, “just handle it when it confirms” doesn’t provide the types of guarantees we were hoping for as placing commitment transactions in mempools can be used to prevent honest nodes from broadcasting the latest state. This implies that HTLC security may be at risk.
>>
>
> Ah, okay.
>
> So the attack is this:
>
> * Attacker connects twice to the LN: one to any node near the victim, one to the victim.
> * Attacker arranges for the attacker-victim channel to have most funds in the side of the victim.
> * The attacker routes a circular payment terminating in the victim-attacker channel.
> * The victim accepts some incoming HTLC, and provides an outgoing HTLC to the attacker via the victim-attacker channel.
> * The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel, one that is too low-fee to practically get confirmed, just before the HTLC timeout.
> * The victim-outgoing HTLC times out, making the victim broadcast a unilateral close attempt for the victim-attacker channel in order to enforce the HTLC onchain.
> * Unfortunately for the victim, relay shenanigans prevent the latest commitment from being broadcast.
> * The attacker waits for the victim-incoming HTLC to timeout, which forces the victim to `update_htlc_failed` the incoming HTLC or risk having that channel closed (and losing future routing fees).
> * The attacker now gets back its outgoing funds.
> * The attacker lets the old-state transaction get relayed, and then re-seats the latest update transaction to that.
> * Once the latest transaction allows the HTLCs to be published, the attacker claims the victim-outgoing HTLC with the hashlock branch.
> * The attacker now gets its incoming funds, doubling its money, because that is how the "send me 1 BTC I send you 2 BTC back" Twitter thing works right?
>
> Hmmm.
>
> The only thing I can imagine helping here is for the forwarding node to drop channels onchain "early", i.e. if the HTLC will time out in say 14 blocks we drop the channel onchain, so we have a little leeway in bumping up fees for the commitment transaction.
> Maybe.
> I am sure Matt can find yet another relay attack that prevents that, at this point, haha.
>
> "Are we *still* talking about onchain fees....?" - Adelaide 2018
>
> Regards,
> ZmnSCPxj
>
>
>
>
>>> On Aug 4, 2020, at 00:23, ZmnSCPxj ZmnSCPxj@protonmail•com wrote:
>>> Good morning Matt,
>>>
>>>> While I admit I haven’t analyzed the feasibility, I want to throw one additional design consideration into the ring.
>>>> Namely, it would ideally be trivial, at the p2p protocol layer, to relay a transaction to a full node without knowing exactly which input transaction that full node has in its mempool/active chain. This is at least potentially important for systems like lighting where you do not know which counterparty commitment transaction(s) are in a random node’s mempool and you should be able to describe to that node that you are spending then nonetheless.
>>>> This is (obviously) an incredibly nontrivial problem both in p2p protocol complexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather useless for lighting without it.
>>>> The least we could do is think about the consensus design in that context, even if we have to provide an external overlay relay network in order to make lighting transactions relay properly (presumably with miners running such software).
>>>
>>> Ah, right.
>>> A feasible attack, without the above, would be to connect to the fullnode of the victim, and connect to miners separately.
>>> Then you broadcast to the victim one of the old txes, call it tx A, but you broadcast to the miners a different old tx, call it B.
>>> The victim reacts only to tA, but does not react to B since it does not see B in the mempool.
>>> On the other hand --- what the victim needs to react to is onchain confirmed transactions.
>>> So I think all the victim needs to do, in a Lightning universe utilizing primarily `SIGHASH_NOINPUT`-based mechanisms, is to monitor onchain events and ignore mempool events.
>>> So if we give fairly long timeouts for our mechanisms, it should be enough, I think, since once a transaction is confirmed its txid does not malleate without a reorg and a `SIGHASH_NOINPUT` signature can then be "locked" to that txid, unless a reorg unconfirms the transaction.
>>> We only need to be aware of deep reorgs and re-broadcast with a malleated prevout until the tx being spent is deeply confirmed.
>>> In addition, we want to implement scorch-the-earth, keep-bumping-the-fee strategies anyway, so we would keep rebroadcasting new versions of the spending transaction, and spending from a transaction that is confirmed.
>>> Or are there other attack vectors you can see that I do not?
>>> I think this is fixed by looking at the blockchain.
>>> Regards,
>>> ZmnSCPxj
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-06 15:58 ` Matt Corallo
@ 2020-08-07 15:34 ` Richard Myers
2020-08-11 0:14 ` Matt Corallo
0 siblings, 1 reply; 14+ messages in thread
From: Richard Myers @ 2020-08-07 15:34 UTC (permalink / raw)
To: Matt Corallo, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
When you say that a special relay network might be more "smart about
replacement" in the context of ANYPREVOUT*, do you mean these nodes could
RBF parts of a package like this:
Given:
- Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1)
-> HtlcTxs(n=1)_A -> .chain of transactions that pin UpdateTx_A(n=1) with
high total fee, etc.
And a new package with higher fee rate versions of ANYPREVOUT* transactions
in the package, but otherwise lower total fee:
- Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_B -> low total fee package
Relay just the higher up-front fee-rate transactions from package B which
get spent by the high absolute fee child transactions from package A:
- Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1)
-> HtlcTxs(n=1)_A -> ...chain of up to 25 txs that pin UpdateTx(n=1) with
high total fee, etc.
On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> In general, SIGHASH_NOINPUT makes these issues much, much simpler to
> address, but only if we assume that nodes can
> somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend
> which can spend an output that something else
> in the mempool already spends (potentially a different input than the
> relaying node thinks the transaction should
> spend). While ideally we'd be able to shove that (significant) complexity
> into the Bitcoin P2P network, that may not be
> feasible, but we could imagine a relay network of lightning nodes doing
> that calculation and then passing the
> transactions to their local full nodes.
[-- Attachment #2: Type: text/html, Size: 2488 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
2020-08-07 15:34 ` Richard Myers
@ 2020-08-11 0:14 ` Matt Corallo
0 siblings, 0 replies; 14+ messages in thread
From: Matt Corallo @ 2020-08-11 0:14 UTC (permalink / raw)
To: Richard Myers, Bitcoin Protocol Discussion
I was assuming, largely, that Bitcoin Core will eventually get what you describe here (which is generally termed
"package relay", implying we relay, and process, groups of transactions as one).
What we'd need for SIGHASH_ANYPREVOUT is a relay network that isn't just smart about fee calculation, but can actually
rewrite the transactions themselves before passing them on to a local bitcoind.
eg such a network would need to be able to relay
"I have transaction A, with one input, which is valid for any output-idx-0 in a transaction spending output B".
and then have the receiver go look up which transaction in its mempool/chain spends output B, then fill in the input
with that outpoint and hand the now-fully-formed transaction to their local bitcoind for processing.
Matt
On 8/7/20 11:34 AM, Richard Myers wrote:
> When you say that a special relay network might be more "smart about replacement" in the context of ANYPREVOUT*, do you
> mean these nodes could RBF parts of a package like this:
>
>
> Given:
> - Package A = UpdateTx_A(n=1): txin: AnchorTx, txout: SettlementTx_A(n=1) -> HtlcTxs(n=1)_A -> .chain of transactions
> that pin UpdateTx_A(n=1) with high total fee, etc.
>
>
> And a new package with higher fee rate versions of ANYPREVOUT* transactions in the package, but otherwise lower total fee:
>
> - Package B = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1) -> HtlcTxs(n=1)_B -> low total fee package
>
>
> Relay just the higher up-front fee-rate transactions from package B which get spent by the high absolute fee child
> transactions from package A:
>
> - Package A' = UpdateTx_B(n=1): txin: AnchorTx, txout: SettlementTx_B(n=1) -> HtlcTxs(n=1)_A -> ...chain of up to 25
> txs that pin UpdateTx(n=1) with high total fee, etc.
>
> On Thu, Aug 6, 2020 at 5:59 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> In general, SIGHASH_NOINPUT makes these issues much, much simpler to address, but only if we assume that nodes can
> somehow be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else
> in the mempool already spends (potentially a different input than the relaying node thinks the transaction should
> spend). While ideally we'd be able to shove that (significant) complexity into the Bitcoin P2P network, that may not be
> feasible, but we could imagine a relay network of lightning nodes doing that calculation and then passing the
> transactions to their local full nodes.
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-08-11 0:14 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-09 21:40 [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT Anthony Towns
2020-07-09 22:30 ` Anthony Towns
2020-07-10 7:46 ` Christian Decker
2020-07-10 3:29 ` ZmnSCPxj
2020-08-03 19:27 ` Richard Myers
2020-08-04 1:38 ` ZmnSCPxj
2020-08-04 4:02 ` lf-lists
2020-08-04 4:23 ` ZmnSCPxj
2020-08-04 10:38 ` Christian Decker
2020-08-04 13:10 ` Matt Corallo
2020-08-04 14:59 ` ZmnSCPxj
2020-08-06 15:58 ` Matt Corallo
2020-08-07 15:34 ` Richard Myers
2020-08-11 0:14 ` Matt Corallo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox