Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Taariq Lewis]

[-- Attachment #1: Type: text/plain, Size: 3403 bytes --]

Our comment was posted to Github:
https://github.com/bitcoin/bitcoin/pull/6771#issuecomment-146429708

We, at Serica and DigitalTangible actively use unspent tx chains to allow
our customers to speed their bitcoin user-experience without the need for
them to wait on blockchain confirmations. These transactions are usually
sequential and must happen between our customers and our marketplace of
merchants and other customers. For example, a user agrees to place an order
to purchase bitcoin and then make a bitcoin payment, for a product or
services, with that bitcoin, should their desired price be met while they
are unable to actively monitor their transaction.

We currently do not have a need to chain more than 5 unspents given our
current use cases for onboarding new customers into the bitcoin ecosystem.
Given this PR, we agree with its principle, since the proposal aims to
limit to MAX_ANCESTORS = 25 and MAX_DESCENDANTS = 25, which we think is
reasonable. We have not **yet** seen a use case for more than 25 chains of
unconfirmed in our ecosystem.

However, we would like to publish our viewpoint that we wish to avoid a
slippery slope of restrictions in unspents to fall from from 25 to 2 or
even 0. The limits imposed should not prevent, at minimum, 5 step chains of
transactions that are needed to give a customer temporary control over
funds that they would otherwise not have access to unless they waited for a
confirmation before conducting another transaction. In these situations,
where an instant purchase must be made with customer control, that btc must
be sent to a customers address and then be quickly relayed to a merchant or
another party in a transaction to create a seamless experience. All of this
must happen within 0 confs because our customers will not wait for a whole
confirm and we do not wish to lose the opportunity to make Bitcoin more
available and useful to a broader audience with higher performance demands.

Zero confirmations, when done properly, help increase adoption of Bitcoin
and make it more competitive against other forms of payments. However, we
do think it's good to prevent abuse of the system with reasonable
constraints for the current ecosystem of applications and wallets.

Cheers,
Taariq Lewis & Serica/DigitalTangible team.



>
> ------------------------------
>
> Message: 2
> Date: Mon, 21 Sep 2015 11:02:20 -0400
> From: Alex Morcos <morcos@gmail.com>
> To: Danny Thorpe <danny.thorpe@gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposed new policy for transactions that
>         depend on other unconfirmed transactions
> Message-ID:
>         <CAPWm=
> eW-g9F5YZ9EdqXGzpzvs2mQJ8N5wKG15Ofz4cWGaHQ0BQ@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for everyone's review.  These policy changes have been merged in to
> master in 6654 <https://github.com/bitcoin/bitcoin/pull/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.
>
>
>


-- 
*Taariq Lewis*
p: +1-646-479-6098
e: taariq.lewis@gmail.com

[-- Attachment #2: Type: text/html, Size: 4532 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Matt Corallo]

[-- Attachment #1: Type: text/plain, Size: 9094 bytes --]

There is a PR up for this change at https://github.com/bitcoin/bitcoin/pull/6771, which is getting some discussion for those following along.

On October 5, 2015 1:02:40 PM PDT, Alex Morcos via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>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 <danny.thorpe@gmail.com>
>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 <morcos@gmail.com>
>wrote:
>>>
>>>> Thanks for everyone's review.  These policy changes have been
>merged in
>>>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/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
><danny.thorpe@gmail.com>
>>>> 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
>>>>>> > <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
>>>
>>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 12351 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 8316 bytes --]

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 <danny.thorpe@gmail.com> 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 <morcos@gmail.com> wrote:
>>
>>> Thanks for everyone's review.  These policy changes have been merged in
>>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/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 <danny.thorpe@gmail.com>
>>> 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
>>>>> > <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
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 11250 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 7683 bytes --]

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 <morcos@gmail.com> wrote:
>
>> Thanks for everyone's review.  These policy changes have been merged in
>> to master in 6654 <https://github.com/bitcoin/bitcoin/pull/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 <danny.thorpe@gmail.com>
>> 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
>>>> > <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
>
>

[-- Attachment #2: Type: text/html, Size: 10428 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 6959 bytes --]

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 <morcos@gmail.com> wrote:

> Thanks for everyone's review.  These policy changes have been merged in to
> master in 6654 <https://github.com/bitcoin/bitcoin/pull/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 <danny.thorpe@gmail.com>
> 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
>>> > <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
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 9270 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Alex Morcos]

[-- Attachment #1: Type: text/plain, Size: 4895 bytes --]

Thanks for everyone's review.  These policy changes have been merged in to
master in 6654 <https://github.com/bitcoin/bitcoin/pull/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 <danny.thorpe@gmail.com>
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
>> > <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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 6797 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Danny Thorpe]

[-- Attachment #1: Type: text/plain, Size: 4167 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5653 bytes --]

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

[Matt Corallo]

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] Proposed new policy for transactions that depend on other unconfirmed transactions

[Alex Morcos]

[-- 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 --]