Taproot proposal

[Wind_FURY]

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

[Carlton Banks]

the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:

The Schnorr/Taproot proposal is now published as BIPs 340, 341, and 342; see github.com/bitcoin/bips/

Note that the assignment of BIP numbers is not any kind of stamp of approval; it just means the process was followed (which includes some amount of public discussion).

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

[fillippone]

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

[DooMAD]

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

I'd anticipate that any conflicts would be purely verbal/written and not even remotely a threat to implementation.  I doubt we'll see any alternative codebases popping up in opposition or anything like that.

The usual detractors will follow their predictable routine of trash-talk and stirring the pot, but I suspect that's about as far as it'll go.

[Carlton Banks]

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

[fillippone]

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

Point taken.
I wasn’t in any case suggesting anyone to derail anything or clash to anyone.

[pereira4]

How far are we from rendering efforts like "chainanalysis" useless? As it stands, interacting with fiat exchanges is a risk by default. Most of us are regular people, we aren't criminals, yet, what those blacklisting services do is basically putting yourself into the insane liability of ending up in a risk linked to criminal activity because some of your addresses once pertained to an address that it's on their blacklists. On a long enough timeline, everyone's chances of having coins that are "tainted" increase to the point that it's absurd putting your coins in an exchange.

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility. Until then, how is one supposed to deposit coins on exchanges? Again, as of right now, you are playing a sick lottery in which your coins may or not have traces of being tainted, and as time goes on and coins move, everyone's chances just keep going up.

[figmentofmyass]

How far are we from rendering efforts like "chainanalysis" useless?

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word.

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

[Wind_FURY]

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

But, without intending to derail, what would be a good technical debate against this proposal? Is there one? I believe there's none, or else we would already hear about it from people like franky1.

[ABCbits]

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

Not only hardfork, but CT have bigger size compared with regular transaction (even if you combine CT with Bulletproof, just like what Monero did), so i doubt it'll gain massive support.

[pooya87]

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

yes. in a Bech32 encoding when you set the witness version to 1 the first character after the separator (ie. 1) is going to become letter "p".
BIP 173 doesn't mention this but it is easy to use one of the libraries to encode an arbitrary length byte array to see what the first character is. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
empty 32 bytes= bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq5us4ke

[figmentofmyass]

has there been discussion about cross-input aggregation and when it might be implemented? i was under the (apparently mistaken) impression it was gonna be included with taproot. it does not appear to be included anywhere in BIP 340-342.

[o_e_l_e_o]

It's mentioned in BIP 341 as essentially not being ready yet:

Combining all these ideas in a single proposal would be an extensive change, be hard to review, and likely miss new discoveries that otherwise could have been made along the way. Not all are equally mature as well. For example, cross-input aggregation interacts in complex ways with upgrade mechanisms, and solutions to that are still in flux.

[gmaxwell]

The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same.  This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

There are also some ideas that could allow for better backwards compatibility.  In particular,  if a new witness-like p2p extension were made that allowed transmitting the concrete sighash values as witness data to old nodes that don't know how to generate those sighashes (but otherwise not keep them in blocks),  then aggregation could be preserved even with future softforked in sig hashes.   But witness-like p2p extensions are a real pain to design and deploy, and no one seemed particularly eager to do that work right now. If one is done it should probably pick up some other improvements other than just backwards compatible aggregation.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready.  Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.

[pereira4]

How far are we from rendering efforts like "chainanalysis" useless?

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word.

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo. We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible. The internet went throught this already. We would have avoided the spying clusterfuck that it has become if it ran private by default. Only now ages later Tor is becoming more known as well as VPNs, but thats far from ideal. It's still nothing in the grand scheme of things.

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?

yes. in a Bech32 encoding when you set the witness version to 1 the first character after the separator (ie. 1) is going to become letter "p".
BIP 173 doesn't mention this but it is easy to use one of the libraries to encode an arbitrary length byte array to see what the first character is. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
empty 32 bytes= bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq5us4ke

Can't regular bech32 addresses begin with a p?

[bulminer]

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.

The bips 340 341 and 342 if there is in the community a large consensus for their implementation, will in my opinion be one of the most important upgrades to Bitcoin. However, this implementation will also be a test of the community and its future, because if Bitcoin was already advertised by governments as a facilitation of money laundering, as well as the financing of criminal and terrorist organizations, with this upgrade, we will see strong attacks by political power.

Regarding to the hashpower, the new stratum v2 protocol, aims to further decentralization and break, in part, with the pools decision-making regarding to block protocol improvements.

[pooya87]

Can't regular bech32 addresses begin with a p?

I don't know what you have in mind when you say "regular address".
Bech-32 encoding is a rather simple encoding of any data that takes an octet string (8 bits) convert it to 5 bit chunks and then converts each chunk to one of 32 characters defined by BIP-173 (that is qpzry9x8gf2tvdw0s3jn54khce6mua7l).
For an address we add the witness version as its first 5-bit chunk without needing any conversion so when it is 0 you choose the first char that is "q" and when it is 1 you choose the second that is "p" and so on.
they are all "regular addresses" with a different version.

[pereira4]

Can't regular bech32 addresses begin with a p?

I don't know what you have in mind when you say "regular address".
Bech-32 encoding is a rather simple encoding of any data that takes an octet string (8 bits) convert it to 5 bit chunks and then converts each chunk to one of 32 characters defined by BIP-173 (that is qpzry9x8gf2tvdw0s3jn54khce6mua7l).
For an address we add the witness version as its first 5-bit chunk without needing any conversion so when it is 0 you choose the first char that is "q" and when it is 1 you choose the second that is "p" and so on.
they are all "regular addresses" with a different version.

By regular I meant what you point to be as bc1q. So bc1p is it for the new one. I didn't realize it was bc1q, but bc1 then random string. Im not a segwit user myself, still only use legacy. There's no way in hell the regular average joe user will notice any of these changes. That's why I insist: we need everything to be "mixed by default" somehow, and optional would be the clear transactions, ideally. What I mean is, the end user should just have to click "send" and that would be by default a mixed transaction. Then have some box you can check to not mix it optionally. This would be the standardized functionality of all wallets. That's how we reach proper fungibility. Otherwise we are going to start seeing horror stories regarding chainanalysis and innocent people ending up with BTC that was "tainted" attached to their names when they deposit in exchanges and whatnot. The only way to avoid this is that everyone by default mixes coins.

[figmentofmyass]

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word.

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo.

taproot/schnorr will run at layer 0. CT could in theory too but there are strong reasons it won't (bloat and lack of support for consensus change).

We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible.

taproot offers the beginnings of that. amounts and output linkability are still unaddressed at this time, but basically everything under the hood of a transaction can be hidden. cross-input aggregation (once implemented) will further provide strong fee incentives to drive users towards schnorr-based coinjoin and/or adaptor signature-based mixing transactions. wallets could offer these as automatic/default mechanisms. if most of the network is using taproot, these are pretty huge privacy gains for everyone.

unfortunately, we can't approach this issue as if it were day 1. as gmaxwell pointed out, there is uncertainty around being able to deploy even mundane consensus changes---let alone ones that are actually contentious.

[pereira4]

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word.

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

These things have to run at layer 0 to get any traction imo.

taproot/schnorr will run at layer 0. CT could in theory too but there are strong reasons it won't (bloat and lack of support for consensus change).

We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible.

taproot offers the beginnings of that. amounts and output linkability are still unaddressed at this time, but basically everything under the hood of a transaction can be hidden. cross-input aggregation (once implemented) will further provide strong fee incentives to drive users towards schnorr-based coinjoin and/or adaptor signature-based mixing transactions. wallets could offer these as automatic/default mechanisms. if most of the network is using taproot, these are pretty huge privacy gains for everyone.

unfortunately, we can't approach this issue as if it were day 1. as gmaxwell pointed out, there is uncertainty around being able to deploy even mundane consensus changes---let alone ones that are actually contentious.

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.