[Bug 1834731] Review Request: bitcoin - Peer to Peer Cryptographic Currency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux