📅 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
Peter R [ARCHIVE] /
npub1vx…lz2gn
2023-06-07 17:44:53
in reply to nevent1q…622m
Author Public Key
npub1vxzlqg5f7ykqr3hheqxdcqe35q02a8rr2mez30sjaldhlvu4hsvsqlz2gnPublished at
2023-06-07 17:44:53Event JSON
{
"id": "0fcd259ae6b25cbadab1f033f5fa78cd80c45309501ee37b8324770ea5e5ac18",
"pubkey": "6185f02289f12c01c6f7c80cdc0331a01eae9c6356f228be12efdb7fb395bc19",
"created_at": 1686159893,
"kind": 1,
"tags": [
[
"e",
"1210ebe800165dee2ccc94a44db020accc39bb94ffc3ab7a1da78a399947e644",
"",
"root"
],
[
"e",
"e3aec0c783d575c59ab7bc22f6ed3090b644905e5f308690790663dbd9ff2bd2",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2015-11-14\n📝 Original message:\u003e On Nov 14, 2015, at 5:08 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\u003e \n\u003e On Sun, Nov 15, 2015 at 1:02 AM, Peter R \u003cpeter_r at gmx.com\u003e wrote:\n\u003e\u003e Hi Greg,\n\u003e\u003e \n\u003e\u003e 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.”\n\u003e \n\u003e Sometimes errors are such that you can catch them (if you're super\n\u003e vigilant and know an error is even possible in that case)-- and\n\u003e indeed, in that case you can get a \"I don't know, something is\n\u003e wrong.\", other times errors are undetectable.\n\nAgreed. There are two cases to consider:\n\nType 1. One implementation says “yes” or “no,” while the other says “I don’t know”, and\n\nType 2. One implementation says “yes” and the other says “no,” because of a bug. \n\nMy 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. \n\nType 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). \n\nThis once again reveals the benefits of multiple competing implementations. \n\nSincerely,\nPeter",
"sig": "92308385b4766d2239e7a096f86782834d4c4fb604fd9267b8d059e9315e6f45939f7d443965b27f20711c9a13c7895614192d30e350d80f86cacf05101c6d8b"
}