> >>> the fact that we do this has a rather odd result: a transaction spending a >>> witness output with an unknown version is valid even if the transaction >>> doesn’t have any witnesses! >> >> I don’t see any reason to have such check. We simply leave unknown witness >> program as any-one-can-spend without looking at the witness, as described in >> BIP141. > > It will lead to a special case in code that does things with witness > transactions, as we can spend a witness output without a witness.
It is trivial to softfork a new rule to require the witness must not be empty for a witness output. However, does it really make the code simpler? > > Thus you could summarize the argument for the P2PKH special case as "We don't > want to make it possible to use 160-bit commitments for multisig, which > _might_ > need 256-bit security. But we do want to special-case pubkeys to save a few > bytes.” Actually I would like to see even shorter hash and pubkey to be used. Storing 1 BTC for a few months does not really require the security level of P2PKH. > >>> we haven’t explicitly ensured that signatures for the new signature hash >>> can’t be reused for the old signature hash >> >> How could that be? That’d be a hash collision. > > Nope. The problem is it might not be a hash collission, if the actual bytes > signed can be interpreted in two different ways, by different types of > signature hashes. > > This is the same reason the signmessage functionality prepends the message > being signed with the "Bitcoin Signed Message:\n" magic string. > In BIP143 sig, first 4 bytes is nVersion, and the next 32 bytes (hashPrevouts) is a hash of all prevouts. (in the case of ANYONECANPAY, the bytes following would be zero, as you proposed) In the original sig, first 4 bytes in nVersion, next 4 bytes is number of inputs, and the next 32 bytes is a txid. For a signature to be valid for both schemes, the last 28 bytes of the hashPrevouts must also be the first 28 bytes of a valid txid. This is already impossible. And this is just one of the many collisions required. In such case SHA256 would be insecure and adding a zero after the nVersion as you suggest would not be helpful at all.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
