Taproot proposal

[gmaxwell]

As I previously stated, the miners are the only entity that cannot fake their level of support. It is trivial to run an arbitrary number of fakes nodes,

The point you're trying to make is a valid one, but your expression of it isn't technically correct.  Miners can easily fake their 'support' for any flag, and they often have in the past-- e.g. signaling BTC1 when they weren't running it and had zero intention of ever running it.

So while it's true that miner signaling is sybil resistant,  the mining pools signaling flags don't necessarily have much skin in what they signal, so fairly little incentive to do so honestly.  This is particularly true because the parties with an investment in hardware are hashers (whom don't control the flags) and not pools (who do control the flags.  Many pools have significant altcoin investments and it's not too hard to imagine a kickback or altcoin play making fake signaling in a pool's interest.  Even hashers can move hashpower to altcoins that might gain value if Bitcoin had issues.

You could imagine a scheme where people pay _ethereum_ into a black hole to vote for bitcoin proposals. ... it would be an unfakable measurement, but if anything it would be anti-correlated with the wants and best interest of the Bitcoin community.

More generally,  we should always be careful when we're substituting what we can measure with what we need.  Measuring hashpower is probably only a reliable proxy when people haven't realized that they can game it, and we know for a fact now that they have.

The real unfakable metric is the eventual market price of the asset -- but we can't know that in advance, only make educated guesses.

[1714165333]

1714165333

[Karartma1]

I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss!
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?

[achow101]

I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss!
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?

It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.

[Pmalek]

It doesn't look like anyone mentioned the article I just read by Mark Friedenbach, so I thought I would mention it here. If it was discussed, I apologize.

It's this one:
https://freicoin.substack.com/p/why-im-against-taproot.
He discusses Taproot and reasons why he is against its activation.

Mark fears that exposing the public key within the output on the blockchain downsizes Bitcoin's quantum protection. If and when quantum computers that are powerful enough to attack secp256k1 are created, they could (potentially) calculate the private key from a public key. The way Bitcoin works now, public keys are exposed when the coins are spent. With Taproot, they are exposed right away after an output is created.

According to Mark, it's quite possible that a quantum computer that can become a treat to Bitcoin can see the light of day by the end of this decade:

We’re only about six doublings away from the scale needed to attack secp256k1 using current algorithms. At about 18 months between doublings, that could be as soon as the end of the decade.

The article goes on to mention that 6.25 million bitcoins in 2019 were kept at addresses whose public keys are known. If the algorithm gets broken, it's those coins that become vulnerable. Another good reason not to reuse addresses. 

When Taproot gets activated (because I assume it will), what is currently being done on improving the security of the network where the public keys will become exposed as soon as an output is created (if I understood Mark's concerns properly)? Quantum computers could be something we have to worry about in 10-20 years, but what if the technology becomes available sooner? We will have Taproot, but how soon can quantum-resistant solutions be built?

Does Mark have valid concerns or is he wrong? I read somewhere that the exposed public keys with Taproot could get hashed preventing possible private key calculations in that way. Is that the way to go or what happens next?

[Karartma1]

I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss!
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?

It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.

I see, thanks for clarifying. I understand that from a press point of view it is very clickbaity and juicy to use such wording and avoiding to be specific. Shame on them as usual.
Now, whatever the way we should move on, let's get this upgrade on its way.

[pooya87]

~

The argument is flawed because security of Bitcoin is not defined based on individual outputs but as a whole system. If some day the technology advances enough to be able to reverse a 256-bit public key to get its corresponding private key that means Bitcoin as a whole becomes insecure and whether or not Taproot is using public key is not going to change that.

[PrimeNumber7]

As I previously stated, the miners are the only entity that cannot fake their level of support. It is trivial to run an arbitrary number of fakes nodes,

The point you're trying to make is a valid one, but your expression of it isn't technically correct.  Miners can easily fake their 'support' for any flag, and they often have in the past-- e.g. signaling BTC1 when they weren't running it and had zero intention of ever running it.

I suspect major mining pools are running their own custom implementations of bitcoin for broadcasting, receiving, and validating blocks. 

In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.

So while it's true that miner signaling is sybil resistant,  the mining pools signaling flags don't necessarily have much skin in what they signal, so fairly little incentive to do so honestly.  This is particularly true because the parties with an investment in hardware are hashers (whom don't control the flags) and not pools (who do control the flags. 

The mining pools earn income from the blocks they mine, and they need to invest in infrastructure to allow their pool to operate. If a pool has fewer hashers, it will have less income. It is also trivial for hashers to move their miners to pools that are signaling for or against a proposal that is in line with the long-term best interest of bitcoin. If a pool is signaling for or against a proposal that is not in bitcoins best interest, it will lose customers.

Many pools have significant altcoin investments and it's not too hard to imagine a kickback or altcoin play making fake signaling in a pool's interest.  Even hashers can move hashpower to altcoins that might gain value if Bitcoin had issues.

I would have to disagree with the bolded part of your statement. The altcoins that can be mined using ASIC miners that can also mine bitcoin have a very low network hashrate as a function of the hashrate of the bitcoin network. If 1% of the hashers (measured by hashrate) currently mining bitcoin were to move to bitcoin cash, the difficulty would more than double, which means the price of bitcoin cash would need to more than double for the hashers to have the same amount of revenue. This is simply not something that will scale for enough hashers to oppose a bitcoin proposal whose failure would benefit bcash. Even if it did scale, once these hashers start mining bcash, any proposal whose failure would benefit bcash could subsequently be implemented.

The real unfakable metric is the eventual market price of the asset -- but we can't know that in advance, only make educated guesses.

I mentioned futures markets for various fork-coins above. Any futures market would need to either be centralized, or run on an altcoin blockchain, such as etherum in order to be reliable.

My position continues to be that it is best to get miners' consent prior to implementing a fork (soft or hard). If there is a BIP proposal that is receiving pushback from the miners (based on what they are signaling), or if the miners are signaling support for a "bad" BIP proposal, a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.

[pooya87]

In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.

It wasn't because of the futures fake markets but because they saw that going ahead with the hard fork part of SegWit2x would split bitcoin and it was not in their best interest. Believe it or not miners have a bigger stake in bitcoin since they both invest in equipment and bitcoin at the same time. Unlike nodes ore regular users who many not even own any bitcoin (anything at stake).

~ a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.

Proposals should be discussed and then approved/rejected based on their merits not based on what the
market (day traders who only care about their short term profit) think. Keep in mind that it is very easy to manipulate the market price on a centralized exchange specially when not enough people turn to that option.

[Wind_FURY]

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.

SegWit was implemented after the miners agreed to the upgrade. A USAF upgrade was threatened, but this threat was never carried out. Read the article you posted, especially the last several paragraphs.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

This is speculation. What ultimately matters is the economic supermajority.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?

BIPs should be implemented the same way they are implemented now. Once a BIP is agreed upon and put into the codebase by the devs, the miners should signal support or opposition to a BIP via their found blocks.

What if the miners hold the network hostage again by not signalling readiness for an upgrade the community wants?

I previously discussed this possibility. If a BIP is not receiving support from the miners, the community could consider implementing a USAF, while taking into consideration the amount of support the miners gave. As I mentioned before, there is a difference between a small minority of miners supporting a BIP and a miner basically using veto power to oppose a BIP. The community should also consider alternatives to a USAF, such as lowering the activation threshold or modifying the BIP in a way that makes the miners more comfortable.

As I previously stated, the miners are the only entity that cannot fake their level of support. It is trivial to run an arbitrary number of fakes nodes, it is trivial to create an arbitrary number of online personas, and it is trivial to send many transactions to yourself to make it appear your business has a lot of economic activity, when your business does not have any customers.

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

[PrimeNumber7]

In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.

It wasn't because of the futures fake markets but because they saw that going ahead with the hard fork part of SegWit2x would split bitcoin and it was not in their best interest. Believe it or not miners have a bigger stake in bitcoin since they both invest in equipment and bitcoin at the same time. Unlike nodes ore regular users who many not even own any bitcoin (anything at stake).

~ a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.

Proposals should be discussed and then approved/rejected based on their merits not based on what the
market (day traders who only care about their short term profit) think. Keep in mind that it is very easy to manipulate the market price on a centralized exchange specially when not enough people turn to that option.

Wells I guess I would ask how would one know if something is in the best interest of bitcoin? I could give my opinion based on my own expertise, but doing something because an "expert" says so is anti-thetical to bitcoin. If an exchange is reputable (or even better, if multiple exchanges are reputable), and are neutrally offering a particular market, the ecosystem can take the information into consideration. This is especially true if reputable exchanges allow for holders of bitcoin.current_implementation to exchange into BIPxxx.yes and BIPxxx.no and vice versa, to allow for arbitrage.

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

I believe a lot of the bitcoin ecosystem did not initially support SegWit. I think it is difficult to argue otherwise. Over time, arguments were made in favor of SegWit, including the various failures of alternate scaling implementations, and the signaling of various futures markets.

In other words, over time, minds were changed after additional data was understood. This is exactly how bitcoin should be improved. A BIP can be proposed that has initial opposition, and those in favor of the BIP should make a compelling argument as to why others should support the BIP.

[Pmalek]

The argument is flawed because security of Bitcoin is not defined based on individual outputs but as a whole system. If some day the technology advances enough to be able to reverse a 256-bit public key to get its corresponding private key that means Bitcoin as a whole becomes insecure and whether or not Taproot is using public key is not going to change that.

That's true and the author made several suggestions. He proposes switching to SHA-512 instead of SHA-256. He would like to see Merkle trees be based on SHA-512, which seems to be something that is not easily achievable right now according to the article. But before that is possible, he thinks users should know the dangers of exposing their public keys in outputs, and in the best-case scenario move their coins to new addresses that haven't been reused.

He explains it much better than I do. If you are interested, read the bottom part of his letter (beginning with What can we do to fix this?). 

[Wind_FURY]

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

I believe a lot of the bitcoin ecosystem did not initially support SegWit. I think it is difficult to argue otherwise. Over time, arguments were made in favor of SegWit, including the various failures of alternate scaling implementations, and the signaling of various futures markets.

In other words, over time, minds were changed after additional data was understood. This is exactly how bitcoin should be improved. A BIP can be proposed that has initial opposition, and those in favor of the BIP should make a compelling argument as to why others should support the BIP.

That’s what I said.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

But you replied that it was only speculation, https://bitcointalk.org/index.php?topic=5140134.msg56707724#msg56707724

The UASF, and its other forms in the future will never be something “bad”, in fact, I believe it’s required to counter-balance governance issues.

[pooya87]

The argument is flawed because security of Bitcoin is not defined based on individual outputs but as a whole system. If some day the technology advances enough to be able to reverse a 256-bit public key to get its corresponding private key that means Bitcoin as a whole becomes insecure and whether or not Taproot is using public key is not going to change that.

That's true and the author made several suggestions. He proposes switching to SHA-512 instead of SHA-256. He would like to see Merkle trees be based on SHA-512, which seems to be something that is not easily achievable right now according to the article. But before that is possible, he thinks users should know the dangers of exposing their public keys in outputs, and in the best-case scenario move their coins to new addresses that haven't been reused.

He explains it much better than I do. If you are interested, read the bottom part of his letter (beginning with What can we do to fix this?). 

Replacing hash functions with quantum-secure variants is easy—just increase the width. Switching from SHA-256 to SHA-512 would be more than adequate.

SHA512 is the same exact algorithm as SHA256 (both referred to as SHA2) and in fact SHA512 is faster than SHA256 on modern computers and if the algorithm were weak it would be weaker for the faster one regardless of its bigger size. Increasing the digest size is not the way to increase "quantum resistance" (although quantum computing doesn't do anything to hash algorithms but that's a different discussion). An entirely different algorithm has to be chosen (like version 3 of S.H.A.).

P.S. Changing hashing algorithm to something that harms scalability of bitcoin and DSA used in Bitcoin to quantum resistance one are not arguments against Taproot!

[PrimeNumber7]

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

I believe a lot of the bitcoin ecosystem did not initially support SegWit. I think it is difficult to argue otherwise. Over time, arguments were made in favor of SegWit, including the various failures of alternate scaling implementations, and the signaling of various futures markets.

In other words, over time, minds were changed after additional data was understood. This is exactly how bitcoin should be improved. A BIP can be proposed that has initial opposition, and those in favor of the BIP should make a compelling argument as to why others should support the BIP.

That’s what I said.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

But you replied that it was only speculation, https://bitcointalk.org/index.php?topic=5140134.msg56707724#msg56707724

The UASF, and its other forms in the future will never be something “bad”, in fact, I believe it’s required to counter-balance governance issues.

USAF is a strong-arm tactic, it is coercion. That is not what I was referring to. I was referring to the proponents of SegWit 'selling' the benefits of SegWit to bitcoin's various stakeholders using persuasion. 

[Wind_FURY]

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

I believe a lot of the bitcoin ecosystem did not initially support SegWit. I think it is difficult to argue otherwise. Over time, arguments were made in favor of SegWit, including the various failures of alternate scaling implementations, and the signaling of various futures markets.

In other words, over time, minds were changed after additional data was understood. This is exactly how bitcoin should be improved. A BIP can be proposed that has initial opposition, and those in favor of the BIP should make a compelling argument as to why others should support the BIP.

That’s what I said.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.

But you replied that it was only speculation, https://bitcointalk.org/index.php?topic=5140134.msg56707724#msg56707724

The UASF, and its other forms in the future will never be something “bad”, in fact, I believe it’s required to counter-balance governance issues.

USAF is a strong-arm tactic, it is coercion.

But a strong-arm tactic against who? Most of the Core Developers were neutral, some that supported the UASF was not the “official” stance, the market wanted it, it was just Jihan Wu, and thr Mining Cartel that didn’t want it because it would kill ASIC-BOOST.

That is not what I was referring to. I was referring to the proponents of SegWit 'selling' the benefits of SegWit to bitcoin's various stakeholders using persuasion. 

Someone said that the biggest mistake was selling Segwit as a scaling solution, I believe that’s true. If it wasn’t sold that way, I believe it would have been activated with no drama.

[BrewMaster]

Someone said that the biggest mistake was selling Segwit as a scaling solution, I believe that’s true. If it wasn’t sold that way, I believe it would have been activated with no drama.

but SegWit was a scaling solution, it increased the maximum capacity by 4 MB weight which currently is capped at 1.6 MB size. it also doesn't stop there, it paved the way for more scaling to come. for example implementation of Schnorr using SegWit is a lot easier and doesn't need a hard fork and is another capacity improvement.
it also made Lightning Network a lot easier by fixing some remaining malleability issues. which is another scaling solution.

[Wind_FURY]

Someone said that the biggest mistake was selling Segwit as a scaling solution, I believe that’s true. If it wasn’t sold that way, I believe it would have been activated with no drama.

but SegWit was a scaling solution, it increased the maximum capacity by 4 MB weight which currently is capped at 1.6 MB size. it also doesn't stop there, it paved the way for more scaling to come. for example implementation of Schnorr using SegWit is a lot easier and doesn't need a hard fork and is another capacity improvement.
it also made Lightning Network a lot easier by fixing some remaining malleability issues. which is another scaling solution.

I never said that Segwit didn’t improve transaction throughput, I said it was the way it was sold. I believe Segwit was mainly a malleability fix and other benefits you posted, not a scaling solution, but was sold as a scaling solution to please the miners. But I might be wrong. Let’s wait for gmaxwell or achow to post the facts.

[Karartma1]

I don't think nobody sold anything. SegWit proved to be a necessary upgrade and let's avoid to bring politics always in.
SegWit meant lower fees, more tx throughput, LN etc.
With Taproot it's the same, it's a necessary upgrade to me.

[Wind_FURY]

I don't think nobody sold anything.

If you ask me, “Sold” = Way it was communicated to the community. It was communicated to the community mainly as a “scaling solution”. I believe if it was communicated as a malleability fix, it would have activated without drama.

BUT, Segwit as a soft fork disabled ASIC-BOOST, the drama might have been nevertheless unavoidable.

SegWit proved to be a necessary upgrade

No one said it wasn’t, except for the big blockers.

and let's avoid to bring politics always in.

I believe that’s the wrong take. Gavin Andresen was the “succesor” to whom Satoshi left the keys of the kingdom to, would you say that we should have followed him to hard fork Bitcoin to Bitcoin XT just to avoid politics?

[DooMAD]

So, steering the conversation back towards Taproot, is that being "sold" the right way?  Is there anything people could conceivably object to?  The communications so far all seem on point to me.