Add BIPs 340-342 bip-schnorr, bip-taproot, bip-tapscript #876
Commits on Jan 19, 2020
-
Includes squashed contributions by GitHub users jonasnick, real-or-random, AustinWilliams, JustinTArthur, ysangkok, RCassatta, Sjors, tnakagawa, and guggero.
-
-
Clarify what 'reduced' means in tests and use word 'message' instead …
…of 'message hash'
-
Though perhaps, the emphasis is warranted given its importance. :-)
-
taproot_output_script: first returned byte should be OP_1 (0x51)
If we look at def IsPayToTaproot(script): return len(script) == 35 and script[0] == OP_1 and script[1] == 33 and script[2] >= 0 and script[2] <= 1 First byte is is checked for OP_1. OP_1 is 0x51 But the example code in this BIP returns `bytes([0x01, 0x21, output_pubkey[0] & 1]) + output_pubkey[1:]` First byte 0x01, but it should be 0x51 -
-
-
-
-
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
Update bip-schnorr/test-vectors.py
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Move plain public key in output rationale to design section
Rebased by Pieter Wuille
-
-
Rebased by Pieter Wuille
-
-
Removed reference to 0xc1 leaf version.
No longer necessary with 32B pubkeys.
-
-
-
-
-
-
-
-
-
-
Add taproot_tweak_pubkey and taproot_tweak_privkey functions to bip-t…
…aproot wallet section
-
Replace taproot_tweak_pubkey assertion with exception and add it to t…
…aproot_tweak_seckey too
-
-
Accept seckey in the form of bytes and not int in the reference BIP-s…
…chnorr code to match the spec.
-
-
-
-
-
-
-
-
-
-
Apply suggestions from code review
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
-
-
bip-schnorr: more on provable security
I'll try to get a link to the CCS paper that does not have a paywall...
-
-
-
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
-
-
-
Change reference for ECDSA proofs
Refer to Manuel Fersch's dissertation for provable security of ECDSA. It's freely accessible and multiple results put well in context.
-
-
-
-
-
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
-
-
-
use bytes() instead of b'' - avoid markdown issue
Currently github markdown renders `b''` inside `<source>` tags incorrectly. This makes `h = b''` show as `h = b` and creates some confusion. The issue can be avoided by using bytes() to create empty byte array
-
fix docstring in taproot_output_script
the final "-None" line in the docstring of `taproot_output_script` example function was actually outside of the docstring
-
-
-
-
Make more clear that signing function in test vectors generation code…
… isn't intended to be used anywhere else
-
-
-
-
fix: script spend, not key spend
For the key spend the script tree depth is not revealed, it is only done for script spends. This sentence makes sense only for the script spend.
-
-
-
-
BIP16 has no relation to bip-taproot/tapscript
Previously did.
-
-
remind reader where [:] is defined
in addition to `point`. This caused confusion for one reader who expected inclusive at end of range.
-
-
-
ADD: Require Schnorr BIP for Taproot
Per https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki: "BIPs may have a Requires header, indicating the BIP numbers that this BIP depends on"
-
-
-
-
Only first mention of each BIP is made into a link
-
bip-taproot: clarify bip-schnorr reference code
- update the paragraph in question to more clearly convey that the helper functions, and not the Python3 example code, are from the bip-schnorr reference code - add a link to the reference code in https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr/reference.py
-
-
In this context we are talking about the script branch, not the Merkle tree branch, right? If so, then this should clear things up a little.
-
-
-
Add missing dots that denote multiplication
Throughout the document, elliptic curve multiplication is denoted with dots, as in `d'⋅G` as opposed to `d'G`. This is not the case in one place in the 'Default Signing' section, and one place in 'Adaptor Signatures' section Missing dots are added for consistency.
-
-
-
-
-
-
-
-
-
-
Fix bip-schnorr footnote 7 by specifying that we're referring to P's …
…y coordinate and not some undefined 'x'
-
-
-
-
Link to proof sketch of security of implicit Y
Thanks to @ajtowns for providing the link
-
-
-
Replace BIP66 link with BIP146
BIP66 does not mention the inherent ECDSA malleability, but BIP146 does
-
-
-
-
Clarify why we don't want short hashes
This is supposed to supersede #158. I tried to say this carefully. I don't think that multiparty signing is in general broken with short hashes. For example the attack in #158 could be avoided by letting everybody not only commit to the nonce but also to the message. It's just that using a collision-resistant hash just eliminates the problem entirely...
-
-
-
-
-
-
Linearity makes sign-for-sum-of-keys easier, not possible entirely.
I'm sure it's possible to construct a complex MPC that can sign for the sum of keys under ECDSA as well.
-
Co-Authored-By: Tim Ruffing <crypto@timruffing.de>
-
-
-
-
-
more precise wording on limits
there are no tx or block size limits (post-Segwit), just block weight limit better wording
-
-
-
- Separate nonce generation into getting a random byte string and converting it to a suitable scalar ... - ... to make clear that the byte string can be generated differently. - Make the warning a little bit more prominent and improve writing
-
-
-
-
-
-
-
-
-
