Published on: 2019-05-27T01:26:01+00:00
Rusty Russell, a Bitcoin developer, and Anthony Towns are engaged in a discussion about the safety of ANYPREVOUT. Rusty suggests renaming it to SIGHASH_UNSAFE_ANYPREVOUT and adding a warning about its unsafe nature for general wallet usage. On the other hand, Anthony argues that if something requires a warning, it should not be included in the consensus layer and suggests finding a way to make ANYPREVOUT safe enough without scary warnings.Rusty believes that funds are safe in Bitcoin as long as they are held in a cryptographically secured UTXO and under sufficient proof of work. He theorizes that if individuals only use ANYPREVOUT to sign transactions that pay the money back to themselves, their funds will remain safe. However, Rusty's concern is sharing with an untrusted party, which he deems insecure without further complex arrangements.Rusty expresses his concerns over the risk to non-ANYPREVOUT using transactions, marking it as a bad idea but concludes that it is not the case. He also highlights the concern of accidentally using ANYPREVOUT, which he believes is unlikely since keys need to be marked now. Furthermore, he mentions the concern of using correctly but nasty gotchas, which is inherent in rebinding. However, this concern is addressed by Don't Reuse Addresses.Rusty suggests changing the bip introduction to explicitly state that "THESE SIGNATURE HASHES ARE UNSAFE FOR NORMAL WALLET USAGE" and renaming it SIGHASH_UNSAFE_ANYPREVOUT. He also expresses discomfort with the new power in Bitcoin called rebinding but insists on supporting objections with facts.Anthony Towns shares a follow-up BIP draft that enables SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT on top of taproot/tapscript. Rusty shows interest in the proposal but suggests eliminating the chaparone signature requirement. He provides four reasons why he believes the benefits of chaparones do not justify enshrining their complexity into the protocol.The author of the BIP draft expresses less confidence in ANYPREVOUT's readiness for implementation and deployment than in taproot's. The author suggests requiring an additional regular signature to accompany every ANYPREVOUT signature to limit possible negative impacts. However, they acknowledge that this assumption may not survive adversarial reality.The BIP draft and a sample implementation based on the taproot branch are available via links provided by the author. The implementation includes interesting features such as upgrading tapscript's existing opcodes for new SIGHASH methods or potentially introducing a new signature scheme or elliptic curve. Two variants of ANYPREVOUT, ANYPREVOUT and ANYPREVOUTANYSCRIPT, are described, which seem useful for eltoo. Lastly, the BIP attempts to describe the security implications of ANYPREVOUT-style signatures.
Updated on: 2023-08-02T00:51:13.043485+00:00