Taproot proposal

[Wind_FURY]

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

no-one's voiced any objections up to now. You keep saying it's going to be a problem though, like maybe 5 times already?


why would anyone care about a new scripting type that prevents choices in those scripts from being written to the blockchain?

• everything that _actually_ happens is written to the blockchain, for all to see
• everything that _does not_ happen is unrecorded

I'd be fascinated to hear the arguments that could possibly be mounted against excising unused script paths from transactions, all it does is make multi-path scripts more economical. Secondary effects of this don't change the fact that the chosen script path is still publicly available.



ot: You're very negative/pessimistic these days WindFURY, are you feeling ok?

I'm never pessimistic about Bitcoin, but I don't trust the mining-cartel.

Or maybe I'm just excited for another drama, and proved right that full nodes control the consensus rules, not the miners.

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.

What are the miners proposing?

[Karartma1]

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.

Let's see what happens has a truly encouraging name 
Anyway, I asked this before and it would be nice to have an answer to see whether I got it right or not.

So let me see if I got this right: after Taproot is activated will it be possible to know if a payment is the opening/closing/mutual closing of LN channel? As far as I understand this, it will be impossible to distinguish if such payment is, let's say, me opening a LN channel. Which is cool.
Right?

Thanks

[gmaxwell]

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

[Karartma1]

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

Ok, cool. I will look into it more. However, the simple fact that openings and cooperative closures will be indistinguishable from ordinary single key payments is great in my opinion. That's a very good step forward. Eagerly waiting for it. 

[Charles-Tim]

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

And I will like people to know that Bitcoin’s Taproot is ready now, only remaining it to be included in bitcoin core, but it's unlikely to be included in the next release. The Bitcoin Improvement Proposals 340 through 342 were merged into the Bitcoin codebase on Thursday, signaling that the anticipated Taproot upgrade is ready.

https://cointelegraph.com/news/bitcoin-s-taproot-is-ready-to-go-but-it-s-unlikely-to-be-included-in-the-next-release
https://cointelegraph.com/news/bitcoins-taproot-upgrade-wont-help-privacy-where-it-matters

[Carlton Banks]

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.

there will be no benefit to Coinjoins from BIPs 340-342. Originally, "cross-input signature aggregation" was vaunted to be included in the Schnorr implementation, but in the end was left out (to simplify the changeset IIRC). All that would have enabled is to make Coinjoins cheaper, they would be equally recognizable on-chain as they were before schnorr sigs

So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

right, or anything using a hash-embedded script (including Lighting channels opens/closes)

this is why Coinjoins don't gain any privacy with Taproot, as a Coinjoin transaction is not script hash based

[gmaxwell]

I think that's not quite the case:  There is a privacy benefit in that single key, multisig, and channels will be less distinguishable, eventually improving the anonymity set for all transactions.  Specifically for coinjoins it means that you could have a single key and a multisig using party coinjoining and you couldn't distinguish them.

Though this is more of a long term benefit once the new style is the most common, initially privacy will be reduced somewhat through the proliferation of more address types.

You're absolutely right though that some people are confusing the aggregation benefits discussed previously with something taproot provides.

[Karartma1]

I am writing it mostly to merge the content into my head......

• Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
• Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

Example: let's imagine a payment channel that Alice and Bob opened on the LN. Once they are done, they want to close the channel and take their BTC back. Before Taproot, the channel’s closure implies the creation of a bulky tx, which would reveal too much about what happened. Enter Taproot, this action between A&B would appear as a regular transaction distributing funds to Alice and Bob, as if a third-party had sent them coins.

Sounds cool to me

[Carlton Banks]

• Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
• Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)


but yes, in essence, the net effect of BIPS 340-342 will remove the distinction between "script hash" addresses (beginning with a "1" character) and "public key hash" addresses (beginning with a "3" character). They will appear identical as addresses encoded on the blockchain, and when multisig is used with the typical scripting opcode sequence (1 input, 2 output, locktime set to current block at signing time). Because Lightning opens and co-operative closes are exactly that kind of transaction, they will also now look identical to these pedestrian tx types too (but not for Lightning uncooperative closes, which require a future locktime)

But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

[gmaxwell]

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)

Terminology danger!

Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature.  This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.

Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing.  Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.

But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

Yes, but almost always you can restructure a script as "[All the parties agree]  OR [Complicated script thing]". If you can do this, you can put an N of N pubkey at the top, and if the parties cooperate, the parties can cooperate and just sign and and the fact that "complicated script thing" exists at all will not be exposed.

The only time the existence of a complicated script would be exposed is if some parties don't cooperate (E.g. because they're offline).
 

[Karartma1]

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.

Of course, and that's actually a very elegant way to put it. Thanks gmaxwell, keep contributing here for us to really get into all-bitcoin-tech-things. And, really, thank you both for your two posts as now I believe I have a much clearer picture regarding what Taproot activation would mean. Thank you so much!

[piotr_n]

Will there be any taproot related tests added to the src/test/data ?

[gmaxwell]

Will there be any taproot related tests added to the src/test/data ?

There are vectors at https://github.com/bitcoin/bitcoin/pull/19953/files#diff-6794e4c8edce5f4dd1a21181a91f0c166f34c876809e40f015e5926ee3d6a126

[Wind_FURY]

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

Some Bitcoin tumblers and Wasabi/Samourai should start developing/testing, and see what they can build for "offchain mixing". I believe that could give a lot of users a very valid reason to start using Lightning.

[piotr_n]

Will there be any taproot related tests added to the src/test/data ?

There are vectors at https://github.com/bitcoin/bitcoin/pull/19953/files#diff-6794e4c8edce5f4dd1a21181a91f0c166f34c876809e40f015e5926ee3d6a126

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.

Are there any new test for entire scripts and transactions?

[piotr_n]

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

[gmaxwell]

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

Schnorr without taproot isn't really that useful: it makes it simpler and safer to write threshold signatures but that's it-- you can already threshold signatures using burdensomely complicated client software.  And threshold signatures by themselves don't even do that much-- they let you make signatures somewhat smaller but only when you don't need to be able to tell which parties signed.   It's better --- but perhaps not worth the trouble of a consensus change by itself.

Taproot without schnorr isn't really that useful: without threshold signatures, which are burdensomely complex to write software for without schnorr, it only lets you have a single party key at the top (which is pretty useless.)

There is a third logical part of taproot,  which is the merkelized script. This part is probably the most useful of the three on its own, but it's much more useful in combination.  With it you can use trees of N of Ns to make thresholds work usefully even when you need to be able to tell which parties signed, and  N of Ns are much easier to deal with than arbitrary thresholds, because the latter requires interactive secret key generation.

In order to have the property where arbitrary complex scripts are normally indistinguishable from one-of-one payments you need all three.  They also can't just be independently implemented: taproot changes the pubkey that goes into schnorr verification to commit to the merkelized script.

There were other techniques proposed, including graftroot (allows you to add scripts to an output after someone has already paid to it), and improved signature flags--  but those were possible to implement independently without leaving the rest not very useful.  There were also a number of next steps like signature aggregation which would have been best implemented in combination but were still left out because the three main features of the taproot bip were still useful without it.

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.
Are there any new test for entire scripts and transactions?

Looks like all the new testing is done with the python framework. I'll prod Pieter to add old style vectors.

They are over here: https://github.com/bitcoin-core/qa-assets/blob/master/unit_test_data/script_assets_test.json

[Wind_FURY]

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/

[Karartma1]

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/

That's a small start: currently, those three pools contribute an overall of 25% of global hashing power. By the way, BTC.com is from Bitmain.
It's interesting to notice the already very different approaches of the first three pools signaling the upgrade:

• Poolin - BIP9 (the same BIP for SegWit that went through tough times where the upgrade need to be activated before a specific time reaching a set threshold)
• Slush Pool - BIP8 (UASF that would also activate the upgrade at a specific future date or block height no matter the threshold reached)
• BTC.com - BIP8 + BIP9

Let's see when other pools join the party.

 

[ABCbits]

That's a small start: currently, those three pools contribute an overall of 25% of global hashing power.

From another perspective 2 of them (Poolin & BTC.com) are 2nd & 3rd with biggest hashrate, which is good start IMO.