Add BIPs 340-342 bip-schnorr, bip-taproot, bip-tapscript #876
Conversation
bip-schnorr/reference.py
Outdated
| def int_from_bytes(b): | ||
| return int.from_bytes(b, byteorder="big") | ||
|
|
||
| def hash_sha256(b): |
There was a problem hiding this comment.
I don't think this function is used anywhere in this script.
|
Does this suggest there will be a new address type? "Instead of using ''compressed'' 33-byte encodings of elliptic curve points which are common in Bitcoin today, public keys in this proposal are encoded as 32 bytes." |
|
@coinables the address type has already been defined by BIP173! Here's an example of a mainnet SegWit V1 (Taproot) address:
This encodes a witness version of |
Indeed but BIP84 does not seem to anticipate these successive versions? Or if it does, it does not contain examples or tests. |
|
@julien-boudry Funny I just asked on IRC about this. Both BIP84 and BIP49 define Extended Key prefixes ( |
|
I propose BIP numbers 200 for schnorr, 201 for taproot and 202 for tapscript |
|
@Relaxo143 BIP numbers 200-202 are already assigned. Please don't confuse people. |
|
These are:
|
luke-jr
changed the title
According to this page 199 is used and then 300+. That's why I suggested 200's. |
sipa
force-pushed
the
bip-taproot
branch
2 times, most recently
from
ebb95d2
to
4380e26
Compare
|
@luke-jr Any idea what I'm doing wrong? The Travis message seems unrelated to my changes. |
sipa
force-pushed
the
bip-taproot
branch
2 times, most recently
from
7209c4d
to
14273ed
Compare
Includes squashed contributions by GitHub users jonasnick, real-or-random, AustinWilliams, JustinTArthur, ysangkok, RCassatta, Sjors, tnakagawa, and guggero.
…of 'message hash'
Though perhaps, the emphasis is warranted given its importance. :-)
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>
Co-Authored-By: Tim Ruffing <tim@timruffing.de>
- 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
sipa
force-pushed
the
bip-taproot
branch
3 times, most recently
from
4e623b9
to
a92523e
Compare
|
Don't merge yet, somehow not all BIP links are rendered correctly. I don't understand why some work and others don't... |
sipa
force-pushed
the
bip-taproot
branch
3 times, most recently
from
eb5723c
to
1ad8242
Compare
|
All links fixed. |
| === Design === | ||
|
|
||
| '''Schnorr signature variant''' Elliptic Curve Schnorr signatures for message ''m'' and public key ''P'' generally involve a point ''R'', integers ''e'' and ''s'' picked by the signer, and the base point ''G'' which satisfy ''e = hash(R || m)'' and ''s⋅G = R + e⋅P''. Two formulations exist, depending on whether the signer reveals ''e'' or ''R'': | ||
| # Signatures are pairs ''(e, s)'' that satisfy ''e = hash(s⋅G - e⋅P || m)''. This variant avoids minor complexity introduced by the encoding of the point ''R'' in the signature (see paragraphs "Encoding R and public key point P" and "Implicit Y coordinates" further below in this subsection). Moreover, revealing ''e'' instead of ''R'' allows for potentially shorter signatures: Whereas an encoding of ''R'' inherently needs about 32 bytes, the hash ''e'' can be tuned to be shorter than 32 bytes, and [http://www.neven.org/papers/schnorr.pdf a short hash of only 16 bytes suffices to provide SUF-CMA security at the target security level of 128 bits]. However, a major drawback of this optimization is that finding collisions in a short hash function is easy. This complicates the implementation of secure signing protocols in scenarios in which a group of mutually distrusting signers work together to produce a single joint signature (see Applications below). In these scenarios, which are not captured by the SUF-CMA model due its assumption of a single honest signer, a promising attack strategy for malicious co-signers is to find a collision in the hash function in order to obtain a valid signature on a message that an honest co-signer did not intent to sign. |
There was a problem hiding this comment.
nit: "did not intend to sign"
| </ref> and ''has_square_y(P)''<ref> | ||
| If ''P := lift_x(x)'' does not fail, then ''y := y(P) = c<sup>(p+1)/4</sup> mod p'' is square. Proof: If ''lift_x'' does not fail, ''y'' is a square root of ''c'' and therefore the [https://en.wikipedia.org/wiki/Legendre_symbol Legendre symbol] ''(c / p)'' is ''c<sup>(p-1)/2</sup> = 1 mod p''. Because the Legendre symbol ''(y / p)'' is ''y<sup>(p-1)/2</sup> mod p = c<sup>((p+1)/4)((p-1)/2)</sup> mod p = 1<sup>((p+1)/4)</sup> mod p = 1 mod p'', ''y'' is square. | ||
| </ref>, or fails if no such point exists. The function ''lift_x(x)'' is equivalent to the following pseudocode: | ||
| *** Let ''c = x<sup>3</sup> + 7 mod p''. |
There was a problem hiding this comment.
Should this be ''c = (x<sup>3</sup> + 7) mod p''?
There was a problem hiding this comment.
Generally when a "mod a" is written after an expression it means all operations are mod a.
This adds the 3 BIPs that describe the consensus rules and (basic) wallet operation for the Taproot proposal (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html). There have been several discussions on the mailing list on the original idea, and this proposal specifically, including ones that resulting in significant changes being made to the proposal. Furthermore, a structured review session (https://github.com/ajtowns/taproot-review) with many participants was held, resulting in many comments and improvements.
I believe it's time to actually publish them as BIPs.
An (unreviewed) reference implementation is available (https://github.com/sipa/bitcoin/commits/taproot), which I'll open as a (WIP) PR as soon as there are BIP numbers to refer to.