DISCUSS: "Consensus is achieved by running code" \ stacker news ~bitcoin

pull down to refresh

DISCUSS: "Consensus is achieved by running code"x.com/mike_4131/status/1964714770294329539

1238 sats \ 12 comments \ @Scoresby 7 Sep bitcoin

I am impressed by the idea of rough consensus (#1208380). It seems good to me that Bitcoin has no real clear governance or instructions for upgrading.

However, it's interesting to ask if there is a role for just running the code you want to see. To that end, here is an interesting post by mike on X:

There is no such thing as rough consensus, it's been argued for 4 years now in respect to covenants and gotten nowhere. Adam pushed for this, and "technical consensus" too and none of these terms mean anything

I originally disagreed with Jeremy's approach to threaten an activation attempt, I thought it was rogue and fundamentally an attack

I now see my view was wrong. You don't reach consensus before hand. Consensus is determined actively by running code

What do you think?

view all related items

305 sats \ 5 replies \ @optimism 7 Sep

I don't want to narrate too much around this, so I'm just going to do this pointwise.

Bitcoin does not run under rough consensus, it runs under absolute consensus. That's why it is super-hard to build alternative fully validating software.
Bitcoin Core is developed under "rough consensus", especially when it comes to protocol changes.
Until now, all soft forks that ever made it into Bitcoin were activated through Bitcoin Core (and before that name was changed, "Bitcoin" or "bitcoind")
If Bitcoin Core ossifies, that doesn't mean that Bitcoin has to ossify, but if you want to do safe miner-enforced soft forks, you'll need something that a very large majority of miners (95% for activation in the past) is willing to run, and play that very long game. It's extremely hard to do that for something that Bitcoin Core doesn't support.
Any developer shortcut to activate (like flag day default-to-true outcomes as was proposed for BIP-8) is playing a very dangerous game, and will eventually fuck up and cause a hard fork. And if it succeeds without fucking up, Bitcoin has become a lame developer centric, governed shitcoin, like BCH or Ethereum.

So be careful what you wish for.

302 sats \ 1 reply \ @DarthCoin 14h

102 sats \ 0 replies \ @optimism 11h

Not having governance. Feature, not bug.

100 sats \ 2 replies \ @Scoresby OP 22h

Bitcoin does not run under rough consensus...Bitcoin Core is developed under "rough consensus"

This is a good way of putting it. I think my OP could have benefitted from making this distinction.

if you want to do safe miner-enforced soft forks

Is there an example of any other kind of soft fork? Have people ever done an unsafe soft fork of Bitcoin?

I think I recognize the truth of all your bullet points. In that case, I suppose it means that releasing and running code external to the Bitcoin Core process is actually a risk.

But then my question becomes, do you think a world where there is significant adoption of multiple implementations by miners precludes soft forks (ie soft forks are only safe to attempt while miners are mostly running the same single implementation)?

238 sats \ 1 reply \ @optimism 22h

Have people ever done an unsafe soft fork of Bitcoin?

Yes. Before devs figured out how to do good softforks when the installed base and value at risk were infinitely smaller. BIP-16 (p2sh) wasn't miner enforced and there were some early Satoshi-made hard forks. Can't think of another example right now. But wishing for that mechanism now is imho really risky and I feel strongly that as users of Bitcoin (and miners) "we" should reject nonsense like that every single time. "95% or gtfo" as an attitude could really help with long-term stability, which, imho, is way more important than, say, CTV. If every softfork becomes an existential risk due to it turning into hardfork drama, like segwit2x, then that's bad for Bitcoin, imho.

I suppose it means that releasing and running code external to the Bitcoin Core process is actually a risk.

As long as a massive majority of miners runs Bitcoin Core, it could be a risk if you're relying on it and there's a bug in the software that you don't know about. But we know that for example btcd is well tested (also: #1206628) and is (or was, haven't checked in a while) regularly fuzzed, so it's not high-risk. I hope the same for libbitcoin, when it's ready.

But then my question becomes, do you think a world where there is significant adoption of multiple implementations by miners precludes soft forks (ie soft forks are only safe to attempt while miners are mostly running the same single implementation)?

It can work if these softforks are implemented and well-tested by all the different implementations. But note that this shifts the problem from having to argue on bitcoin/bitcoin, to having to argue elsewhere. For a while now, some of the more vocal bitcoin devs seem to be rather high on their retarded power trips. As long as that's the case, I don't think we'll see a successful softfork, but I'm open to miracles.

That said, there is something to be said about just forking Bitcoin Core and seeing who will run a signaling node. See who picks up on it. But if you do it while there are unaddressed concerns on Bitcoin Core (rough consensus means everything is addressed, not that everything is agreed upon) then that's a massive hurdle to overcome.

100 sats \ 0 replies \ @Scoresby OP 21h

Thanks for this answer. I'm always learning more about bitcoin.

I am going to think on the "95% or gtfo" motto. It has a ring to it...

283 sats \ 0 replies \ @028559d218 7 Sep

Consensus is determined by code, fees, blockspace, and economic demand.

If all the 'bitcoin is money' people used bitcoin as money, transactionally, at least semi-regularly, we would have way less spam and we wouldn't even be having these "debates."

People will tell you "we need to keep the chain clean" and "bitcoin is money..." while rarely using it as such. If only a small percentage of Earth's population were using Bitcoin on a regular basis the fees would be way higher, miner revenue more robust, miner centralization in better shape, and the 'censorship resistance' tested more thoroughly and more completely.

So where are these people???

210 sats \ 3 replies \ @SimpleStacker 7 Sep

I might be a bit confused about how you're using the word consensus.

My interpretation of "consensus" in a bitcoin context is the rules by which nodes determine whether a block is valid or not, and which chain is the true chain.

To that end, it doesn't matter what software you run -- you could even be doing it by hand -- as long as you accept the blocks that everyone else accepts as valid, you are in "consensus".

100 sats \ 2 replies \ @Scoresby OP 7 Sep

I think Mike's post is about coming to consensus on changes to the protocol.

For instance, prior to taproot, taproot addresses were not consensus. Now they are. How did we get here?

What I found thought provoking was that he seems to be implying that if we are going to operate under rough consensus, releasing and running code may be an important tool.

100 sats \ 1 reply \ @SimpleStacker 22h

I thought taproot was a soft fork though? Meaning, taproot addresses were consensus (at the protocol level, and thus older nodes see them as valid), but older nodes just wouldn't understand how to operate with them?

If by consensus you mean social consensus and not protocol consensus, then I agree, it's achieved by just running code. But if a group starts running code that is not within protocol consensus, we end up with a hard fork and two chains.

50 sats \ 0 replies \ @optimism 21h

Meaning, taproot addresses were consensus (at the protocol level, and thus older nodes see them as valid)

Simplified: Non-taproot enabled node skips spending constraints in the script: "the output of this tx doesn't spend more than the input, but i cannot check the witness program because it is undefined for me, so whatever."

If a set of miners would run these non-taproot nodes, then you could spend my taproot output in their blocks, because the constraint that only I can spend my output is in the taproot script. And of course enforcing miners would not accept these blocks, so you'd have chaintip fork galore. This to my memory happened with CSV due to unupdated block template construction scripts.

Therefore, softforks are consensus updates and they only work if all miners enforce them. If you don't get a very high adoption from miners, then the new feature is useless.

10 sats \ 0 replies \ @nitter 7 Sep

https://xcancel.com/mike_4131/status/1964714770294329539