<div dir="ltr">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.  <div><br></div><div>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 )</div><div><br></div><div>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.</div><div><br></div><div>-Danny</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I dont see any problem with such limits. Though, hell, if you limited<br>
entire tx dependency trees (ie transactions and all required unconfirmed<br>
transactions for them) to something like 10 txn, maximum two levels<br>
deep, I also wouldnt have a problem.<br>
<br>
Matt<br>
<br>
On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:<br>
&gt; Hi everyone,<br>
&gt;<br>
&gt;<br>
&gt; I&#39;d like to propose a new set of requirements as a policy on when to<br>
&gt; accept new transactions into the mempool and relay them.  This policy<br>
&gt; would affect transactions which have as inputs other transactions which<br>
&gt; are not yet confirmed in the blockchain.<br>
&gt;<br>
&gt; The motivation for this policy is 6470<br>
&gt; &lt;<a href="https://github.com/bitcoin/bitcoin/pull/6470" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/6470</a>&gt; which aims to limit the<br>
&gt; size of a mempool.  As discussed in that pull<br>
&gt; &lt;<a href="https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736</a>&gt;,<br>
&gt; once the mempool is full a new transaction must be able to pay not only<br>
&gt; for the transaction it would evict, but any dependent transactions that<br>
&gt; would be removed from the mempool as well.  In order to make sure this<br>
&gt; is always feasible, I&#39;m proposing 4 new policy limits.<br>
&gt;<br>
&gt; All limits are command line configurable.<br>
&gt;<br>
&gt; The first two limits are required to make sure no chain of transactions<br>
&gt; will be too large for the eviction code to handle:<br>
&gt;<br>
&gt; Max number of descendant txs : No transaction shall be accepted if it<br>
&gt; would cause another transaction in the mempool to have too many<br>
&gt; descendant transactions (all of which would have to be evicted if the<br>
&gt; ancestor transaction was evicted).  Default: 1000<br>
&gt;<br>
&gt; Max descendant size : No transaction shall be accepted if it would cause<br>
&gt; another transaction in the mempool to have the total size of all its<br>
&gt; descendant transactions be too great.  Default : maxmempool / 200  =  2.5MB<br>
&gt;<br>
&gt; The third limit is required to make sure calculating the state required<br>
&gt; for sorting and limiting the mempool and enforcing the first 2 limits is<br>
&gt; computationally feasible:<br>
&gt;<br>
&gt; Max number of ancestor txs:  No transaction shall be accepted if it has<br>
&gt; too many ancestor transactions which are not yet confirmed (ie, in the<br>
&gt; mempool). Default: 100<br>
&gt;<br>
&gt; The fourth limit is required to maintain the pre existing policy goal<br>
&gt; that all transactions in the mempool should be mineable in the next block.<br>
&gt;<br>
&gt; Max ancestor size: No transaction shall be accepted if the total size of<br>
&gt; all its unconfirmed ancestor transactions is too large.  Default: 1MB<br>
&gt;<br>
&gt; (All limits include the transaction itself.)<br>
&gt;<br>
&gt; For reference, these limits would have affected less than 2% of<br>
&gt; transactions entering the mempool in April or May of this year.  During<br>
&gt; the period of 7/6 through 7/14, while the network was under stress test,<br>
&gt; as many as 25% of the transactions would have been affected.<br>
&gt;<br>
&gt; The code to implement the descendant package tracking and new policy<br>
&gt; limits can be found in 6557<br>
&gt; &lt;<a href="https://github.com/bitcoin/bitcoin/pull/6557" rel="noreferrer" target="_blank">https://github.com/bitcoin/bitcoin/pull/6557</a>&gt; which is built off of 6470.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Alex<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>