pull down to refresh
You're apparently assuming that the mining signalling will remain static.
RDTS has been signaling for something like six months, but has yet to breach 1% of hashrate support. Anyone wanting a soft fork to succeed would want to signal early to shift the Overton Window and get people to prepare. The idea that miners don’t signal for six months, but suddenly start signaling at the mandatory signaling height doesn’t pass the giggle test.
the "fork off" narrative shows exactly why Core is so unpopular with certain parts of their intended userbase.
It’s the clear result of the RDTS supporters course. Committing to a flag day activation as the first and final position in a community conversation signals unwillingness to negotiate. Between getting active to enable a loud minority trying to walk all over the network or doing nothing to let them run aground, what did you think is the expected outcome?
But, externally, anything could happen with a new hard fork. We have no idea how that's going to play out. Bitcoin's reputation could take a major hit. The new chain would definitely claim to be the "monetary" Bitcoin compared to the spam, institution, and crypto-casino beholden "original" Bitcoin.
The new network’s figurehead is Luke, who has endeared himself to everyone else by famously working great with others, and calling people liar and pedo left and right for the past years. He has a history of poor security practices, publicly advocates for absolutist rule, and has zero support from the dev community and economic actors. The new network having any credibility at all will be an uphill battle. Bitcoin resisting a vocal minority imposing its will on the network will make it look more reliable if anything.
The main predicament is watching this trainwreck in slo-mo as a bunch of people who we used to respect set their social capital on fire. Sucks for the people that let themselves be suckered into this ritual self-sacrifice, but thanks, I guess.
Everyone is already running the URSF software. Whenever RDTS finds its first block and the Bitcoin chain is at least 100 blocks ahead of RDTS, the obvious thing is to call invalidateblock on the first RDTS block. It’s not in the interest of anyone to accept a reorg of 100 blocks or more.
Thanks for covering my blog post, but please don’t feel like you should cover my posts because I sometimes tune into your show. ;)
Probably the one I described in the blog post: make a low-feerate self-send on the Bitcoin chaintip, then spend the same UTXO to a different output on the RDTS chaintip.
Users forking off after being told for nine months that their action will cause them to fork off sounds like an expected outcome, not chaos.
If there is about one RDTS-compliant block per day, it will be indeed difficult to get confirmations on the RDTS chaintip. Not getting confirmations delays things and makes for a terrible user experience, but could you spell out for me how that would translate to "chaos"?
If your main concern is that data embedding increases competition for blockspace, how do you square that with feerates being under 3 s/vB for the last two years, under 1 s/vB for the last year?
Mea culpa, I posted and then amended my post to clarify my question, but you answered before I finished my edit.
What makes you think that BIP110 is happening no matter what?
Edit to clarify my question:
What I’m seeing is:
- ≤ 1% of the hashrate
- about 12% of listening nodes with the
NODE_KNOTS_BIP110_UASF (27)service bit - Basically no support from any businesses
- Basically no support from the dev community
Are you seeing something else than me?
Though if that were about to happen, I would presume miners and pools would use invalidateblock to blacklist the BIP 110 side (if total work on the BIP 110 side were to approach attaining greatest work), at least until Core did a release in response, with that protection hard-coded, or whatever other wipeout protection they'ld implement.
Why would BIP110 opponents wait that long? With the current hashrate distribution and RDTS having ≤ 1% of the hashrate, the Bitcoin chaintip will find scores of blocks before RDTS finds a single one. As you say, all the blocks mined on the Bitcoin chaintip would be at risk of being reorged if RDTS ever pulled ahead. It seems obvious that a reorg of 100 block depth would be unacceptable to the network. The reasonable thing would be to nip it in the bud immediately. So, people that don’t support BIP110 should run invalidateblock on the first RDTS block once the Bitcoin chaintip has progressed 100 blocks from the mandatory signaling height. Since RDTS will be way behind at that time, people can run it safely at different times and it would work fine regardless (although I expect it to be completely unnecessary in the first place).
It’s not a stupid suggestion. It’s just harder to get right than one might think at first glance. Putting ideas out there to get people to comment on them is how we make progress at figuring it out.
I have no issue with adding a territory for it, I just don’t think that it would financially sustain itself after looking at Scoresby’s recent posts that mentioned BIPs, and most of them having a handful or fewer comments.
It certainly would be a more fruitful place than Xitter!
The simplest one to describe is only allowing zero-fee transactions if the transaction has fewer outputs than inputs, in the hope of incentivizing a reduction of the UTXO set size.
That might be too simple. This would e.g., break incentives as follows:
- Miners would be incentivized to skip inclusions of consolidatory txs, and instead only include transactions that create additional outputs, because those pay fees.
- If Miners do accept consolidatory txs for free, senders might bank a few extra outputs and then send large batched payment transactions with a bunch of extra inputs to make them free.
I’d love more people chiming in on BIPs, but how much do people actually engage with BIPs here?
"Which chain they land on" kind of sounds like they could only land in one chaintip. May I ask what you meant with that?