diff options
author | Mike Hearn <mike@plan99.net> | 2015-06-01 17:33:41 +0200 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-01 15:33:49 +0000 |
commit | 93293feba32b9287fa8ab8975130fe055f6dd58b (patch) | |
tree | a6ca3cf3d179dfb13fbc8b0fbab9886e6ecedc9d | |
parent | 87dcbab2846b4fb4156d09c28cfcf6f795ffc0b4 (diff) | |
download | pi-bitcoindev-93293feba32b9287fa8ab8975130fe055f6dd58b.tar.gz pi-bitcoindev-93293feba32b9287fa8ab8975130fe055f6dd58b.zip |
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
-rw-r--r-- | dd/89f1f5668bdbbddef2923a8522fcc52a926f89 | 128 |
1 files changed, 128 insertions, 0 deletions
diff --git a/dd/89f1f5668bdbbddef2923a8522fcc52a926f89 b/dd/89f1f5668bdbbddef2923a8522fcc52a926f89 new file mode 100644 index 000000000..305720519 --- /dev/null +++ b/dd/89f1f5668bdbbddef2923a8522fcc52a926f89 @@ -0,0 +1,128 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1YzRin-0004Ug-Bk + for bitcoin-development@lists.sourceforge.net; + Mon, 01 Jun 2015 15:33:49 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.212.170 as permitted sender) + client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com; + helo=mail-wi0-f170.google.com; +Received: from mail-wi0-f170.google.com ([209.85.212.170]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YzRim-00071I-AI + for bitcoin-development@lists.sourceforge.net; + Mon, 01 Jun 2015 15:33:49 +0000 +Received: by wicmx19 with SMTP id mx19so74747061wic.0 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 01 Jun 2015 08:33:42 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.194.157.168 with SMTP id wn8mr41359456wjb.79.1433172822312; + Mon, 01 Jun 2015 08:33:42 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.194.143.9 with HTTP; Mon, 1 Jun 2015 08:33:41 -0700 (PDT) +In-Reply-To: <CAFzgq-wzQaS5K1hQMz_TcbvKMKQbAde488bx4uDXhODNXpqtsA@mail.gmail.com> +References: <554BE0E1.5030001@bluematt.me> + <CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com> + <CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com> + <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com> + <CAFzgq-zTybEQyGz0nq90u5n5JZcJzxQS_XKaTpr5POJi-tHM6A@mail.gmail.com> + <CABsx9T2L5bi-c63-KqSifOMeNayUWSPo0_Hx8VjMR_4=kC3ixg@mail.gmail.com> + <CAE28kUT61qYxqV0mOqw5Dan=eMiCvnG2SnsAeWzOWTxwLydyeQ@mail.gmail.com> + <CABsx9T2hfpts5y_M6PdDcxmq9Q2smesJ0Nmp9a9iyPD_MoPC9g@mail.gmail.com> + <CAE28kUTZV3YsaSCX2d5YwLetnf=f+bOWGrwxLXdZFywTZ=+Pjg@mail.gmail.com> + <CALC81CNq-GK5q6R4bmgHL5_Ej2+cZrtQMMLVmuhvMxkZokM3hQ@mail.gmail.com> + <CAE28kUQr+kUPak67tcNQGGscUXtJiD1LiXfjdD8_LMUWyVdR5w@mail.gmail.com> + <CANEZrP12WAcUOJp5UYg4pfWL7_4WiAHWWZAoaxAb5xB+qAP4Xg@mail.gmail.com> + <CAFzgq-ykeMeWF-ndgSm9upHTe8j6ZFYhBQjFs_WSz1oVd29j7g@mail.gmail.com> + <CAFzgq-x+-s_Nbt4z-C4SWQbHdPr159AmL2JvpP0zg1axM+Vwcw@mail.gmail.com> + <CABsx9T2aEvPs68pQA-KrtaDQFcTTtiB36eqKAcJRkiOFQr6WsA@mail.gmail.com> + <CAFzgq-wzQaS5K1hQMz_TcbvKMKQbAde488bx4uDXhODNXpqtsA@mail.gmail.com> +Date: Mon, 1 Jun 2015 17:33:41 +0200 +X-Google-Sender-Auth: zbR6ZOy4lHiBmFzagG9kNqTNRsw +Message-ID: <CANEZrP1OX4j=AoiHDQx10mSVY6D4Yu7rd9Lnq=RW-H+byhCnyw@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Chun Wang <1240902@gmail.com> +Content-Type: multipart/alternative; boundary=089e0122e968f9ce9b0517768c4a +X-Spam-Score: -0.5 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1YzRim-00071I-AI +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 01 Jun 2015 15:33:49 -0000 + +--089e0122e968f9ce9b0517768c4a +Content-Type: text/plain; charset=UTF-8 + +I'm OK with a smaller size + a formula that ramps it up over time. We are +far from having enough demand to fill 10MB blocks, let alone 20MB today. + +To put it in perspective, to be feeling squeezed inside 10MB within two +years, we would need to double usage five times. I wish I knew a way to +make that happen. So the chances of us going to 20MB blocks full of real +transactions any time soon is close to zero short of some amazing killer +app that takes the world by storm (in which case: yay, nice problem to +have). As long as capacity significantly outpaces organic growth, we should +avoid problems. + +The reason to pick 20MB then is merely one of expedience: we have to pick a +number, 20 is tested and seems to work, and we don't want to get caught by +surprise if demand does outstrip expectations. + +Still, I question the underlying logic. We have no idea what connectivity +into China will look like a few years from now: it's seems to be a function +of politics rather than hardware trends. It might go down rather than up. +So 10 vs 20 feels a bit arbitrary. We can't let the Chinese government +dictate how Bitcoin is used, that would never be accepted by the rest of +the world. But if we optimistically assume things don't get worse, and 10 +== more acceptance, then alright - it should make no difference in practice. + +--089e0122e968f9ce9b0517768c4a +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">I'm OK with a smaller size + a formula that ramps it u= +p over time. We are far=C2=A0from having enough demand to fill 10MB blocks,= + let alone 20MB today.<div><br></div><div>To put it in perspective, to be f= +eeling squeezed inside 10MB within two years, we would need to double usage= + five times. I wish I knew a way to make that happen. So the chances of us = +going to 20MB blocks full of real transactions any time soon is close to ze= +ro short of some amazing killer app that takes the world by storm (in which= + case: yay, nice problem to have). As long as capacity significantly outpac= +es organic growth, we should avoid problems.</div><div><br></div><div>The r= +eason to pick 20MB then is merely one of expedience: we have to pick a numb= +er, 20 is tested and seems to work, and we don't want to get caught by = +surprise if demand does outstrip expectations.</div><div><div><br></div><di= +v><div>Still, I question the underlying logic. We have no idea what connect= +ivity into China will look like a few years from now: it's seems to be = +a function of politics rather than hardware trends. It might go down rather= + than up. So 10 vs 20 feels a bit arbitrary. We can't let the Chinese g= +overnment dictate how Bitcoin is used, that would never be accepted by the = +rest of the world. But if we optimistically assume things don't get wor= +se, and 10 =3D=3D more acceptance, then alright - it should make no differe= +nce in practice.</div></div></div><div><br></div></div> + +--089e0122e968f9ce9b0517768c4a-- + + |