MIME-Version: 1.0
In-Reply-To: <CAAUFj12JC1e7wY1M-_U_Kh5wQv8V4X0SeGGtONn7m8PcOEhp_Q@mail.gmail.com>
References: <6D3AACE5-D6CD-4785-8A55-F6DF0B94D927@ricmoo.com>
	<CAPWm=eWH9rZpwJeK2tTdHH8+BWDU_Vam8oBtG0u49v2yZuYVfw@mail.gmail.com>
	<CAE-z3OWMpCW51FjwT8409k_10Uj9Zq=H8AVUo5B6PfYBTQ_Axg@mail.gmail.com>
	<201507102110.33706.luke@dashjr.org>
	<CAAmoQf1B1nFfS6ZXOkvoJGTaPpbN_NDwOcwCw30MSbRwooSh4Q@mail.gmail.com>
	<CAAUFj12JC1e7wY1M-_U_Kh5wQv8V4X0SeGGtONn7m8PcOEhp_Q@mail.gmail.com>
Date: Sun, 12 Jul 2015 00:19:14 +0100
Message-ID: <CAE-z3OVLF5whUL_HoP3i5B5mxB_KztBLJSB1dJ=dQ9+UDg55hg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11c124368883f0051aa1b7b5
Subject: Re: [bitcoin-dev] Why not Child-Pays-For-Parent?
Precedence: list

--001a11c124368883f0051aa1b7b5
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 11, 2015 at 10:30 PM, Dan Bryant <dkbryant@gmail.com> wrote:

> I think a compromise will be somewhere in the middle.  I think most people
> would be OK with TXs that don't have enough fees for P2P transfer to stay
> in deadmans land.  Most people are stuck in a situation where they payed
> enough to get it into (and keep it in) the pool, but not enough to get it
> out.
>

Agreed.  A lot of the functionality could be achieved by a system that
works in most cases.  Even if 100 transaction chains aren't supported, 3-5
transaction chains would give a significant fraction of the desired
functionality.

At the moment, a transaction is only added into the memory pool if it meets
the relay threshold and spends transactions that are either in the memory
pool or in a block.

There is an orphan pool that can store up to 100 orphans.

The same could be done for child pays for parent.  A node could remember
the last 100 transactions (up to 5000 bytes) that were rejected from the
memory pool due to insufficient relay fees.

This allows nodes to send a chain of transactions in a row.  If the child
is sent last, then the parent(s) will be in the unrelayed transaction pool.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Jul 11, 2015 at 10:30 PM, Dan Bryant <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:dkbryant@gmail.com" target=3D"_blank">dkbryant@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I think a=
 compromise will be somewhere in the middle.=C2=A0 I think most
 people would be OK with TXs that don&#39;t have enough fees for P2P=20
transfer to stay in deadmans land.=C2=A0 Most people are stuck in a situati=
on
 where they payed enough to get it into (and keep it in) the pool, but=20
not enough to get it out.<br></div></div></blockquote><div><br></div><div>A=
greed.=C2=A0 A lot of the functionality could be achieved by a system that =
works in most cases.=C2=A0 Even if 100 transaction chains aren&#39;t suppor=
ted, 3-5 transaction chains would give a significant fraction of the desire=
d functionality.<br></div><div><br></div><div></div><div>At the moment, a t=
ransaction is only added into the memory pool if it meets the relay thresho=
ld and spends transactions that are either in the memory pool or in a block=
.<br><br></div><div>There is an orphan pool that can store up to 100 orphan=
s.<br><br></div><div>The same could be done for child pays for parent.=C2=
=A0 A node could remember the last 100 transactions (up to 5000 bytes) that=
 were rejected from the memory pool due to insufficient relay fees.<br><br>=
</div><div>This allows nodes to send a chain of transactions in a row.=C2=
=A0 If the child is sent last, then the parent(s) will be in the unrelayed =
transaction pool.<br></div></div></div></div>

--001a11c124368883f0051aa1b7b5--