[bitcoin-dev] Taproot updates

Hi all, I wanted to give an update on some of the changes we've made to the bip-schnorr/taproot/tapscript drafts following discussions on this list: * The original post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html and follow-ups * Using 2 or 4 byte indexes: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017046.html * 32-byte public keys: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html * Resource limits: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017306.html * P2SH support or not: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017297.html). We've made the following semantical changes to the proposal: * 32-byte public keys everywhere instead of 33-byte ones: dropping one byte that provably does not contribute to security, while remaining compatible with existing BIP32 and other key generation algorithms. * No more P2SH support: more efficient chain usage, no gratuitous fungibility loss from having 2 versions, no mode limited to 80-bit security for non-interactive multiuser constructs; however senders will need bech32 support to send to Taproot outputs. * 32-bit txin position and codesep position indexes instead of 16-bits ones. * Tagged hashes also in bip-schnorr: the signature and nonce generation now also use tagged hashes, rather than direct SHA256 (previously tagged hashes were only used in bip-taproot and bip-tapscript) * Dropping the 10000 byte script limit and 201 non-push opcode limit: as no operations remain whose validation performance depends on the size of scripts or number of executed opcodes, these limits serve no purpose, but complicate creation of Scripts. * Increased the limit on the depth of Merkle trees from 32 to 128: a limit of 32 would necessitate suboptimal trees in some cases, but more than 128 levels are only necessary when dealing with leaves that have a chance of ~1/2^128 of being executed, which our security level treats as impossible anyway. See the updated documents: * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki In addition, a lot of clarifications and rationales were added. The reference implementation on https://github.com/sipa/bitcoin/commits/taproot was also updated to reflect these changes, has a cleaner commit history now, and improved tests (though those can still use a lot of work). Cheers, -- Pieter