* [bitcoin-dev] Taproot updates
@ 2019-10-09 21:34 Pieter Wuille
0 siblings, 0 replies; only message in thread
From: Pieter Wuille @ 2019-10-09 21:34 UTC (permalink / raw)
To: Bitcoin Dev
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-10-09 21:34 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09 21:34 [bitcoin-dev] Taproot updates Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox