What is the current status of Schnorr signatures, MAST, Taproot and Graftroot

[Andriian]

Hi. It seems that there were no discussions specific to the subject for the last year. So would like to collect a summary regarding the following

• Current status of corresponding BIPs and its development
  
• Any kind of technical or economical obstacles for including into Bitcoin Core release
  
  • New opportunities for business and users if that is released
    
  Thank you.

[1714826474]

1714826474

[1714826474]

1714826474

[1714826474]

1714826474

[1714826474]

1714826474

[ABCbits]

Hi. It seems that there were no discussions specific to the subject for the last year. So would like to collect a summary regarding the following

There are few threads discuss those improvement you mentioned, such as :
MuSig: Schnorr Multisig and signature aggregation
Taproot proposal
[Schnorr] Should batched verification result in reduced weight per sig?

• Current status of corresponding BIPs and its development
  
• Any kind of technical or economical obstacles for including into Bitcoin Core release
  

I don't join Bitcoin dev mailing or Bitcoin IRC channel, so i can't answer this one.

• New opportunities for business and users if that is released
  

Since all of those improvement offer reduced transaction size and privacy to some degree (except for Graphtroot which i never heard), there are few obvious opportunities :
1. Spend less Bitcoin for transaction fees
2. Prevent release whole script when spend UTXO (on MAST & Taproot)
3. Allow more transaction fit into a block due to reduced transaction size
4. Prevent de-anonymization by analyzing transaction (on Schnorr & Taproot)
5. Improve privacy for those who use mixers and CoinJoin

P.S. it's only high level overview

[Andriian]

Since all of those improvement offer reduced transaction size and privacy to some degree (except for Graphtroot which i never heard), there are few obvious opportunities :

That was my misspelling. Graftroot is correct one. Here is Gregory Maxwell's proposal for it https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015700.html

P.S. Have fixed subject in the initial message as well

[achow101]

The taproot and schnorr proposed BIPs are still being worked on. Recently there has been discussion on the mailing list on using just 32 byte public keys rather than using the standard 33 byte public keys.

There are implementations of taproot and schnorr in one of sipa's branches but he has not yet opened a PR to merge them into Core. The proposed BIPs also do not have a BIP number yet as they are still in flux.

Graftroot does not yet have a proposed BIP.

[pooya87]

Recently there has been discussion on the mailing list on using just 32 byte public keys rather than using the standard 33 byte public keys.

is something different with Schnorr regarding signature verification using public key?
i don't have any code to test ECSDSA but i could check ECDSA and in there you can't use -P for verification or it fails.
in other words if we use 32 byte public keys then we have no way of knowing which Y is the correct answer, as a result we would have 2 public key points (P and -P) one of which fails the verification.
so how did the discussion solve this?

[achow101]

is something different with Schnorr regarding signature verification using public key?
i don't have any code to test ECSDSA but i could check ECDSA and in there you can't use -P for verification or it fails.
in other words if we use 32 byte public keys then we have no way of knowing which Y is the correct answer, as a result we would have 2 public key points (P and -P) one of which fails the verification.
so how did the discussion solve this?

Given a public/private key pair, by negating the private key, you can obtain another public key that has the same X coordinate but a Y coordinate that is of opposite oddness. For example, if key k has a pubkey P where the Y coordinate is odd, then the key -k has a public key with the same X but the Y is even.

Knowing that, the solution is to dictate that all 32 byte public keys must use the even Y value. For signing, if the pubkey has an odd Y value, then the signer just negates the private key. For verifiers, when computing the Y value, they choose the even one.