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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VAKas-0004tm-Ao
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 14:01:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VAKaq-0007KS-J6 for bitcoin-development@lists.sourceforge.net;
Fri, 16 Aug 2013 14:01:34 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r7GE1PxT091707; Fri, 16 Aug 2013 15:01:25 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r7GE1H2f072135
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 16 Aug 2013 15:01:19 +0100 (BST)
Date: Fri, 16 Aug 2013 10:01:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20130816140116.GB16201@petertodd.org>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="PmA2V3Z32TCmWXqI"
Content-Disposition: inline
In-Reply-To: <CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 53b799b2-067c-11e3-b5c5-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwQUGUATAgsB AmUbWlFeUFx7W2M7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxt2 cx9mUE9ycAdHe3s+ Z0RlXXIVWUcock90
EExJFWsBNnphaTUc TRJdJAZJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMTci RhZNBn03GlYZAn11
flQaDXI7VEIQKVl0 dx1J
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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
X-Headers-End: 1VAKaq-0007KS-J6
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: Fri, 16 Aug 2013 14:01:34 -0000
--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 16, 2013 at 02:24:04PM +0200, Mike Hearn wrote:
> The only other thing I'd like to see there is the start of a new anti-DoS
> framework. I think once the outline is in place other people will be able
> to fill it in appropriately. But the current framework has to be left
> behind.
Part of anti-DoS should include making it easier for people to
contribute back to the network. Lowest hanging fruit:
1) SPV nodes with spare bandwidth should relay whole blocks to reduce
the load on full-nodes. The SPV security model is based on hashing power
anyway, so there is no major harm in doing so - if you have the
resources to fake blocks, you probably have the resources to sybil the
network anyway.
2) It's probably reasonable for SPV peers with bandwidth to be willing
to do bloom filtering on the behalf of peers that don't have spare
bandwidth. Hence they would set NODE_BLOOM, but not NODE_NETWORK. (or
more likely some more nuanced flags) Again this has to apply to full
blocks only unless we come up with some PoW scheme or similar to
discourage DoS attacks via invalid transactions. (maintaining partial
UTXO sets is another possibility, although a complex one)
Both examples work best with payment protocols where the recipient is
responsible for getting the transaction broadcast. Similarly you can by
default not connect to full-node peers, and then connect to them on
demand when you have a transaction to send.
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.
Deanonymization is another attack that can be done at the same time of
course.
In any case, the more peers on the network that can relay data the
better.
3) Make it easier to run a full node. IMO partial mode is the way to go
here. Note that from a legal perspective we really want to make sure
that running full nodes (and mining p2pool or solo) continue to be
something ordinary users do. We do not want to give the impression to
regulators that running a full node is in any way unusual or rare, and
thus something that might be practical or desirable to regulate. Users
should be given clear options about how much disk space and bandwidth to
donate to the health of the network, and within those limits nodes
should always try to make progress towards being full nodes, and in the
meantime being increasingly productive partial nodes.
Even with pure SPV nodes if they are relaying block data and ideally
transactions they make it much more difficult for regulations to be made
that, say, require full node operators to apply blacklists to
transactions in the mempool or in blocks.
4) This is really a side effect, and not directly DoS-related, but
unfortunately we're going to have to create some kind of
proof-of-UTXO-possession that miners include in the blocks they mine.
With partial mode it's just too easy and tempting for people to mine
blocks with fee paying transactions in them without actually having the
full UTXO set; such nodes can't tell if a block is invalid due to a fake
txin, and thus will happily extend a invalid chain. This possession
proof can probably be make part of a UTXO commitment.
> If I had to choose one thing to evict to make time for that, it'd be the
> whitepapers. At the moment we still have plenty of headroom in block size=
s,
> even post April. It can probably be safely delayed for a while.
Lots of off-chain tx solutions are popping up which will help push back
the issue's relevance as well. Also your micropayment channels possibly.
--=20
'peter'[:-1]@petertodd.org
000000000000000b9656276a0fdab028ca759c3fd7f951fb20196c264b5cd1ce
--PmA2V3Z32TCmWXqI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlIOMKwACgkQpEFN739thoxusACdHlQifBh2/AOWq7oMbeLgB/pO
AhUAn2W5vIQj384QPwn6tihCCPId4gqO
=1OOu
-----END PGP SIGNATURE-----
--PmA2V3Z32TCmWXqI--
|
