Danny Thorpe [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-05 📝 Original message:What does "package" mean ...

📅 Original date posted:2015-10-05
📝 Original message: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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>> >
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/a1640a71/attachment.html>;