summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGavin Andresen <gavinandresen@gmail.com>2015-12-09 11:40:34 -0500
committerbitcoindev <bitcoindev@gnusha.org>2015-12-09 16:40:37 +0000
commit9ba93ea2d4ca1c5cfab0d94ec4308a4216f63d00 (patch)
tree3987d809b0ceeb3f82436fbc4c03a71156a3d983
parente92372b5a6e5fb2239594d5a52585b6a584a78e3 (diff)
downloadpi-bitcoindev-9ba93ea2d4ca1c5cfab0d94ec4308a4216f63d00.tar.gz
pi-bitcoindev-9ba93ea2d4ca1c5cfab0d94ec4308a4216f63d00.zip
Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Diffstat
-rw-r--r--23/2d54eb86c8ca084fbeaa2f02936cd4b0c256ed153
1 files changed, 153 insertions, 0 deletions
diff --git a/23/2d54eb86c8ca084fbeaa2f02936cd4b0c256ed b/23/2d54eb86c8ca084fbeaa2f02936cd4b0c256ed
new file mode 100644
index 000000000..858d8ab3e
--- /dev/null
+++ b/23/2d54eb86c8ca084fbeaa2f02936cd4b0c256ed
@@ -0,0 +1,153 @@
+Return-Path: <gavinandresen@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 47F86CDD
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 9 Dec 2015 16:40:37 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com
+ [209.85.215.49])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9FC98171
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 9 Dec 2015 16:40:36 +0000 (UTC)
+Received: by lfs39 with SMTP id 39so38580015lfs.3
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 09 Dec 2015 08:40:35 -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;
+ bh=g2WZxPQf2/e/t42w1k+vzVxEWcdXu/cSx6A66+w7+JM=;
+ b=tOGHkVEbdRpV3lcJDYiSEYH4+xS7iFHRnre5fdWJ2w3T5PNRIEVftQYiTMtFukJUad
+ 4J6oavUEpKCNfYNKGdeq9UDH3eZDwum61dT1kpO0L2jIXwk2v4YRAOTbJ1P2HCD/2tBC
+ O85PXWQjSaPAH+wsm+QBG7CEae4Euzvz9S80qNhEqWs+jZX57LxFEyu0e0HC83OeEqfn
+ pw13zjLXUut2sZr3fkSV8L2El9jPTFxum6pqDQ2DJuAkAXC9wKbhHVgQ5Q5Sf60xFbrg
+ FaQss3ONDPKmfG/ztYz8SNyG16YM+5k8DFPrQqUFRIX6OClfKsx0C8LakamJJaJmny3W
+ cZ/A==
+MIME-Version: 1.0
+X-Received: by 10.25.27.147 with SMTP id b141mr2730644lfb.87.1449679234962;
+ Wed, 09 Dec 2015 08:40:34 -0800 (PST)
+Received: by 10.25.22.95 with HTTP; Wed, 9 Dec 2015 08:40:34 -0800 (PST)
+In-Reply-To: <CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@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>
+ <CAAS2fgS-jjEVeHf_LErppTadtAaSeBum+KiGHpoo=Jz5BZArsQ@mail.gmail.com>
+ <CABm2gDq4f0ettDhh14jZ0zztSwSJ0Z=KDEeMTOJxTHF8VV+KXw@mail.gmail.com>
+ <CAAS2fgTAFgANJ495xiOkiW-OeFA_VZHhhR5uL+jVaoYQz_yBPg@mail.gmail.com>
+Date: Wed, 9 Dec 2015 11:40:34 -0500
+Message-ID: <CABsx9T1pLtOaGOVpVs8URAwpbb884htkrFLWtX8-2gGpS6gPWw@mail.gmail.com>
+From: Gavin Andresen <gavinandresen@gmail.com>
+To: Gregory Maxwell <greg@xiph.org>
+Content-Type: multipart/alternative; boundary=001a11401350d6a136052679bfde
+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 16:40:37 -0000
+
+--001a11401350d6a136052679bfde
+Content-Type: text/plain; charset=UTF-8
+
+On Wed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> I think it would be logical to do as part of a hardfork that moved
+> commitments generally; e.g. a better position for merged mining (such
+> a hardfork was suggested in 2010 as something that could be done if
+> merged mining was used), room for commitments to additional block
+> back-references for compact SPV proofs, and/or UTXO set commitments.
+> Part of the reason to not do it now is that the requirements for the
+> other things that would be there are not yet well defined. For these
+> other applications, the additional overhead is actually fairly
+> meaningful; unlike the fraud proofs.
+>
+
+So just design ahead for those future uses. Make the merkle tree:
+
+
+ root_in_block_header
+ / \
+ tx_data_root other_root
+ / \
+ segwitness_root reserved_for_future_use_root
+
+... where reserved_for_future_use is zero until some future block version
+(or perhaps better, is just chosen arbitrarily by the miner and sent along
+with the block data until some future block version).
+
+That would minimize future disruption of any code that produced or consumed
+merkle proofs of the transaction data or segwitness data, especially if the
+reserved_for_future_use_root is allowed to be any arbitrary 256-bit value
+and not a constant that would get hard-coded into segwitness-proof-checking
+code.
+
+
+--
+--
+Gavin Andresen
+
+--001a11401350d6a136052679bfde
+Content-Type: text/html; charset=UTF-8
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
+ed, Dec 9, 2015 at 3:03 AM, Gregory Maxwell via bitcoin-dev <span dir=3D"lt=
+r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
+blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
+kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
+c solid;padding-left:1ex"><div id=3D":1lt" class=3D"a3s" style=3D"overflow:=
+hidden">I think it would be logical to do as part of a hardfork that moved<=
+br>
+commitments generally; e.g. a better position for merged mining (such<br>
+a hardfork was suggested in 2010 as something that could be done if<br>
+merged mining was used), room for commitments to additional block<br>
+back-references for compact SPV proofs, and/or UTXO set commitments.<br>
+Part of the reason to not do it now is that the requirements for the<br>
+other things that would be there are not yet well defined. For these<br>
+other applications, the additional overhead is actually fairly<br>
+meaningful; unlike the fraud proofs.<div class=3D"yj6qo ajU"><div id=3D":1m=
+9" class=3D"ajR" tabindex=3D"0"></div></div></div></blockquote></div><br>So=
+ just design ahead for those future uses. Make the merkle tree:</div><div c=
+lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div cl=
+ass=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0root_in=
+_block_header</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =C2=A0 =C2=A0 =C2=A0\</di=
+v><div class=3D"gmail_extra">=C2=A0 tx_data_root =C2=A0 =C2=A0 =C2=A0other_=
+root</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
+=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ =
+=C2=A0 =C2=A0 =C2=A0 \</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0=
+ =C2=A0 segwitness_root =C2=A0 =C2=A0 reserved_for_future_use_root</div><di=
+v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">... where rese=
+rved_for_future_use is zero until some future block version (or perhaps bet=
+ter, is just chosen arbitrarily by the miner and sent along with the block =
+data until some future block version).</div><div class=3D"gmail_extra"><br>=
+</div><div class=3D"gmail_extra">That would minimize future disruption of a=
+ny code that produced or consumed merkle proofs of the transaction data or =
+segwitness data, especially if the reserved_for_future_use_root is allowed =
+to be any arbitrary 256-bit value and not a constant that would get hard-co=
+ded into segwitness-proof-checking code.</div><div class=3D"gmail_extra"><b=
+r clear=3D"all"><div><br></div>-- <br><div class=3D"gmail_signature">--<br>=
+Gavin Andresen<br></div><div class=3D"gmail_signature"><br></div>
+</div></div>
+
+--001a11401350d6a136052679bfde--
+
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-26 02:46:22 +0000