path: root/6d/c4900f0786fda76667bc25884c99a4a0812cab

Return-Path: <jtwinslow@juno.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7C1A596
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Aug 2015 20:29:26 +0000 (UTC)
X-Greylist: delayed 00:06:40 by SQLgrey-1.7.6
Received: from outbound-mail02.vgs.untd.com (outbound-mail02.vgs.untd.com
	[64.136.55.36])
	by smtp1.linuxfoundation.org (Postfix) with SMTP id 668248F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat,  1 Aug 2015 20:29:25 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha;
	t=1438460964; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0;
	h=From:Subject:To:Message-ID:Date:Content-Type;
	b=bLZaz/7A9YxMcRe01APznhzSBOO6ZrANqgYxvAhAmWoPj7feoQXTq2iAAUpSp0vGT
	4XCHREL+m4XuaowWgSF/d8m2N7CA9d1lu4cyKKSUs22wUEaxioneVxCX4eyvkHB+pc
	wXAe1f4hroRzUFwabGn8v2QrcR4EBSVIpoTL3Jqk=
Received: from [192.168.1.137] (cpe-75-82-98-197.socal.res.rr.com
	[75.82.98.197])
	by smtpout01.vgs.untd.com with SMTP id AABL54LV7AMDSU3A
	for <bitcoin-dev@lists.linuxfoundation.org> (sender
	<jtwinslow@juno.com>); Sat,  1 Aug 2015 13:22:21 -0700 (PDT)
From: "John T. Winslow" <jtwinslow@juno.com>
To: bitcoin-dev@lists.linuxfoundation.org
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
	<25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com>
	<4608887.aSM42bDkNk@coldstorage>
	<CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
Message-ID: <55BD2A7C.9060504@juno.com>
Date: Sat, 1 Aug 2015 13:22:20 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080801090306000501040607"
X-Originating-Ip: 75.82.98.197
X-UNTD-BodySize: 13978
X-ContentStamp: 49:24:2426628306
X-MAIL-INFO: 2f2d31fd2da4a4993194f4dd94d4f444e1e5f14949ed70c08d51fd5950fdc9f0593150fdfd853194b17999c931941dd06d806d544530f4c46d412561f11dd1413489115585957d550161253480a1a1e4149db90944c1f5440dd9c129f544447529644d
X-UNTD-OriginStamp: 3BHtMxlTjQpeqTE3t6I7r0MDRmi+uHVAunp+iWQtibRqJAotL7txoQ==
X-UNTD-Peer-Info: 10.181.42.31|smtpout01.vgs.untd.com|smtpout01.vgs.untd.com|jtwinslow@juno.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	T_DKIM_INVALID autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
 temporary
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: Sat, 01 Aug 2015 20:29:26 -0000

This is a multi-part message in MIME format.
--------------080801090306000501040607
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Regarding the block size increase, at least conceptually it seems to me 
there should be an easy solution. If we look at what works well with 
bitcoin, for example the block reward halving and difficulty regimes 
which due to their step function nature both contribute to the stability 
and predictability of the bitcoin universe while still allowing for the 
necessary dynamic adjustments. It seems to me there should be a 
corresponding and equally simple solution for the maximum block size.

I've never quite understood the supposed rationale behind the proposals 
for a new static maximum of 20 MB or 8 MB or 2 MB other than it would be 
trivial to implement. Why not come up with an equally simple, 
predictable dynamic function consistent with what is already proven to 
work in the bitcoin universe that would both preserve the scarcity of 
transaction capacity to encourage a fee market but also allow for more 
transactions when needed.

For example how about something like once every month at month-end, take 
the 6-month average non-zero transaction fee block size and multiply by 1.5?

With the # of transactions increasing then plateauing you arrive at a 
constant excess capacity of around 33%:

MO    ABS    MBS    EX CAP
1    750    1000    25.0%
2    775    1000    22.5%
3    800    1000    20.0%
4    825    1000    17.5%
5    850    1000    15.0%
6    875    1219    28.2%
7    900    1256    28.4%
8    925    1294    28.5%
9    950    1331    28.6%
10    975    1369    28.8%
11    1000    1406    28.9%
12    1000    1438    30.4%
13    1000    1463    31.6%
14    1000    1481    32.5%
15    1000    1494    33.1%
16    1000    1500    33.3%
17    1000    1500    33.3%
18    1000    1500    33.3%

Similarly, in a declining then plateauing # of transactions market you 
also arrive at a constant excess capacity of about 33%

MO    ABS    MBS    EX CAP
1    750    1000    25.0%
2    725    1000    27.5%
3    700    1000    30.0%
4    675    1000    32.5%
5    650    1000    35.0%
6    625    1031    39.4%
7    600    994    39.6%
8    575    956    39.9%
9    550    919    40.1%
10    525    881    40.4%
11    500    844    40.7%
12    500    813    38.5%
13    500    788    36.5%
14    500    769    35.0%
15    500    756    33.9%
16    500    750    33.3%
17    500    750    33.3%
18    500    750    33.3%

With some simple statistical analysis, one could easily arrive at a 
statistically-inferred excess capacity linked the to probability of 
transaction volume exceeding the new cap in any forward monthly 
interval. In the tables above, I have used my own intuition that people 
seem to be generally comfortable with excess capacity of >= 33% and 
become less so at < 33%.

A scheme like this would have multiple benefits:

1) Adapts predictably and automatically to both rising and declining 
market demand for transactions

2) Preserves the fee market with a constant target excess capacity

3) Monthly adjustment interval and six month lookback allow for 
sufficient time to plan for changes in system capacity

In the case where transaction volume spikes such that it exceeds the 
monthly limit, the fee market would then take over to ensure high 
priority transactions get through fastest. In the case of malicious 
activity, such an attack would have to be maintained for well over a 
month to significantly adversely affect the maximum block size. As long 
as there is a non-zero cost to such attacks, the likelihood of 
maintaining one for a period of months decreases significantly.

Thx,

JTW

On 7/31/2015 1:45 PM, Eric Lombrozo via bitcoin-dev wrote:
>
> I would love to be able to increase block size. But I have serious 
> doubts about being able to do this safely at this time given what we 
> presently know about the Bitcoin network. And I'm pretty sure I'm not 
> alone in this sentiment.
>
> Had we been working on fixing the known issues that most complicate 
> bigger blocks in the last six years, or even in the last three years 
> after many issues had already been well-identified, perhaps we'd be 
> ready to increase the limit. But other things have seemed more 
> important, like specifying the use of X.509 overlay protocols or 
> adding complex filtering mechanisms to the p2p protocol to make it 
> practical to use tx merkle trees...and as a result we're not ready for 
> safely allowing larger blocks.
>
> - Eric
>
> On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" 
> <bitcoin-dev@lists.linuxfoundation.org 
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     On Thursday 30. July 2015 16.33.16 <tel:2015%2016.33.16> Eric
>     Lombrozo via bitcoin-dev wrote:
>     >  I don’t think it’s really a matter of whether we agree on
>     whether it’s good
>     > to raise the block size limit, Gavin. I think it’s a matter of a
>     difference
>     > in priorities.
>
>     Having different priorities is fine, using your time to block
>     peoples attempts
>     to increase block size is not showing different priorities, it
>     shows conflicting
>     priorities.
>     Different priorities means you can trust someone else to do things
>     they care
>     about while you do things you care about.
>     --
>     Thomas Zander
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------080801090306000501040607
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Regarding the block size increase, at
      least conceptually it seems to me there should be an easy
      solution. If we look at what works well with bitcoin, for example
      the block reward halving and difficulty regimes which due to their
      step function nature both contribute to the stability and
      predictability of the bitcoin universe while still allowing for
      the necessary dynamic adjustments. It seems to me there should be
      a corresponding and equally simple solution for the maximum block
      size.<br>
      <br>
      I've never quite understood the supposed rationale behind the
      proposals for a new static maximum of 20 MB or 8 MB or 2 MB other
      than it would be trivial to implement. Why not come up with an
      equally simple, predictable dynamic function consistent with what
      is already proven to work in the bitcoin universe that would both
      preserve the scarcity of transaction capacity to encourage a fee
      market but also allow for more transactions when needed.<br>
      <br>
      For example how about something like once every month at
      month-end, take the 6-month average non-zero transaction fee block
      size and multiply by 1.5?<br>
      <br>
      With the # of transactions increasing then plateauing you arrive
      at a constant excess capacity of around 33%:<br>
          <br>
      MO    ABS    MBS    EX CAP<br>
      1    750    1000    25.0%<br>
      2    775    1000    22.5%<br>
      3    800    1000    20.0%<br>
      4    825    1000    17.5%<br>
      5    850    1000    15.0%<br>
      6    875    1219    28.2%<br>
      7    900    1256    28.4%<br>
      8    925    1294    28.5%<br>
      9    950    1331    28.6%<br>
      10    975    1369    28.8%<br>
      11    1000    1406    28.9%<br>
      12    1000    1438    30.4%<br>
      13    1000    1463    31.6%<br>
      14    1000    1481    32.5%<br>
      15    1000    1494    33.1%<br>
      16    1000    1500    33.3%<br>
      17    1000    1500    33.3%<br>
      18    1000    1500    33.3%<br>
      <br>
      Similarly, in a declining then plateauing # of transactions market
      you also arrive at a constant excess capacity of about 33%<br>
      <br>
      MO    ABS    MBS    EX CAP<br>
      1    750    1000    25.0%<br>
      2    725    1000    27.5%<br>
      3    700    1000    30.0%<br>
      4    675    1000    32.5%<br>
      5    650    1000    35.0%<br>
      6    625    1031    39.4%<br>
      7    600    994    39.6%<br>
      8    575    956    39.9%<br>
      9    550    919    40.1%<br>
      10    525    881    40.4%<br>
      11    500    844    40.7%<br>
      12    500    813    38.5%<br>
      13    500    788    36.5%<br>
      14    500    769    35.0%<br>
      15    500    756    33.9%<br>
      16    500    750    33.3%<br>
      17    500    750    33.3%<br>
      18    500    750    33.3%<br>
      <br>
      With some simple statistical analysis, one could easily arrive at
      a statistically-inferred excess capacity linked the to probability
      of transaction volume exceeding the new cap in any forward monthly
      interval. In the tables above, I have used my own intuition that
      people seem to be generally comfortable with excess capacity of
      &gt;= 33% and become less so at &lt; 33%.<br>
      <br>
      A scheme like this would have multiple benefits:<br>
      <br>
      1) Adapts predictably and automatically to both rising and
      declining market demand for transactions<br>
      <br>
      2) Preserves the fee market with a constant target excess capacity<br>
      <br>
      3) Monthly adjustment interval and six month lookback allow for
      sufficient time to plan for changes in system capacity<br>
      <br>
      In the case where transaction volume spikes such that it exceeds
      the monthly limit, the fee market would then take over to ensure
      high priority transactions get through fastest. In the case of
      malicious activity, such an attack would have to be maintained for
      well over a month to significantly adversely affect the maximum
      block size. As long as there is a non-zero cost to such attacks,
      the likelihood of maintaining one for a period of months decreases
      significantly.<br>
      <br>
      Thx,<br>
      <br>
      JTW<br>
      <br>
      On 7/31/2015 1:45 PM, Eric Lombrozo via bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CABr1YTc46x3RoKKF=cckcmVRWCaAQc0KOTrGRX+A-h5V=xYB9A@mail.gmail.com"
      type="cite">
      <p dir="ltr">I would love to be able to increase block size. But I
        have serious doubts about being able to do this safely at this
        time given what we presently know about the Bitcoin network. And
        I'm pretty sure I'm not alone in this sentiment.</p>
      <p dir="ltr">Had we been working on fixing the known issues that
        most complicate bigger blocks in the last six years, or even in
        the last three years after many issues had already been
        well-identified, perhaps we'd be ready to increase the limit.
        But other things have seemed more important, like specifying the
        use of X.509 overlay protocols or adding complex filtering
        mechanisms to the p2p protocol to make it practical to use tx
        merkle trees...and as a result we're not ready for safely
        allowing larger blocks.</p>
      <p dir="ltr">- Eric</p>
      <div class="gmail_quote">On Jul 30, 2015 11:43 PM, "Thomas Zander
        via bitcoin-dev" &lt;<a moz-do-not-send="true"
          href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;

        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thursday
          30. July <a moz-do-not-send="true" href="tel:2015%2016.33.16"
            value="+12015163316">2015 16.33.16</a> Eric Lombrozo via
          bitcoin-dev wrote:<br>
          &gt;  I don’t think it’s really a matter of whether we agree
          on whether it’s good<br>
          &gt; to raise the block size limit, Gavin. I think it’s a
          matter of a difference<br>
          &gt; in priorities.<br>
          <br>
          Having different priorities is fine, using your time to block
          peoples attempts<br>
          to increase block size is not showing different priorities, it
          shows conflicting<br>
          priorities.<br>
          Different priorities means you can trust someone else to do
          things they care<br>
          about while you do things you care about.<br>
          --<br>
          Thomas Zander<br>
          _______________________________________________<br>
          bitcoin-dev mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
          <a moz-do-not-send="true"
            href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
            rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------080801090306000501040607--