[bitcoin-dev] Why not Child-Pays-For-Parent?
Tier Nolan
tier.nolan at gmail.com
Sat Jul 11 23:19:14 UTC 2015
On Sat, Jul 11, 2015 at 10:30 PM, Dan Bryant <dkbryant at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150712/ff0bec33/attachment.html>
More information about the bitcoin-dev
mailing list