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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <drak@zikula.org>) id 1VdqIc-0005Fb-Im
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 23:44:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of zikula.org
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=drak@zikula.org;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdqIb-0002C3-Mi
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Nov 2013 23:44:42 +0000
Received: by mail-wg0-f41.google.com with SMTP id b13so3653085wgh.4
for <bitcoin-development@lists.sourceforge.net>;
Tue, 05 Nov 2013 15:44:35 -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=tgpBTUiId67tbwO4KH/WpdYgYoiSlTx+J5UzvMgyQBg=;
b=azoIrAUZMnzYNiulvQyN/lScQMJW3iNUzgZbwMd4vOIWH7rKuWPg3CbdNG1jM8sP9H
W0AAJMzd/MnnpbRrEKPPcw7zxCH84rW8fKKFwhQ+dC7IDujwerheJMit5KQ1pKjSuEFS
Z+3NLh/zK4sfW/oVSd1yaeSrradkJMFluku/KdHgBAGN2VGbsSwib42/q3r6NObYQvj0
eZ0ZHPuMxWOsjYcbpmLfg8lNJII37lZbnO8EdLk/gwZu2lUQZbGs3Wti77RSaiRhXPkt
ro16LmI69Gy5+q236NvMGZV9nmbKGvw3svkSJ+PsHsT/PvUH7ON5n25+xspM2mfkawkk
pZXA==
X-Gm-Message-State: ALoCoQmZtMlBtan1ECfqboZOaQaa3jWtT7qL3JZ4otTS4f8WG+bXWOcLZ98nd53y8P4dZmNWqfMl
X-Received: by 10.181.11.163 with SMTP id ej3mr53717wid.47.1383695075381; Tue,
05 Nov 2013 15:44:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Tue, 5 Nov 2013 15:44:15 -0800 (PST)
In-Reply-To: <CAAS2fgTofL7ura17KjUR5pL_fOOM=a0gdZTZ7seVMRPOPi66xw@mail.gmail.com>
References: <N1-9eAtMHauq2@Safe-mail.net>
<CANAnSg2sUfRH0mYEir_XKUz-iOYRpdzNgM-AJ7t-H=SOa4wBig@mail.gmail.com>
<CAAS2fgTofL7ura17KjUR5pL_fOOM=a0gdZTZ7seVMRPOPi66xw@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Tue, 5 Nov 2013 23:44:15 +0000
Message-ID: <CANAnSg1vrUZPuioZ7LQcSK4MeiWWWQ2nggnDYp5VP4WdhtErhQ@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=f46d043be1e0722de704ea769d91
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
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: zikula.org]
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1VdqIb-0002C3-Mi
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:44:42 -0000
--f46d043be1e0722de704ea769d91
Content-Type: text/plain; charset=UTF-8
On 5 November 2013 23:06, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Tue, Nov 5, 2013 at 2:15 PM, Drak <drak@zikula.org> wrote:
> > If I understand the issue properly, this seems like a pretty elegant
> > solution: if two blocks are broadcast within a certain period of
> eachother,
> > chose the lower target. That's a provable fair way of randomly choosing
> the
> > winning block and would seem like a pretty simply patch.
>
> uh. and so when my solution is, by chance, unusually low... I am
> incentivized to hurry up and release my block because?
Yes, I saw the flaw as pointed out by Quinn so I then suggested two step
solution:
1. Decide high or low by taking a the leading bytes from
hash(alice)+hash(bob): above certain number we the rule is "higher wins",
below a certain number the "lower hash wins"
2. Chose winner based on the higher or lower of hash(alice) or hash(bob)
based on the rule coming from 1
Now you have a situation where you don't know the rules of the game in
advance (whether high or low wins) until the hands are already dealt nor
have any idea about how high or low Bob's hash will be since it's not based
on target anymore, but on a hash of the blockhash so it makes it a guessing
game.
You might have an unusually high or low hash, but then you have no idea
whether higher or lower is going to win. So it is better for Alice to just
broadcast the block.
What do you think?
Drak
--f46d043be1e0722de704ea769d91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 5 November 2013 23:06, Gregory Maxwell <span dir=3D"ltr=
"><<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmai=
l.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Tue, Nov 5, 2013 at 2:15 PM, Drak <=
;<a href=3D"mailto:drak@zikula.org">drak@zikula.org</a>> wrote:<br>
> If I understand the issue properly, this seems like a pretty elegant<b=
r>
> solution: if two blocks are broadcast within a certain period of eacho=
ther,<br>
> chose the lower target. That's a provable fair way of randomly cho=
osing the<br>
> winning block and would seem like a pretty simply patch.<br>
<br>
</div>uh. and so when my solution is, by chance, unusually low... I am<br>
incentivized to hurry up and release my block because?</blockquote><div>=C2=
=A0</div>Yes, I saw the flaw as pointed out by Quinn so I then suggested tw=
o step solution:<div><br></div><div>1. Decide high or low by taking a the l=
eading bytes from hash(alice)+hash(bob): above certain number we the rule i=
s "higher wins", below a certain number the "lower hash wins=
"</div>
<div>2. Chose winner based on the higher or lower of hash(alice) or hash(bo=
b) based on the rule coming from 1</div><div><br></div><div>Now you have a =
situation where you don't know the rules of the game in advance (whethe=
r high or low wins) until the hands are already dealt nor have any idea abo=
ut how high or low Bob's hash will be since it's not based on targe=
t anymore, but on a hash of the blockhash so it makes it a guessing game.=
=C2=A0</div>
<div><br></div><div>You might have an unusually high or low hash, but then =
you have no idea whether higher or lower is going to win. So it is better f=
or Alice to just broadcast the block.</div><div><br></div><div>What do you =
think?</div>
<div><br></div><div>Drak<br></div><div><br></div><div><br></div></div><br><=
/div></div>
--f46d043be1e0722de704ea769d91--
|
