Yes, you can't tell people what code to write/not write.

It's more about having the Bitcoin community try to define what code they want to run and then funding new implementations that are willing to follow at least some of the rules.

There can also be bounties for devs who read the opensource repo and find bugs/find places where the agreed upon rules are not being followed.

For example, Bitcoin Core removed the definition of Bitcoin from their GitHub repository, so they're changing something they can't define or won't define because their definition might get backlash.

You need to at least define what Bitcoin is, what is changeable, what is not changeable to be considered a serious implementation.

Reply to this note

Please Login to reply.

Discussion

But to be clear, I wrote the article as a draft, in like 1 hour, in a busy morning. I was hoping that someone (with a larger audience) would take some of the ideas and write a better one.

I agree with most points you mentioned. I would be very tempted to define it simply as :

- No changes unless to fix an existential bug or problem (possibly quantum at some point).

A third implementation that is extremely conservative would be wonderful in my opinion. It would probably have to start with Core version 28 (no later than v28).

Adam Simecka seems to feel that way too and he has a fairly substantial presence on X, but I can't find him here on Nostr.

https://xcancel.com/AdamSimecka/status/1985405874031194290#m