Yes, total number of dependent transactions regardless of chain depth. A descendant package means all the transactions that can not be included in a block before the transaction in question. An ancestor package means all the transactions that are required to be included in a block before the transaction in question can be. On Mon, Oct 5, 2015 at 2:51 PM, Danny Thorpe wrote: > What does "package" mean here? > > When you say 25 txs, does that mean maximum linked chain depth, or total > number of dependent transactions regardless of chain depth? > > Thanks, > -Danny > > > > On Mon, Oct 5, 2015 at 11:45 AM, Alex Morcos via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I'd like to propose updates to the new policy limits on unconfirmed >> transaction chains. >> >> The existing limits in master and scheduled for release in 0.12 are: >> Ancestor packages = 100 txs and 900kb total size >> Descendant packages = 1000 txs and 2500kb total size >> >> Before 0.12 is released I would like to propose a significant reduction >> in these limits. In the course of analyzing algorithms for mempool >> limiting, it became clear that large packages of unconfirmed transactions >> were the primary vector for mempool clogging or relay fee boosting attacks. >> Feedback from the initial proposed limits was that they were too generous >> anyway. >> >> The proposed new limits are: >> Ancestor packages = 25 txs and 100kb total size >> Descendant packages = 25 txs and 100kb total size >> >> Based on historical transaction data, the most restrictive of these >> limits is the 25 transaction count on descendant packages. Over the period >> of April and May of this year (before stress tests), 5.8% of transactions >> would have violated this limit alone. Applying all the limits together >> would have affected 6.1% of transactions. >> >> Please keep in mind these are policy limits that affect transactions >> which depend on other unconfirmed transactions only. They are not a change >> to consensus rules and do not affect how many chained txs a valid block may >> contain. Furthermore, any transaction that was unable to be relayed due to >> these limits need only wait for some of its unconfirmed ancestors to be >> included in a block and then it could be successfully broadcast. This is >> unlikely to affect the total time from creation to inclusion in a block. >> Finally, these limits are command line arguments that can easily be changed >> on an individual node basis in Bitcoin Core. >> >> Please give your feedback if you know of legitimate use cases that would >> be hindered by these limits. >> >> Thanks, >> Alex >> >> On Mon, Sep 21, 2015 at 11:02 AM, Alex Morcos wrote: >> >>> Thanks for everyone's review. These policy changes have been merged in >>> to master in 6654 , which >>> just implements these limits and no mempool limiting yet. The default >>> ancestor package size limit is 900kb not 1MB. >>> >>> Yes I think these limits are generous, but they were designed to be as >>> generous as was computationally feasible so they were unobjectionable >>> (since the existing policy was no limits). This does not preclude future >>> changes to policy that would reduce these limits. >>> >>> >>> >>> >>> >>> On Fri, Aug 21, 2015 at 3:52 PM, Danny Thorpe >>> wrote: >>> >>>> 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 >>>>> > which aims to limit >>>>> the >>>>> > size of a mempool. As discussed in that pull >>>>> > >>>> >, >>>>> > 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 >>>>> > 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 >> >> >