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
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1WxMlV-0007bS-B6
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Jun 2014 20:47:29 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=natanael.l@gmail.com;
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 1WxMlT-0000cQ-7B
for bitcoin-development@lists.sourceforge.net;
Wed, 18 Jun 2014 20:47:29 +0000
Received: by mail-wi0-f169.google.com with SMTP id hi2so9148684wib.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 18 Jun 2014 13:47:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.184.198 with SMTP id ew6mr560098wic.13.1403124440877;
Wed, 18 Jun 2014 13:47:20 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Wed, 18 Jun 2014 13:47:20 -0700 (PDT)
Received: by 10.194.243.104 with HTTP; Wed, 18 Jun 2014 13:47:20 -0700 (PDT)
In-Reply-To: <20140617155845.8177ADFC55C@quidecco.de>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
<CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
<20140617155845.8177ADFC55C@quidecco.de>
Date: Wed, 18 Jun 2014 22:47:20 +0200
Message-ID: <CAAt2M182f6=_MHqH33MbP3_d6ojAgnFu-T4mzL2SW5CWC74eDg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=001a11c3348cdfd5d304fc225d38
X-Spam-Score: -0.6 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WxMlT-0000cQ-7B
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
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: Wed, 18 Jun 2014 20:47:29 -0000
--001a11c3348cdfd5d304fc225d38
Content-Type: text/plain; charset=UTF-8
Den 17 jun 2014 17:59 skrev "Isidor Zeuner" <cryptocurrencies@quidecco.de>:
>
> quote:
> > Mike Hearn, why don't we just have all nodes report attempted double
spends
> > through the node network. No need to involve the miners at all really,
or
> > do your suggestion but also report the double spend attempt. By waiting
> > maybe 10-60 seconds (instead of 10 minutes for first conf), merchants
can
> > be more sure that a double spend attack was not tried. Attacker would
have
> > to hold back second tx by 10-60 seconds and hope that that second tx
(with
> > higher fee) get's into a solved block before the first one. This forced
> > delay time ought to make the attack less successful (but not
impossible).
> >
>
> What prevents the following steps from happening:
>
> 1. attacker sends first transaction, paying to the merchant
>
> 2. merchant waits 10-60 seconds
>
> 3. merchant confirms the payment as received
>
> 4. attacker sees merchant's confirmation
>
> 5. attacker sends double spend
>
> The security improvement seems to be pretty much exactly the chance
> that during the 10-60 seconds, a block is solved. Am I missing
> something?
>
> Regarding "reporting double spends", this would only help if it comes
> with some kind of penalty for the double spend. Now what if the double
> spend was not done on malicious motives? Maybe someone posted a
> transaction which does not confirm for some reason, and wants to
> recover his funds? Should we regard transactions which do not confirm
> as forever lost, in order to get to an "every double spend is a
> misbehaviour" policy?
>
> Best regards,
>
> Isidor
With 2-of-2 multisignature notaries, the doublespend (the set of
conflicting transactions) would be published and propagated together as
evidence of the notary being malicious. This is trivial and self-evident
self-contained proof.
But there should be no direct penalty IMHO in the Bitcoin protocol itself.
If a transaction would have to be replaced honestly because of being wrong
or simply not confirming, then I think there should be some means of
showing the second transaction is "legitimate". Don't ask me how exactly it
would work in practice, but one method could be through showing the
original recipients have signed off on it (showing they agree it should be
reversed).
If you can't get the original recipient to sign, then you're stuck with
either not replacing it or the notary trying to prove the replacing
transaction was legitimate.
--001a11c3348cdfd5d304fc225d38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Den 17 jun 2014 17:59 skrev "Isidor Zeuner" <<a=
href=3D"mailto:cryptocurrencies@quidecco.de">cryptocurrencies@quidecco.de<=
/a>>:<br>
><br>
> quote:<br>
> > Mike Hearn, why don't we just have all nodes report attempted=
double spends<br>
> > through the node network. No need to involve the miners at all re=
ally, or<br>
> > do your suggestion but also report the double spend attempt. By w=
aiting<br>
> > maybe 10-60 seconds (instead of 10 minutes for first conf), merch=
ants can<br>
> > be more sure that a double spend attack was not tried. Attacker w=
ould have<br>
> > to hold back second tx by 10-60 seconds and hope that that second=
tx (with<br>
> > higher fee) get's into a solved block before the first one. T=
his forced<br>
> > delay time ought to make the attack less successful (but not impo=
ssible).<br>
> ><br>
><br>
> What prevents the following steps from happening:<br>
><br>
> 1. attacker sends first transaction, paying to the merchant<br>
><br>
> 2. merchant waits 10-60 seconds<br>
><br>
> 3. merchant confirms the payment as received<br>
><br>
> 4. attacker sees merchant's confirmation<br>
><br>
> 5. attacker sends double spend<br>
><br>
> The security improvement seems to be pretty much exactly the chance<br=
>
> that during the 10-60 seconds, a block is solved. Am I missing<br>
> something?<br>
><br>
> Regarding "reporting double spends", this would only help if=
it comes<br>
> with some kind of penalty for the double spend. Now what if the double=
<br>
> spend was not done on malicious motives? Maybe someone posted a<br>
> transaction which does not confirm for some reason, and wants to<br>
> recover his funds? Should we regard transactions which do not confirm<=
br>
> as forever lost, in order to get to an "every double spend is a<b=
r>
> misbehaviour" policy?<br>
><br>
> Best regards,<br>
><br>
> Isidor</p>
<p dir=3D"ltr">With 2-of-2 multisignature notaries, the doublespend (the se=
t of conflicting transactions) would be published and propagated together a=
s evidence of the notary being malicious. This is trivial and self-evident =
self-contained proof.</p>
<p dir=3D"ltr">But there should be no direct penalty IMHO in the Bitcoin pr=
otocol itself. </p>
<p dir=3D"ltr">If a transaction would have to be replaced honestly because =
of being wrong or simply not confirming, then I think there should be some =
means of showing the second transaction is "legitimate". Don'=
t ask me how exactly it would work in practice, but one method could be thr=
ough showing the original recipients have signed off on it (showing they ag=
ree it should be reversed).</p>
<p dir=3D"ltr">If you can't get the original recipient to sign, then yo=
u're stuck with either not replacing it or the notary trying to prove t=
he replacing transaction was legitimate. </p>
--001a11c3348cdfd5d304fc225d38--
|
