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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1WIMRc-0005bV-3t
for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 18:09:28 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1WIMRb-0005Bj-3f for bitcoin-development@lists.sourceforge.net;
Tue, 25 Feb 2014 18:09:28 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co
; Tue, 25 Feb 2014 10:09:27 -0800
Content-Type: multipart/alternative; boundary=----------2hveFpErhO0lXNJTQcw4UM
To: "Peter Todd" <pete@petertodd.org>, "Mike Hearn" <mike@plan99.net>
References: <20140225044116.GA28050@savin>
<f35865264f37315d580a30dc49789a5a.squirrel@fulvetta.riseup.net>
<CANEZrP1wB9zpnD+DOnmCNycEGB+nZMt8gQrjpn5V92MMkausaA@mail.gmail.com>
<20140225144922.GA25549@savin>
<CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
Date: Tue, 25 Feb 2014 10:09:23 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xbundx2eyldrnw@laptop-air>
In-Reply-To: <CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
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 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 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: 1WIMRb-0005Bj-3f
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: Tue, 25 Feb 2014 18:09:28 -0000
------------2hveFpErhO0lXNJTQcw4UM
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
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.
The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of
course only transactions which hit the blockchain actually PAY the fee, so
this allows lower-cost spam in the true dollar sense.
I guess it comes down to how 'sharp' the edge is between staying above
MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a
completely deterministic boundary, so an attacker can generate an infinite
number of transactions which are guaranteed never to see the inside of a
block, and so therefore completely free for the attacker, and all of which
the network will relay (by default).
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.
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).
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?
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.
- 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
Thanks,
Jeremy
------------2hveFpErhO0lXNJTQcw4UM
Content-Type: multipart/related; boundary=----------2hveFpErhO0lXNCkP9CqSp
------------2hveFpErhO0lXNCkP9CqSp
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1393351763943.9c14006d426b4ce7@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body><div>
<div>If I understand correctly, the risk here is this would open a histo=
rically 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. </d=
iv><div><br></div><div>The relay network does anti-spam with MIN_RELAY a=
nd MIN_DUST, but of course only transactions which hit the blockchain ac=
tually PAY the fee, so this allows lower-cost spam in the true dollar se=
nse.</div><div><br></div><div>I guess it comes down to how 'sharp' the e=
dge is between staying above MIN_RELAY and staying OUT of the blockchain=
. In the worst case, there's a completely deterministic boundary, so an =
attacker can generate an infinite number of transactions which are guara=
nteed never to see the inside of a block, and so therefore completely fr=
ee for the attacker, and all of which the network will relay (by default=
).</div></div><div>On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn <mi=
ke@plan99.net> wrote:<br></div><blockquote style=3D"margin: 0 0 0.80e=
x; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir=3D"ltr">N=
odes 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.
</div></blockquote><div><br></div><div>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 'reasonab=
le' means different things to different nodes).</div><div><br></div><div=
>We have an input gate on transactions entering mempool, we persist memp=
ool, and I don't know the specifics but, I assume there's some expiratio=
n 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?</div><div><br></div><div>How closely should mempool selection ali=
gn with the expected block inclusion? I think if they align perfectly in=
theory that means optimal mempool resource allocation. For example, a m=
iner would push out cheaper transactions which they were previously hash=
ing 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.</div><div><br></div><div> - After hitting X number of transacti=
ons, the fee has to be larger than a transaction in mempool in order to =
get in,</div><div> - That in turn that ejects a random transaction=
which paid less fees than the incoming Tx from mempool</div><div> =
- We would have to consider how ejection would work with chains of unco=
nfirmed transactions (cumulative average fee/kb?) but again in this case=
, you would want to 'do what miners would do' if you could</div><div><br=
></div><div>Thanks,</div><div>Jeremy</div></body></html>
------------2hveFpErhO0lXNCkP9CqSp--
------------2hveFpErhO0lXNJTQcw4UM--
|
