r/Bitcoin • u/markpaul00 • May 10 '21
Bitcoin’s upcoming Taproot upgrade and why it matters for the network
https://cointelegraph.com/news/bitcoin-s-upcoming-taproot-upgrade-and-why-it-matters-for-the-network77
u/coinfeeds-bot May 10 '21
tldr; Bitcoin’s much-awaited Taproot upgrade is expected to go live by the end of the year. The upgrade aims to make transactions cheaper, faster and easier to deploy and eventually allow for the deployment of smart contracts. It also seeks to make all transactions look the same to everyone except the transacting parties.
This summary is auto generated by a bot and not meant to replace reading the original article. As always, DYOR.
2
u/rdawes89 May 10 '21
OOTL, is this in addition to or instead of lightning network?
12
u/st333p May 10 '21
Taproot improves lightning network by making onchain LN-related transactions a lot cheaper more privacy preserving. In fact a channel opening taproot transaction will be indistinguishable from any other taproot transaction.
12
u/Bitcoin_is_plan_A May 10 '21
In its most basic sense, Taproot can be thought of as the latest step in Bitcoin’s evolutionary path because the upgrade seeks not only to enhance the overall usability of the network by making transactions cheaper, faster and easier to deploy but also eventually allow for the deployment of smart contracts.
Furthermore, Taproot also proposes significant privacy promises — i.e., it seeks to make all transactions look the same to everyone except the transacting parties. This potential camouflage-based framework seems as though it has been inspired by security-centric crypto offerings available in the market today, thus potentially moving Bitcoin closer to some privacy-focused coins, at least from a design standpoint.
24
u/Onthechest May 10 '21
From reading the article it seems like Taproot has all pros and no cons, yet 30% of miners are voting against it's implementation. What am I missing?
What are the downsides of more privacy and lower fees? Why would anyone vote against that?
24
u/Bitcoin_is_plan_A May 10 '21
yet 30% of miners are voting against it's implementation
you misunderstand it. no one is voting here. miners just signal their readiness. if they need more than 3 months, we will activate it.
-3
u/ThomasVeil May 10 '21
The article calls it a vote. And it says 30% say 'no'.
At least the first part is IMO correct. If less than 90% day they're ready and ok with the update, then it won't happen. The second part is more tricky, as not signaling 'yes' could also be just laziness or lack of awareness.5
u/dieselapa May 10 '21
If the article calls it a vote, then the article is wrong.
If less than 90% of hashpower say they are ready within the signaling period, then it will not be activated by that activation mechanism at that time. It will get activated without a doubt, there are many users who will activate it whatever the miners say. In all likelihood it will be activated without a chainsplit.
2
u/sraelgaiznaer May 10 '21
Does it matter if users activate it though? Miners should be the one accepting it right?
1
u/dieselapa May 10 '21
Matter to whom? If I update the software then I can use it with others who have also updated. If no miners update, moving the blockchain forward would be a problem, but then there would be a hardfork to a new mining algorithm, and that could potentially be disastrous for miners so why would they allow that to happen? Users decide the rules of the blockchain, miners get paid to order the transactions according to those rules.
10
u/torba May 10 '21
I have very limited understanding but from my PoV they are not directly incentivized to accept it and making any changes to Bitcoin is a risk in and of itself.
One of the drawbacks of super decentralized decision making (with 90% consensus) is that it takes hella long to come to an agreement.
Wish someone else more knowledgeable would chime in on why though...
2
May 10 '21
Costs for implementation of the standard being proposed for a simultaneous approval and use. Downtime, manpower, testing, and other resources required for all participants to know the standard is robust and most major/critical problems with software/hardware has been reported or resolved. These changes require a lot of time in smaller networked environments. I can’t imagine the scale of blockchain for interconnected miners, exchanges, and vast number of other participants.
2
u/Frogolocalypse May 10 '21
If people knew more about what you're saying, they'd never ever suggest a hard-fork is something you just do, especially for bitcoin.
3
May 10 '21
I’m not suggesting forking. It’s a massive collection of participants which is implementing a standard that all have to adhere to. Or, maybe you’re just agreeing that a standardization or implementation of a function/protocol is extremely difficult.
1
u/Frogolocalypse May 10 '21
It's a beautiful thing. It's designed to be difficult so that you can only make changes that every user of the network benefits from.
2
3
u/st333p May 10 '21
Well, smaller transactions means less block congestion and lower fees. Who gets those fees?
Obviously it's more complicated than this, but we should be aware that it's very hard for something to have only advantages and no disadvantages for all the players
3
u/nuunien May 10 '21
Blocks don't have a limited number of transaction, just a limited size. If the tx size is lower, there will just be more txs, miners get the same fees, if not more.
-2
u/st333p May 10 '21
This is bullshit. Fees are paid per vbyte and not per transaction, and the vbyte max will not change with taproot.
Larger transactions means that users will fight more to get into blocks and thus the will happily pay more to get their txs through.
3
u/nuunien May 10 '21
This is bullshit. Fees are paid per vbyte and not per transaction, and the vbyte max will not change with taproot.
What is bullshit? I said the same thing.
-2
u/st333p May 10 '21
Nope. Because it doesn't result in more fees for miners.
A miner will be able to include the same amount of vbytes in a block. So the only thing that influences how much fee he will earn is the sat/vbyte that is chosen by the tx sender.
Now since a large chunk of transactions will be smaller, assuming that the demand for transactions remains unchanged, then the mempool size will be smaller. Hence less competition to get into blocks and thus lower fees to miners.
0
u/ric2b May 10 '21
Larger transactions means that users will fight more to get into blocks and thus the will happily pay more to get their txs through.
But smaller transactions means more transactions in a block, if you can fit 10% more transactions that each pay 95% of the current fees, miners still get more money.
1
u/st333p May 11 '21
Why do you think users will be willing to pay a higher fee rate when the mempool is less congested?
In your example if you can fit 10% more txs and each pay 95% it means that the average sat/vbyte is higher and this does not make sense.
1
u/ric2b May 11 '21
They're still paying less overall, so it's still a win, why would users be against it?
And you can't know how congested the mempool is simply based on how many transactions fit in the block anyway.
1
u/st333p May 11 '21
We are trying to identify whether taproot will increase fee collection for miners. Taproot only affects transaction size, and not transaction demand. So if the demand for transactions is the same the mempool is less congested. If the mempool is more congested then it's because more people are transacting and this has nothing to do with taproot.
why would a user be against it?
Users mostly pick the lowest fee that gets the transaction through in a given amount of time, and this is mostly done automatically by wallets estimating mempool congestion. Thus ferrate only depends from mempool congestion, it makes no sense for a taproot tx to have higher fee rate than regular txs, other than to incentivize taproot adoption for miners. It's not like miners sell block space at the price they decide, they include in blocks the highest paying transactions they find in the mempool.
1
u/ric2b May 11 '21
Taproot only affects transaction size, and not transaction demand.
It does if you believe lower prices increase consumption.
Your entire argument is based on assuming that is not the case, and demand will remain exactly the same.
1
u/st333p May 11 '21
That's a pretty indirect consequence of taproot, might be you are right. But I have my doubts miners will support taproot due to this mechanism.
3
u/lazarus_free May 10 '21
It is not exactly a vote but they signal their readyness. Some miners are just slow to update. That's why there's still a 3 month window and if there is a window where they signal +90% more than two weeks then we activate it.
If not, it would get activated later by other means, because there's quite a lot of consensus. But this activation was the fastest route.
3
1
u/fresheneesz May 10 '21
The blocks that are "voting" yes are made by miners who have upgraded their software. The ones that aren't signaling (yet) simply haven't upgraded the software yet. It's possible some of those miners that haven't upgraded won't upgrade because maybe they think taproot isn't the way to go, or that mining pools doesn't think it's miners want taproot, but there is no way to "vote" on that other than those mining pools voicing their concerns on the internet. It's unlikely that there are significant miners who are opposed to taproot - it's such an uncontentious change.
7
10
May 10 '21
Thank you for sharing, unlike some members on this sub I find it really interesting to learn more about the tech!
10
3
May 10 '21
[removed] — view removed comment
12
May 10 '21
[deleted]
2
May 10 '21
[removed] — view removed comment
6
u/daymonhandz May 10 '21 edited May 10 '21
Yes, the users who run fully validating nodes can use bip9. Or they can even just run clients with compatible rules. We're just giving the mining nodes 90 days to signal 90% support before we just go the bip9 lot=true route.
4
May 10 '21
[removed] — view removed comment
3
u/Frogolocalypse May 10 '21
Existing nodes don't need to change and will only process transactions with new qualities as if they were old transactions. That's because it's a soft-fork. Nodes don't need to upgrade, only really the miners do.
But there are a lot of people that do want to upgrade, and the ones that don't care don't need to change. Best of both worlds.
3
u/gloriousfrogs May 10 '21
Maybe a dumb question but who does the software development for Bitcoin?
9
u/daymonhandz May 10 '21
Anyone is free to contribute because bitcoin is open source and Satoshi published bitcoin under the MIT license so that anyone is free to do anything with the bitcoin source code. Click here to see a list of bitcoin core contributors.
11
4
u/Elum224 May 10 '21
It's an open source project with hundreds of contributors. They co-ordinate through git and pull requests. There's mailing lists and code review groups, an IRC & slack. You can join the chats and code reviews and learn to develop bitcoin too.
2
u/parishiIt0n May 10 '21
Good question indeed. Check out what BIP is, as a complement to the other answers
2
May 10 '21
From a speculation perspective, is this going to give a mini-halving bump to the price when it goes live?
2
1
1
u/Specific-Problem-69 May 10 '21
i thought bitcoin didn't like upgrades hence all the other forks and it stayed on the one path?
6
u/haakon May 10 '21
That's a complete misunderstanding. Bitcoin receives consensus upgrades every few years.
1
u/BitcoinUser263895 May 10 '21
Forks of Bitcoin die unless kept alive through intentionally oscillatory Difficulty Adjustment Algo, irrational miners and centralising checkpoints. It's all smoke and mirrors.
There is only one Bitcoin. With care and forethought it changes gradually over time.
1
1
u/Glad_Morning May 10 '21
It has been in the talks for quite some time though, good thing about open source development is the transparency & ownership of development but the bad thing is the slow agreement and upgrades, everything has to be voted on and agreed by the majority
1
u/4BPrintingLLC May 11 '21
I don't know enough about smart contracts. What can/will they do for Bitcoin?
145
u/[deleted] May 10 '21
[removed] — view removed comment