From: Pieter Wuille <pieter.wuille@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Taproot updates
Date: Wed, 9 Oct 2019 14:34:32 -0700 [thread overview]
Message-ID: <CAPg+sBi9CYyz7O3ToEvoDwEbykUZAW2A-jwuR0aAA769Pb0=tA@mail.gmail.com> (raw)
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
reply other threads:[~2019-10-09 21:34 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPg+sBi9CYyz7O3ToEvoDwEbykUZAW2A-jwuR0aAA769Pb0=tA@mail.gmail.com' \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox