<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 11, 2015 at 10:30 PM, Dan Bryant <span dir="ltr"><<a href="mailto:dkbryant@gmail.com" target="_blank">dkbryant@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div></div><div>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.<br><br></div><div>There is an orphan pool that can store up to 100 orphans.<br><br></div><div>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.<br><br></div><div>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.<br></div></div></div></div>