Published on: 2016-02-29T00:25:53+00:00
In a discussion on the Bitcoin-dev mailing list, developers are considering a new feature that would allow for outsourced monitoring of Lightning network channels. This feature would involve three transactions: an anchor transaction, a commitment transaction, and a penalty transaction. The commitment transaction includes multiple payments and HTLCs to different parties, while the penalty transaction enables one party to take 99% of the commitment transaction's value in case of foul play. However, outsourcing the monitoring of these channels would require sending a lot of data to the chain-monitoring service.To address this issue, Joseph Poon proposed the use of a SIGHASH flag called SIGHASH_NOINPUT. This flag would allow for the inclusion of the spent outpoint's script as part of the signature, without including the outpoint being spent or the amount. This proposed flag would make it possible to write fully malleability-proof wallet software. However, Poon emphasized that the flag should only be used in SegWit transactions, as SegWit provides sufficient malleability solutions. Implementing the flag in pre-SegWit transactions would complicate matters unnecessarily.The topic of SIGHASH flags was further discussed in an email conversation between Bryan Bishop and Joseph Poon. Bryan suggested considering other types of SIGHASH flags while drafting a BIP for the new flag. Poon agreed to review those proposals and expressed interest in hearing about other sighash flags if there were clear use cases for them. However, he also mentioned concerns about replay attacks when using SIGHASH_NOINPUT, stating that SegWit resolves malleability without worrying about such attacks.Another email chain between Gregory Maxwell and Joseph Poon focused on implementing a new SegWit script type that would include fees as part of the signature. This would prevent wallets from having to download input transactions and reduce the risk of users being exposed to replay attacks. They suggested naming the new flag SIGHASH_REPLAY_VULNERABLE to emphasize its importance.Poon also discussed the idea of adding a "without-inputs SIGHASH flag" to make it easier to create transactions that spend from the same inputs as other transactions. However, he warned about the potential for replay attacks and suggested deploying a fee-committing sighash-all option to protect users.In summary, developers are considering adding new SIGHASH flags to enhance the functionality and security of SegWit transactions. These flags would allow for outsourced monitoring of Lightning network channels, prevent the need to download input transactions, and protect against replay attacks. The design of SegWit was carefully crafted to allow for safe soft-forks for future script enhancements, and developers are cautious about making unnecessary changes beyond what is necessary for a safe deployment of SegWit.
Updated on: 2023-08-01T17:52:36.461912+00:00