Are there any languages which can't call a static external c library? I think this is a solid solution and one of the things I am excited about in the latest release. To my knowledge C# (.net), Java, go, and python all support calling c libraries. Maybe we can put together some requirements (data types, etc) to ensure the library remains easily callable in a variety of languages. I hope to see libconsensus expanded significantly in the future. It is the first step forward in ensuring the safe development of alternative full nodes.
Kinda. There are hosting providers that will only allow you to run code written in some trendy language or another, with no native code libraries (I don't know the details as to why). There have been some large and high profile bitcoin services running in those hosting enviroments and thus "unable" to run native code, and thus very interested in complete reimplementation in other languages. I don't know what amount of relevance that kind of motivation will have in the future.
Anyone know if bitcoinj and other libraries intend to integrate libconsensus?
I think it's really too immature to say right now. At the moment it's just script.
Beyond libconsensus there is the idea of reducing the consensus code to a bytecode with a trivial interpreter. We're not yet sure how well this will work, but it's something people are also working towards. Libconsensus is a necessary first step which is useful even if the bytecode path doesn't work out.
Interesting. Do you have any links?
[/quote]It's mostly been IRC discussion over the last couple years-- it's a pretty low priority effort, esp since libconsensus is a hard prereq as it's unreasonable to put a whole implementation in a slow bytecode, so first the consensus parts must be completely isolated into parts with limited interaction. There has been some experiment work which has had some payoffs, e.g.
http://moxielogic.org/blog/real-world-multiply.html.
The idea is simply enough you can create a C-targetable load/store machine instruction set which can be run with a <1000 line switch statement (moxie is such an example), one which is simple enough to formally specify and even prove multiple distinct implementations mach the specification. The consensus code just gets compiled to a bytecode and then everyone can use the same bytecode. The challenge is that a simple machine has performance that may be unacceptably low, adding a general JIT like things to your VM has insane risks and makes it much harder to reason about or implement exactly. One possible solution to that is extending the architecture to add some crypto blocks similar to how many embedded processors have multimedia accelerators-- macroscopic hardcoded units that do things like perform a whole 8x8 dct-- e.g. so the instruction set is a big switch statement with a small amount of special case handling does things like compute sha256 with native code. It's relatively easy to be quite confident that an implementation of sha256's compression function is correct... other crypto implementations, less so. Hopefully its possible to add just enough native accelerators to get acceptable performance without greatly increasing the implementation complexity/risky. Otherwise the pure bytecode approach will be slow enough that people would either JIT it or replace it with a native implementation and defeat the safety gains.
