Author: Anthony Towns 2018-05-14 09:23:29
Published on: 2018-05-14T09:23:29+00:00
The discussion is about the risk of adding NOINPUT to Bitcoin's code. The concern is that if the same key is used for multiple inputs and one of them is signed with NOINPUT, all of them are spent which can lead to losing other coins as well. It was suggested to drop support for SIGHASH_NONE or limit it similarly to limiting SIGHASH_NOINPUT. Taproot and graftroot scripts have the same tradeoffs as NOINPUT. A new segwit version with taproot that includes an opcode was proposed. Two sorts of addresses can be generated from a public key X: addresses where you spend each coin individually, and different addresses where you spend the wallet of coins with that public key at once. It is more reasonable to worry about signing with NOINPUT compared to SIGHASH_NONE because if you want to use lightning v2, your wallet will be signing things with SIGHASH_NOINPUT. Finally, the benefit of a separate opcode is support can be soft-forked in independently of a new segwit version.
Updated on: 2023-05-20T08:09:31.189517+00:00