From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vdpeu-0000o4-3W for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 23:03:40 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of zikula.org designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=drak@zikula.org; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vdpet-0007o5-DH for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 23:03:40 +0000 Received: by mail-wi0-f169.google.com with SMTP id cb5so4065922wib.2 for ; Tue, 05 Nov 2013 15:03:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=/u76sAnsNVFYAp20BMNHeYen8Q8vX+K3Ub4lIvUULZU=; b=EwhgZJJmHZO7UKX41535qkVxHitzi6Oh22ouDy5393MwmWpauS6APlfvWJTWUIHv50 9EJkoX/bV7qq2rIiV2uSihx/Gja1KbPQ7k9yYI6A+HAS8aGornEOgRNGIsPCFjga7kff AW5LiyczuFjsiFlvRylWi7j0BbjntfTfaQS8SPOMsKY7NqyAhXTNZ5Kg5v+fVLXqjVuR yHIQjUitobR29+HmGZXwIhpDsNrS8KAlXhap6wy0MOJP9oxuVFzh8gY+RFCXbfGixKUm vEi2MSnZn9jzxFVfzJHeo5Y/BOlwNH065jiWb9Wmtz2vZXpN6BKPPwx2vKV2QCkhQgVu FqOQ== X-Gm-Message-State: ALoCoQkbzJM8PJXl+pJKPFm6hGeU5NzUyywPVIsLbrSuS5ZgFKL6+wU/WK07QXRD6lY0v4FUNeTx X-Received: by 10.194.238.230 with SMTP id vn6mr3792317wjc.57.1383692613150; Tue, 05 Nov 2013 15:03:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.93.105 with HTTP; Tue, 5 Nov 2013 15:03:13 -0800 (PST) In-Reply-To: <52796C14.5070300@quinnharris.me> References: <52796C14.5070300@quinnharris.me> From: Drak Date: Tue, 5 Nov 2013 23:03:13 +0000 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=089e01493984af81aa04ea760a02 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: quinnharris.me] X-Headers-End: 1Vdpet-0007o5-DH Subject: Re: [Bitcoin-development] Possible Solution To SM Attack 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: Tue, 05 Nov 2013 23:03:40 -0000 --089e01493984af81aa04ea760a02 Content-Type: text/plain; charset=UTF-8 On 5 November 2013 22:07, Quinn Harris wrote: > I don't think choosing the block with the lowest hash is the best > option. The good and bad miners have an equal probability of finding a > lower hash. But after Alice finds a block she can easily determine the > probability that someone else will find a lower hash value that meets > the difficulty requirement. This can be used to judge if its best to > start working on the next block or work on finding a lower value hash to > increase the chance her block is used. Well in that case, you could make it unpredictable by choosing based on a hash of the blockhash and chose the lowest from two. There is no way for Alice to know if Bob's resulting hash will be higher or lower than hers since she does not know Bob's blockhash in advance and therefore she would be better broadcasting her block immediately. You could even add another unpredictable factor: deciding the rules of whether higher or lower wins by hashing both competing blockhashes. If the leading two hex digits are below 128 lower wins, and if above, higher wins. Drak --089e01493984af81aa04ea760a02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 5 November 2013 22:07, Quinn Harris &= lt;btcdev@quinnh= arris.me> wrote:
I don't think choosing the block with th= e lowest hash is the best
option. =C2=A0The good and bad miners have an equal probability of finding = a
lower hash. =C2=A0But after Alice finds a block she can easily determine th= e
probability that someone else will find a lower hash value that meets
the difficulty requirement. =C2=A0This can be used to judge if its best to<= br> start working on the next block or work on finding a lower value hash to increase the chance her block is used.

Well= in that case, you could make it unpredictable by choosing based on a hash = of the blockhash and chose the lowest from two. There is no way for Alice t= o know if Bob's resulting hash will be higher or lower than hers since = she does not know Bob's blockhash in advance and therefore she would be= better broadcasting her block immediately.

You could even add another unpredictable factor: decidi= ng the rules of whether higher or lower wins by hashing both competing bloc= khashes. If the leading two hex digits are below 128 lower wins, and if abo= ve, higher wins.

Drak
--089e01493984af81aa04ea760a02--