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 1WJLT0-0003mU-4l
for bitcoin-development@lists.sourceforge.net;
Fri, 28 Feb 2014 11:18:58 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.112 as permitted sender)
client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
helo=outmail148112.authsmtp.co.uk;
Received: from outmail148112.authsmtp.co.uk ([62.13.148.112])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WJLSy-000833-Ez for bitcoin-development@lists.sourceforge.net;
Fri, 28 Feb 2014 11:18:58 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1SBIo7C005425;
Fri, 28 Feb 2014 11:18:50 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1SBIfPb042290
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 28 Feb 2014 11:18:43 GMT
Date: Fri, 28 Feb 2014 06:18:26 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy Spilman <jeremy@taplink.co>
Message-ID: <20140228111826.GA6798@savin>
References: <20140225044116.GA28050@savin>
<f35865264f37315d580a30dc49789a5a.squirrel@fulvetta.riseup.net>
<CANEZrP1wB9zpnD+DOnmCNycEGB+nZMt8gQrjpn5V92MMkausaA@mail.gmail.com>
<20140225144922.GA25549@savin>
<CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
<op.xbundx2eyldrnw@laptop-air>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <op.xbundx2eyldrnw@laptop-air>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 15ac6bc3-a06a-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAoUHlAWAgsB AmIbWlVeUVV7XWc7 bAxPbAVDY01GQQRq
WVdMSlVNFUsrAH9z f0h+ABl2dQdPeDBy ZkRnWD5aWRUpcxQu
QVMFFWtXeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4lEzN0 SwoFBV0A
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/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: 1WJLSy-000833-Ez
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fee drop
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, 28 Feb 2014 11:18:58 -0000
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote:
> If I understand correctly, the risk here is this would open a
> historically large discrepancy between MIN_RELAY and the expected
> minimum fee to actually obtain block inclusion. I don't know if
> that's true, but I think that's what Peter is saying makes it
> different this time.
That's exactly the problem.
Of course every time we make a new transaction type standard we also run
that risk, but at least it's a temporary situation and we can expect to
get hashing power on-board fairly quickly. With such a low MIN_RELAY
that's not true, and in an absolute sense, the funds required to DoS
attack the network are fairly low.
> On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn <mike@plan99.net> wrote:
> >Nodes that are encountering memory pressure can increase their min
> >relay fee locally until their usage fits inside their resources.
> >It's annoying to do this >by hand but by no means infeasible.
>=20
> Perhaps this is just another way to think of the floating fee
> problem. What does MIN_RELAY need to be so that my local resources
> stay within some reasonable limit (and 'reasonable' means different
> things to different nodes).
>=20
> We have an input gate on transactions entering mempool, we persist
> mempool, and I don't know the specifics but, I assume there's some
> expiration policy other than block inclusion to clear out a Tx from
> mempool. But are transactions prioritized in any way after they make
> it into mempool today?
There's currently no expiration policy at all; that's the root of the
DoS problem I was referring too.
> How closely should mempool selection align with the expected block
> inclusion? I think if they align perfectly in theory that means
> optimal mempool resource allocation. For example, a miner would push
> out cheaper transactions which they were previously hashing against
> to make room for higher fee transactions (bsaed on max block size or
> orphan rate projections), but do we do the same for mempool? E.g.
>=20
> - After hitting X number of transactions, the fee has to be larger
> than a transaction in mempool in order to get in,
> - That in turn that ejects a random transaction which paid less
> fees than the incoming Tx from mempool
> - We would have to consider how ejection would work with chains of
> unconfirmed transactions (cumulative average fee/kb?) but again in
> this case, you would want to 'do what miners would do' if you could
Have you seen the mempool superblock design that keeps getting
suggested? jgarzik has the most recent write-up here:
https://github.com/bitcoin/bitcoin/issues/3723
I was working on a relatively ambitious version of it last summer that
calculated the fee/KB for transactions, including depedencies, and then
simply ordered the mempool with highest fee/KB first. The idea was you
could then easily limit the total size of the mempool and drop
transactions with the lowest fee/KB first. Transactions that paid less
than the lowest fee/KB in a max-size mempool simply would not get
relayed at all. Pity had to put it off for higher-priority work.
What's interesting is how this makes zero-conf transactions even less
safe: all you have to do to double-spend one (or more!) that pay X
fee/KB is broadcast enough transactions paying X+e fee/KB to push out
the unconfirmed tx from mepools around the network, then broadcast your
double-spend. Obviously the economics of this are going to make attacks
frequently profitable, especially if you can attack multiple targets at
once. You can of course have schemes where you don't entirely drop
transactions, saving, say, the inputs they spend and a transaction id,
(so a rebroadcast can succeed) but that just reduces the effectiveness
of the attack by a constant factor and makes it possible to get into
complex situations where your funds are locked and unspendable.
--=20
'peter'[:-1]@petertodd.org
00000000000000011ffdfe2bfdf8f1f983bebfa160670b85afeebbd815fdf484
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQGrBAEBCACVBQJTEHCBXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDEzM2QyMjdkNzkzYTgyMzc2N2FmMGI5YTVhZjJkNzUyM2Ji
NGZlNmY3OTE2ZmU3MDcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuw8ggAs+5r4iJX0y6tMBuqv9oOvbcc
35sdmITzKFnD7dcfj3O3iZS4Lpm+RWYGOP9xByuLt9hzixpYeLS2Nb3bblpCdy5E
LCL08vdUFjRDCrFpGiuIzRDromVjeKaDWvt9YT+FC2tX0WIrbGmDgMmam/z1274q
nMAdmkMtcjATMFu37pV2VKH/gsWidjoIStvCQO4Y/Wy1QnHgS4EYIbBdp+dYfjkZ
wjddfalMXMyKWEaicQTTrT3DMzqeZ9jJg6eUNlIHp9P4jhmjY179ybKsQp2Bd8zF
wFvACun8uU3TgTg3ptPBlWjcp1L3uwdlzhyMkyuzCEmfkNtE8aUzrJ1AM//TBw==
=UZ9/
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--
|
