This is the first time I read that sending bitcoin to a P2TR output will become more expensive than sending to standard legacy or native segwit addresses.
Since the P2TR outputs seem to be using SHA256 hash, they are only smaller than P2PKH, P2SH and P2WPKH but they take up the same space as a P2WSH output. This difference is only 12 bytes though (32 byte hash versus 20). 
Topic: Taproot proposal - page 15. (Read 11253 times)
Quote
Using this new script type, a user can create a UTXO which can be unlocked and spent by either the owner of the private key or anyone who can satisfy the requirements of any script within the Merkle tree.
What requirements within the Merkle Tree need to be satisfied exactly to be able to spend from P2TR? Being one of the parties that has his signature aggregated is one I assume. What else is there? This is the first time I read that sending bitcoin to a P2TR output will become more expensive than sending to standard legacy or native segwit addresses. But spending those P2TR outputs will be much cheaper.
I found the following Taproot 101 on the latest Jimmy Song article. This is a pretty damn good taproot explanation and I wanted to leave it here for you all.
https://river.com/learn/what-is-taproot/
I didn't know about this River Financial before, looks good to me. They do bitcoin-only!
https://river.com/learn/what-is-taproot/
I didn't know about this River Financial before, looks good to me. They do bitcoin-only!
My role on this thread is to provide a news flows for the less technical readers, so we don’t hassle knowledgeable people with silly, or already answered questions.
I point you to this piece by Aaron Van Wirdum:
THERE ARE NOW TWO TAPROOT ACTIVATION CLIENTS, HERE’S WHY
Taproot, the proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, is getting closer to activation. The Taproot code itself had already been included in the most recent major Bitcoin Core release (Bitcoin Core 0.21.0), which is currently the de-facto reference implementation for the Bitcoin protocol. The next step was to deploy activation code for the upgrade to go live across the Bitcoin network.
But due to technical and philosophical disagreements on how the Bitcoin protocol should be upgraded, discussion about Taproot activation turned out to be a long and sometimes heated debate. Now, it has resulted in two different Taproot activation paths, embedded in two main software clients that could in some scenarios even become incompatible with one another.
This is the story of these main two Taproot activation clients, the difference between them and some possible scenarios going forward.
I point you to this piece by Aaron Van Wirdum:
THERE ARE NOW TWO TAPROOT ACTIVATION CLIENTS, HERE’S WHY
Quote
Taproot, the proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, is getting closer to activation. The Taproot code itself had already been included in the most recent major Bitcoin Core release (Bitcoin Core 0.21.0), which is currently the de-facto reference implementation for the Bitcoin protocol. The next step was to deploy activation code for the upgrade to go live across the Bitcoin network.
But due to technical and philosophical disagreements on how the Bitcoin protocol should be upgraded, discussion about Taproot activation turned out to be a long and sometimes heated debate. Now, it has resulted in two different Taproot activation paths, embedded in two main software clients that could in some scenarios even become incompatible with one another.
This is the story of these main two Taproot activation clients, the difference between them and some possible scenarios going forward.
The drama/issue will be in “LOT=TRUE or LOT=FALSE”. There will be some actors in the network who might take advantage, and divide the community again. The Core developers are neutral, except for lukedashjr, who wants LOT=TRUE?
No, that's really been resolved with the Speedy Trial initiative (it was one of the reasons to take that route).
(note: I'm not entering into a conversation with you, please don't reply)
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.
I believe none. The drama/issue will be in “LOT=TRUE or LOT=FALSE”. There will be some actors in the network who might take advantage, and divide the community again. The Core developers are neutral, except for lukedashjr, who wants LOT=TRUE?
In a weird circular reference loop, let me report here this Bitcoin Magazine Article:
SPEEDY TRIAL HAS BEEN MERGED INTO BITCOIN CORE, POTENTIALLY SETTING PATH TO TAPROOT ACTIVATION
According to a GitHub pull request, a BIP 9-based implementation of Speedy Trial has been merged with the code for Bitcoin Core, offering a potential path for activating the much-anticipated protocol upgrade Taproot.
SPEEDY TRIAL HAS BEEN MERGED INTO BITCOIN CORE, POTENTIALLY SETTING PATH TO TAPROOT ACTIVATION
Quote
According to a GitHub pull request, a BIP 9-based implementation of Speedy Trial has been merged with the code for Bitcoin Core, offering a potential path for activating the much-anticipated protocol upgrade Taproot.
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.
there's always some angle to be had for a committed axe-grinder, but no-one's made any credible claims that taproot/schnorr will be detrimental to Bitcoin.
Is there anything people could conceivably object to? The communications so far all seem on point to me.
Besides the part that with Taproot the public key will be exposed before an output is spent, there doesn't seem to be any major objections. Even this doesn't seem like an issue as pooya87 explained in one of his previous posts. The article I linked to hasn't created confusion or uncertainty in regards to whether or not Bitcoin should go ahead with Taproot activation. If we arrive to a point where SHA2 is not quantum resistant, an exposed public key is the least of our problems. 
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.
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.
Quote
SegWit proved to be a necessary upgrade
No one said it wasn’t, except for the big blockers.
Quote
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?
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.
SegWit meant lower fees, more tx throughput, LN etc.
With Taproot it's the same, it's a necessary upgrade to me.
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.
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.
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.
Quote
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://bitcointalksearch.org/topic/m.56707724
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.
Quote
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.
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.
Quote
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://bitcointalksearch.org/topic/m.56707724
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.
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?).
Quote
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!
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.
Quote
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://bitcointalksearch.org/topic/m.56707724
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.
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?).
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 Quote
~ 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.
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.
Jump to: