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
|
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 <christophe.biocca@gmail.com>) id 1XXMJ7-0004p9-WF
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Sep 2014 03:34:58 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.173 as permitted sender)
client-ip=209.85.217.173;
envelope-from=christophe.biocca@gmail.com;
helo=mail-lb0-f173.google.com;
Received: from mail-lb0-f173.google.com ([209.85.217.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XXMJ6-0007DD-QO
for bitcoin-development@lists.sourceforge.net;
Fri, 26 Sep 2014 03:34:57 +0000
Received: by mail-lb0-f173.google.com with SMTP id 10so11970235lbg.18
for <bitcoin-development@lists.sourceforge.net>;
Thu, 25 Sep 2014 20:34:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.146.1 with SMTP id sy1mr16119764lbb.77.1411702490183;
Thu, 25 Sep 2014 20:34:50 -0700 (PDT)
Received: by 10.112.89.228 with HTTP; Thu, 25 Sep 2014 20:34:50 -0700 (PDT)
In-Reply-To: <CACq0ZD6sMHW6QEHHqDkaZwEwyfuk1CUjb0BRhzt3B+g+8CoP5A@mail.gmail.com>
References: <CACq0ZD4Ki=7Tba_2UhmuH-dPCbOnfXrJRcLPc+fP6Uur4FpG_A@mail.gmail.com>
<1447373.AzvO89eGJS@crushinator>
<CACq0ZD55G7sAXuu-UxoVJuuk1rwxKKwAPg4qkRoTreD1X2fc9Q@mail.gmail.com>
<6165581.aoAyGZkGge@crushinator>
<CACq0ZD6sMHW6QEHHqDkaZwEwyfuk1CUjb0BRhzt3B+g+8CoP5A@mail.gmail.com>
Date: Thu, 25 Sep 2014 23:34:50 -0400
Message-ID: <CANOOu=8-x_eLXP7JARyqjVs6YbM+NRk3N_ProJ6D+U2rqeAohw@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(christophe.biocca[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1XXMJ6-0007DD-QO
Subject: Re: [Bitcoin-development] SPV clients and relaying double spends
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: Fri, 26 Sep 2014 03:34:58 -0000
A lot of this discussion has already occured. Some code was even
merged into master, then reverted.
See:
https://github.com/bitcoin/bitcoin/issues/4550
https://github.com/bitcoin/bitcoin/pull/4570
It would probably be a good idea to start from that code, as it
addresses many of the possible pitfalls you've been discussing.
On Thu, Sep 25, 2014 at 10:37 PM, Aaron Voisine <voisine@gmail.com> wrote:
> Of course you wouldn't want nodes to propagate alerts without
> independently verifying them, otherwise anyone could just issue alerts
> for every new transaction.
>
> Aaron Voisine
> breadwallet.com
>
>
> On Thu, Sep 25, 2014 at 7:16 PM, Matt Whitlock <bip@mattwhitlock.name> wr=
ote:
>> Probably the first double-spend attempt (i.e., the second transaction to=
spend the same output(s) as another tx already in the mempool) would still=
need to be relayed. A simple "double-spend alert" wouldn't work because it=
could be forged. But after there have been two attempts to spend the same =
output, no further transactions spending that same output should be relayed=
, in order to prevent flooding the network.
>>
>>
>> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>>> Something like that would be a great help for SPV clients that can't
>>> detect double spends on their own. (still limited of course to sybil
>>> attack concerns)
>>>
>>> Aaron Voisine
>>> breadwallet.com
>>>
>>>
>>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock <bip@mattwhitlock.name> =
wrote:
>>> > What's to stop an attacker from broadcasting millions of spends of th=
e same output(s) and overwhelming nodes with slower connections? Might it b=
e a better strategy not to relay the actual transactions (after the first) =
but rather only propagate (once) some kind of double-spend alert?
>>> >
>>> >
>>> > On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine wrote:
>>> >> There was some discussion of having nodes relay double-spends in ord=
er
>>> >> to alert the network about double spend attempts.
>>> >>
>>> >> A lot more users will be using SPV wallets in the future, and one of
>>> >> the techniques SPV clients use to judge how likely a transaction is =
to
>>> >> be confirmed is if it propagates across the network. I wonder if and
>>> >> when double-spend relaying is introduced, if nodes should also send
>>> >> BIP61 reject messages or something along those lines to indicate whi=
ch
>>> >> transactions those nodes believe to be invalid, but are relaying
>>> >> anyway.
>>> >>
>>> >> This would be subject to sybil attacks, as is monitoring propagation=
,
>>> >> however it does still increase the cost of performing a 0 confirmati=
on
>>> >> double spend attack on an SPV client above just relaying double-spen=
ds
>>> >> without indicating if a node believes the transaction to be valid.
>>> >>
>>> >> Aaron Voisine
>>> >> breadwallet.com
>>> >
>
> -------------------------------------------------------------------------=
-----
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=3D154622311&iu=3D/4140/ostg=
.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
