From: Alex Morcos <morcos@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions
Date: Fri, 14 Aug 2015 15:33:31 -0400 [thread overview]
Message-ID: <CAPWm=eWuvC8zYM_ipAnaQttKQQG2Vas6np_bAFkxG31eR5w=xQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]
Hi everyone,
I'd like to propose a new set of requirements as a policy on when to accept
new transactions into the mempool and relay them. This policy would affect
transactions which have as inputs other transactions which are not yet
confirmed in the blockchain.
The motivation for this policy is 6470
<https://github.com/bitcoin/bitcoin/pull/6470> which aims to limit the size
of a mempool. As discussed in that pull
<https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736>, once
the mempool is full a new transaction must be able to pay not only for the
transaction it would evict, but any dependent transactions that would be
removed from the mempool as well. In order to make sure this is always
feasible, I'm proposing 4 new policy limits.
All limits are command line configurable.
The first two limits are required to make sure no chain of transactions
will be too large for the eviction code to handle:
Max number of descendant txs : No transaction shall be accepted if it would
cause another transaction in the mempool to have too many descendant
transactions (all of which would have to be evicted if the ancestor
transaction was evicted). Default: 1000
Max descendant size : No transaction shall be accepted if it would cause
another transaction in the mempool to have the total size of all its
descendant transactions be too great. Default : maxmempool / 200 = 2.5MB
The third limit is required to make sure calculating the state required for
sorting and limiting the mempool and enforcing the first 2 limits is
computationally feasible:
Max number of ancestor txs: No transaction shall be accepted if it has too
many ancestor transactions which are not yet confirmed (ie, in the
mempool). Default: 100
The fourth limit is required to maintain the pre existing policy goal that
all transactions in the mempool should be mineable in the next block.
Max ancestor size: No transaction shall be accepted if the total size of
all its unconfirmed ancestor transactions is too large. Default: 1MB
(All limits include the transaction itself.)
For reference, these limits would have affected less than 2% of
transactions entering the mempool in April or May of this year. During the
period of 7/6 through 7/14, while the network was under stress test, as
many as 25% of the transactions would have been affected.
The code to implement the descendant package tracking and new policy limits
can be found in 6557 <https://github.com/bitcoin/bitcoin/pull/6557> which
is built off of 6470.
Thanks,
Alex
[-- Attachment #2: Type: text/html, Size: 2767 bytes --]
next reply other threads:[~2015-08-14 19:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 19:33 Alex Morcos [this message]
2015-08-21 19:22 ` Matt Corallo
2015-08-21 19:52 ` Danny Thorpe
2015-09-21 15:02 ` Alex Morcos
2015-10-05 18:45 ` Alex Morcos
2015-10-05 18:51 ` Danny Thorpe
2015-10-05 20:02 ` Alex Morcos
2015-10-08 3:33 ` Matt Corallo
2015-10-08 6:10 Taariq Lewis
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='CAPWm=eWuvC8zYM_ipAnaQttKQQG2Vas6np_bAFkxG31eR5w=xQ@mail.gmail.com' \
--to=morcos@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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