Taproot proposal

[fillippone]

What will be interesting to see is how exchanges and businesses react to this, as well as governments. The only reason governments are allowing Bitcoin to stay legal, or even neutral, is due the fact that they think they have the means to control it with efforts such as chainanalysis. Once/if BTC reached a point of actual fungibility in which the costs of trying something like chainanalysis are bigger than simply outlawing it, that is what I would predict would happen (that governments outlaw it and go into a full front attack), which will only make other governments become tax havens for BTC holders. Ultimately the price would most likely be pushed upwards but there would be an awkward period of, once again, "Bitcoin is dead" all over mainstream media.

I think it is worth noting that chainanalysis is based on very weak heutistics.
The reality is there is nothing linking an address to another one. (taking to the extreme, even a transaction with one input and one output).  And each steps those heuristics become weaker and weaker every step down the chain analysis.
 
I am afraid the "chainanalysis stuff" is nothing would hold in a serious trial.

By the way batch transactions (output aggregation) togheter with coinjoin (input + output aggregation) are the best practices to transact over the bitcoin protocol. The fact that these techniques aren't implemented in "basic" wallets is not relevant. Everyone should always transact this way for every of his transaction.

[figmentofmyass]

I think it is worth noting that chainanalysis is based on very weak heutistics.
The reality is there is nothing linking an address to another one. (taking to the extreme, even a transaction with one input and one output).  And each steps those heuristics become weaker and weaker every step down the chain analysis.

indeed, there are layers upon layers of deniability baked in. there are other privacy pitfalls that could play a role, like browser/cookie analysis and IP address/bloom filter analysis by adversarial nodes. even then, the notion of getting a jury to convict based on this kind of chain of evidence is a tossup at best. blockchain analysis companies are generally working off a huge number of assumptions and that will become obvious to any jurors studying their protocols.
 

By the way batch transactions (output aggregation) togheter with coinjoin (input + output aggregation) are the best practices to transact over the bitcoin protocol. The fact that these techniques aren't implemented in "basic" wallets is not relevant. Everyone should always transact this way for every of his transaction.

in theory (actually this is arguable since coinjoin transactions are always currently more expensive).

in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

[fillippone]

in theory. in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

When an exchange harms your privacy applying weird heuristic to your transaction before or (worst) after using them, just stop using it.
I started a thread on this exact fact: [PAXOS+COINJOIN]Your privacy is a threat to exchange business?#deletepaxos

[figmentofmyass]

in theory. in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

When an exchange harms your privacy applying weird heuristic to your transaction before or (worst) after using them, just stop using it.
I started a thread on this exact fact: [PAXOS+COINJOIN]Your privacy is a threat to exchange business?#deletepaxos

people should absolutely "vote with their money" and leave such exchanges, if that's a viable option for them.

that doesn't address the larger issue though. we need to consider what people actually do by default. think about why the maker/taker fee model is so prevalent: because the vast majority of market participants are liquidity takers. further, there is zero indication that privacy is a priority for most of them. they will continue seeking out the highest liquidity exchanges, who all seem to be ratcheting up their AML standards one by one.

so while i agree with you, i don't think that's a viable solution long term. privacy advocates will just have less and less services at their disposal, with worse and worse liquidity. what we need are better coinjoin solutions so that we can slip through unnoticed with the the rest of the masses---so we aren't at a constant disadvantage re liquidity. this will take some time.....probably years.

wasabi wallet was groundbreaking as a first step, but its coinjoin implementation obviously puts its users at a great disadvantage re existing blockchain analysis heuristics. that's a problem we can't afford to ignore.

[fillippone]

Nice article by Aaron Van Wirdum to non-technically sum up all the recent development in Taproot and how  Payment Pools could be used as as Layer 1 scaling solutions and privacy feature.

I don't want to cross-post, so I am linking it here.

[gmaxwell]

Pieter has posted about changing BIP340 to us a different R tiebreaker: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.html

This is some signature algorithm behavioural minutia. Basically BIP340 did an unconventional thing because we believed it was faster enough to be worth a small increase in implementation complexity but it turns out that our belief was based on a both a broken benchmark and a supporting (wrong) assumption and it's not actually faster and might, in fact, be slightly slower in the long run.  Changing to the more conventional thing would simplify implementations and make them somewhat faster.

He tells me that he's received a bunch of positive commentary on it, so I expect the change will be made soon!

[gmaxwell]

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218

[DooMAD]

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218

Honestly thought this news deserved a little more attention than it seems to be getting.  A hardy "Good work!" to all involved.  Is the lack of fanfare purely because people are more excited about the aggregation part that isn't quite ready yet?

[Carlton Banks]

it's now merged: https://github.com/bitcoin/bitcoin/pull/19944



(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)

[Wind_FURY]

it's now merged: https://github.com/bitcoin/bitcoin/pull/19944



(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)

There's no drama from the trolls/big-blockers so far. Here's to hoping that this is activated as smoothly, and quickly as possible. Onward!

[DooMAD]

There's no drama from the trolls/big-blockers so far.

I wasn't expecting any.  It's not particularly controversial and there aren't really any coherent arguments to be made against it.

[Carlton Banks]

drama

I wasn't expecting any.

we may well see some


The most important point:

taproot only hides things that do not even happen. The script that is executed always appears on the blockchain when BTC is sent from a taproot address


stick to that argument, i say

(the troll reply is obvious: "no, the taproot secret script is encrypted with SHA256, not even Einstein and Hawking together could crack it and tell what's in the secret script. and money launderers, and Kazakh warlord gangsters. and people smoking Tide pods". Or something to that effect)

[Carlton Banks]

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

positive comments are accumulating already, the case for taproot activation code in 0.21.1 just became that little bit more promising

[Carlton Banks]

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

it's now merged

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1

[gmaxwell]

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1

That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.

[Karartma1]

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?

[Wind_FURY]

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953

it's now merged

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1

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.

[Carlton Banks]

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?

[DooMAD]

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.

I suppose, given the lengths certain trolls are prepared to go to in causing drama, it's easy to get paranoid about this sort of thing.  But honestly, it would be too obvious they were clutching at straws if they tried to oppose such an obviously beneficial change.  Playing devil's advocate, what argument against it would you expect them to give?  I can't think of any downsides.

Miners, I figure, would be indifferent at worst.  There are no negative impacts on them that I'm aware of.  If anything, once aggregation is implemented later, it potentially allows them to earn a tiny fraction more in fees if we're making more efficient use of space within blocks and can occasionally squeeze in a few more transactions.

[darosior]

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.