Hot answers tagged

15

Before we start I realize your question is only about single-sig scenarios, and you want an answer focused on how validation works. I will address these things, but I think I need to elaborate a bit on how P2TR outputs are created, and how scripts fit in first, as I fear it'd be a lot more confusing otherwise. In what follows I'm going to make a ...


9

TL;DR: Wallets SHOULD allow sending to all bech32m addresses at this point, but wallets MUST NOT request P2TR outputs before the Taproot spending rules are enforced on the network¹. The design of segwit anticipated the lengthy process that is the adoption of optional features. Case in point, segwit activated in August 2017, yet Blockchain.com, a wallet ...


9

There is no ypub/zpub similar thing for Taproot. The recommendation is to use xpriv/xpub along with some extra information indicating that the script to create is Taproot, (e.g. with a tr() descriptor). This is because it is a layer violation to have the extended keypair indicate the script type to create. The keys should not and do not care about what ...


8

Taproot activated in block 709 632, but the first P2TR transactions were in block 709 635. A few P2TR transactions that may be useful for test vectors would be: 33e7…9036, the first P2TR transaction 3777…35c8, the first transaction with both a P2TR scriptpath and a P2TR keypath input 83c8…7d82 with multiple P2TR keypath inputs 905e…d530, the first ...


8

This functionality in the Bitcoin Core wallet has deliberately not been merged pre activation to prevent users from easily generating and giving out Taproot addresses prior to the Taproot rules being enforced. You can get around this by importing a Taproot descriptor into the wallet prior to this PR being merged as described here, here, here or here but that ...


6

Short answer: no, at least not via the key path (and using a script path would be less efficient than using P2WPKH instead) Longer answer: no, and even if it were possible, this would be a terrible idea. The address a receiver gives you is how they expect you to pay them. Giving them money by paying in a different way is not something you should expect them ...


6

Taproot inputs are smaller but outputs are larger. Specifically, P2WPKH (Native SegWit) inputs and outputs take 68 and 31 vbytes in a transaction, respectively, while P2TR (Taproot) inputs and outputs take 57.5 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. ...


6

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 ...


4

You can find the first on https://txstats.com/dashboard/db/utxo-set-repartition-by-output-type?orgId=1. For a version weighed by value you can look at the graphs of the individual output types on the same site.


3

How am I supposed to broadcast a Taproot transaction to older nodes when they won't accept it? You can't. You need to broadcast it to new nodes for it to propagate.


3

As Pieter said in the comments there are Taproot test vectors that have recently been merged into BIP 341. You can also find additional P2TR spends on signet, testnet on block explorers e.g. mempool.space. Any transaction that is spending from a tb1p address is a Taproot spend (tb1q is SegWit version 0 and tb1p is SegWit version 1 as discussed here). ...


3

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.


3

For a sender to send to a P2TR address pre activation they must have received that P2TR address from the receiver and so it would be an indirect safeguard to protect the receiver having given out P2TR addresses prematurely. The receiver's funds being vulnerable to being stolen pre activation isn't the sender's direct concern. There are already safeguards in ...


2

This is a draft answer (incomplete). To get set up on Signet ie sync the Signet chain and claim some Signet Bitcoin, follow these instructions. (You can run a Signet node in parallel with your mainnet node, ie same hardware) You now have funds at a non-P2TR (i.e. SegWit v0, bech32) Signet address. Now you need to generate a P2TR address to send funds to so ...


2

You are right. You could either use a leaf with a single aggregated key or a leaf with a more traditional multisig construction using OP_CHECKSIGADD. The advantage of the aggregated key is its smaller input saving fees. The disadvantage is that MuSig2 is an interactive protocol with multiple rounds which can be inconvenient if some of the signers are ...


2

BIP 341 (BIP-Taproot) discusses this example where you don't require the script path. If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path. The BIP also explains here the rationale for this. If the taproot output key is an aggregate of keys, there is the ...


2

While I think Pieter's answer provides exactly what you were asking for with the UTXO set repartition by output type, I think that you may also be interested in the Output Types by Count chart on transactionfee.info: The site has also more related charts that may be interesting in the context such as Input Types by Count Output Types by Value and various ...


1

TL;DR: A P2TR keypath input will weigh 57.5 vbytes. A P2TR scriptpath input will weigh a variable amount greater than that. Composition of a P2TR input Each input commits to spending a specific UTXO by providing its transaction outpoint: PREVOUT: hash (32 bytes) index (4 bytes) The scriptsig for a P2TR input is empty, however, the scriptsig length ...


1

On mainnet there are a number of P2TR transactions in block 709635. A few transaction IDs are included in the index of my bitcoin-dev mailing list post.


1

It depends on what you mean by public key. P2TR outputs encode an "x-only pubkey", that is a public key with just the X coordinate. The Y coordinate is implicitly the even one (on elliptic curve like secp256k1, every X coordinate has either exactly 2 corresponding Y coordinates, or none; and one of those two will always be odd, and one will be even)...


Only top voted, non community-wiki answers of a minimum length are eligible