<!DOCTYPE html><html><head>
<style type="text/css">body { font-family:'Times New Roman'; font-size:13px}</style>
</head>
<body><div>
<div>If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time. </div><div><br></div><div>The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of course only transactions which hit the blockchain actually PAY the fee, so this allows lower-cost spam in the true dollar sense.</div><div><br></div><div>I guess it comes down to how 'sharp' the edge is between staying above MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a completely deterministic boundary, so an attacker can generate an infinite number of transactions which are guaranteed never to see the inside of a block, and so therefore completely free for the attacker, and all of which the network will relay (by default).</div></div><div>On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn <mike@plan99.net> wrote:<br></div><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF 2px solid; padding-left: 1ex"><div dir="ltr">Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible.
</div></blockquote><div><br></div><div>Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes).</div><div><br></div><div>We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today?</div><div><br></div><div>How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g.</div><div><br></div><div> - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in,</div><div> - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool</div><div> - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you could</div><div><br></div><div>Thanks,</div><div>Jeremy</div></body></html>