public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jeremy Spilman" <jeremy@taplink.co>
To: "Peter Todd" <pete@petertodd.org>, "Mike Hearn" <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fee drop
Date: Tue, 25 Feb 2014 10:09:23 -0800	[thread overview]
Message-ID: <op.xbundx2eyldrnw@laptop-air> (raw)
In-Reply-To: <CANEZrP0pDjHr3v2w_zKnME+6GjVdvV5HYjrLH7xthbNdBniK4g@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

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.

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.

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).

On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn <mike@plan99.net> wrote:
> 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.

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).

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?

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.

   - After hitting X number of transactions, the fee has to be larger than  
a transaction in mempool in order to get in,
   - That in turn that ejects a random transaction which paid less fees  
than the incoming Tx from mempool
   - 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

Thanks,
Jeremy

[-- Attachment #2.1: Type: text/html, Size: 3046 bytes --]

  parent reply	other threads:[~2014-02-25 18:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25  4:41 [Bitcoin-development] Fee drop Peter Todd
2014-02-25  7:34 ` naman naman
2014-02-25 12:40 ` Odinn Cyberguerrilla
2014-02-25 12:55   ` Mike Hearn
2014-02-25 14:49     ` Peter Todd
2014-02-25 16:55       ` Mike Hearn
2014-02-25 17:13         ` Peter Todd
2014-02-25 18:09         ` Jeremy Spilman [this message]
2014-02-28 11:18           ` Peter Todd
2014-02-25 22:43         ` Odinn Cyberguerrilla
2014-02-26 22:51 ` Jeff Garzik
2014-02-28  4:50 ` Troy Benjegerdes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.xbundx2eyldrnw@laptop-air \
    --to=jeremy@taplink.co \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox