[Bitcoin-development] Fee drop

[Bitcoin-development] Fee drop

[Peter Todd]

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

So, just to be clear, we're adding, say, a memory limited mempool or
something prior to release so this fee drop doesn't open up an obvious
low-risk DDoS exploit.... right? As we all know, the network bandwidth
DoS attack mitigation strategy relies on transactions we accept to
mempools getting mined, and the clearance rate of the new low-fee
transactions is going to be pretty small; we've already had problems in
the past with mempool growth in periods of high demand. Equally it
should be obvious to people how you can create large groups of low-fee
transactions, and then cheaply double-spend them with higher fee
transactions to suck up network bandwidth - just like I raised for the
equally foolish double-spend propagation pull-req.

Of course, there's also the problem that we're basically lying to people
about whether or not Bitcoin is a good medium for microtransactions.
It's not. Saying otherwise by releasing software that has known and
obvious DoS attack vulnerabilities that didn't exist in the previous
version is irresponsible on multiple levels.

-- 
'peter'[:-1]@petertodd.org
0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Fee drop

[naman naman]

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

I quite agree with Peter, anything that can be exploited will be exploited,
just like malleability was.


On Tue, Feb 25, 2014 at 10:11 AM, Peter Todd <pete@petertodd.org> wrote:

> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
>
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2849 bytes --]

Re: [Bitcoin-development] Fee drop

[Odinn Cyberguerrilla]

> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.

It's good that the core devs keep doing good work on these topics, thanks.

>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.

I don't hear anyone lying.


> It's not.

Actually, it is, and comparatively speaking, Bitcoin is better than the
most common alternatives in use by people around the world.  There are
obvious issues (dust, how to handle fee issues moving forward, one could
blather on forever about that), but again, I think core devs have done
fairly well and will probably continue to do so along with many others. 
That's just my own 0.00004 BTC though (my way of saying, at time of
posting this, "my own 2 cents").

>Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.

That was not very specific.  Could you be more specific?

>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] Fee drop

[Mike Hearn]

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

Given that the fee drop puts fees in "real" (i.e. dollar) terms back to
where they were some months ago, it seems odd to claim this is creating
vulnerabilities that didn't exist in the previous version. The cost of an
attack would be the same as before.

[-- Attachment #2: Type: text/html, Size: 290 bytes --]

Re: [Bitcoin-development] Fee drop

[Peter Todd]

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

On Tue, Feb 25, 2014 at 06:25:18PM +0530, Mike Hearn wrote:
> Given that the fee drop puts fees in "real" (i.e. dollar) terms back to
> where they were some months ago, it seems odd to claim this is creating
> vulnerabilities that didn't exist in the previous version. The cost of an
> attack would be the same as before.

No it's not. The cost is only incurred in the transactions actually get
mined, and unlike before the drop appears to be well under the
break-even orphan cost of transactions; we've got no reason to think the
clearance rate of these low-fee transactions will be significant.


But anyway, mostly I'm writing this to register my strong opposition
knowing full well that I don't expect it to change your minds.

-- 
'peter'[:-1]@petertodd.org
0000000000000000eb671d932a8d310e8ab963c53b2be8a27bd5de2a712c2f59

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Fee drop

[Mike Hearn]

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

There are two possibilities.

One is that the value of transactions with the new lower fee is outweighed
by increased orphan costs and miners refuse to include them en-masse.
Wallet authors lose the staring match and go back to setting higher fees
until such a time as block propagation is optimised and the orphan costs go
down. 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.

The other is that the total value of transactions even with the lower fee
is not outweighed by orphan costs. The value of a transaction is higher
than its simple monetary value - the fact that Bitcoin is useful, growing
and considered cheap also has a value which is impossible to calculate, but
we know it's there (because Bitcoin does not exist in a vacuum and has
competitors). In this case miners stop including lots of useful
transactions that represent desired economic activity and are put under
pressure by the community to change their policies. If all miners do this
and making small blocks is considered errant behaviour, then we're back to
the same situation we're in today.

The possibility you're worried about - that someone does a DoS attack by
flooding the network with small transactions - is only an issue in the
first situation, and it is by no means the easiest or cheapest way to DoS
Bitcoin. We all want to see more DoS resistance but basically any change to
Bitcoin can be objected to on anti-DoS grounds at the moment, and this will
remain the case until someone steps up to spend significant time on
resource scheduling and code audits.

[-- Attachment #2: Type: text/html, Size: 1839 bytes --]

Re: [Bitcoin-development] Fee drop

[Peter Todd]

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

On Tue, Feb 25, 2014 at 10:25:58PM +0530, Mike Hearn wrote:

Well, I've done my responsible disclosure, and I've got better things to
do than argue with wishful thinking.

> There are two possibilities.
> 
> One is that the value of transactions with the new lower fee is outweighed
> by increased orphan costs and miners refuse to include them en-masse.
> Wallet authors lose the staring match and go back to setting higher fees
> until such a time as block propagation is optimised and the orphan costs go
> down. 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.
> 
> The other is that the total value of transactions even with the lower fee
> is not outweighed by orphan costs. The value of a transaction is higher
> than its simple monetary value - the fact that Bitcoin is useful, growing
> and considered cheap also has a value which is impossible to calculate, but
> we know it's there (because Bitcoin does not exist in a vacuum and has
> competitors). In this case miners stop including lots of useful
> transactions that represent desired economic activity and are put under
> pressure by the community to change their policies. If all miners do this
> and making small blocks is considered errant behaviour, then we're back to
> the same situation we're in today.
> 
> The possibility you're worried about - that someone does a DoS attack by
> flooding the network with small transactions - is only an issue in the
> first situation, and it is by no means the easiest or cheapest way to DoS
> Bitcoin. We all want to see more DoS resistance but basically any change to
> Bitcoin can be objected to on anti-DoS grounds at the moment, and this will
> remain the case until someone steps up to spend significant time on
> resource scheduling and code audits.

-- 
'peter'[:-1]@petertodd.org
0000000000000000445db8e568846d542c86ab395137b32b2a05577afcc7c6a3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Fee drop

[Jeremy Spilman]

[-- 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 --]

Re: [Bitcoin-development] Fee drop

[Peter Todd]

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

On Tue, Feb 25, 2014 at 10:09:23AM -0800, Jeremy Spilman wrote:
> 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.

That's exactly the problem.

Of course every time we make a new transaction type standard we also run
that risk, but at least it's a temporary situation and we can expect to
get hashing power on-board fairly quickly. With such a low MIN_RELAY
that's not true, and in an absolute sense, the funds required to DoS
attack the network are fairly low.

> 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?

There's currently no expiration policy at all; that's the root of the
DoS problem I was referring too.

> 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

Have you seen the mempool superblock design that keeps getting
suggested? jgarzik has the most recent write-up here:
https://github.com/bitcoin/bitcoin/issues/3723

I was working on a relatively ambitious version of it last summer that
calculated the fee/KB for transactions, including depedencies, and then
simply ordered the mempool with highest fee/KB first. The idea was you
could then easily limit the total size of the mempool and drop
transactions with the lowest fee/KB first. Transactions that paid less
than the lowest fee/KB in a max-size mempool simply would not get
relayed at all. Pity had to put it off for higher-priority work.

What's interesting is how this makes zero-conf transactions even less
safe: all you have to do to double-spend one (or more!) that pay X
fee/KB is broadcast enough transactions paying X+e fee/KB to push out
the unconfirmed tx from mepools around the network, then broadcast your
double-spend. Obviously the economics of this are going to make attacks
frequently profitable, especially if you can attack multiple targets at
once. You can of course have schemes where you don't entirely drop
transactions, saving, say, the inputs they spend and a transaction id,
(so a rebroadcast can succeed) but that just reduces the effectiveness
of the attack by a constant factor and makes it possible to get into
complex situations where your funds are locked and unspendable.

-- 
'peter'[:-1]@petertodd.org
00000000000000011ffdfe2bfdf8f1f983bebfa160670b85afeebbd815fdf484

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] Fee drop

[Odinn Cyberguerrilla]

Am suggesting a (possible) mitigation of [possible flooding, etc], via
some kind of discussion (potentially process BIP, related to bundling and
/ or randomization) not now, but down the road.  However, needs more
thought and analysis (you mentioned code audit?) before it could be
floated around or acted on in any way shape or form.  Thanks for this
discussion, things to think about.... am watching, listening (...)

> There are two possibilities.
>
> One is that the value of transactions with the new lower fee is outweighed
> by increased orphan costs and miners refuse to include them en-masse.
> Wallet authors lose the staring match and go back to setting higher fees
> until such a time as block propagation is optimised and the orphan costs
> go
> down. 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.
>
> The other is that the total value of transactions even with the lower fee
> is not outweighed by orphan costs. The value of a transaction is higher
> than its simple monetary value - the fact that Bitcoin is useful, growing
> and considered cheap also has a value which is impossible to calculate,
> but
> we know it's there (because Bitcoin does not exist in a vacuum and has
> competitors). In this case miners stop including lots of useful
> transactions that represent desired economic activity and are put under
> pressure by the community to change their policies. If all miners do this
> and making small blocks is considered errant behaviour, then we're back to
> the same situation we're in today.
>
> The possibility you're worried about - that someone does a DoS attack by
> flooding the network with small transactions - is only an issue in the
> first situation, and it is by no means the easiest or cheapest way to DoS
> Bitcoin. We all want to see more DoS resistance but basically any change
> to
> Bitcoin can be objected to on anti-DoS grounds at the moment, and this
> will
> remain the case until someone steps up to spend significant time on
> resource scheduling and code audits.
>

Re: [Bitcoin-development] Fee drop

[Jeff Garzik]

Just pushed out a mempool janitor change to
https://github.com/bitcoin/bitcoin/pull/3753   The goal was to create
a simple bolt-on change, and /not/ rewrite the mempool code.

I'll be running some metrics on what does and does not get into the
mempools of my public nodes for 48 hours, ending Friday ~midnight EST.

On Mon, Feb 24, 2014 at 11:41 PM, Peter Todd <pete@petertodd.org> wrote:
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
>
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000b28e2818c4d8019fb71e33ec2d223f5e09394a89caccf4e2
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Fee drop

[Troy Benjegerdes]

On Mon, Feb 24, 2014 at 11:41:16PM -0500, Peter Todd wrote:
> So, just to be clear, we're adding, say, a memory limited mempool or
> something prior to release so this fee drop doesn't open up an obvious
> low-risk DDoS exploit.... right? As we all know, the network bandwidth
> DoS attack mitigation strategy relies on transactions we accept to
> mempools getting mined, and the clearance rate of the new low-fee
> transactions is going to be pretty small; we've already had problems in
> the past with mempool growth in periods of high demand. Equally it
> should be obvious to people how you can create large groups of low-fee
> transactions, and then cheaply double-spend them with higher fee
> transactions to suck up network bandwidth - just like I raised for the
> equally foolish double-spend propagation pull-req.
> 
> Of course, there's also the problem that we're basically lying to people
> about whether or not Bitcoin is a good medium for microtransactions.
> It's not. Saying otherwise by releasing software that has known and
> obvious DoS attack vulnerabilities that didn't exist in the previous
> version is irresponsible on multiple levels.

Well, if your investors take money with market manipulating news stories,
this is absolutely the responsible thing to do to increase shareholder
value with a future opportunity to cause a crash-on-demand.

Besides, if you really want microtransactions, you should be using an
altcoin with faster block times, smaller market cap, and larger 'human'
readable currency supply.

That being said, I'd say include the change, we all know about it. What
would be nice would be some exploits and attack signatures for what the
DOS will look like when it hits so that those of us paying attention
can make some money trading in anticipation of the market crash instead
of just the guys paying for the attack.

The real killer feature of Bitcoin is that we can learn from it's mistakes
(and bitcoin can learn from the copycatcoins), instead of one-size-fits
all fiat.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash