New answers tagged taproot
3
As far as I can tell, P2TR is better than P2WSH in almost every way. I cannot think of a case in which it would be a significant advantage to use P2WSH over P2TR, except that P2WSH is already established.
Privacy
P2TR outputs will stand out at first since there will be few of them. In the long term, the anonymity set of P2TR is likely to be larger since both ...
0
Thanks to darosior for answering this on IRC.
You can obtain the checksum using:
bitcoin-cli getdescriptorinfo insert_descriptor_here.
This outputs the descriptor with the checksum appended at the end under "descriptor" and a separate "checksum" field with the checksum on its own.
{
"descriptor": "tr(...
1
Public keys are not hashed in Taproot (SegWit v1). The Taproot (Merkle) tree in the script path uses hashes but the Merkle root of this tree tweaks the unhashed public key (internal key) and the resulting tweaked public key is not hashed either. For more details on why see the reference 2 in BIP 341.
4
Taproot inputs are smaller but outputs are larger. Specifically, P2WPKH (Native SegWit) inputs and outputs take 67.75 and 31 vbytes in a transaction, respectively, while P2TR (Taproot) inputs and outputs take 57.25 and 43 vbytes, respectively. In terms of fees this makes Taproot transactions about 1.5% more expensive when you don't use multisig or scripting.
...
0
No SegWit version 1 (Taproot) doesn't support ECDSA signing at all. All signatures must be Schnorr to take advantage of the various benefits of Schnorr signatures e.g. batch verification. (Obviously SegWit version 0 still supports ECDSA and will continue to do so but SegWit version 0 doesn't support Taproot trees/MAST.) Pieter Wuille added on IRC that the ...
0
You can do either. Putting the hash of the single script (hash_TapLeaf) instead of the Merkle root makes it cheaper to spend as you don't need to reveal other hashes to prove that script is present in the Merkle tree. However, if you want to obscure the fact that there was only a single script path in the Merkle tree on spending (and are willing to pay a ...
0
This is a draft answer and may contain inaccuracies. I will update if it does.
It is worth noting that it is looking likely that Taproot will be active on mainnet in November 2021 but until then Taproot rules will not be enforced on the network. Any attempted Taproot spends before then will be treated as anyone-can-spend by the network.
Bitcoin Core v0.21.1 ...
0
See Pieter's responses.
(1) seems ok
(2) Mark's concern is real, but worry about exposing the tweaked pubkey doesn't seem to be of a high concern to people supporting Taproot. In ref to Taproot exposing pubkey, "numerous advantages (it's smaller, cheaper, and makes a number of more advanced protocols on top a lot easier)."
"TL;DR: public keys ...
2
The foundation of a channel is a multisig output which can't be distinguished from other outputs when using musig and taproot.
The mutual channel close is just a regular tx spending this output so I'd say it'll be hard to detect this as a lightning Chanel without other data (similar as with current channels)
However the unilateral close is different and ...
4
In addition to what Rene wrote, the adoption of Taproot will provide many bitcoin user's with a higher degree of privacy.
The structure of a bitcoin transaction can contain clues about the nature of that transaction. By using certain heuristics, anyone watching the blockchain record can group together certain transactions and addresses, to attempt to ...
5
Bitcoin transactions require a certain size and with taproot and tapscript we can decrease that size.
This means that effectively we will be able to store more transactions in one block allowing overall a slightly higher throughput of bitcoin transactions in the network.
So even if you continue to use legacy transaction formats you might still benefit from ...
Top 50 recent answers are included
