On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
> We have seen that the consensus critical code practically extends to
> Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a
> consensus library is not the same as Bitcoin Core, less its P2P service
> rules, wallet and RPC server.

You can describe 'A' from a group of A, B, C, D, E as "the group minus B, C, 
D, E", sure - but I don't see how this is relevant?

UTXO storage is indeed consensus critical, as you say, but it is a lot simpler 
to get right than the rest combined. Thus, the end goal is to have a 
libbitcoinconsensus with "the rest", and a (as of yet named) 
libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally, 
software should use the latter when it is available, but if there is a strong 
reason to change UTXO storage, one can remain mostly-safe with just the 
former. I'm not sure why this topic is of relevance, though...


Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Bitcoin-development mailing list

Reply via email to