Hot answers tagged

29

I am afraid the sent coins are irrevocably burned. The reason is that P2TR addresses encode a (tweaked) public key, while P2WSH addresses encode a script hash. If someone would take a P2TR address so that it is interpreted as a P2WSH address with the same payload, you'd need find a script that hashes to the public key in the P2TR address. This is completely ...


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


13

The first output of transaction b53e3bc5…5377f141 has the following scriptPubKey: OP_PUSHNUM_1 OP_PUSHBYTES_32 01010101…0101010101 The segwit softfork in 2017 defined versioning rules for all native segwit outputs, but only defined spending rules for version 0.¹ This output worth 5431 satoshis matches the native segwit schema, but the leading OP_PUSHNUM_1 ...


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

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

Taproot benefits everyone who uses it, but it has the most benefit to those who use complex scripts and multisigs. Since that group is a small portion of users of Bitcoin, that may be why some people are saying it is useful only to that small part of the population. However I would not characterize such statements as meaning Taproot is not useful to anyone ...


8

Beginning with Taproot? Hmm... Something about this feels scary to me. Your mistrust is misguided. So, they are no longer making "signed" installers? The releases are still signed with the release GPG key, what is lacking is the Windows specific binary signatures which have to be made by a paid certificate by one of several authorities Microsoft ...


7

TL;DR: depending on what you mean, there is probably no published scheme with a security proof, but there is hope for such a scheme. First, a few clarifications Aggregation is just a concept, not an actual protocol, and there are many ways of accomplishing that. It is made significantly simpler due to Schnorr's linearity property, but the security of a ...


6

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


6

Will Taproot allow me to skip Lightning Network and simply use pure Bitcoin Core? Well, Bitcoin Core doesn't support Lightning for now, and probably won't for the foreseeable future, but there is no reason why that can't change over time. I'm going to assume your question is: Will Taproot allow getting all the benefits the Lightning Network provides with ...


6

With respect to the original wording of the question I believe Taproot will actually make the Lightning Network pointfull instead of pointless. While Taproot allows us to save some space on the bitcoin base layer, it will not make the Lightning Network obsolete. Remember, the main issue with respect to on-chain scaling is that a protocol in which every ...


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


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

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

As far as I know, there is not even a published specification for MuSig2. One is being worked on at https://github.com/ElementsProject/secp256k1-zkp/blob/master/src/modules/musig/musig-spec.mediawiki, but it is incomplete and has no test vectors.


5

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

Yes, you can commit to data this way, but there is nothing special about Taproot here. The Pay-to-Contract construction used to tweak the root key in Taproot is generally usable, and has in fact been used for exactly this purpose. In fact, it is one of the mechanisms used in OpenTimestamps to commit to timestamped data (including a variant sign-to-contract ...


5

To add to Murch's answer: The output was created by Matthew Zipkin to test support for sending to SegWit v1 support on purse.io. This was done in the context of the Bitcoin Optech Compatibility Matix. Here is a screenshot of the purse.io withdrawal that was added in PR 303 to the Bitcoin Optech website.


4

In addition to the rationale given in BIP 341, I know of two arguments for not supporting P2SH-wrapped taproot outputs: backwards-compatibility: P2SH-wrapped segwit outputs were included in BIP 141 as a way to allow unupgraded wallets to send outputs to upgraded segwit wallets[0]. Segwit activation happened around 4 years ago, and almost all wallets/...


4

Hampus Sjöberg has set up a site (https://taproot.watch/) with a graphic for which blocks have signaled for Taproot activation and a breakdown by mining pools. It was announced here on Twitter. AJ Towns stated on Mastodon that once signaling starts the Bitcoin Core RPC getblockchaininfo will report the number of signaling blocks in the current period. David ...


4

Given Taproot is a soft fork and a consensus change I will assume you are interested in consensus changes rather than non-consensus changes. There are incremental privacy improvements being worked on in Bitcoin Core (e.g. transaction rebroadcasting, coin selection) that don't require consensus changes. In addition, there is a lot of work to do to take ...


4

Yes, the BIP340 signature scheme that was added to libsecp256k1 is an Elliptic Curve based variant of Schnorr signatures. Traditionally Schnorr signatures use a group of integer multiplication modulo a large prime, but that's not what is used here. It's integrated into libsecp256k1, because it is a Schnorr scheme over the secp256k1 group, so lots of code is ...


4

In general this shouldn't be a concern, as every script almost certainly contains at least a public key, and you can use fresh public keys in every branch. If you're still concerned about privacy of the revealed script, you can tweak the public keys in it manually with some secret that's shared between all participants (e.g. the hash of concatenation of all ...


4

That's exactly right. Compute the tweak H(P||c), compute the "public key" corresponding to that tweak, and then add (elliptic curve point addition) the internal public key with that tweak public key.


4

No, Taproot does not change how private keys and their corresponding public keys are generated. The same secp256k1 curve is used, and public keys are still points on that curve. What Taproot changes is the signature algorithm used for Taproot outputs and a few other script things. You can read the full specification in BIPs 340, 341, and 342.


4

When wondering if version X of software Y supports feature Z, I find it useful to search for "release notes" Y X https://bitcoin.org/en/releases/0.21.1/ Notable changes Taproot Soft Fork Included in this release are the mainnet and testnet activation parameters for the taproot soft fork (BIP341) which also adds support for schnorr signatures (...


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


3

There are two possible ways of spending a Taproot output: Through the key path: simply providing a BIP340 signature signing the spending transaction with the public key in the output. Through the script path: revealing that the output was in fact a tweaked key, by revealing the original and the tweak, and showing that this tweak commits to a script leaf. ...


3

with taproot we can create cancelable payments to mitigate a stuck onion. we can create multiparty Channels with less onchain footprint as only one aggregated signature is necessary (however it is a complex dataflow without eltoo) payment decorelation becomes possible via adaptor signatures. The payments secrets can change at every hop and thus payments at ...


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