Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.180 as permitted sender)
	client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f180.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20131104142621.GA2190@petertodd.org>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
	<20131104142621.GA2190@petertodd.org>
Date: Mon, 4 Nov 2013 16:27:58 +0100
Message-ID: <CANEZrP0pUvyP62NKu2hdzFYxaMdD7iPPmkL699-gZksZa=HHzg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=047d7bf0e94c9a673a04ea5b8f7f
Cc: Ittay Eyal <ittay.eyal@cornell.edu>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Precedence: list

--047d7bf0e94c9a673a04ea5b8f7f
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd <pete@petertodd.org> wrote:

> The attacker now only needs to connect to every identified miner
> with especially fast nodes. With judicious use of DoS attacks and low
> latency .....
>

So you're back to a complicated sybil attack. I don't follow your thought
process here - I didn't say anything about numerical advantage. The attack
outlined in the paper *requires* you to be able to race the rest of the
network and win some non-trivial fraction of the time. If you can't do that
then all it means is that when you try to release a private block to
compete with the other found block, you're quite likely to lose and you
sacrifice the block rewards by doing so.


> The correct, and rational, approach for a miner is to always mine to
> extend the block that the majority of hashing power is trying to extend.
>

There's no stable way to know that. The whole purpose of the block chain to
establish the majority. I think your near-miss headers solution is
circular/unstable for that reason, it's essentially a recursive solution.


> Mining strategy is now to mine to extend the first block you see, on the
> assumption that the earlier one probably propagated to a large portion
> of the total hashing power. But as you receive "near-blocks" that are
> under the PoW target, use them to estimate the hashing power on each
> fork, and if it looks like you are not on the majority side, switch.
>

But you can't reliably estimate that. You can't even reliably estimate the
speed of the overall network especially not on a short term basis like a
block interval.

--047d7bf0e94c9a673a04ea5b8f7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd <span dir=3D"lt=
r">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@peterto=
dd.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gm=
ail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">The attacker now only needs to connect to every identified miner<=
/span><br>
</div>
with especially fast nodes. With judicious use of DoS attacks and low<br>
latency .....<br></blockquote><div><br></div><div>So you&#39;re back to a c=
omplicated sybil attack. I don&#39;t follow your thought process here - I d=
idn&#39;t say anything about numerical advantage. The attack outlined in th=
e paper <b>requires</b>=C2=A0you to be able to race the rest of the network=
 and win some non-trivial fraction of the time. If you can&#39;t do that th=
en all it means is that when you try to release a private block to compete =
with the other found block, you&#39;re quite likely to lose and you sacrifi=
ce the block rewards by doing so.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">The correct, and rational, =
approach for a miner is to always mine to<br>
extend the block that the majority of hashing power is trying to extend.<br=
></blockquote><div><br></div><div>There&#39;s no stable way to know that. T=
he whole purpose of the block chain to establish the majority. I think your=
 near-miss headers solution is circular/unstable for that reason, it&#39;s =
essentially a recursive solution.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">Mining strategy is now to m=
ine to extend the first block you see, on the<br>
assumption that the earlier one probably propagated to a large portion<br>
of the total hashing power. But as you receive &quot;near-blocks&quot; that=
 are<br>
under the PoW target, use them to estimate the hashing power on each<br>
fork, and if it looks like you are not on the majority side, switch.<br></b=
lockquote><div><br></div><div>But you can&#39;t reliably estimate that. You=
 can&#39;t even reliably estimate the speed of the overall network especial=
ly not on a short term basis like a block interval.</div>
</div></div></div>

--047d7bf0e94c9a673a04ea5b8f7f--