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
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z54RP-0003CC-8A
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Jun 2015 03:55:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.115 as permitted sender)
client-ip=62.13.149.115; envelope-from=pete@petertodd.org;
helo=outmail149115.authsmtp.co.uk;
Received: from outmail149115.authsmtp.co.uk ([62.13.149.115])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z54RN-0007q7-B3 for bitcoin-development@lists.sourceforge.net;
Wed, 17 Jun 2015 03:55:07 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5H3swqd094351;
Wed, 17 Jun 2015 04:54:58 +0100 (BST)
Received: from muck ([212.183.128.195]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5H3sqfe037335
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 17 Jun 2015 04:54:56 +0100 (BST)
Date: Wed, 17 Jun 2015 04:54:45 +0100
From: Peter Todd <pete@petertodd.org>
To: Aaron Voisine <voisine@gmail.com>
Message-ID: <20150617035445.GA23826@muck>
References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com>
<CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com>
<CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q@mail.gmail.com>
<CANEZrP148U0V7bU-u0tOTk2xWwq5wy-yU-jk805DcU_3cBHtnw@mail.gmail.com>
<CABaSBawXZDcyR96g4hBNAiFRDpTcUJX+bMXyqGeuY5wVm4k1KQ@mail.gmail.com>
<CALx=ga7axVzUvpUd5Fvr=UruzUZWhXqJ7ibCEzjrRC-58gSWjw@mail.gmail.com>
<9834E283-727C-47F7-A3D0-667951727E5F@gmail.com>
<CACq0ZD5TTJ=dvz+o-ex6vUWAnOtMfD=VE7JaZWXYM1Lo2L_9wA@mail.gmail.com>
<CAPWm=eWTnVCoRCGSycUGsYjx8M3NFdqEXAU1ykm08_FdJQCP5Q@mail.gmail.com>
<CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz"
Content-Disposition: inline
In-Reply-To: <CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com>
X-Server-Quench: 9ead8373-14a4-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdwUUEkAaAgsB AmMbW1BeVVl7XGQ7 aQtTcwRVYVRPXQ10
UUFMXVdaExppT1gE fh1dE08ndwZBe311 K0VjXnJTEk0vJBJ1
QUlXCGwCNGN9aWFK VV1RIQRQbQNKfBpM agF+V3ZZYitlM3Bw
LCUyIzs2PDMaJClL TwUKNVcfR1o+Vich SgseHDIpBgUMTSIu
M1QsK0IXG0cXd3UO eVAmVV9QPRgICUUQ fQlLBykcLF4HXCct
Fh5BFU4XCjEYTyBG AXUA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 212.183.128.195/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: 1Z54RN-0007q7-B3
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
non-consensus hard-fork
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: Wed, 17 Jun 2015 03:55:07 -0000
--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:
> Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
> should at least prevent nodes from crashing. When I looked a few days ago=
I
> only found a few old PRs that seemed to have fallen by the wayside, so th=
is
> new one is encouraging.
BTW it's worth working out how many $ in fees you need for a given
amount of MB worth of mempool.
At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5
worth of fees - kinda ridiculous when a block earns a miner $6250 in
revenue. Pretty much all txs pay significantly higher rates - more like
100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed
by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to
fill to pay the fees, and in practice will probably quickly get higher.
https://github.com/bitcoin/bitcoin/pull/6281
> I can respond in the PR comments if it's more appropriate there, but I
> believe ejecting tx from mempools rather than preemptively refusing them
> according to standard network wide propagation rules will result in spott=
y,
> inconsistent tx propagation, and possibly a large increase in tx
> re-broadcasts, so if those haven't been addressed they will need to be. It
> would also be prudent to run some simulations to see what other issues are
> going to pop-up.
See above - filling the mempool like that will be both a slow process,
and require lots of funds. Equally, once full, the sensible thing to do
is raise the minimum relay fee appropriately, so those transactions that
pay too low a fee will simply be rejected.
It'd be reasonable to tell peers that, and what the minimum fee needed
for acceptance would be for that particular node.
> We're currently using CPFP already in breadwallet when spending unconfirm=
ed
> non-change inputs. A small percentage of hashing power is using it, but
> enough to get a transaction unstuck assuming breadwallet's fee calculation
> is better than the sender's.
> The problem with RBF is that there's currently no way to tell if your tx
> has been picked up by miners or not in order to know if you need to repla=
ce
> it. Miners broadcasting partial block solutions would be helpful in this
> regard, but only for tx in the currently-being-worked-on block, not for tx
> that won't be picked up until the block after. If miners were to eject tx
> that were previously being worked on in favor of higher fee tx, then that
> causes another set of problems for wallets that thought their tx was going
> to get in but then it doesn't. The other problem with RBF is that users
> don't know up front what fee they're actually going to pay which is a big
> blow to real world usability. Also mobile wallets will have to sign lots =
of
> tx up front and rely on a service to replace as necessary. And this is all
> just on the send side.
For an interactive, mobile wallet, the best thing to do is estimate the
fee correctly the first time, using RBF as a follow up mechanism only if
needed. For other users - e.g. exchanges handling customer withdrawals -
using RBF more agressively to get the minimum possible fee may make
sense.
> On the receive side it's much worse since you can't
> rely on the sender to do the replacing. The real problem seems to be the
> fact that RBF is an interactive iterative process rather than a
> send-and-forget one.
In any case, the *existance* of RBF makes no difference to any of these
problems; RBF does make solving the easier. You can always choose to not
use it after all, resulting in the same "send-and-forget" process.
Having it available allows mistakes to be fixed after the fact, always
an improved user experience over not being able to re-bid for block
space.
Incidentally, if my FSS-RBF bug bounty isn't collected in the next week
or two, we'll likely have a major double-digits % of hashing power
mining FSS-RBF soon after.
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08=
122.html
> What you really need is some way to tell up-front, is a transaction going
> to get mined with a high probability? That problem seems really difficult
> to solve with fixed-size blocks that are full.
Have you looked at the fee estimation code in Bitcoin Core? I have no
reason to think it doesn't basically speaking work. Of course, SPV
wallets will need a semi-trusted third party to securely get that data,
but this seems to be a fundemental problem in a decentralized network -
the purpose of the blockchain itself is to prove that some data was
published to some audience, an analogous problem to proving to the SPV
wallet that their transaction actually reached miners and they actually
are considering it for inclusion.
Guaranteed reliable transaction processing is only possible in
centralized environments that can make service guarantees.
> If the goal is simply to
> reduce or limit the growth of the blockchain, then there are much simpler
> solutions, which is why I've advocated for the blocksize increase, follow=
ed
> by tx selection and propagation rule changes to create fee pressure.
Few if any of those mechanisms can be deployed in a consensus-critical
way that is resistant to attack; the blocksize limit is needed to -
among other things - resist attacks by one miner on another to reduce
the competitors profitability. Without an explicit limit tx selection
and propagation rule changes can be gamed.
--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVgO+CXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udz9RQf+MLazxyrr313kvIn1jN+VIRDW
3i63zg6j3oyF5D1OSoRrwxwsYJKRxIXSP4p8WaNyr3MMf0U9oFeovHqwWthXO1Ow
Gv/7NlBkTHslxgbWpZ8WoXdCR3ywgp9/pFJqbnnJ2iO+aawyOB2iBpXKk2qWNScM
SQFEUl4gPeuwqYZprGSwOOo2gCh5lJVWSmbzx1YdShW7fVj1XZAiEqmV5YvZkuIf
TSBsgqdNlhYgfIwOz7yKjBH6zHGKi7CVQ/hOpJMTUuPiOcayCrBaXT7xbSoXns4d
i8kpG1b0TMB3P2YjkyqOeC8OW77gURXmGMCkvo81dOssvBvADiqoK+FkFo2UWA==
=MN0D
-----END PGP SIGNATURE-----
--3V7upXqbjpZ4EhLz--
|
