Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db

[Peter R <peter_r@gmx.com>]

> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 
> On Sun, Nov 15, 2015 at 1:02 AM, Peter R <peter_r@gmx.com> wrote:
>> Hi Greg,
>> 
>> Like you said, the issue with using more than one database technology is not that one node would prove that Block X is valid while the another node proves that Block X is NOT valid.  Instead, the problem is that one node might say “valid” while the other node says “I don’t know.”
> 
> Sometimes errors are such that you can catch them (if you're super
> vigilant and know an error is even possible in that case)-- and
> indeed, in that case you can get a "I don't know, something is
> wrong.", other times errors are undetectable.

Agreed.  There are two cases to consider:

Type 1.  One implementation says “yes” or “no,” while the other says “I don’t know”, and

Type 2.  One implementation says “yes” and the other says “no,” because of a bug.  

My previous email described how Type 1 consensus failures can be safely dealt with.  These include many kinds of database exceptions (e.g., the LevelDB fork at block #225,430), or consensus mismatches regarding the max size of a block.  

Type 2 consensus failures are more severe but also less likely (I’m not aware of a Type 2 consensus failure besides the 92 million bitcoin bug from August 2010).  If Core was to accept a rogue TX that created another 92 million bitcoins, I think it would be a good thing if the other implementations forked away from it (we don’t want bug-for-bug compatibility here).   

This once again reveals the benefits of multiple competing implementations.  

Sincerely,
Peter