reply on: Undeprecate datacarrier PR rationale - @schmidty \ stacker news ~bitcoin

pull down to refresh

17 sats \ 9 replies \ @optimism 2h \ parent \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin

I'll try.

One of my reasonings for deprecating is that any bad decisions have a more isolated impact

Yes, but it will also be more chaotic. What I'm pointing to is that in a fragmented node software landscape, it will be easier for softforks to become hardforks, simply because of developer hubris / yoloing. "Miners disagreed because miners are evil". Shitcoiners can show us how crazy it can get: check out the BCH->XEC insanity.

Right now, it is easy for a Bitcoin Core dev to say "just make a signaling client for your softfork", knowing full well that since every pool except Ocean runs Core, it's not dangerous. However if this landscape becomes more fragmented, then softfork devs will be emboldened to just do that LOT=true fork, and that is a risk for the overall ecosystem, especially if you remember that Rusty, imho validly, cautioned against easy (ST) softforks, because it means the ecosystem is less developed against future trouble when someone pushes LOT=true:

But one day, a real crisis will return. We won't have an answer, and we won't have practiced: this will make the crisis far worse. Instead, if we codify "devs propose, miners activate, users override" (i.e. a LOT=true option, off by default) we'll know exactly what the process will be when miners fail to activate. It may still be messy, of course, but we'll have all the tools at hand, and we'll even know the date the crisis will come to a head.

100 sats \ 6 replies \ @justin_shocknet 2h

hmm, I can appreciate the fear of unknown unknowns, but this example seems a little contrived

Nothing stops a yolo dev from pushing a hardfork today, nor a miner from running it. And afaik most miners are implementation forked for template tuning already.

Miners are disincentivized from mining bad blocks, hardforking therefore requires intent, or carelessness... Distribution is only a soft-impediment to accidental hardfork.

Now sure "updating" in a post-Core era could be a footgun for the careless, because it shakes up distribution... but I'd think that both transitory and extremely isolated.

What I see as most likely happening is that implementations get a little more splintered and niche, and what ultimately "replaces" core is a smaller footprint consensus library or test vectors.

102 sats \ 5 replies \ @optimism 1h

I'd think that both transitory and extremely isolated.

Everything landed okay-ish after the blocksize war so besides time nothing was wasted, except maybe the invention of LOT itself, which is imho an abomination. It's seen a lot of discussion and was at some point proposed for taproot activation, but we got ST in its place.

I do agree that this isn't a reason to not move forward with any decentralization though. And it's easy for anyone to use this fear against the current power that has vested in Core.

202 sats \ 4 replies \ @justin_shocknet 1h

SegWit discount may still manifest itself as a much bigger problem than is understood today, and that was a result of compromise... Compromise being a dereliction of principles and "weak men creating hard times".

I'm not in the weeds enough to know the LOT history but I assume it's a similar story. These types of compromises only happen because of Core's positioning and the battlefield it's become as a result.

Without Core, no one has to compromise, it's a level field for ideas to compete on.

146 sats \ 3 replies \ @optimism 41m

If you're a pool, you can kill segwit discount today if you want to. You anyway need the witness data before you create your blocktemplate, so you can just calculate the inclusion fee as absolute per-byte. Fees aren't part of consensus. You can also enforce 1MB block space to include witness data. Your block template, your choice.

100 sats \ 2 replies \ @justin_shocknet 15m

But the centralized distribution of Core normalized it, where it wasn't before. Miners being rational market actors had the market rules changed on them by a politburo, one that leads the auto-downloaders.

Can't on the one hand worry about chaos by multiple distributions while ignoring the chaos caused by a universal one.

0 sats \ 1 reply \ @optimism 12m

We can do a little experiment - though it will take some time to code up - where we dump mempool, recalculate without segwit discount, and see what happens to transaction ordering. If there is more money in it for miners, especially with current fee regime, then I don't see any reason why they wouldn't want to patch.

0 sats \ 0 replies \ @justin_shocknet 3m

Possible, but trying to get the genie back in the bottle isn't something we want to rely on with future changes. The threshold for letting it out in the first place needs to be higher than a few salaried devs punching a clock having the keys just because they usurped a given GitHub repo.

117 sats \ 1 reply \ @tomlaies 2h

Right now, it is easy for a Bitcoin Core dev to say "just make a signaling client for your softfork", knowing full well that since every pool except Ocean runs Core, it's not dangerous.

Miners running different code isn't dangerous. In fact, Bitcoin is fundamentally designed with different valid blocks being valid in mind.

Back in the day the people in cryptography expected not every miner having the same transactions propagated to them in time. Which is the same thing as if the blocks contents where chosen by different software.

Dont worry about it :)

0 sats \ 0 replies \ @optimism 1h

Ah! But that wasn't my point really - and we've seen on BIP68 activation that there's a lot of "SPV-mining" risk anyway, where early templates are being pre-made by some script that just builds on top of the last known header. I don't know how common that still is; I should spend more time with b10c's observer.

I'm not worried about multiple valid implementations, I'm worried about this: you soft-fork in your proof-of-chips OP_CHECKLAYSVERIFY upgrade and when your activation fails with 20% support it activates. People start verifying their chips and then someone on a non-supporting node (80% of the network) spends an utxo without verified chips. Now 20% of the network hardforked off.