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; 
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>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &
 non-consensus hard-fork
Precedence: list


--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--