diff options
| author | Joel Joonatan Kaartinen <joel.kaartinen@gmail.com> | 2015-05-08 15:32:00 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-08 12:32:06 +0000 |
| commit | 93fb4c1ae3fdf69eaf43bc1d02b29280519a00ce (patch) | |
| tree | 55ad90bbc5ea233611c467c00aa05f11c93441fb | |
| parent | 968c6136f935aa4015a54c03b5c5c1a91e7415da (diff) | |
| download | pi-bitcoindev-93fb4c1ae3fdf69eaf43bc1d02b29280519a00ce.tar.gz pi-bitcoindev-93fb4c1ae3fdf69eaf43bc1d02b29280519a00ce.zip | |
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
| -rw-r--r-- | a6/c280a84ebf5ba8162bc63cc71715c93851ef95 | 276 |
1 files changed, 276 insertions, 0 deletions
diff --git a/a6/c280a84ebf5ba8162bc63cc71715c93851ef95 b/a6/c280a84ebf5ba8162bc63cc71715c93851ef95 new file mode 100644 index 000000000..94c3e9193 --- /dev/null +++ b/a6/c280a84ebf5ba8162bc63cc71715c93851ef95 @@ -0,0 +1,276 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <joel.kaartinen@gmail.com>) id 1YqhRm-00016i-Ti + for bitcoin-development@lists.sourceforge.net; + Fri, 08 May 2015 12:32:06 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.218.49 as permitted sender) + client-ip=209.85.218.49; envelope-from=joel.kaartinen@gmail.com; + helo=mail-oi0-f49.google.com; +Received: from mail-oi0-f49.google.com ([209.85.218.49]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YqhRl-0006Vx-Jq + for bitcoin-development@lists.sourceforge.net; + Fri, 08 May 2015 12:32:06 +0000 +Received: by oiko83 with SMTP id o83so57204234oik.1 + for <bitcoin-development@lists.sourceforge.net>; + Fri, 08 May 2015 05:32:00 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.202.195.23 with SMTP id t23mr2690007oif.117.1431088320203; + Fri, 08 May 2015 05:32:00 -0700 (PDT) +Received: by 10.202.49.16 with HTTP; Fri, 8 May 2015 05:32:00 -0700 (PDT) +In-Reply-To: <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com> +References: <16096345.A1MpJQQkRW@crushinator> + <CAP63atbdFSw0rDeuwgtjsDYsXnKSHNN9=zedzip2MsZ0hSY59w@mail.gmail.com> +Date: Fri, 8 May 2015 15:32:00 +0300 +Message-ID: <CAGKSKfW7fJB6n3B-OoyXOep7hAQqWGGDTiZCkpJ7vXxWRFgveA@mail.gmail.com> +From: Joel Joonatan Kaartinen <joel.kaartinen@gmail.com> +To: Matt Whitlock <bip@mattwhitlock.name> +Content-Type: multipart/alternative; boundary=001a1137c846f7d06605159136f0 +X-Spam-Score: -0.6 (/) +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 + (joel.kaartinen[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 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: 1YqhRl-0006Vx-Jq +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step + function +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: Fri, 08 May 2015 12:32:06 -0000 + +--001a1137c846f7d06605159136f0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +Matt, + +It seems you missed my suggestion about basing the maximum block size on +the bitcoin days destroyed in transactions that are included in the block. +I think it has potential for both scaling as well as keeping up a constant +fee pressure. If tuned properly, it should both stop spamming and increase +block size maximum when there are a lot of real transactions waiting for +inclusion. + +- Joel + +On Fri, May 8, 2015 at 1:30 PM, Cl=C3=A9ment Elbaz <clem.ds@gmail.com> wrot= +e: + +> Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my +> favorite. +> +> I see two problems with proposal #2. +> The first problem with proposal #2 is that, as we see in democracies, +> there is often a mismatch between the people conscious vote and these sam= +e +> people behavior. +> +> Relying on an intentional vote made consciously by miners by choosing a +> configuration value can lead to twisted results if their actual behavior +> doesn't correlate with their vote (eg, they all vote for a small block si= +ze +> because it is the default configuration of their software, and then they +> fill it completely all the time and everything crashes). +> +> The second problem with proposal #2 is that if Gavin and Mike are right, +> there is simply no time to gather a meaningful amount of votes over the +> coinbases, after the fork but before the Bitcoin scalability crash. +> +> I like proposal #1 because the "vote" is made using already available +> data. Also there is no possible mismatch between behavior and vote. As a +> miner you vote by choosing to create a big (or small) block, and your +> actions reflect your vote. It is simple and straightforward. +> +> My feelings on proposal #3 is it is a little bit mixing apples and +> oranges, but I may not seeing all the implications. +> +> +> Le ven. 8 mai 2015 =C3=A0 09:21, Matt Whitlock <bip@mattwhitlock.name> a +> =C3=A9crit : +> +>> Between all the flames on this list, several ideas were raised that did +>> not get much attention. I hereby resubmit these ideas for consideration = +and +>> discussion. +>> +>> - Perhaps the hard block size limit should be a function of the actual +>> block sizes over some trailing sampling period. For example, take the +>> median block size among the most recent 2016 blocks and multiply it by 1= +.5. +>> This allows Bitcoin to scale up gradually and organically, rather than +>> having human beings guessing at what is an appropriate limit. +>> +>> - Perhaps the hard block size limit should be determined by a vote of th= +e +>> miners. Each miner could embed a desired block size limit in the coinbas= +e +>> transactions of the blocks it publishes. The effective hard block size +>> limit would be that size having the greatest number of votes within a +>> sliding window of most recent blocks. +>> +>> - Perhaps the hard block size limit should be a function of block-chain +>> length, so that it can scale up smoothly rather than jumping immediately= + to +>> 20 MB. This function could be linear (anticipating a breakdown of Moore'= +s +>> Law) or quadratic. +>> +>> I would be in support of any of the above, but I do not support Mike +>> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the +>> road without actually solving the problem, and it does so in a +>> controversial (step function) way. +>> +>> +>> ------------------------------------------------------------------------= +------ +>> One dashboard for servers and applications across Physical-Virtual-Cloud +>> Widest out-of-the-box monitoring support with 50+ applications +>> Performance metrics, stats and reports that give you Actionable Insights +>> Deep dive visibility with transaction tracing using APM Insight. +>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +> +> +> -------------------------------------------------------------------------= +----- +> One dashboard for servers and applications across Physical-Virtual-Cloud +> Widest out-of-the-box monitoring support with 50+ applications +> Performance metrics, stats and reports that give you Actionable Insights +> Deep dive visibility with transaction tracing using APM Insight. +> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> + +--001a1137c846f7d06605159136f0 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div>Matt,</div><div><br></div>It seems you missed my sugg= +estion about basing the maximum block size on the bitcoin days destroyed in= + transactions that are included in the block. I think it has potential for = +both scaling as well as keeping up a constant fee pressure. If tuned proper= +ly, it should both stop spamming and increase block size maximum when there= + are a lot of real transactions waiting for inclusion.<div><br></div><div>-= + Joel<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, = +May 8, 2015 at 1:30 PM, Cl=C3=A9ment Elbaz <span dir=3D"ltr"><<a href=3D= +"mailto:clem.ds@gmail.com" target=3D"_blank">clem.ds@gmail.com</a>></spa= +n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= +order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div= +>Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my f= +avorite.<br><br></div><div>I see two problems with proposal #2.<br></div>Th= +e first problem with proposal #2 is that, as we see in democracies,=C2=A0 t= +here is often a mismatch between the people conscious vote and these same p= +eople behavior. <br><br>Relying on an=C2=A0 intentional vote made conscious= +ly by miners by choosing a configuration value can lead to twisted results = +if their actual behavior doesn't correlate with their vote (eg, they al= +l vote for a small block size because it is the default configuration of th= +eir software, and then they fill it completely all the time and everything = +crashes).<br><br></div><div>The second problem with proposal #2 is that if = +Gavin and Mike are right, there is simply no time to gather a meaningful am= +ount of votes over the coinbases, after the fork but before the Bitcoin sca= +lability crash. <br></div><div><br></div>I like proposal #1 because the &qu= +ot;vote" is made using already available data. Also there is no possib= +le mismatch between behavior and vote. As a miner you vote by choosing to c= +reate a big (or small) block, and your actions reflect your vote. It is sim= +ple and straightforward.<br><br></div>My feelings on proposal #3 is it is a= + little bit mixing apples and oranges, but I may not seeing all the implica= +tions.<div><div class=3D"h5"><br><div><div><div><div><div><br><div class=3D= +"gmail_quote">Le=C2=A0ven. 8 mai 2015 =C3=A0=C2=A009:21, Matt Whitlock <= +<a href=3D"mailto:bip@mattwhitlock.name" target=3D"_blank">bip@mattwhitlock= +.name</a>> a =C3=A9crit=C2=A0:<br><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Between= + all the flames on this list, several ideas were raised that did not get mu= +ch attention. I hereby resubmit these ideas for consideration and discussio= +n.<br> +<br> +- Perhaps the hard block size limit should be a function of the actual bloc= +k sizes over some trailing sampling period. For example, take the median bl= +ock size among the most recent 2016 blocks and multiply it by 1.5. This all= +ows Bitcoin to scale up gradually and organically, rather than having human= + beings guessing at what is an appropriate limit.<br> +<br> +- Perhaps the hard block size limit should be determined by a vote of the m= +iners. Each miner could embed a desired block size limit in the coinbase tr= +ansactions of the blocks it publishes. The effective hard block size limit = +would be that size having the greatest number of votes within a sliding win= +dow of most recent blocks.<br> +<br> +- Perhaps the hard block size limit should be a function of block-chain len= +gth, so that it can scale up smoothly rather than jumping immediately to 20= + MB. This function could be linear (anticipating a breakdown of Moore's= + Law) or quadratic.<br> +<br> +I would be in support of any of the above, but I do not support Mike Hearn&= +#39;s proposed jump to 20 MB. Hearn's proposal kicks the can down the r= +oad without actually solving the problem, and it does so in a controversial= + (step function) way.<br> +<br> +---------------------------------------------------------------------------= +---<br> +One dashboard for servers and applications across Physical-Virtual-Cloud<br= +> +Widest out-of-the-box monitoring support with 50+ applications<br> +Performance metrics, stats and reports that give you Actionable Insights<br= +> +Deep dive visibility with transaction tracing using APM Insight.<br> +<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= +=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</blockquote></div></div></div></div></div></div></div></div></div> +<br>-----------------------------------------------------------------------= +-------<br> +One dashboard for servers and applications across Physical-Virtual-Cloud<br= +> +Widest out-of-the-box monitoring support with 50+ applications<br> +Performance metrics, stats and reports that give you Actionable Insights<br= +> +Deep dive visibility with transaction tracing using APM Insight.<br> +<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target= +=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>= +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></blockquote></div><br></div></div></div> + +--001a1137c846f7d06605159136f0-- + + |