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

pull down to refresh

117 sats \ 1 reply \ @tomlaies 2h \ parent \ on: Undeprecate datacarrier PR rationale - @schmidty bitcoin

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.