Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-15 📝 Original message:On Sun, Nov 15, 2015 at ...
📅 Original date posted:2015-11-15
📝 Original message:On Sun, Nov 15, 2015 at 1:45 AM, Peter R <peter_r at gmx.com> wrote:
> 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.
The size of a block is not a type 1 failure. There is a clear, known,
unambiguous, and easily measured rule in the system that a block is
not permitted to have a size over a threshold. A block that violates
this threshold is invalid. The only way I can see to classify that
as a type 1 failure is to call the violation of any known system rule
a type 1 failure. "Spends a coin that was already spent" "provides a
signature that doesn't verify with the pubkey" "creates bitcoins out
of thin air" -- these are not logically different than "if size>x
return false".
> 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).
The only consensus consistency error we've ever that I would have
classified as potentially type 1 had has been the BDB locks issue.
Every other one, including the most recently fixed one (eliminated by
BIP66) was a type 2, by your description. They are _much_ more common;
because if the author understood the possible cases well enough to
create an "I don't know" case, they could have gone one step further
and fully defined it in a consistent way. The fact that an
inconsistency was possible was due to a lack of complete knowledge.
Even in the BDB locks case, I don't know that the type 1 distinction
completely applies, a lower layer piece of software threw an error
that higher layer software didn't know was possible, and so it
interpreted "I don't know" as "no"-- it's not that it chose to treat I
don't know as no, its that it wasn't authored with the possibility of
I don't know in mind, and that exceptions were used to handle general
failures (which should have been treated as no). Once you step back to
the boundary of the calling code (much less the whole application) the
"I don't know" doesn't exist anymore; there.
📝 Original message:On Sun, Nov 15, 2015 at 1:45 AM, Peter R <peter_r at gmx.com> wrote:
> 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.
The size of a block is not a type 1 failure. There is a clear, known,
unambiguous, and easily measured rule in the system that a block is
not permitted to have a size over a threshold. A block that violates
this threshold is invalid. The only way I can see to classify that
as a type 1 failure is to call the violation of any known system rule
a type 1 failure. "Spends a coin that was already spent" "provides a
signature that doesn't verify with the pubkey" "creates bitcoins out
of thin air" -- these are not logically different than "if size>x
return false".
> 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).
The only consensus consistency error we've ever that I would have
classified as potentially type 1 had has been the BDB locks issue.
Every other one, including the most recently fixed one (eliminated by
BIP66) was a type 2, by your description. They are _much_ more common;
because if the author understood the possible cases well enough to
create an "I don't know" case, they could have gone one step further
and fully defined it in a consistent way. The fact that an
inconsistency was possible was due to a lack of complete knowledge.
Even in the BDB locks case, I don't know that the type 1 distinction
completely applies, a lower layer piece of software threw an error
that higher layer software didn't know was possible, and so it
interpreted "I don't know" as "no"-- it's not that it chose to treat I
don't know as no, its that it wasn't authored with the possibility of
I don't know in mind, and that exceptions were used to handle general
failures (which should have been treated as no). Once you step back to
the boundary of the calling code (much less the whole application) the
"I don't know" doesn't exist anymore; there.