Same as RC1, with a few minor fixes:
- CI is now fully passing
- The spurious warning about Taproot being an unknown deployment has been fixed
- The node now properly requests preferred peers when querying DNS seeds
Known issues:
If you are switching an existing installation from a non-BIP110 client to this client, your node may fail to find peers. If this happens, you can delete your peers.dat file or add addnode=<any-bitcoin-node> to your config. This will be fixed in the next release.
Identical to bitcoinknots#238, except the last commit, which modifies the user agent string for this standalone release.
pull down to refresh
related posts
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.
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.
If 2016 blocks is plenty of time to upgrade, why not just have BIP 110 activate 2016 blocks from now?
You cannot be serious.
@remindme in 265 days
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?
"The network" doesn't orphan. Nodes do. People run these nodes.
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.)
So everyone that doesn't signal readiness is malicious?
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.
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.
But so does anyone that runs your code, so that's a double-edged sword?
Ah, for fuck's sake?
As if it wasn't ridiculous the first time. Censors, get the fuck out
Forking is "getting the fuck out" 😂
I mean, I guess -.-
I should have been more explicit: shut the fuck up and change your retarded mind.
Why? Let them be shitcoiners if they wanna? Better fork now than have 10 more years of the retardation?
or they just stop digging where there's nothing but pain to be had?
Stupid/trivial idea, but what if they just stop? Like right now. Go tend to their garden or whatever.
I don't want them out of Bitcoin -- we need everyone here. We just need them to stop fucking around
Why do we need everyone?
because it's money for everyone...?
#1403332
I think that's wrong. It's money for
anyone, noteveryone. Opt-in, and therefore, opt-out too.Softforking is not the same as hardforking.
BIP-110 has nothing to do with censorship. It has to do with preserving Bitcoin as money.
in this case, same thing
Bitcoin works fine as money as is. No need to fuck around
Unfortunately, this is not true. Most blockchains were never used, or are no longer used, as money. BIP-110 helps Bitcoin avoid this same fate.
oh noooo, the retards are here too!
My using of bitcoin as money hasn't been affected by the disagreeable presence you and your lot dislike so much. Has yours?
You have no response to my argument, so you resort to name-calling. Very mature.
What separates Bitcoin from other, non-monetary blockchains? Wishful thinking?
I have plenty, they are in print and on podcast.
At some point, particularly when yous operate with such blinders and obscene ideological conviction, there's nothing left but to name-call.
Please leave me alone, and may all your endeavors fail spectacularly
Feel free to continue ignoring the softfork - your node will smoothly begin to follow the new rules upon activation.
Curious decision to only make outbound connections to BIP 110 clients, when there are merely ~50 of those (per glancing at coin.dance).
This restriction will likely be relaxed in the next update. Inbound connections from non-BIP110 peers are allowed, of course.
free censor fork coins for all non retarded bitcoiners.
thanks dathom!
Dathon has been doing god's work with this BIP...!!!
Long live bitcoin and fuck you to shitcoin core and coretards.
"fork your mother if you want fork"
Chengpeng Zhao.
A lojg time ago in a galaxy far away ..
https://opensea.io/item/ethereum/0x495f947276749ce646f68ac8c248420045cb7b5e/77336740797316700504454315716535025613762697363521278226029230979302876512257
Amazing. Shutout to Dathon Ohm. bip110.org
What's amazing about it, Greg?
https://twiiit.com/dathon_ohm/status/2008326050179088775