This is a meta-discussion for any approach that allows the witness committing 
to only transaction outputs, but not inputs.

We can already do the following things with the existing bitcoin script system:
* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with 
* commit to only inputs but not outputs: SIGHASH_NONE with optional 
* not commit to any input nor output: not using any sigop; using a trivial 
private key; using the SIGHASH_SINGLE bug in legacy script

The last one is clearly unsafe as any relay/mining node may redirect the 
payment to any output it chooses. The witness/scriptSig is also replayable, so 
any future payment to this script will likely be swept immediately

SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but the 
signature is not replayable

But it’s quite obvious that not committing to outputs are inherently insecure

The existing system doesn’t allow committing only to outputs, and we now have 3 
active proposals for this function:


With outputs committed, redirecting payment is not possible. On the other hand, 
not committing to any input means the witness is replayable without the consent 
of address owner. Whether replayability is acceptable is subject to 
controversy, but the ANYPREVOUT proposal fixes this by requiring a chaperone 
signature that commits to input. However, if the rationale for chaperone 
signature stands, it should be applicable to all proposals listed above.

A more generic approach is to always require a “safe" signature that commits to 
at least one input. However, this interacts poorly with the "unknown public key 
type” upgrade path described in bip-tapscript 
<>), since 
it’d be a hardfork to turn an “unknown type sig” into a “safe sig”. But we 
could still use a new “leaf version” every time we introduce new sighash types, 
so we could have a new definition for “safe sig”. I expect this would be a rare 
event and it won’t consume more than a couple leaf versions. By the way, 
customised sighash policies could be done with CAT/CSFS.
bitcoin-dev mailing list

Reply via email to