delvingbitcoin

Lightning transactions with v3 and ephemeral anchors

Lightning transactions with v3 and ephemeral anchors

Original Postby t-bast

Posted on: January 18, 2024 14:31 UTC

The email exchange addresses a highly technical aspect of Bitcoin's Lightning Network and its security against certain types of attacks, specifically regarding the handling of Hashed Time-Locked Contracts (HTLCs) and signature extraction.

The conversation highlights the prevention of potential Man-in-the-Middle (MitM) pinning attacks that could arise from extracting a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY signature. It is pointed out that for an output to be spent, an additional signature from the owner of the HTLC transaction using SIGHASH_ALL would be required, thus complicating such an attack.

The discussants acknowledge another form of pinning attack previously described by another developer, ariard. They note that the attacked node does not necessarily require their HTLC-timeout transaction to confirm if they can learn the preimage, negating the need to claim the output altogether. The attacker also takes a risk in this scenario because if the attacked node learns the preimage and gets their HTLC-timeout confirmed, the attacker stands to lose money. Solutions such as a preimage gossip mechanism over the Lightning Network or a feature in bitcoind to inspect conflicting transactions for preimage extraction are suggested as potential fixes.

Furthermore, the correspondence covers the impracticality of exchanging signatures to require a second-stage HTLC transaction when spending from the remote commit due to the current protocol limitations within commit_sig and revoke_and_ack. This is exemplified by previous issues encountered during the exploration of liquidity ads changes, which faced similar chicken-and-egg problems (referenced with a specific URL to a Linux Foundation mailing list).

An interesting point raised is the behavior of revoked states allowing HTLC-Timeout paths to create pins. However, it is clarified that if Bob broadcasts a revoked commitment, it cannot pin while unconfirmed due to the use of v3. Once confirmed, Bob can only spend the HTLC outputs via a pre-signed HTLC transaction which includes a revocation path that Alice can potentially claim, ensuring she ultimately receives the funds.

Lastly, the discussion touches upon a significant but often overlooked benefit of the v3 change: the ability to pay on-chain fees directly from the channel balance, enhancing the overall efficiency and user experience of the Lightning Network.