Published on: 2020-08-11T00:14:29+00:00
In a recent conversation on the Bitcoin-dev mailing list, Matt Corallo discussed the potential of a relay network that could handle transactions with SIGHASH_ANYPREVOUT. This network would need to rewrite transactions before passing them on to a local bitcoind. The idea is that a sender could relay a transaction with one input that is valid for any output index 0 in a transaction spending output B. The receiver would then look up which transaction spends output B and fill in the input with that outpoint.Richard Myers asked if such a relay network could be more "smart about replacement" in the context of ANYPREVOUT by RBF-ing parts of a package. Matt responded that SIGHASH_NOINPUT would simplify these issues if nodes could be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. However, shoving this complexity into the Bitcoin P2P network may not be feasible. Instead, a relay network of lightning nodes could potentially handle the calculation and pass the transactions to their local full nodes.In the context of ANYPREVOUT*, a special relay network could be more intelligent about replacement. This would involve relaying only the higher up-front fee-rate transactions from a lower total fee package (Package B) which get spent by the high absolute fee child transactions from a higher total fee package (Package A). The result is Package A', which includes the higher fee rate versions of the ANYPREVOUT* transactions from Package B, but with an overall lower total fee. However, implementing this solution requires nodes to be "smart" about replacement when they see a SIGHASH_NOINPUT spend which can spend an output that something else in the mempool already spends.The conversation between Matt and ZmnSCPxj revolves around a relay-based attack that can compromise HTLC security in the Lightning Network. The attacker connects twice to the LN - once to any node near the victim and once to the victim. The attacker arranges for the victim-attacker channel to have most funds on the victim's side and routes a circular payment terminating in the victim-attacker channel. The attacker broadcasts a very low-fee old-state transaction of the victim-attacker channel just before the HTLC timeout, forcing the victim to broadcast a unilateral close attempt for the victim-attacker channel to enforce the HTLC on-chain. However, relay shenanigans prevent the latest commitment from being broadcast, leaving the victim at risk.ZmnSCPxj suggests that forwarding nodes drop channels on-chain "early" if the HTLC will time out soon. Matt notes that SIGHASH_NOINPUT makes these issues much simpler to address if nodes can be "smart" about replacement when they see a SIGHASH_NOINPUT spend that can spend an output already spent by something else in the mempool. They also discuss the possibility of an overlay relay network of lightning nodes that do calculation and pass transactions to their local full nodes.Christian discusses a feasible attack that can be executed without the victim's knowledge in a Lightning universe primarily utilizing SIGHASH_NOINPUT-based mechanisms. He suggests monitoring on-chain events and ignoring mempool events to react to confirmed transactions. To ensure security, deep timeouts for mechanisms are necessary so that a SIGHASH_NOINPUT signature can be "locked" to a confirmed txid, unless a reorg unconfirms the transaction. Additionally, implementing scorch-the-earth, keep-bumping-the-fee strategies can help keep rebroadcasting new versions of the spending transaction.In the context of recent relay-based attacks, there have been concerns about the security of Hash Time-Locked Contract (HTLC) transactions. ZmnSCPxj raises a design consideration for the p2p protocol layer that would allow relaying a transaction to a full node without knowing which input transaction that full node has in its mempool or active chain. This is important for systems like lighting where you may 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 them nonetheless.Richard expresses his interest in implementing a Taproot version of Decker-Russell-Osuntokun (eltoo) and discusses the differences between ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and their exploitation. ZmnSCPxj provides clarifications on key-path spending, reducing the round trips for MuSig signing sessions, and the security implications of chaperone signatures for SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. They also discuss the implementation of scorch-the-earth, keep-bumping-the-fee strategies.In another email thread, Anthony Towns opens a draft pull request to update BIP 118 with the ANYPREVOUT bip, including significant changes since previous discussions.
Updated on: 2023-08-02T02:29:39.241532+00:00