So it seems likely that we will be doing this in such a way as to give a small group of miners the ability to veto this upgrade - and thus put us in a situation identical to activating segwit where we have to scramble together a UASF to force them to signal the upgrade before timeout.
Right now everyone is saying "lol it won't happen that way this time. The miners all approve of taproot it's not controversial like segwit was, and also they wouldn't try that shit again. Bitmain is rekt. blah blah."
This is so painfully naive and it's downright stupid not to learn our lesson from last time.
Firstly: even if they are honest about wanting taproot now, they might change their minds.
Secondly: if they are dishonest then we are playing ourselves - and we definitely shouldn't be assuming honesty. What happened to don't trust, verify? We can't verify here so we shouldn't be trusting either.
Thirdly: What about coercion? Governments aren't big fans of privacy upgrades. Pools may be forced to withdraw signalling by authorities.
Fourthly, and most importantly: Taproot is a controversial upgrade! It significantly improves privacy in bitcoin by making MAST transactions indistinguishable from normal transactions (in cooperative instances). This means, for example, that transactions where one is closing a channel on the Lightning Network will appear to be completely normal transactions, making censorship of transactions by type impractical.
Also consider that we had no idea that an unknown like ASICBOOST was going to end up being the reason for a controversy that had no technical basis (the blocksize 'debate') and seemed to make no sense when analyzing incentives - that is until we found out that BITMAIN needed to maintain their hidden advantage - and segwit (at least if the advantage was to remain hidden) needed to be a hardfork instead of a softfork. Even that got politicized to the point where King Vitalik of Ethereum pushed for the hardfork just to add to our confusion and the general chaos out of pure malice. The confusion that a MINER would be fighting to make blocks larger makes no sense as the scarcity of blockspace is increasingly the source of their income.
With taproot, who knows what hidden agendas are going to surface? I have no intention of finding out and with this upgrade - as has been pointed out by Luke-Jr - is: if we don't want the thing activated for 100% sure, why are we doing this at all? And if we do - why are we modifying BIP8 to have that same critical weakness that BIP9 had - giving miners veto power?
BIP8 specifically means that if the miners don't activate the softfork voluntarily before timeout, activation happens anyway.
From what I can gather, it seems to me that the wind is blowing in favour of modifying BIP8 so that we get some of the other benefits (activation deadline is a blockheight, not a time, meaning that if we do have to do an emergency UASF, at least we don't have to worry about a drop in hashrate causing us to sail past the deadline without having activated), BUT we give miners the power of veto, that if they decide to use, we will then have to UASF. Which is just WTF. If we are serious about it, why give them veto power in the first place? Just make it essentially a UASF from the beginning and then so much potential chaos and politics can be avoided!
lockinontimeout = true
The above code is us learning our lesson.
I know everyone wants to not stall anymore and just YOLO at this point, but I think we're going about it the wrong way.
Please don't give the miners the option to do any more than delay the upgrade. A successful UASF in retaliation is not inevitable in the case that one pool with - say - 11% of the hashrate decides not to activate. (Activation threshold unknown at this point - that would prevent activation if requirement is 90% or greater.)
[link] [comments]
No comments:
Post a Comment