📅 Original date posted:2015-08-21
📝 Original message: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/2d59e699/attachment-0001.html>;
Danny Thorpe [ARCHIVE] /
npub1q5…3ps87
2023-06-07 17:35:10
in reply to nevent1q…tzu7
Author Public Key
npub1q5sgcakfxhw3ya93tvnpqeacvf32p6lw70hke53rkjnf9lhw9w8s43ps87Published at
2023-06-07 17:35:10Event JSON
{
"id": "2ddeb2d181994142c26dd7c653fccbac408e1ebcdf5c5c1d4fd87fb9d7de31d3",
"pubkey": "05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f",
"created_at": 1686159310,
"kind": 1,
"tags": [
[
"e",
"9285cf479004b5417e37da3c080f4c3ca3448d5a76c612deebe0a39245fce061",
"",
"root"
],
[
"e",
"900134d4d5ef3bf7a68ad27159aa6be5f83deac444f8c32d3c105670cf2d3362",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2015-08-21\n📝 Original message:The limits Alex proposed are generous (bordering on obscene!), but dropping\nthat down to allowing only two levels of chained unconfirmed transactions\nis too tight.\n\nUse case: Brokered asset transfers may require sets of transactions with a\ndependency tree depth of 3 to be published together. ( N seller txs, 1\nbroker bridge tx, M buyer txs )\n\nIf the originally proposed depth limit of 100 does not provide a sufficient\ncap on memory consumption or loop/recursion depth, a depth limit of 10\nwould provide plenty of headroom for this 3 level use case and similar\npatterns.\n\n-Danny\n\nOn Fri, Aug 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I dont see any problem with such limits. Though, hell, if you limited\n\u003e entire tx dependency trees (ie transactions and all required unconfirmed\n\u003e transactions for them) to something like 10 txn, maximum two levels\n\u003e deep, I also wouldnt have a problem.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:\n\u003e \u003e Hi everyone,\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I'd like to propose a new set of requirements as a policy on when to\n\u003e \u003e accept new transactions into the mempool and relay them. This policy\n\u003e \u003e would affect transactions which have as inputs other transactions which\n\u003e \u003e are not yet confirmed in the blockchain.\n\u003e \u003e\n\u003e \u003e The motivation for this policy is 6470\n\u003e \u003e \u003chttps://github.com/bitcoin/bitcoin/pull/6470\u003e which aims to limit the\n\u003e \u003e size of a mempool. As discussed in that pull\n\u003e \u003e \u003chttps://github.com/bitcoin/bitcoin/pull/6470#issuecomment-125324736\u003e,\n\u003e \u003e once the mempool is full a new transaction must be able to pay not only\n\u003e \u003e for the transaction it would evict, but any dependent transactions that\n\u003e \u003e would be removed from the mempool as well. In order to make sure this\n\u003e \u003e is always feasible, I'm proposing 4 new policy limits.\n\u003e \u003e\n\u003e \u003e All limits are command line configurable.\n\u003e \u003e\n\u003e \u003e The first two limits are required to make sure no chain of transactions\n\u003e \u003e will be too large for the eviction code to handle:\n\u003e \u003e\n\u003e \u003e Max number of descendant txs : No transaction shall be accepted if it\n\u003e \u003e would cause another transaction in the mempool to have too many\n\u003e \u003e descendant transactions (all of which would have to be evicted if the\n\u003e \u003e ancestor transaction was evicted). Default: 1000\n\u003e \u003e\n\u003e \u003e Max descendant size : No transaction shall be accepted if it would cause\n\u003e \u003e another transaction in the mempool to have the total size of all its\n\u003e \u003e descendant transactions be too great. Default : maxmempool / 200 =\n\u003e 2.5MB\n\u003e \u003e\n\u003e \u003e The third limit is required to make sure calculating the state required\n\u003e \u003e for sorting and limiting the mempool and enforcing the first 2 limits is\n\u003e \u003e computationally feasible:\n\u003e \u003e\n\u003e \u003e Max number of ancestor txs: No transaction shall be accepted if it has\n\u003e \u003e too many ancestor transactions which are not yet confirmed (ie, in the\n\u003e \u003e mempool). Default: 100\n\u003e \u003e\n\u003e \u003e The fourth limit is required to maintain the pre existing policy goal\n\u003e \u003e that all transactions in the mempool should be mineable in the next\n\u003e block.\n\u003e \u003e\n\u003e \u003e Max ancestor size: No transaction shall be accepted if the total size of\n\u003e \u003e all its unconfirmed ancestor transactions is too large. Default: 1MB\n\u003e \u003e\n\u003e \u003e (All limits include the transaction itself.)\n\u003e \u003e\n\u003e \u003e For reference, these limits would have affected less than 2% of\n\u003e \u003e transactions entering the mempool in April or May of this year. During\n\u003e \u003e the period of 7/6 through 7/14, while the network was under stress test,\n\u003e \u003e as many as 25% of the transactions would have been affected.\n\u003e \u003e\n\u003e \u003e The code to implement the descendant package tracking and new policy\n\u003e \u003e limits can be found in 6557\n\u003e \u003e \u003chttps://github.com/bitcoin/bitcoin/pull/6557\u003e which is built off of\n\u003e 6470.\n\u003e \u003e\n\u003e \u003e Thanks,\n\u003e \u003e Alex\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150821/2d59e699/attachment-0001.html\u003e",
"sig": "d922d1ba1a1a951c00b0ac00f3289b2cf00560b23072a493f4728ca72c6d3ced669a79aa174ca0081324bbf0b3253aff68dc3f5f30c7f4f8cf13c3a9bf3fca84"
}