From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdM4U-0004d4-Be for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:28:06 +0000 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; Received: from mail-ob0-f180.google.com ([209.85.214.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdM4S-0005gH-Cz for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 15:28:06 +0000 Received: by mail-ob0-f180.google.com with SMTP id wo20so7092218obc.25 for ; Mon, 04 Nov 2013 07:27:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.155.145 with SMTP id vw17mr1889895oeb.50.1383578879024; Mon, 04 Nov 2013 07:27:59 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 07:27:58 -0800 (PST) In-Reply-To: <20131104142621.GA2190@petertodd.org> References: <20131104142621.GA2190@petertodd.org> Date: Mon, 4 Nov 2013 16:27:58 +0100 X-Google-Sender-Auth: blkQ34pMifkSSdbOZSEZZFrknNc Message-ID: From: Mike Hearn To: Peter Todd Content-Type: multipart/alternative; boundary=047d7bf0e94c9a673a04ea5b8f7f X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1VdM4S-0005gH-Cz Cc: Ittay Eyal , Bitcoin Dev Subject: Re: [Bitcoin-development] Auto-generated miner backbone X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 15:28:06 -0000 --047d7bf0e94c9a673a04ea5b8f7f Content-Type: text/plain; charset=UTF-8 On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd 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
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd <pete@peterto= dd.org> wrote:
The attacker now only needs to connect to every identified miner<= /span>
with especially fast nodes. With judicious use of DoS attacks and low
latency .....

So you're back to a c= omplicated sybil attack. I don't follow your thought process here - I d= idn't say anything about numerical advantage. The attack outlined in th= e paper requires=C2=A0you 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 th= en 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 sacrifi= ce the block rewards by doing so.
=C2=A0
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. 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's = essentially a recursive solution.
=C2=A0
Mining strategy is now to m= ine 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 especial= ly not on a short term basis like a block interval.
--047d7bf0e94c9a673a04ea5b8f7f--