Bitcoin is the most popular and popular cryptocurrency, but as the network grows in popularity, so does the speed and fees of transactions, and the associated privacy and security concerns are becoming more concerning.
In order to improve the privacy, scalability, and smart contract processing capabilities of the Bitcoin network, the Bitcoin Taproot upgrade was officially activated at the end of 2021, and the upgrade consists of three major Bitcoin Improvement Proposals (BIPs): Schnorr Signature (BIP 340), Taproot (BIP 341), and TapScript (BIP 342).
Among them, BIP 341 defines a new way to send bitcoin - Pay-to-Taproot (P2TR), which combines the functionality of Pay-to-Public-Key (P2PK) and Pay-to-Script-Hash (P2SH) scripts to provide users with great flexibility and privacy benefits.
P2TR is essentially a ScriptPubKey that locks Bitcoin onto a script that allows users to pay the Merkle root of the Schnorr public key or various other scripts. Ostensibly, a P2TR output locks Bitcoin to a Schnoorer public key, which we assume is Q. However, this public key Q is actually the sum of a public key P and a public key M, which is computed by the Merkle root of the other ScriptPubKeys lists.
The bitcoins in the P2TR output can be spent either by issuing the signature of the public key P, which is called the key path, or by satisfying one of the scripts contained in the Merkle tree, which is called the key path, and the latter being the script path. While there may be many ways to output P2TR, only the one that is used will be made public, which will keep it private for other unused alternatives.
In addition, due to the Schnorr key aggregation feature, the public key P itself can be an aggregate key, and the state of the public key P as an aggregate key or a single key is never revealed, because all P2TR outputs are similar to each other, which will break many chain analysis heuristics and enhance user privacy.
In addition to Pay-to-Taproot (P2TR), there are four common payment methods in the Bitcoin network: Pay-to-Public-Key-Hash (P2PKH), Pay-to-Witness-Public-Key-Hash (P2WPKH), Pay-to-Script-Hash (P2SH), and Pay-to-Witness-Script-Hash ( P2WSH), each of these payment methods has different characteristics and application scenarios.
P2PKH
Pay-to-Public-Key-Hash (P2PKH) is a ScriptPubKey that locks Bitcoin on a hash of a public key (Bitcoin address). For example, Alice wants to send 1 BTC to Bob in a P2PKH transaction, Bob provides Alice with an address in his wallet, and Bob's address is included in the transaction. When Bob tries to spend the bitcoins he receives, he must sign the transaction with the private key that corresponds to the public key, which is hashed to match the hash provided in Alice's transaction.
P2WPKH
Pay-to-Witness-Public-Key-Hash (P2WPKH) is a ScriptPubKey that is used to lock bitcoins to a SegWit address. The P2WPKH transaction is similar to the P2PKH transaction in most ways, it still locks the Bitcoin to the hash of the public key, with the main difference being that P2WPKH uses SegWit. This means that all input ScriptSig (the script that unlocks Bitcoin) is removed from the transaction body and enters the witness section, and is called a script witness. This data is still recorded on the blockchain, but the fees generated for the data will be lower than regular data, making SegWit transactions cheaper than regular transactions.
P2SH
Pay-to-Script-Hash (P2SH) is a ScriptPubKey that is primarily used in multisig wallets to make output script logic and check for multisig before accepting transactions. For example, if Alice sends 1 BTC to Bob in a P2SH transaction, she will include the hash of the script needed to spend Bitcoin in the transaction. This script may require Bob's private key and/or the signature of many others. When Bob wants to spend the bitcoins he received from Alice, he reconstructs the hash of the script that Alice used to send the bitcoins and signs the transaction with whatever private key the script requires. P2SH is very flexible because it allows users to build arbitrary scripts. In addition, the sender of the transaction does not need to know what type of script they are sending to. In the example above, Bob can build the script he wants offline and only send Alice a hash of that script, keeping more privacy for Bob.
Pay-to-Witness-Script-Hash (P2WSH) is a transaction type that is similar to P2SH transactions in most ways, except that it uses SegWit. Like P2SH transactions, P2WSH transactions lock bitcoins to a hash of the script. In order to spend this bitcoin, the spender must present a script called RedeemScript and any required signatures. On a technical level, P2WSH actually describes the ScriptPubKey used to lock Bitcoin to the SegWit script hash.
By comparing the different types of signature sizes, it can be seen that using P2TR on a single signature is a bit larger than an equivalent P2WPKH, but a closer look reveals that there are many benefits to using P2TR for single-signature wallet users and the network as a whole:
At the investment level, it costs about 15% less to spend a single-signature P2TR UTXO than to spend a P2WPKH UTXO. An overly simplistic analysis like the table above hides a detail that the spender can't choose the address they're asked to pay for, so if you stay on P2WPKH and everyone else upgrades to P2TR, the actual typical size of your 2-in-2-out transaction will be 232.5vbytes, while all P2TR transactions will still only be 211.5vbytes.
While early adopters lose some privacy when they switch to the new script format, users who switch to Taproot also get an immediate boost in privacy. Your transactions will be able to look no different from those working on new LN channels, more efficient DLCs, secure multi-signatures, various clever wallet backup and recovery schemes, or a hundred other groundbreaking developments. Single-signature with P2TR now also allows your wallet to upgrade to multi-signature, Tapscripts, LN support, or other features at a later date without compromising the privacy of your existing users. It doesn't matter if the old or new version of the software receives the UTXO – both UTXOs will look the same on-chain.
Since the rediscovery of the Fee Overpayment Attack, some hardware signing devices have refused to sign a transaction unless each UTXO spent in that transaction has metadata that contains a copy of a significant portion of the entire transaction that produced that UTXO. Taproot, on the other hand, eliminates the potential vulnerability of overpayment attacks, so it can significantly improve the performance of hardware signers.
ECDSA signatures for P2PKH and P2WPKH UTXOs can have different sizes, and since wallets need to choose the rate of the transaction before creating the signature, most wallets just assume the worst-case signature size, so they will pay slightly more when accepting smaller signatures. Whereas for P2TR, the size of the signature is known in advance, allowing the wallet to choose a precise rate.
The overall security of Bitcoin depends on the majority of Bitcoin users using their own nodes to verify every confirmed transaction, including the transactions created by your wallet. Taproot's schnorr signatures can be effectively used for batch verification, and the CPU cycles required for nodes to verify signatures are reduced by about 1/2 during the process of synchronous blocks. Even if you reject all of the above benefits, consider using Taproot to help run a full node.
For wallets that already support receiving and spending v0 segwit P2WPKH output, upgrading to v1 segwit P2TR for single signing should be easy, here are the main steps:
It is highly recommended to use a new derivation path (e.g. defined by BIP86) for the P2TR public key, which can be attacked if you use the same key in both ECDSA and schnorr signatures.
While a single signature is not technically required, especially if all of your keys are from a randomly selected BIP32 seed, BIP341 recommends submitting your keys to a non-consumable scripthash tree. It's as simple as using elliptic curve addition, adding your public key to the curve points of the hash of that key. The benefit of following this advice is that if you add support for scriptless multi-signature in the future, or add support for tr() descriptors, you will be able to use the same code.
Use bech32m to create your address. The payment will be sent to the scriptPubKey OP_1. You can use any method used to scan v0 SegWit addresses (e.g. P2WPKH) to scan transactions for payment scripts.
All of Taproot's non-witness fields are the same as P2WPKH's, so you don't need to worry about changes to transaction serialization.
It's a promise of data for spending transactions. Most of the data is the same as the data you signed for the P2WPKH exchange, but the order of the fields is changed and there are a few extra things that are signed. Achieving this is just a matter of serializing and hashing all sorts of data, so writing code should be easy.
There are many different ways to create Schnorr signatures. So the best approach at the moment is not to "roll out your own methods", but to use features from a highly vetted library that you trust. However, if you can't do that for some reason, BIP340 provides an algorithm that should be easy to implement if you already have the foundation for making ECDSA signatures. When you have your signature, put it in the entered witness data and send your payout transaction.
Overall, P2TR not only simplifies the transaction process and enhances user privacy, but also allows for flexible payment methods and more complex smart contract execution. Bitcoin's Layer2 solution, BEVM, takes full advantage of this by making Taproot one of the core architectures of its "Taproot Consensus" technology, bringing the Bitcoin network's privacy, scalability, and smart contract processing capabilities to new heights.
In BEVM, all transactions are in P2TR format, which means that every transaction benefits from lower fees, better privacy protection, and friendly support for hardware-signed devices. In addition, BEVM leverages P2TR's key path and script path features to ensure the privacy and security of transactions while improving the scalability of the network. Through these technologies, the BEVM project has successfully built a more reliable smart contract platform within the Bitcoin ecosystem, promoting the further development of the entire ecosystem.
