Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.48 as permitted sender)
	client-ip=74.125.82.48; envelope-from=startithub@gmail.com;
	helo=mail-wg0-f48.google.com; 
MIME-Version: 1.0
In-Reply-To: <52792CF2.10709@intersango.com>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
	<20131105170541.GA13660@petertodd.org>
	<CABT1wWnPJOKKT5v2hGePkUT8jNau=TEK5s-n2so2kQKnv-HfqQ@mail.gmail.com>
	<52792CF2.10709@intersango.com>
Date: Tue, 5 Nov 2013 19:18:22 +0100
Message-ID: <CADre0dkw+Lhh9HodgPz0u4MgxkpO+KJhCoGfDbOQZM3TExab+w@mail.gmail.com>
From: Alessandro Parisi <startithub@gmail.com>
To: Patrick <patrick@intersango.com>
Content-Type: multipart/alternative; boundary=001a11c25c9ed2d8da04ea720ef9
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish
 mining threshold.
Precedence: list

--001a11c25c9ed2d8da04ea720ef9
Content-Type: text/plain; charset=ISO-8859-1

Patrick, could you please explain us why the solution proposed by Ittay
would drop the actual honest miners ratio, becoming so backfire? Thanks a
lot


2013/11/5 Patrick <patrick@intersango.com>

>  The ratio of honest miners that mine the first block they see is > 0.5
>
> Your proposed solution would reduce that ratio to 0.5
>
> In other words your proposed change would make the attack you describe
> easier not harder.
>
>
> On 11/05/2013 09:26 AM, Ittay wrote:
>
> That sounds like selfish mining, and the magic number is 25%. That's the
> minimal pool size.
> Today the threshold is 0% with good connectivity.
>
>  If I misunderstood your point, please elaborate.
>
>  Ittay
>
>
>
> On Tue, Nov 5, 2013 at 12:05 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Tue, Nov 05, 2013 at 11:56:53AM -0500, Ittay wrote:
>> > Hello,
>> >
>> > Please see below our BIP for raising the selfish mining threshold.
>> > Looking forward to your comments.
>>
>>  <snip>
>>
>> > 2. No new vulnerabilities introduced:
>> > Currently the choice among equal-length chains is done arbitrarily,
>> > depending on network topology. This arbitrariness is a source of
>> > vulnerability. We replace it with explicit randomness, which is at the
>> > control of the protocol. The change does not introduce executions that
>> were
>> > not possible with the old protocol.
>>
>>  Credit goes to Gregory Maxwell for pointing this out, but the random
>> choice solution does in fact introduce a vulnerability in that it
>> creates incentives for pools over a certain size to withhold blocks
>> rather than immediately broadcasting all blocks found.
>>
>> The problem is that when the pool eventually choses to reveal the block
>> they mined, 50% of the hashing power switches, thus splitting the
>> network. Like the original attack this can be to their benefit. For
>> pools over a certain size this strategy is profitable even without
>> investing in a low-latency network; Maxwell or someone else can chime in
>> with the details for deriving that threshold.
>>
>> I won't get a chance to for a few hours, but someone should do the
>> analysis on a deterministic switching scheme.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707
>>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and registerhttp://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a11c25c9ed2d8da04ea720ef9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div><div style>Patrick, could =
you please explain us why the solution proposed by Ittay would drop the act=
ual honest miners ratio, becoming so backfire? Thanks a lot</div></div>
<br><br><div class=3D"gmail_quote">2013/11/5 Patrick <span dir=3D"ltr">&lt;=
<a href=3D"mailto:patrick@intersango.com" target=3D"_blank">patrick@intersa=
ngo.com</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>The ratio of honest miners that mine
      the first block they see is &gt; 0.5<br>
      <br>
      Your proposed solution would reduce that ratio to 0.5<br>
      <br>
      In other words your proposed change would make the attack you
      describe easier not harder.<div><div class=3D"h5"><br>
      <br>
      On 11/05/2013 09:26 AM, Ittay wrote:<br>
    </div></div></div>
    <blockquote type=3D"cite"><div><div class=3D"h5">
      <div dir=3D"ltr">That sounds like selfish mining, and the magic
        number is 25%. That&#39;s the minimal pool size.=A0
        <div>Today the threshold is 0% with good connectivity.=A0</div>
        <div><br>
        </div>
        <div>If I misunderstood your point, please elaborate.=A0</div>
        <div><br>
        </div>
        <div>Ittay=A0</div>
        <div><br>
        </div>
      </div>
      <div class=3D"gmail_extra"><br>
        <br>
        <div class=3D"gmail_quote">On Tue, Nov 5, 2013 at 12:05 PM, Peter
          Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@petertodd.org" =
target=3D"_blank">pete@petertodd.org</a>&gt;</span>
          wrote:<br>
          <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
            <div>On Tue, Nov 05, 2013 at 11:56:53AM -0500,
              Ittay wrote:<br>
              &gt; Hello,<br>
              &gt;<br>
              &gt; Please see below our BIP for raising the selfish
              mining threshold.<br>
              &gt; Looking forward to your comments.<br>
              <br>
            </div>
            &lt;snip&gt;<br>
            <div><br>
              &gt; 2. No new vulnerabilities introduced:<br>
              &gt; Currently the choice among equal-length chains is
              done arbitrarily,<br>
              &gt; depending on network topology. This arbitrariness is
              a source of<br>
              &gt; vulnerability. We replace it with explicit
              randomness, which is at the<br>
              &gt; control of the protocol. The change does not
              introduce executions that were<br>
              &gt; not possible with the old protocol.<br>
              <br>
            </div>
            Credit goes to Gregory Maxwell for pointing this out, but
            the random<br>
            choice solution does in fact introduce a vulnerability in
            that it<br>
            creates incentives for pools over a certain size to withhold
            blocks<br>
            rather than immediately broadcasting all blocks found.<br>
            <br>
            The problem is that when the pool eventually choses to
            reveal the block<br>
            they mined, 50% of the hashing power switches, thus
            splitting the<br>
            network. Like the original attack this can be to their
            benefit. For<br>
            pools over a certain size this strategy is profitable even
            without<br>
            investing in a low-latency network; Maxwell or someone else
            can chime in<br>
            with the details for deriving that threshold.<br>
            <br>
            I won&#39;t get a chance to for a few hours, but someone should
            do the<br>
            analysis on a deterministic switching scheme.<br>
            <span><font color=3D"#888888"><br>
                --<br>
                &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" targe=
t=3D"_blank">petertodd.org</a><br>
0000000000000005e25ca9b9fe62bdd6e8a2b4527ad61753dd2113c268bec707<br>
              </font></span></blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><div class=3D"im"><pre>----------------------------------=
--------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explor=
e
techniques for threading, error checking, porting, and tuning. Get the most=
=20
from the latest Intel processors and coprocessors. See abstracts and regist=
er
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;iu=3D/4140/ostg.clktrk</a></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>
</pre>
    </div></blockquote>
    <br>
  </div>

<br>-----------------------------------------------------------------------=
-------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;iu=3D/4140/ostg.clktrk</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>

--001a11c25c9ed2d8da04ea720ef9--