From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EC35494A for ; Sun, 15 Nov 2015 02:10:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53DDCCB for ; Sun, 15 Nov 2015 02:10:44 +0000 (UTC) Received: by iouu10 with SMTP id u10so124070333iou.0 for ; Sat, 14 Nov 2015 18:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2BbPlE1Z44QoqqLQ5dCubzn1V3wPabvEFsB88bQeTCM=; b=BAC57n+U1x5QzBMZ6uGmcHbSE66RpMPmD7istVVh2iKLYp4aA3AMlRD/HNg+Pu8Wbf FUgUjlwhwHVFIiMWinN0ndG5F71iUIjKPjwMmfaOZvt6C/wsIEX6b1S3iFDDloDtMbue jLBxOUxC6zwHnCTiKvpXekrAzeul9A4CNBxdyNewOjKbjauwAcBP8ID4CN7dEvyA/YnL 3ISIbDF9G9v+6KMRZ1ACXHytFX17nMjtSSmNK1qZViWrA1B+iO3cHB7UZ0RZz12bjRwq tGaatCxiXj6/FuHuBU7eHX8Fts/zZvaRQchsaN7TGAEvJnoKi4As7oEQ6tVwHgFF7qBy BQWw== MIME-Version: 1.0 X-Received: by 10.107.4.83 with SMTP id 80mr28143033ioe.150.1447553443710; Sat, 14 Nov 2015 18:10:43 -0800 (PST) Received: by 10.107.192.199 with HTTP; Sat, 14 Nov 2015 18:10:43 -0800 (PST) In-Reply-To: <6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com> References: <5631C363.5060705@neomailbox.net> <201510290803.52734.luke@dashjr.org> <5632DE33.7030600@bitcartel.com> <3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com> <571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com> <6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com> Date: Sun, 15 Nov 2015 02:10:43 +0000 Message-ID: From: Gregory Maxwell To: Peter R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , telemaco Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 02:10:45 -0000 On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote: > My previous email described how Type 1 consensus failures can be safely d= ealt with. These include many kinds of database exceptions (e.g., the Leve= lDB 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=E2=80= =99m 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 anot= her 92 million bitcoins, I think it would be a good thing if the other impl= ementations forked away from it (we don=E2=80=99t want bug-for-bug compatib= ility 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.