From: Peter R <peter_r@gmx•com>
To: Luke Dashjr <luke@dashjr•org>
Cc: bitcoin-dev@lists•linuxfoundation.org,
telemaco <telemaco@neomailbox•net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Date: Sat, 14 Nov 2015 19:17:08 -0800 [thread overview]
Message-ID: <F2D5CE08-FEF1-4E56-8B76-3E7964FC1C7B@gmx.com> (raw)
In-Reply-To: <201511150304.41003.luke@dashjr.org>
> 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
next prev parent reply other threads:[~2015-11-15 3:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 6:57 telemaco
2015-10-29 8:03 ` Luke Dashjr
2015-10-30 3:04 ` Simon Liu
2015-10-30 3:35 ` Gregory Maxwell
2015-10-30 4:04 ` Peter R
2015-10-30 4:28 ` Gregory Maxwell
2015-11-15 1:02 ` Peter R
2015-11-15 1:08 ` Gregory Maxwell
2015-11-15 1:45 ` Peter R
2015-11-15 2:10 ` Gregory Maxwell
2015-11-15 2:58 ` Peter R
2015-11-15 3:30 ` Gregory Maxwell
2015-11-15 4:10 ` Peter R
2015-11-15 10:12 ` Jorge Timón
2015-11-15 11:28 ` Jorge Timón
2015-11-15 15:48 ` Peter R
2015-11-15 17:06 ` Peter R
2015-11-17 13:54 ` Tamas Blummer
2015-11-17 15:24 ` Tom Harding
2015-11-17 22:17 ` telemaco
2015-11-20 14:15 ` Jorge Timón
2015-11-16 1:52 ` Rusty Russell
2015-11-15 3:04 ` Luke Dashjr
2015-11-15 3:17 ` Peter R [this message]
2015-10-29 8:17 ` Gregory Maxwell
-- strict thread matches above, loose matches on Subject: below --
2015-10-22 21:26 Jeff Garzik
2015-10-22 21:54 ` Patrick Strateman
2015-10-22 21:56 ` Joseph Gleason ⑈
2015-10-23 6:53 ` Jonas Schnelli
2015-10-23 7:45 ` Lucas Betschart
2015-10-28 20:28 ` Sean Lynch
2015-10-28 21:11 ` Jeff Garzik
2015-10-23 10:30 ` Tom Zander
2015-10-26 18:06 ` Douglas Roark
2015-10-28 15:52 ` Tom Zander
2015-11-18 0:06 ` Jonathan Wilkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F2D5CE08-FEF1-4E56-8B76-3E7964FC1C7B@gmx.com \
--to=peter_r@gmx$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
--cc=telemaco@neomailbox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox