Message-ID: <55D38B19.2090609@ows.fr>
Date: Tue, 18 Aug 2015 21:44:25 +0200
From: cedric perronnet <cp@ows.fr>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
In-Reply-To: <CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------010804030508030306040108"
Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap
Precedence: list

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

Sounds like a much better approach than arbitrary deciding what the 
block size should be
BR

Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :
> Regarding: 
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html 
>
>
>
> I am arguing with the following statement here...
>
>     /I see problems to this approach. The biggest one I see is that a
>     miner with 11% of hash power could sabotage block size increases
>     by only ever mining empty blocks./
>
>
>
> First, I would like to argue from economics' point of view. If someone 
> wants to hold back the block size increase with 11% hash power by 
> mining empty blocks, he has to sacrifice Tx fees, which is not 
> economical. 11% hash power will most likely be a pool and pool miners 
> will find out soon that they are losing Tx fees because of pool 
> owner's intention. Hence, they'll switch pool and pool owner will lose 
> out. This is the same reason why 51% attack will never happen, even if 
> a pool gets more than 51% hash power.
>
>
> Next, I would like to propose a slightly modified technical solution 
> to this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last 
> difficulty period, is more than 90% MaxBlockSize
>          Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the 
> last difficulty period, is less than 50% MaxBlockSize
>          Half MaxBlockSize
> Else
>          Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 
> 50% hash power. Those who want to stop decrease, need to have more 
> than 10% hash power, but must mine more than 50% of MaxBlockSize in 
> all blocks. In this approach, not only miners, but also the end user 
> have their say. Because, end users will fill up the mempool, from 
> where miners will take Tx to fill up the blocks. Please note that, 
> taking first 2000 of the last 2016 blocks is important to avoid data 
> discrepancy among different nodes due to orphan blocks. It is assumed 
> that a chain can not be orphaned after having 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------010804030508030306040108
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">
    Sounds like a much better approach than arbitrary deciding what the
    block size should be<br>
    BR<br>
    <br>
    <div class="moz-cite-prefix">Le 18/08/2015 14:13, Upal Chakraborty
      via bitcoin-dev a écrit :<br>
    </div>
    <blockquote
cite="mid:CAED3CWgTOMFgaM6bBfU0Dn-R0NrdrhGAQo34wHEneYkTtB4Opg@mail.gmail.com"
      type="cite">
      <div dir="ltr">Regarding: <a moz-do-not-send="true"
href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html</a>
        <div><br>
          <div><br>
          </div>
          <div>I am arguing with the following statement here...</div>
          <div><br>
          </div>
          <div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><i>I
                see problems to this approach. The biggest one I see is
                that a miner with 11% of hash power could sabotage block
                size increases by only ever mining empty blocks.</i></blockquote>
            <div><br>
            </div>
            <div><br>
            </div>
            <div>First, I would like to argue from economics' point of
              view. If someone wants to hold back the block size
              increase with 11% hash power by mining empty blocks, he
              has to sacrifice Tx fees, which is not economical. 11%
              hash power will most likely be a pool and pool miners will
              find out soon that they are losing Tx fees because of pool
              owner's intention. Hence, they'll switch pool and pool
              owner will lose out. This is the same reason why 51%
              attack will never happen, even if a pool gets more than
              51% hash power.</div>
          </div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Next, I would like to propose a slightly modified technical
          solution to this problem in algorithmic format...</div>
        <div><br>
        </div>
        <div>If more than 50% of block's size, found in the first 2000
          of the last difficulty period, is more than 90% MaxBlockSize</div>
        <div>         Double MaxBlockSize</div>
        <div>
          <div>Else if more than 90% of block's size, found in the first
            2000 of the last difficulty period, is less than 50%
            MaxBlockSize</div>
          <div>         Half MaxBlockSize</div>
        </div>
        <div>Else</div>
        <div>         Keep the same MaxBlockSize</div>
        <div><br>
        </div>
        <div>This is how, those who want to stop increase, need to have
          more than 50% hash power. Those who want to stop decrease,
          need to have more than 10% hash power, but must mine more than
          50% of MaxBlockSize in all blocks. In this approach, not only
          miners, but also the end user have their say. Because, end
          users will fill up the mempool, from where miners will take Tx
          to fill up the blocks. Please note that, taking first 2000 of
          the last 2016 blocks is important to avoid data discrepancy
          among different nodes due to orphan blocks. It is assumed that
          a chain can not be orphaned after having 16 confirmation.</div>
        <div><br>
        </div>
        <div>Looking for comments.</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
      </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>

--------------010804030508030306040108--