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; 
MIME-Version: 1.0
In-Reply-To: <52796C14.5070300@quinnharris.me>
References: <N1-9eAtMHauq2@Safe-mail.net> <52796C14.5070300@quinnharris.me>
From: Drak <drak@zikula.org>
Date: Tue, 5 Nov 2013 23:03:13 +0000
Message-ID: <CANAnSg19N6Ri9vVkKqP2VB14KgLN6=whAbtzV9EBcLUfDs_dJQ@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e01493984af81aa04ea760a02
Subject: Re: [Bitcoin-development] Possible Solution To SM Attack
Precedence: list

--089e01493984af81aa04ea760a02
Content-Type: text/plain; charset=UTF-8

On 5 November 2013 22:07, Quinn Harris <btcdev@quinnharris.me> 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

<div dir=3D"ltr">On 5 November 2013 22:07, Quinn Harris <span dir=3D"ltr">&=
lt;<a href=3D"mailto:btcdev@quinnharris.me" target=3D"_blank">btcdev@quinnh=
arris.me</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I don&#39;t think choosing the block with th=
e lowest hash is the best<br>
option. =C2=A0The good and bad miners have an equal probability of finding =
a<br>
lower hash. =C2=A0But after Alice finds a block she can easily determine th=
e<br>
probability that someone else will find a lower hash value that meets<br>
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<br=
>
increase the chance her block is used.</blockquote><div><br></div><div>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&#39;s resulting hash will be higher or lower than hers since =
she does not know Bob&#39;s blockhash in advance and therefore she would be=
 better broadcasting her block immediately.</div>

<div><br></div><div>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.</div>


<div><br></div><div>Drak</div></div></div></div>

--089e01493984af81aa04ea760a02--