Peter R [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-14 📝 Original message:> On Nov 14, 2015, at 5:08 ...
📅 Original date posted:2015-11-14
📝 Original message:> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> On Sun, Nov 15, 2015 at 1:02 AM, Peter R <peter_r at 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
📝 Original message:> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
>
> On Sun, Nov 15, 2015 at 1:02 AM, Peter R <peter_r at 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