pull down to refresh
This doesn't split the network. It just means that any miners still mining blocks using the old rules will have their blocks orphaned by 55% of the hashrate. It is very unlikely that miners will take this risk.
If that's the expectation then it can be set at 95% too?
I have not heard a convincing rationale as to why this would be better.
Minimizing disruption?
A 55% threshold will not cause disruption. Everyone will have plenty of time to upgrade.
You do know that just repeating this claim like a mantra doesn’t actually make it so, right?
If someone can argue coherently as to why it's wrong, I will change my mind. I have only heard incoherent FUD up until now.
Incoherent FUD like this proposed guide?
If 2016 blocks is plenty of time to upgrade, why not just have BIP 110 activate 2016 blocks from now?
You cannot be serious.
serious as:
Social consensus is overwhelmingly in favor of rejecting data storage as a use case, and BIP-110 is the best way to accomplish this. If someone finds a better way, I will withdraw BIP-110. Failing that, there is absolutely no reason to oppose BIP-110.
Isn't it the case that waiting to activate until you see 95% of miners signalling reduces the likelihood of lengthy reorgs?
at 55% of miners, there are still a large chunk of miners who will be mining non-BIP-110 blocks. the 55% will have to reorg out these blocks every time they occur. This seems like it would be a pretty messy process and could go on for quite some time.
I would expect such a situation to result in very few people making any transactions at all, because confirmation becomes highly unreliable.
"at 55% of miners, there are still a large chunk of miners who will be mining non-BIP-110 blocks"
This is a very dubious claim. Why would any miner waste money like this?
Remember, all miners have 2 weeks to upgrade once lock-in occurs, before their blocks will start being orphaned by the network.
So once we have a difficulty period with at least 1109 blocks that signal for BIP 110, we have another 2016 blocks before lock-in occurs?
Does this mean that if there is a difficulty period with at least 1109 blocks signaling for BIP 110, even if the next difficulty period has less than 1109 blocks signaling for BIP 110, then people running the BIP 110 rc will start enforcing BIP 110 rules at the beginning of the next difficulty period?
So, once activated, BIP 110 rules won't be enforced on blocks until the 2017th block?
Lock-in occurs immediately once there is a two-week difficulty adjustment period with at least 1109 signaling blocks. Activation occurs two weeks after lock-in.
There will be a period of mandatory signaling two weeks before the last possible lock-in, which is two weeks before the mandatory activation height.
Does this mean that if there is a difficulty period with at least 1109 blocks signaling for BIP 110, even if the next difficulty period has less than 1109 blocks signaling for BIP 110, then people running the BIP 110 rc will start enforcing BIP 110 rules at the beginning of the next difficulty period?
Yes.
So, once activated, BIP 110 rules won't be enforced on blocks until the 2017th block?
If you mean "once locked in" rather than "once activated", then the answer is yes. "Activation" means the new rules are immediately enforced.
In this case, 55% of the hashrate would be doing the orphaning. That is "the network" by any practical definition.
If I run the BIP 110 rc2 will it enforce the new rules if anything less than 55% of miners are also running it?
It will activate unconditionally on ~Sep 1, 2026 if miners do not signal readiness before then.
If the 55% threshold is reached sooner, then the new rules will activate sooner.
So the plan is to either convince x% of the miners in an epoch, which is why your threshold is so low, because you know you cannot make this less controversial than it is, and if you don't get that, then an economic nodes majority will kick in and your camp will just fork off on a chaintip with whatever miners you can convince that will then stop cooperating with the majority.
I must admit, we're going to learn a lot from this.
The threshold is lower than usual mostly to prevent malicious miners from vetoing the change, which we have seen with past miner-activated softfork attempts. If 55% of the hashpower is ready to change the rules, then there is no reason to wait any longer than that.
Seems to me that if there are "malicious miners" they might be willing to try to "waste money" (as you called it in another comment) and refuse to shift over to BIP 110.
You seem to be arguing that few miners would be willing to lose money mining non-BIP 110 blocks after activation BUT also that some significant portion of miners is willing to act maliciously toward BIP 110.
Considering the amount of false signaling we saw before segwit and taproot activation, 55% signaling could easily be reached with less than a majority of the hashrate enforcing the new rules. (Assuming there were an expectation for this proposal to come anywhere close to that level of signaling.)
Do you have more data on false signaling? I presume it should be straightforward to identify miners who are doing this.
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?)
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.
I'm still wondering the same thing I have since the first time this repo popped up: why is there BIP-9 parametrization to split the network at a 55% activation of bit 4 if this is a UASF?
I'm probably incredibly stupid for not understanding this.