summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJonathan Toomim <j@toom.im>2015-12-09 07:48:58 +0800
committerbitcoindev <bitcoindev@gnusha.org>2015-12-08 23:49:06 +0000
commit4ae77e124b74bcbd2366edddf09746d2a7b7ae72 (patch)
tree92191f1a4ef445934cc35a5d5504ab706eb6648f
parent0add2244a3a3e6216b23fa014e545d17722e092e (diff)
downloadpi-bitcoindev-4ae77e124b74bcbd2366edddf09746d2a7b7ae72.tar.gz
pi-bitcoindev-4ae77e124b74bcbd2366edddf09746d2a7b7ae72.zip
Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
-rw-r--r--cf/f0c0e18c967e3c7a02af20de765e3a51837173137
1 files changed, 137 insertions, 0 deletions
diff --git a/cf/f0c0e18c967e3c7a02af20de765e3a51837173 b/cf/f0c0e18c967e3c7a02af20de765e3a51837173
new file mode 100644
index 000000000..e6c03d4a8
--- /dev/null
+++ b/cf/f0c0e18c967e3c7a02af20de765e3a51837173
@@ -0,0 +1,137 @@
+Return-Path: <j@toom.im>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 257DAC3D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 8 Dec 2015 23:49:06 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD1D6145
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Tue, 8 Dec 2015 23:49:05 +0000 (UTC)
+Received: from [192.168.0.136] (1-64-179-042.static.netvigator.com
+ [1.64.179.42]) (authenticated bits=0)
+ by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tB8NmxTu011851
+ (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
+ Tue, 8 Dec 2015 15:49:02 -0800
+Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
+Content-Type: multipart/signed;
+ boundary="Apple-Mail=_997F15C3-CDF7-4694-A002-F54D5AEF78E4";
+ protocol="application/pgp-signature"; micalg=pgp-sha512
+X-Pgp-Agent: GPGMail 2.5.2
+From: Jonathan Toomim <j@toom.im>
+In-Reply-To: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
+Date: Wed, 9 Dec 2015 07:48:58 +0800
+Message-Id: <5F73C59C-7939-4937-839D-CA93880CB21F@toom.im>
+References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
+To: Gregory Maxwell <greg@xiph.org>
+X-Mailer: Apple Mail (2.1878.6)
+X-Sonic-CAuth: UmFuZG9tSVbieX+Bk351VBAXA4tfrD2g3f3Uk+DFMHl96GFHmcGKAqg7TsAuu9pXa+id0hX7uYG4EyoZDptIKRlhu2T3yUU/
+X-Sonic-ID: C;uhRqQAae5RGZOsgxU3XIUw== M;IHv2QQae5RGZOsgxU3XIUw==
+X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
+X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Tue, 08 Dec 2015 23:49:06 -0000
+
+
+--Apple-Mail=_997F15C3-CDF7-4694-A002-F54D5AEF78E4
+Content-Type: multipart/alternative;
+ boundary="Apple-Mail=_6D85F9D4-3680-461F-8CA4-ED05B6159553"
+
+
+--Apple-Mail=_6D85F9D4-3680-461F-8CA4-ED05B6159553
+Content-Transfer-Encoding: quoted-printable
+Content-Type: text/plain;
+ charset=us-ascii
+
+On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via bitcoin-dev =
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> The particular proposal amounts to a 4MB blocksize increase at worst.
+
+I understood that SegWit would allow about 1.75 MB of data in the =
+average case while also allowing up to 4 MB of data in the worst case. =
+This means that the mining and block distribution network would need a =
+larger safety factor to deal with worst-case situations, right? If you =
+want to make sure that nothing goes wrong when everything is at its =
+worst, you need to size your network pipes to handle 4 MB in a timely =
+(DoS-resistant) fashion, but you'd normally only be able to use 1.75 MB =
+of it. It seems to me that it would be safer to use a 3 MB limit, and =
+that way you'd also be able to use 3 MB of actual transactions.
+
+As an accounting trick to bypass the 1 MB limit, SegWit sounds like it =
+might make things less well accounted for.
+
+
+--Apple-Mail=_6D85F9D4-3680-461F-8CA4-ED05B6159553
+Content-Transfer-Encoding: quoted-printable
+Content-Type: text/html;
+ charset=us-ascii
+
+<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
+charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
+-webkit-nbsp-mode: space; -webkit-line-break: =
+after-white-space;"><div>On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via =
+bitcoin-dev &lt;<a =
+href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
+nuxfoundation.org</a>&gt; wrote:</div><div><br =
+class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
+style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
+font-variant: normal; font-weight: normal; letter-spacing: normal; =
+line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
+text-transform: none; white-space: normal; widows: auto; word-spacing: =
+0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
+!important;">The particular proposal amounts to a 4MB blocksize increase =
+at worst. </span></blockquote><div><br></div><div><div>I understood that =
+SegWit would allow about 1.75 MB of data in the average case while also =
+allowing up to 4 MB of data in the worst case. This means that the =
+mining and block distribution network would need a larger safety factor =
+to deal with worst-case situations, right? If you want to make sure that =
+nothing goes wrong when everything is at its worst, you need to size =
+your network pipes to handle 4 MB in a timely (DoS-resistant) fashion, =
+but you'd normally only be able to use 1.75 MB of it. It seems to me =
+that it would be safer to use a 3 MB limit, and that way you'd also be =
+able to use 3 MB of actual transactions.</div><div><br></div><div>As an =
+accounting trick to bypass the 1 MB limit, SegWit sounds like it might =
+make things less well accounted =
+for.</div><div><br></div></div></div></body></html>=
+
+--Apple-Mail=_6D85F9D4-3680-461F-8CA4-ED05B6159553--
+
+--Apple-Mail=_997F15C3-CDF7-4694-A002-F54D5AEF78E4
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment;
+ filename=signature.asc
+Content-Type: application/pgp-signature;
+ name=signature.asc
+Content-Description: Message signed with OpenPGP using GPGMail
+
+-----BEGIN PGP SIGNATURE-----
+Comment: GPGTools - https://gpgtools.org
+
+iQEcBAEBCgAGBQJWZ2xqAAoJEIEuMk4MG0P1fd8IAI94wRxV7GY6DSnHdOvmMcDo
+Q4yy0OZauQrannfZLcHsc9P0YHgRHpSwdJaeO/1rUI68oZK67KbZXowpcnVaPC6X
+H/qIICwFDK9i/ukrJnHydoyy2KFNn+ZJ1mMjdrzI+9yWU1zBb09QVBVFyo7wQdA2
+TIEgVeVKFV39wuR4Prj/r1RFKx0iOA4SjiFN3BFbsdn1THwTMdpq7D0wlastAswO
+jBozMW4nhL5u0p1Lhm2xn26PZzFsnETNvCFr/mNY6HW1JGbi4vBZHab4C43au/i4
+26GJX1utQHEFjLxtCB3Cv1s+6buCTn7oXecm49Sxm+42iKAPdyipN5yQerjsQLg=
+=FQcE
+-----END PGP SIGNATURE-----
+
+--Apple-Mail=_997F15C3-CDF7-4694-A002-F54D5AEF78E4--
+