From: Peter Todd <pete@petertodd•org>
To: Aaron Voisine <voisine@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
Date: Wed, 17 Jun 2015 04:54:45 +0100 [thread overview]
Message-ID: <20150617035445.GA23826@muck> (raw)
In-Reply-To: <CACq0ZD6M5Rv_iaB8=7_XgG-QX21CvxCf_Wm5ciRALgRYPt=eYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5630 bytes --]
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 this
> 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 spotty,
> 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 unconfirmed
> 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 replace
> 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/msg08122.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, followed
> 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.
--
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-06-17 3:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 0:04 Adam Back
2015-06-15 9:56 ` Mike Hearn
2015-06-15 18:03 ` Adam Back
2015-06-15 20:55 ` Mike Hearn
2015-06-15 21:56 ` Bryan Bishop
2015-06-15 22:17 ` Faiz Khan
2015-06-15 22:56 ` Brian Hoffman
2015-06-15 23:05 ` [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Raystonn .
2015-06-16 0:08 ` [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork Aaron Voisine
2015-06-16 0:41 ` Mark Friedenbach
2015-06-16 1:17 ` Alex Morcos
2015-06-16 4:00 ` Aaron Voisine
2015-06-17 3:54 ` Peter Todd [this message]
2015-06-18 15:23 ` Jorge Timón
2015-06-16 11:29 ` Mike Hearn
2015-06-16 11:20 ` Mike Hearn
2015-06-16 12:33 ` Pindar Wong
2015-06-16 13:33 ` Peter Todd
2015-06-16 13:55 ` Pindar Wong
2015-06-17 3:59 ` Peter Todd
2015-06-25 6:43 ` [bitcoin-dev] " Pindar Wong
2015-06-26 19:30 ` Peter Todd
2015-06-15 22:54 ` odinn
2015-06-16 1:20 ` Eric Lombrozo
2015-06-16 5:18 ` Venzen
2015-06-16 6:09 ` Marcel Jamin
2015-06-16 9:21 ` Benjamin
2015-06-16 11:01 ` Tier Nolan
2015-06-17 3:52 ` Troy Benjegerdes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150617035445.GA23826@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=voisine@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox