path: root/36/42e654eb768211d0ab8915a0f31f00d375d478

Return-Path: <danny.thorpe@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B23FC3EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 19:52:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com
	[209.85.214.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C576114C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 19:52:35 +0000 (UTC)
Received: by obbhe7 with SMTP id he7so67586615obb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 21 Aug 2015 12:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=M9+m/IwAaxtatifybnc0DJm6U0dGbQBrOkmB4/GfBNo=;
	b=DelElXySPw+QHwVYn6dGg86+HapPo+0hDqm8NzTwHSRNu6E5mOqBeEhCxQC35P3bgY
	3LSgP7MLIeZn/EseD/yY1jF4Wv9cgc2fPs1413qH0e2qo71PMPeLIX0CcEJafhCOkpjF
	lFPcJS5M8mz2GGi9iaZnx216hOLpe2sgNxCAsZgKhWwVjPsza4ob8+xYLkAKkobKu8pZ
	nl5Qjs/oYoyJh9uo1bAuwcO0gQaF6S/ZXCZGV8G+mOWr3ShIp4Un53EuGcPzjZc1MvB6
	OB/fx/Kp2sai/a4Dq9RBKd8wTEYZKgYUr4Oj4cpD0Rzv/z0lwzxIIhJYMxgH2u55Xbt1
	6SrQ==
MIME-Version: 1.0
X-Received: by 10.182.250.137 with SMTP id zc9mr9266050obc.79.1440186755189;
	Fri, 21 Aug 2015 12:52:35 -0700 (PDT)
Received: by 10.202.134.78 with HTTP; Fri, 21 Aug 2015 12:52:35 -0700 (PDT)
In-Reply-To: <55D77A7F.40402@mattcorallo.com>
References: <CAPWm=eWuvC8zYM_ipAnaQttKQQG2Vas6np_bAFkxG31eR5w=xQ@mail.gmail.com>
	<55D77A7F.40402@mattcorallo.com>
Date: Fri, 21 Aug 2015 12:52:35 -0700
Message-ID: <CAJN5wHVzzo-dD6FFyaydEDm27HK2OkWxC0o0Pxcy-N9wTfv8Gw@mail.gmail.com>
From: Danny Thorpe <danny.thorpe@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=089e01537b22f41424051dd79b72
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2015 19:52:36 -0000

--089e01537b22f41424051dd79b72
Content-Type: text/plain; charset=UTF-8

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
>

--089e01537b22f41424051dd79b72
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The limits Alex proposed are generous (bordering on obscen=
e!), but dropping that down to allowing only two levels of chained unconfir=
med transactions is too tight. =C2=A0<div><br></div><div>Use case: Brokered=
 asset transfers may require sets of transactions with a dependency tree de=
pth of 3 to be published together. ( N seller txs, 1 broker bridge tx, M bu=
yer txs )</div><div><br></div><div>If the originally proposed depth limit o=
f 100 does not provide a sufficient cap on memory consumption or loop/recur=
sion depth, a depth limit of 10 would provide plenty of headroom for this 3=
 level use case and similar patterns.</div><div><br></div><div>-Danny</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Aug=
 21, 2015 at 12:22 PM, Matt Corallo via bitcoin-dev <span dir=3D"ltr">&lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">I dont see any problem with such limits. Though, hell, if=
 you limited<br>
entire tx dependency trees (ie transactions and all required unconfirmed<br=
>
transactions for them) to something like 10 txn, maximum two levels<br>
deep, I also wouldnt have a problem.<br>
<br>
Matt<br>
<br>
On 08/14/15 19:33, Alex Morcos via bitcoin-dev wrote:<br>
&gt; Hi everyone,<br>
&gt;<br>
&gt;<br>
&gt; I&#39;d like to propose a new set of requirements as a policy on when =
to<br>
&gt; accept new transactions into the mempool and relay them.=C2=A0 This po=
licy<br>
&gt; would affect transactions which have as inputs other transactions whic=
h<br>
&gt; are not yet confirmed in the blockchain.<br>
&gt;<br>
&gt; The motivation for this policy is 6470<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6470</a=
>&gt; which aims to limit the<br>
&gt; size of a mempool.=C2=A0 As discussed in that pull<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6470#issuecomme=
nt-125324736" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitco=
in/bitcoin/pull/6470#issuecomment-125324736</a>&gt;,<br>
&gt; once the mempool is full a new transaction must be able to pay not onl=
y<br>
&gt; for the transaction it would evict, but any dependent transactions tha=
t<br>
&gt; would be removed from the mempool as well.=C2=A0 In order to make sure=
 this<br>
&gt; is always feasible, I&#39;m proposing 4 new policy limits.<br>
&gt;<br>
&gt; All limits are command line configurable.<br>
&gt;<br>
&gt; The first two limits are required to make sure no chain of transaction=
s<br>
&gt; will be too large for the eviction code to handle:<br>
&gt;<br>
&gt; Max number of descendant txs : No transaction shall be accepted if it<=
br>
&gt; would cause another transaction in the mempool to have too many<br>
&gt; descendant transactions (all of which would have to be evicted if the<=
br>
&gt; ancestor transaction was evicted).=C2=A0 Default: 1000<br>
&gt;<br>
&gt; Max descendant size : No transaction shall be accepted if it would cau=
se<br>
&gt; another transaction in the mempool to have the total size of all its<b=
r>
&gt; descendant transactions be too great.=C2=A0 Default : maxmempool / 200=
=C2=A0 =3D=C2=A0 2.5MB<br>
&gt;<br>
&gt; The third limit is required to make sure calculating the state require=
d<br>
&gt; for sorting and limiting the mempool and enforcing the first 2 limits =
is<br>
&gt; computationally feasible:<br>
&gt;<br>
&gt; Max number of ancestor txs:=C2=A0 No transaction shall be accepted if =
it has<br>
&gt; too many ancestor transactions which are not yet confirmed (ie, in the=
<br>
&gt; mempool). Default: 100<br>
&gt;<br>
&gt; The fourth limit is required to maintain the pre existing policy goal<=
br>
&gt; that all transactions in the mempool should be mineable in the next bl=
ock.<br>
&gt;<br>
&gt; Max ancestor size: No transaction shall be accepted if the total size =
of<br>
&gt; all its unconfirmed ancestor transactions is too large.=C2=A0 Default:=
 1MB<br>
&gt;<br>
&gt; (All limits include the transaction itself.)<br>
&gt;<br>
&gt; For reference, these limits would have affected less than 2% of<br>
&gt; transactions entering the mempool in April or May of this year.=C2=A0 =
During<br>
&gt; the period of 7/6 through 7/14, while the network was under stress tes=
t,<br>
&gt; as many as 25% of the transactions would have been affected.<br>
&gt;<br>
&gt; The code to implement the descendant package tracking and new policy<b=
r>
&gt; limits can be found in 6557<br>
&gt; &lt;<a href=3D"https://github.com/bitcoin/bitcoin/pull/6557" rel=3D"no=
referrer" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6557</a=
>&gt; which is built off of 6470.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Alex<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--089e01537b22f41424051dd79b72--