--- Comment #56 from Oleg Girko <ol+redhat(a)infoserver.lv> ---
(In reply to Warren Togami from comment #55)
> So far this threat is purely theoretical, there were no incidents related to that.
This is incorrect. Some alt coins like PPC suffered exactly a catastrophic
fork because they disregarded warnings in this regard.
I was not talking about minor altcoins with very low adoption rate. They suffer
from more serious problems, like being vulnerable to 51% attacks. Also, they
suffer from lack of developer resources and accumulate technical debt much
quicker as a result. Hence, I'm not surprised that among thousands of altcoins
you can find one that suffered because of this problem. You can find even more
altcoins that suffered much worse problems because of bugs in their code
The diversity argument is counter to the opinion of among Bitcoin
Yes, I know. But this doesn't automatically mean that Bitcoin Core developers
are right. Ethereum developers have radically different opinion, for example.
Debating the diversity of implementations issue is not
I'm not debating diversity of implementations. I'm just using this argument to
point to the fact that insisting on using particular versions of libraries is
not an acceptable way to build reliable software. Unfortunately, it's becoming
quite common mindset among developers: "I've tested my program with these
particular versions of libraries, hence everyone should use them". Yes, this
makes life easier for developers, but complicates life for everyone else.
There is a good reason Fedora has a strong attitude against bundling of
libraries. Upstream developers are usually not proficient enough to update all
libraries they use in a timely manner. Maintainers of library packages are more
proficient in this. If a remotely exploitable vulnerability is found in one of
many libraries Bitcoin Core uses, it will take much more time for new version
of Bitcoin Core to be released and packaged than for new version of this
particular library packaged in Fedora. Very often Fedora gets patched package
even before upstream releases a new version.
Hence, if my argument about beneficial diversity is not enough for you, I have
a much stronger argument: vulnerability in a bundled library.
Remotely exploitable vulnerability is a true nightmare scenario for a
cryptocurrency software, because it can lead to massive theft of funds.
Unintended forks are just a nuisance compared to that. Even large-scale fork
can lead just to temporary outage and increased time to reach consensus. Some
transactions may be remaining in the mempool for a long time or even lost, so
they have to be repeated later, but it's very unlikely that funds will be lost
or stolen as a result. Single cases of double spend that can happen during an
outage like this (that will be resolved when the fork is over anyway) are
nothing compared to mass theft of funds.
Considering a very minor fraction of nodes that will run Fedora-packaged
Bitcoin Core, a theoretical fork involving these nodes will not be even
large-scale. In worst case scenario, small percentage of nodes will be
temporarily banned from the network until the problem is fixed. And probability
of this is still lower than an unpatched vulnerability in a library Bitcoin
uses. And packaging procedures in Fedora are well suited exactly to mitigate
risks like this.
I ask that folks please defer to upstream Bitcoin Core
developer opinions on the wisdom and safety of how to ship Bitcoin Core in
As a former Dash Core developer, I strongly disagree. Bitcoin Core deveopers'
"wisdom" prevented Bitcoin Core client from being shipped in downstream
distributions at all for 12 years already.
> I'm fine with your proposal, but the original bug report for the review is open
since 2013, and apart high level things that should be done or not done I've not seen
much from you on the topic.
Upstream did not have a feasible build method until recently. I am sorry
this took so long. I also recognize this is extremely weird compared to the
normal way software is built in Fedora. The upstream developers felt so
strong about this that it was preferable to have no Bitcoin in the leading
Linux distros all these years. Now however we are close to a satisfactory
solution. I ask for a bit more patience.
I don't think that building with all libraries bundled is satisfactory
solution. At least, not for me. So, let's package Bitcoin Core client according
to Fedora guidelines for now. However, I'm not against providing a bundled
version as another option when it's available. I'm just against having this as
the only option (and no option at all for quite a long time before it's
available). Let users decide which slightly increased risk they prefer to take:
minor fork and temporary ban or remotely exploitable vulnerability.
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