From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C1AF84 for ; Fri, 21 Aug 2015 19:22:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCFFC63 for ; Fri, 21 Aug 2015 19:22:41 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 6C1BD56652; Fri, 21 Aug 2015 19:22:40 +0000 (UTC) To: Alex Morcos , Bitcoin Dev References: From: Matt Corallo Message-ID: <55D77A7F.40402@mattcorallo.com> Date: Fri, 21 Aug 2015 19:22:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 19:22:42 -0000 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 >