Published on: 2017-11-15T10:37:22+00:00
During a conversation between Tomas and Rusty Russell, the issue of malleation in commitment transactions was discussed. This problem affects every commitment transaction that uses HTLC transactions. Rusty suggested that SIGHASH_NOINPUT could be used as a workaround for this issue. However, he noted that separate keys are required on every output to ensure that transactions cannot be connected to the wrong outputs.Tomas questioned whether the current specification already ensures that every key is only used once. Rusty clarified that while this is true for different commitment transactions, it is not the case for different HTLC outputs attached to the same transaction. Rusty further explained that SIGHASH_NOINPUT can reduce the number of updates by about a factor of 2 under typical use. It is generally considered beneficial to have, but it becomes extremely dangerous if keys are reused. If addresses are reused, a signed SIGHASH_NOINPUT input can be attached to either one, which may or may not be a problem depending on the exact usage.In another discussion between Rusty Russell and Tomas, malleation was identified as a problem for every commitment transaction. To address this issue, HTLC transactions are used. SIGHASH_NOINPUT could also be used to work around malleation by allowing updates to dependent transactions. However, separate keys on every output are needed to prevent transactions from being connected to the wrong outputs. The current specification already ensures that every key is only used once, reducing the number of updates by about a factor of 2 under typical use, and even more under unusual conditions. However, it is important to avoid reusing keys when using SIGHASH_NOINPUT to prevent potential dangers.The writer of a proposal on the bitcoin-dev mailing list has raised some questions regarding the use of SIGHASH_NOINPUT. They inquire if LN's malleated transaction problem is limited to the punishment transaction that spends an unconfirmed transaction, and if LN could still function without SegWit if SIGHASH_NOINPUT were in place. The writer also asks if other solutions have been presented to prevent excessive recreation and routing of punishment transactions to 3rd party monitoring services, or if SIGHASH_NOINPUT remains the best option. They also inquire about any ongoing work in this area.In response to these questions, it is explained that malleation is indeed a problem for every commitment transaction, including HTLC transactions. SIGHASH_NOINPUT can be used as a workaround by allowing updates to dependent transactions. However, separate keys are necessary on every output to ensure that transactions cannot be connected to the wrong outputs. While SIGHASH_NOINPUT is generally considered beneficial, it becomes extremely dangerous if keys are reused. Under typical use, SIGHASH_NOINPUT can reduce the number of updates by about a factor of 2, and even more under unusual conditions. This means that instead of needing a new HTLC transaction, the existing one can simply be reattached.Tomas van der Wansem from bitcrust has raised some questions regarding the proposal to use SIGHASH_NOINPUT on the bitcoin-dev mailing list. He asks if LN's malleated transactions are limited to the punishment transaction and whether LN could still function without SegWit if SIGHASH_NOINPUT were implemented. He also questions the importance of using SIGHASH_NOINPUT to prevent excessive recreation and routing of punishment transactions to 3rd party monitoring services, and whether alternative solutions have been proposed. Finally, Tomas inquires about any ongoing work related to this matter.
Updated on: 2023-07-31T19:25:47.451858+00:00