pull down to refresh
FWIU¹, it’s a BIP 9 (Versionbits) + LOT²=true activation attempt.
I.e., it would be a miner activated soft fork if in any one difficulty period before September 1st 55% of block headers signal readiness to enforce the soft fork, at which point the soft fork locks in, and then starts being enforced by all soft forking nodes after one more difficulty period without enforcement.
In the case that this doesn’t happen, it turns into an unconditional flag day activation on September 1st. Since it wouldn’t have locked-in in beforehand in that case, the soft fork would only be supported by a minority of the hashrate, but in theory at that point (steelmanning here) an overwhelming majority of the nodes and especially the economic majority would enforce the soft fork by rejecting any blocks that don’t adhere to the rules of the soft fork. As the majority of the economic activity would then supposedly be happening on the soft fork chain, there would be less to no demand for the block rewards on the non-soft forking chain and thus the economic majority would impose their will on the miners, forcing them to mine the soft fork chain in order to get paid.
Alternatively, if neither hashrate nor economic majority back their soft fork proposal, it would not lock in before the timeout, and on September 1st, any nodes still running the activation client would start rejecting blocks that don’t adhere to their soft fork rules. Given that pretty much every block today would be invalid according to their soft fork rules, the enforcing nodes would immediately fork themselves off onto a minority chain as the rest of the Bitcoin network pulls away with the most-work chaintip. Supposedly, the economic majority and majority of the hashrate would then be going to sacrifice their transaction history and block rewards, and impose upon themselves the rules of the soft fork in order to mend the network. I have yet to see a plausible explanation why the network’s majority would choose to let themselves be subjugated by the minority against their financial and ideological interests. It seems obvious to me that the soft forking nodes would be abandoned to their minority chaintip with drastically diminished value which they then would either give up on by switching back to a Bitcoin node, or double down upon per another consensus change that spins off a forkcoin.
As to the actual expected outcome, I would be surprised if this proposal gets more than a low single-digit percentage of signaling, and I’m therefore anticipating no more than a few dozen nodes forking themselves off on September 1st.
¹ I have put in no effort to validate this. The proposal was changing on a daily basis for several weeks, so they might have decided to do something else meanwhile.
² LockinOnTimeout (see BIP 8)
The main issue is that I would never run anything with a < 95% activation threshold or with LOT, because I think that that's oppressive. Yes, even at a true 55% signal, or even 80% economic nodes: democratic oppression is not only possible, but common, to varying degrees.
I've been thinking of forking both the current activation clients and re-releasing them clean [1] and integrated [2], but this is way too much work when measured in bread not put on my table when done full-time and too slow when not done full-time. Also made painful due to the lack of deep docs, tests and fuzzing harnesses, so this needs 3-4 people.
An additional upside of that, besides reducing fragmentation, would be that if both our expectations are wrong and there is massive support for either, there's a clean, tested, fuzzed patch-set for Core. Something that's very hard right now for at least BIP-110.
Traditionally, this was the "staging tree" role of Core, but when faced with controversy it is impossible to do it there, and I observe that the "reference client" role has gained much more importance, especially in the past 5 years. The Bitcoin protocol doesn't have to ossify, but Core must be extremely conservative and thus be (perceived as) a beacon of stability, at least on the consensus code. I think that I'm not the only one seeing it this way anymore.
"Standardized", i.e. without LOT, without UASF, and with 95% threshold, and (re)based on latest Core. ↩
because with all the fragmented activation clients, the biggest benefit of
versionbits, concurrent activation, is gone. If I were wanting to signallnhancebut in the meantimeBIP-110activates, I have to at one point either stop signaling, or hope that without mistakes, thelnhanceactivation client updates to supportBIP-110... this is a crap situation. ↩
Thanks for the summary. I suppose it's a good thing for Bitcoin to get tested in this way -- an aggressive minority pushing for a kinda bonkers soft fork.
Actually, thinking more about it, and having had a look at BIP 9 again, the “flag day activation” description is not correct. lockinontimeout is implemented as a period of mandatory signaling in the last eligible difficulty period. If a minority of the hashrate were trying to enforce mandatory signaling then, there could be some reorgs in that difficulty period if any non-signaling blocks were reorged out by the soft forking hashrate. If the soft forking nodes were supported by a minority of the hashrate, they would already fork themselves off on a minority chain during the mandatory signaling rather than at activation, likely with very few or no reorgs, as they’d have to find two blocks before the rest of the network finds one.
I don't see that in the code, I think
My bad, I should have stated my assumptions, especially given that my assumption appears to have been incorrect.
BIP 9 does not have the lockinontimeout mechanism as it was introduced later by BIP 8. I assumed that RDTS was going to reuse the semantics of BIP 8 which enforce activation by mandatory signaling, but it appears that this assumption was incorrect, instead RDTS appears to simply switch to LOCKED_IN one difficulty period and a block before the max activation height, so a flag day activation was actually a fitting description.
If you're polling for a bit in the block header then I don't see how this has anything to do with user activation. I'll go through the diff against knots some time this week, and hope that Knots doesn't have any hidden triggers vs core, because the range diff against Core is just too big to analyze.
but UASF sounds cool and badass.
besides, hasn't the filter thing been about semantics all along? calling valid transaction spam, calling policy rules Bitcoin rules...
It's a UASF in spirit just like spam is not a "real" monetary transaction.
deleted by author
It's not just "in our minds"; that's actually what's happening. Miners need to weigh the cost of enforcing the new rules versus the risk of having their blocks orphaned by other nodes enforcing the new rules. It would be reckless not to enforce the new rules, once a large enough number of nodes is doing so.
Does it mean that this is a User Signaled Miner Activated Soft Fork?
Like in their minds they think running BIP 110 starts a window in which users can try to convince miners to go along with them and run BIP 110?
Maybe they did it this way because they don't believe they will have enough support and are afraid of getting themselves forked off, so instead they try to make it "consequence-free" to run the release candidate?
Everybody who wants to talk a big game about spam can run this without being afraid they are going to end up on some stupid minority chain with no hash rate.
I am not good at reading code, though, so perhaps I have woefully misunderstood things. (I couldn't even come up with a better acronym for it than USMASF?)