Namecoin-Qt 3.72 - Chinese Translation Added

[phelix]

My understanding is that for blockchain-based software like Bitcoin/Namecoin, static linking has some security benefits.

Which? Any pointers? Then why are only some libraries linked statically while others aren't?

The general downside (also security-wise) is that if there's a bug in the library you'll have to re-build all statically linked programs, whereas for dynamically linked stuff it is sufficient to update only the library itself.

Peter

On windows the libraries should be linked statically/dynamically as they are for Bitcoin (built on Windows, no idea about the official build).

[biolizard89]

My understanding is that for blockchain-based software like Bitcoin/Namecoin, static linking has some security benefits.

Which? Any pointers? Then why are only some libraries linked statically while others aren't?

The general downside (also security-wise) is that if there's a bug in the library you'll have to re-build all statically linked programs, whereas for dynamically linked stuff it is sufficient to update only the library itself.

Peter

This article has a decent summary of the issues: http://bitcoinmagazine.com/5858/linux-d ... d-bitcoin/

Some of this doesn't (yet) apply to Namecoin, e.g. Namecoin doesn't yet use reproducible builds. And I'm not sure how much auditing the libs Namecoin uses go through prior to changing a version (probably not much). So this is kind of a theoretical concern right now. Just wanted to make sure people are aware of the issue.

[pmc]

This article has a decent summary of the issues: http://bitcoinmagazine.com/5858/linux-d ... d-bitcoin/

very interesting, thanks!

The reasoning in the article is basically this: subtle changes in external libraries can lead to different views on what the network-wide consensus should be wrt the blockchain. Therefore, packagers should not unbundle included libraries, and people should only use upstream binaries anyway.

While the authors of that article do have a point, IMO they're drawing the wrong conclusion:

1. In the example they're citing (BIP_0050), the problem was not caused by included libraries or by anything done by packagers. It was caused by an incompatibility between different versions of the original upstream bitcoin software.
2. As long as you're self-compiling the sources (or creating packages) it doesn't matter if you link libraries statically or dynamically. The problems they're trying to solve stem from different software versions, not from static or dynamic linking. As a packager or self-compiling person you always use the system-provided library versions anyway.
3. *coin is not the only P2P application out there, nor is it the only security-sensitive software out there. To my knowledge, no developer of other software packages draws the same conclusions, including freenetproject.org, GnuPG or iptables (to name a few popular examples).
4. Much of the trust in *coin stems from the fact that it's open source. Publishing source code and telling people to use pre-compiled binaries only is not what open source is about, though.

I think not unbundling included libraries makes sense. Static linking does not.

Peter

[snailbrain]

Chinese Translation Added - binaries not updated (and neither is official namecoinq repo - probably hold a little bit)