0 sats \ 2 replies \ @ek 28 Oct 2022 \ parent \ on: Are alternate Bitcoin implementations dangerous? bitcoin
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.
-- https://bitcointalk.org/index.php?topic=195.msg1611#msg1611
Exactly. tl;dr: if you accept a block as valid due to a bug that others reject, you're forked and the world ends.
-- https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-November/006878.html
(reused the links from the original post)
write
preview
5 sats \ 1 reply \ @nerd2ninja 28 Oct 2022
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
0 sats \ 0 replies \ @ek 28 Oct 2022
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