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... Luke ------------------------------------------------------------------------------ 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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
