pull down to refresh

I am pro multiple implementations. A situation where core has to adapt to an alternative implementation, is a situation where we don't have to accept the structure of how code is merged to core as the government of our money.
That being said, I do believe the way core does review BIPS and merge them to core is the best implementation we have, so I don't really feel like jumping to a different implementation XD
This. YESSSSSS! Decentralize the whole stack!
reply
Core will most likely never need to adapt. It can keep running its own rules while everyone else either forks away or also uses the same rules.
What we call Bitcoin will most likely be decided by who is compatible with the previous rules which were defined by core, the reference implementation.
reply
This assertion assumes core is the dominant implementation. It doesn't have to be, and a future of disagreeable developers could drive a shift to the alternative implementations which would make core the minority implementation.
reply
Well, it is the dominant implementation. Yes, you can argue that this could change but I don't see how or why. Why would it need to change? If bitcoin is based on consensus, we all have to run the same code anyway (doesn't matter which programming language). Why take the risk to fork or rewrite core if what you end up with is code which requires to do the same as core or you just created a fork or risk your transactions not being valid to core nodes.
Other arguments:
A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.
I know, most developers don't like their software forked, but I have real technical reasons in this case.
Exactly. tl;dr: if you accept a block as valid due to a bug that others reject, you're forked and the world ends.
(reused the links from the original post)
reply
You didn't make any new points.
Yes it is the dominant implementation, and I currently like the core developers, but human nature being what it is, at some point there will be some key developer who determines who gets added and who gets kicked from the core repo who turns arrogant and ignores social consensus. Yes that is not the case now but don't miss the point.
Now, a new point. I like the idea of super soft forks. Wherein an alternative implementation soft forks, rather than merge with the majority implementation. If the soft fork has a bug that hard forks them from consensus, instead of accepting the bug as consensus, we can just fix the bug. Yes this would mean you'd be forked until the fix came in (or you imported your private keys to a working implementation in the meantime), but while it was working you had access to use a soft fork feature that the majority didn't have and the majority keeps their security in the meantime.
Being forked also doesn't mean the world ends. You just have to understand what you're getting yourself into and accept the risks with as much mitigation as you can.
reply
Yes it is the dominant implementation, and I currently like the core developers, but human nature being what it is, at some point there will be some key developer who determines who gets added and who gets kicked from the core repo who turns arrogant and ignores social consensus. Yes that is not the case now but don't miss the point.
Now, a new point. I like the idea of super soft forks. [...]
Both are fair points.
Being forked also doesn't mean the world ends. You just have to understand what you're getting yourself into and accept the risks with as much mitigation as you can.
That's where I disagree.
But I think we can agree to disagree :)
reply