1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
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 <drak@zikula.org>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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>></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'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'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.</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--
|
