diff options
| author | Gregory Maxwell <greg@xiph.org> | 2015-12-09 06:29:53 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-12-09 06:29:54 +0000 |
| commit | 20e3b0f0e1ce1dbd1aad6080f3d1afbc9da10cf7 (patch) | |
| tree | 185982c8931f79ae1ac7edab0384af71a209f4a9 | |
| parent | f9691d9266e574c34431361bf443ba0fa1efd72f (diff) | |
| download | pi-bitcoindev-20e3b0f0e1ce1dbd1aad6080f3d1afbc9da10cf7.tar.gz pi-bitcoindev-20e3b0f0e1ce1dbd1aad6080f3d1afbc9da10cf7.zip | |
Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
| -rw-r--r-- | 20/dd7cb5dc334ee293f8a702eac5d7c3af1eceb9 | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/20/dd7cb5dc334ee293f8a702eac5d7c3af1eceb9 b/20/dd7cb5dc334ee293f8a702eac5d7c3af1eceb9 new file mode 100644 index 000000000..761ef0d5e --- /dev/null +++ b/20/dd7cb5dc334ee293f8a702eac5d7c3af1eceb9 @@ -0,0 +1,118 @@ +Return-Path: <gmaxwell@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3D58DB01 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Dec 2015 06:29:54 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com + [209.85.213.172]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD161107 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 9 Dec 2015 06:29:53 +0000 (UTC) +Received: by igvg19 with SMTP id g19so117698321igv.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 08 Dec 2015 22:29:53 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:sender:in-reply-to:references:date:message-id:subject + :from:to:cc:content-type; + bh=n7k4TP53NO26osEd/yf0Tm41HIZPMwdCOvSY4PmJOR4=; + b=bP4wwpm9AHmO6OeojQfldVbaoJ0WQv7t8OP2PxqfZaaADrG0B4QwhCJZkYuYius1R2 + FGmsmzWtf+yDr75+gejzhCSuaTKNEZS4xKgzk6zuk/8SL8E6nU7l6hISo+zmkulRI937 + xDXwTCOCNTEOI0A2rP/Qy8D8blJavmHEjUPlZc5PemzGsrGxFf0x2qdjQLzvaM3/b3rw + I0f2J87tgzWeDtfRwLAfe2g6EsocZKm9taK3jal4HO2eBWvgGGiedaEFXtuFf5qo1znr + YuH75ttIwqD+tQmm0h0tqVPAH4HxGlqVuOO7DiuI++odPdtZ9fSXaULeA93u5+aemLkf + Y6RA== +MIME-Version: 1.0 +X-Received: by 10.50.134.2 with SMTP id pg2mr24370576igb.48.1449642593318; + Tue, 08 Dec 2015 22:29:53 -0800 (PST) +Sender: gmaxwell@gmail.com +Received: by 10.107.192.70 with HTTP; Tue, 8 Dec 2015 22:29:53 -0800 (PST) +In-Reply-To: <CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com> +References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com> + <20151208110752.GA31180@amethyst.visucore.com> + <CABm2gDpcek=u=Rpe68EMOq6M7Bji9J=s5VvoQWKRqaQDAP5kTw@mail.gmail.com> + <CABsx9T1wga3Tandoe2mVGSKdHJytHoc9Ko7HRm2SvJXABEFk9w@mail.gmail.com> + <CAAS2fgTGYSiAJHZq80rD4UieV8XetS=W0b45b5onWAS9gF-F7g@mail.gmail.com> + <CABsx9T1i50Gvxj18W=n2mYGNpsMrSkDT26CdA3aQqT5FFN86yw@mail.gmail.com> + <CAAS2fgSxpSat3VOje3-C4zgaRUVJVx-eRJbSYJqhvfR5SvCDwA@mail.gmail.com> + <CAF_2MyUJMdJyh7FKq6UYCtwJZQ59i-pnWT_tFEK5EQx65iwHDQ@mail.gmail.com> +Date: Wed, 9 Dec 2015 06:29:53 +0000 +X-Google-Sender-Auth: tEbDHDm4UoEwFVsIqcqbl7Z_tNI +Message-ID: <CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com> +From: Gregory Maxwell <greg@xiph.org> +To: Ryan Butler <rryananizer@gmail.com> +Content-Type: text/plain; charset=UTF-8 +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, 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 <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system. +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 09 Dec 2015 06:29:54 -0000 + +On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler <rryananizer@gmail.com> wrote: +>>I agree, but nothing I have advocated creates significant technical +>>debt. It is also a bad engineering practice to combine functional +>>changes (especially ones with poorly understood system wide +>>consequences and low user autonomy) with structural tidying. +> +> I don't think I would classify placing things in consensus critical code +> when it doesn't need to be as "structural tidying". Gavin said "pile on" +> which you took as implying "a lot", he can correct me, but I believe he +> meant "add to". + +Nothing being discussed would move something from consensus critical +code to not consensus critical. + +What was being discussed was the location of the witness commitment; +which is consensus critical regardless of where it is placed. Should +it be placed in an available location which is compatible with the +existing network, or should the block hashing data structure +immediately be changed in an incompatible way to accommodate it in +order to satisfy an ascetic sense of purity and to make fraud proofs +somewhat smaller? + +I argue that the size difference in the fraud proofs is not +interesting, the disruption to the network in an incompatible upgrade +is interesting; and that if it really were desirable reorganization to +move the commitment point could be done as part of a separate change +that changes only the location of things (and/or other trivial +adjustments); and that proceeding int this fashion would minimize +disruption and risk... by making the incompatible changes that will +force network wide software updates be as small and as simple as +possible. + +>> (especially ones with poorly understood system wide consequences and low +>> user autonomy) +> +> This implies there you have no confidence in the unit tests and functional +> testing around Bitcoin and should not be a reason to avoid refactoring. +> It's more a reason to increase testing so that you will have confidence when +> you refactor. + +I am speaking from our engineering experience in a public, +world-wide, multi-vendor, multi-version, inter-operable, distributed +system which is constantly changing and in production contains private +code, unknown and assorted hardware, mixtures of versions, unreliable +networks, undisclosed usage patterns, and more sources of complex +behavior than can be counted-- including complex economic incentives +and malicious participants. + +Even if we knew the complete spectrum of possible states for the +system the combinatioric explosion makes complete testing infeasible. + +Though testing is essential one cannot "unit test" away all the risks +related to deploying a new behavior in the network. + |