# Lightning transactions with v3 and ephemeral anchors **URL:** \ **Category:** Protocol Design\ **Tags:** mempool, lightning\ **Created:** [January 16, 2024, 5:28pm UTC](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 "2024-01-16T17:28:44Z")\ **Posts on this page:** 1\ **Showing post:** 17
**Author:** ![t-bast](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/t-bast/32/98_2.png) [@t-bast](https://delvingbitcoin.org/u/t-bast)\ **Post date:** [January 18, 2024, 2:31pm UTC](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/17 "2024-01-18T14:31:34Z")
> [@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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-November/004219.html)) > [@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. --- _[View the full topic](https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418)._