MIME-Version: 1.0
In-Reply-To: <571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
References: <5631C363.5060705@neomailbox.net>
	<201510290803.52734.luke@dashjr.org>
	<5632DE33.7030600@bitcartel.com>
	<CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
	<3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com>
	<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
	<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
Date: Sun, 15 Nov 2015 01:08:16 +0000
Message-ID: <CAAS2fgTLE1cpDqKTiy0r1VMex7zTAB8tgUC=Y0WXmbNBJL42xQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter R <peter_r@gmx.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Precedence: list

On Sun, Nov 15, 2015 at 1:02 AM, Peter R <peter_r@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 mi=
ght say =E2=80=9Cvalid=E2=80=9D while the other node says =E2=80=9CI don=E2=
=80=99t know.=E2=80=9D

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.

> In reality, this fear is largely unfounded.

I cited an issue in leveldb (before we used it) where it would
silently fail to return records.

> If the software was written with the philosophy that tracking consensus w=
as more important than bug-for-bug compatibility, it would have returned an=
 exception rather than =E2=80=9Cinvalid.=E2=80=9D

That invariant requires the software to be completely free of errors
that would violate it.