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
|
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 <john.dillon892@googlemail.com>) id 1VBFqE-0002Cm-OH
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 03:09:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com
designates 74.125.83.52 as permitted sender)
client-ip=74.125.83.52;
envelope-from=john.dillon892@googlemail.com;
helo=mail-ee0-f52.google.com;
Received: from mail-ee0-f52.google.com ([74.125.83.52])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VBFqD-0003Bu-P7
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 03:09:14 +0000
Received: by mail-ee0-f52.google.com with SMTP id c41so1866889eek.25
for <bitcoin-development@lists.sourceforge.net>;
Sun, 18 Aug 2013 20:09:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.15.43.140 with SMTP id x12mr45633eev.61.1376881747432; Sun,
18 Aug 2013 20:09:07 -0700 (PDT)
Received: by 10.223.41.4 with HTTP; Sun, 18 Aug 2013 20:09:07 -0700 (PDT)
In-Reply-To: <20130816141536.GD16201@petertodd.org>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
<20130816140116.GB16201@petertodd.org>
<20130816141536.GD16201@petertodd.org>
Date: Mon, 19 Aug 2013 03:09:07 +0000
Message-ID: <CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com>
From: John Dillon <john.dillon892@googlemail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
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
(john.dillon892[at]googlemail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (john.dillon892[at]googlemail.com)
-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: 1VBFqD-0003Bu-P7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
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: Mon, 19 Aug 2013 03:09:15 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd <pete@petertodd.org> wrote:
> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>> Doing this also makes it more difficult to sybil the network - for
>> instance right now you can create "SPV honeypots" that allow incoming
>> connections only from SPV nodes, thus attracting a disproportionate % of
>> the total SPV population given a relatively small number of nodes. You
>> can then use that to harm SPV nodes by, for instance, making a % of
>> transactions be dropped deterministicly, either by the bloom matching
>> code, or when sent. Users unlucky enough to be surrounded by sybil nodes
>> will have their transactions mysteriously fail to arrive in their
>> wallets, or have their transactions mysteriously never confirm. Given
>> how few full nodes there are, it probably won't take very many honeypots
>> to pull off this attack, especially if you combine it with a
>> simultaneous max connections or bloom io attack to degrade the capacity
>> of honest nodes.
>
> Oh, here's an even better way to do the "tx drop" attack: when you drop
> a transaction, make a fake one that pays the same scriptPubKeys with the
> same amount, and send it to the SPV peer instead. They'll see the
> transaction go through and show up in their wallet, but it'll look like
> it got stuck and never confirmed. They'll soon wind up with a wallet
> full of useless transactions, effectively locking them out of their
> money.
Excellent, and makes a mockery of zero-confirmation transactions to boot.
Can be prevented by passing along txin proofs, but they require the full
transaction, so the effective UTXO set size would go up greatly post-pruning. I
am sure Mike would love to demand that full nodes do this for their peers
though, at least until UTXO commitments are greated, at great cost to full
nodes.
On the other hand, a tx with some txin proofs can be safely relayed by SPV
nodes, an interesting concept. Do the UTXO commitment people have keeping proof
size small in mind?
> Here's another question for you Mike: So does bitcoinj have any
> protections against peers flooding you with useless garbage? It'd be
> easy to rack up a user's data bill for instance by just creating junk
> unconfirmed transactions matching the bloom filter.
That is good too.
I'll bounty 2.5BTC to implement the first attack, and 0.5BTC for the second.
Should be easy to do as a patch to satoshi bitcoin I think. The implementation
must include a RFC3514 compliant service bit to let peers know of the operators
intentions. Along those lines I'll donate 3BTC to adding service bit selection
to DNS seeds.
We should clearly show people the limitations of SPV before they depend too
much on it. Nothing wakes users up like a 21 million BTC transaction in their
wallet.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSEYvxAAoJEEWCsU4mNhiPxI8IAJaWJ9s0YG3Ex5h8Dr6oPJ9M
uXTXa/Rt0DqS6mmyD9O80sXfgPbPbQa2rDL6imlqONaWfpXFZl2W9vxRGaZJ9wrr
3KBHzK8lasDOKqlEX92h8ZmQBjw4w5bK/heRLo1PnSZ8ojKn8+My1JvZWOPzF0Ct
tDXXuCE94csKuGRdmdDdVoXqy4XZaMQhHrGbrWVotQs1HzX3iK146GoGaZC0YyBx
cdWg/xDPtAxgb5zf2RSeNHfXeY0wZawe8vBxaS56gCRl54PG7fJvqL+YPcarNb1p
zEmahJjoyQHskjFeDpgEiXnWu3K3JGTSA5GvekWvBbJCcV4o1E6EI6LG0f1SfIs=
=12DC
-----END PGP SIGNATURE-----
|
