From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Peter R <peter_r@gmx.com>
Date: Sun, 15 Nov 2015 03:04:33 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; )
References: <5631C363.5060705@neomailbox.net>
	<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
	<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
In-Reply-To: <571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201511150304.41003.luke@dashjr.org>
Cc: telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Precedence: list

On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
> A group of us have been exploring this =E2=80=9Cmeta-cognition=E2=80=9D i=
dea with Bitcoin
> Unlimited.  For example, Bitcoin Unlimited can be (optionally) made to
> automatically fork to the longest chain if it =E2=80=9Cgets stuck=E2=80=
=9D 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. I=
f=20
you can't determine the validity of a block, you also cannot process its=20
results correctly. Taking for example the BDB/LevelDB issue, the result was=
=20
that BDB failed to accept further changes to the UTXO set. Unless the UTXO =
set=20
could be updated correctly, there is no way to even attempt to validate the=
=20
next block or any new transactions.

Luke