https://bugzilla.redhat.com/show_bug.cgi?id=1834731 --- Comment #54 from Oleg Girko <ol+redhat@xxxxxxxxxxxxx> --- I think that threat of unintentional fork due to slightly different versions of system libraries is significantly exaggerated. So far this threat is purely theoretical, there were no incidents related to that. The problem fixed with BIP66 was caused not by variations of OpenSSL behaviour between different versions, but by using OpenSSL incorrectly in Bitcoin Core client. https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki Relying on specific implementation details of particular versions of libraries is harmful because it introduces undocumented implicit consensus rules nobody knows about. And requiring using one true build of a single client does not help at all, it just hides a ticking bomb until it explodes later. An incident with unintended hard fork when migrating Bitcoin Core client from BerkleyDB to LevelDB has shown this quite prominently. https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Another lesson from this incident is that unintended forks caused by bugs in consensus rules do not cause catastrophic consequences and are resolved very quickly. And I'm pretty sure that they are beneficial in the long run because they fix hidden critical bugs that (also theoretically) can be exploited by malicious actors. Approach taken by Ethereum is much healthier. They not only don't require one true build of a single client, but they even encourage multiple client implementations. Consensus rules of Ethereum 2 beacon chain make using the most popular validator client riskier than less popular ones: more clients misbehave synchronously, bigger penalty they get. Of course, this doesn't guarantee from unintended forks caused by bugs of consensus implementation. But this causes most of these bugs to be caught early in testnet. Hence, building Bitcoin client with system libraries is only slightly riskier than using one true build, but this risk is very minor (and only theoretical so far), and this is acceptable risk. If Linux distributions adopt this approach, this will be beneficial in the long run because it will help to detect and fix bugs in consensus implementation earlier. I'm voting for adding properly built (using system libraries) Bitcoin Core client to Fedora and accepting minor risks caused by this for bigger benefit of Bitcoin ecosystem's diversity. And to show that I've already put my money where my mouth is, I use Dash Core client built the same way for almost 4 years without a single incident. https://obs.infoserver.lv/package/show/cryptocurrency/dash-core (Dash Core codebase is originally a fork of Bitcoin's one.) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
