Peter R [ARCHIVE] on Nostr: đź“… Original date posted:2015-11-15 đź“ť Original message:> On Sunday, November 15, ...
đź“… Original date posted:2015-11-15
đź“ť Original message:> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
>> A group of us have been exploring this “meta-cognition” idea with Bitcoin
>> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to
>> automatically fork to the longest chain if it “gets stuck” and can neither
>> prove that a block is valid nor that the block is invalid.
>
> This situation isn't something that can be ignored and simply moved past. If
> you can't determine the validity of a block, you also cannot process its
> results correctly. Taking for example the BDB/LevelDB issue, the result was
> that BDB failed to accept further changes to the UTXO set. Unless the UTXO set
> could be updated correctly, there is no way to even attempt to validate the
> next block or any new transactions.
Great point, Luke!
Indeed, whether the program can or cannot continue after a Type 1 consensus mismatch depends on the specifics of the situation and exactly how the code was written. But I agree: there are cases where the program *can’t* continue. In those cases it would halt. This would require manual intervention to fix but avoids the problem of potential double-spends during the fork event. This would be preferable to knowingly causing a fork.
Peter
đź“ť Original message:> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
>> A group of us have been exploring this “meta-cognition” idea with Bitcoin
>> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to
>> automatically fork to the longest chain if it “gets stuck” and can neither
>> prove that a block is valid nor that the block is invalid.
>
> This situation isn't something that can be ignored and simply moved past. If
> you can't determine the validity of a block, you also cannot process its
> results correctly. Taking for example the BDB/LevelDB issue, the result was
> that BDB failed to accept further changes to the UTXO set. Unless the UTXO set
> could be updated correctly, there is no way to even attempt to validate the
> next block or any new transactions.
Great point, Luke!
Indeed, whether the program can or cannot continue after a Type 1 consensus mismatch depends on the specifics of the situation and exactly how the code was written. But I agree: there are cases where the program *can’t* continue. In those cases it would halt. This would require manual intervention to fix but avoids the problem of potential double-spends during the fork event. This would be preferable to knowingly causing a fork.
Peter