I dont think a libconsensus would have any kind of networking layer, nor is C++ an antique tool set (hopefully libconsensus can avoid a boost dependency, though thats not antique either). Ideally it would have a simple API to give it blocks and a simple API for it to inform you of what the current chain is. If you really want to get fancy maybe it has pluggable block storage, too, but I dont see why you couldnt use this in ~any client?
On 08/20/15 08:35, Tamas Blummer via bitcoin-dev wrote: > Every re-implementation, re-factoring even copy-paste introduces a risk of > disagreement, > but also open the chance of doing the work better, in the sense of software > engineering. > >> On Aug 20, 2015, at 10:06, Jorge Timón <jti...@jtimon.cc> wrote: >> >> >> But the goal is not reimplementing the consensus rules but rather >> extract them from Bitcoin Core so that nobody needs to re-implement >> them again. > > > > My goal is different. Compatibility with Bitcoin is important as I also want > to deal with Bitcoins, > but it is also imperative to be able to create and serve other block chains > with other rules and for those > I do not want to carry on the legacy of an antique tool set and a spaghetti > style. > > Bits of Proof uses scala (akka networking), java (api service), c++ (leveledb > and now libconsensus) > and I am eager to integrate secp256k1 (c) as soon as part of consensus. The > choices were > made because each piece appears best in what they do. > > Tamas Blummer > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
