> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > > On Sun, Nov 15, 2015 at 1:02 AM, Peter R <pete...@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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
