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

From: Danny Thorpe <danny.thorpe@gmail•com>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions
Date: Fri, 21 Aug 2015 12:52:35 -0700	[thread overview]
Message-ID: <CAJN5wHVzzo-dD6FFyaydEDm27HK2OkWxC0o0Pxcy-N9wTfv8Gw@mail.gmail.com> (raw)
In-Reply-To: <55D77A7F.40402@mattcorallo.com>

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