Lightning transactions with v3 and ephemeral anchors

[t-bast]

@morehouse

I think v3 also prevents MitM pinning attacks where someone extracts the SIGHASH_SINGLE | SIGHASH_ANYONECANPAY signature and uses it to construct and pin a low feerate conflicting transaction.

Can you explain that? I don’t see how someone can do anything with the SIGHASH_SINGLE | SIGHASH_ANYONECANPAY signature extracted from the witness, as it’s not sufficient to spend the output, they also need a second signature from the owner of the HTLC tx, which will be using SIGHASH_ALL?

@morehouse

Because Mallory’s preimage spend can opt out of v3 policy, she is able to pin her transaction in mempools while preventing Alice from learning the preimage or confirming her HTLC-timeout transaction.

True, that’s another pinning attack (that ariard described a while ago if I remember correctly). I’m not sure this one needs to be fixed by v3 though. When we discussed it a long time ago, we realized that:

• the attacked node doesn’t necessarily need their HTLC-timeout tx to confirm: if they learn the preimage, they don’t need to claim the output at all
• the attacker is taking some risk, because the attacked node can potentially still learn the preimage and get their HTLC-timeout confirmed, in which case the attacker is losing money
• a simple preimage gossip mechanism over lightning would fix that
• a mechanism in bitcoind that would let us inspect conflicting peer transactions to potentially extract the preimage would also fix that

I don’t think we should go down the rabbit hole of trying to exchange signatures to require a 2nd-stage HTLC transaction when spending from the remote commit: we simply cannot do this with the current commit_sig / revoke_and_ack protocol, as there’s a chicken-and-egg issue where you don’t know beforehand what you should be signing (we had the same issue when investigating that change for liquidity ads: [Lightning-dev] Liquidity Ads: Updated Spec Posted, please review)

@instagibbs

Huh! I hadn’t considered the fact that revoked states would allow HLTC-Timeout paths to create pins.

Can you describe that in more details? I don’t see what issue you’re referring to. If Bob broadcasts a revoked commitment, it cannot pin it while it’s unconfirmed because that revoked commitment is using v3. Once the revoked commitment is confirmed, Bob can only spend the HTLC outputs via a pre-signed HTLC tx, whose output also contains a revocation path that Alice will be able to claim? So in the end Alice will get all the funds?

@ajtowns

In either case, she probably doesn’t need to use any confirmed funds, as she can pay the on-chain fees directly from her channel balance immediately.

Yes, that is a very nice benefit of the v3 change! Being able to pay the on-chain fees directly from the channel balance is a very important but often overlooked improvement in my opinion.