Every epoch we delight stackers with the news that nothing changes yet... until it does, of course.
Last epoch we got a BIP-110 block late in the period, and thus we thought that perhaps reporting a little later into this period would mean that we'd have more to show than zero blocks for any activation clients. We were wrong; there is currently no momentum for any activation client.
We've also found no orphaned blocks with an activation bit set on any of our nodes, and @0xB10C's fabulous fork.observer project agrees with this assessment - the only stale was between Foundry and F2Pool. We suggest that this means that at this time, there is no evidence of anything being suppressed.
Bottom line, this epoch will once more be incapable of effectuating any changes, because more than 907 blocks (1721 at the time of writing) have not signaled for any tracked version bit (the red line on None shows the threshold for this.)
We measure block versions masked with 0xE0000038 to track activation client adoption of the following clients:
- Bit 3 (
0x08): LNHANCE (0/1714 blocks thus far, can't be activated this epoch) - Bit 4 (
0x10): BIP-110 (0/1109 blocks thus far, can't be activated this epoch) - Bit 5 (
0x20): CTV (0/1815 blocks thus far, can't be activated this epoch)
Even though it seems there is not much to report, I find these reports terribly exciting! Thank you for producing them.
bitcoinknots#256makes clear what the forking intent for 110 is.What I'd be interested in learning is: who is hedging against this becoming reality and building their own compatible client, and do they find it worth the investment?
This really gets me. Luke said this thing again a couple days ago on X, and eventually agreed that it is true only if BIP 110 has a significant amount of hashrate but then immediately retreated to "there is zero reason to reject RTDS"
source
it is not the case that you must implement your own rejection fork if you do not like BIP 110.
Implicitly, I think his position is that without RDTS, the main chain will become so unusable/undesirable that only the RDTS chain will survive to achieve bitcoin's intended purpose, even if it falls behind in chainwork for a time period.
I think he might be waiting for an extremely long time, possibly infinity. Blockspace is not in high demand, so there's no immediate reason for people to adopt RDTS. And it's not clear when/if demand for blockspace will recover. Lightning continues to mature.
In fact, I"m a lot more worried about lack of demand for monetary transactions, as a threat to Bitcoin's future, than I am about too much demand for storing data on the chain.
If such is his position (and I think it's as good an interpretation as any) I still think it's not being entirely honest to say that people must counterfork...indeed, to flash a warning that if you don't counterfork or else you will be "insecure." That just sounds like trying to scare people into doing what you want them to do.
Either way if you don't want to be on an island, you don't make "your own hardfork". You need consensus on what that hard fork will be.
But a hard fork is not the only solution. You can position for doublespending your coin as long as there is a split chaintip. Every sat that is valid on both chaintips you can spend to a 1-byte-too-large OP_RETURN (must be a scriptPubKey solution.) Or funnier, you can orchestrate a massive coinjoin on their tip with a single doublespent utxo in the history and then all the involved coins will be doublespendable.
Doublespend as a service, anyone? You pay my coordinator 10k sats, I coinjoin you in with my unspendable utxo on mainchain and woop, now you have mutually incompatible sats on both chaintips as insurance for a rollback. And this is just a basic mitigation.
If Luke & co thought that they can
fawithout thefo... lmaoYeah, I agree that that "Caution" pop up is inappropriately worded.
I try to not read Luke's words anymore because they make me very very sad from an empathy pov. I can't help him. That last sentence in the last reply sets out the massive barrier sitting between my sympathy and Luke's current worldview.
https://twiiit.com/LukeDashjr/status/2033589689941156160
Signaling will begin at the end of this month according to the parameters defined in the activation client.
// Deployment of CTV (BIP-119) consensus.vDeployments[Consensus::DEPLOYMENT_CTV].bit = 5; consensus.vDeployments[Consensus::DEPLOYMENT_CTV].nStartTime = 1774809000; // 30 March 2026 consensus.vDeployments[Consensus::DEPLOYMENT_CTV].nTimeout = 1806345000; // 30 March 2027 consensus.vDeployments[Consensus::DEPLOYMENT_CTV].min_activation_height = 1001952; // May 2027 consensus.vDeployments[Consensus::DEPLOYMENT_CTV].threshold = 1815; // 90% consensus.vDeployments[Consensus::DEPLOYMENT_CTV].period = 2016;Thanks - missed that!