The limits Alex proposed are generous (bordering on obscene!), but dropping that down to allowing only two levels of chained unconfirmed transactions is too tight.
Use case: Brokered asset transfers may require sets of transactions with a dependency tree depth of 3 to be published together. ( N seller txs, 1 broker bridge tx, M buyer txs ) If the originally proposed depth limit of 100 does not provide a sufficient cap on memory consumption or loop/recursion depth, a depth limit of 10 would provide plenty of headroom for this 3 level use case and similar patterns. -Danny On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I dont see any problem with such limits. Though, hell, if you limited > entire tx dependency trees (ie transactions and all required unconfirmed > transactions for them) to something like 10 txn, maximum two levels > deep, I also wouldnt have a problem. > > Matt > > On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote: > > 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 > > > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
