public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] what do you think about having a maximum fee rate?
@ 2017-12-22  8:26 oscar
  2017-12-24  1:13 ` Damian Williamson
  0 siblings, 1 reply; 3+ messages in thread
From: oscar @ 2017-12-22  8:26 UTC (permalink / raw)
  To: bitcoin-dev

Hello,
I'm not a bitcoin developer, but I'd like to receive feedback on what
I think is a serious problem. Hope I'm not wasting your time.
I'm also sure this was already discussed, but google doesn't give me
any good result.

Let me explain: I think that the current incentive system doesn't
really align with the way miners are distributed (not very
decentralized, due to pools and huge asic producers).
I think big miners are incentivized to spam the network with low(ish)
fee transactions, thereby forcing regular users into paying extremely
high fees to be able to get their transactions confirmed.

Obviously this is the result of insufficient mining decentralization,
but as I will try to show, such an attack could be profitable even if
you are controlling just 5-10% of the hashing power, which could
always be easy for a big player and with some collusion.

Let's look at some numbers: https://i.imgur.com/sCn4eDG.png

These are 10 blocks mined yesterday, and they all have rewards hugely
exceeding the normal 12.5 mining output. Even taking the lowest value
of 20, it's a nice 60% extra profit for the miner. Let's say you
control 10% of the hashing power, and you spam enough transactions to
fill 144 blocks (1 day's worth) at 50 satoshi/byte, losing just 72 BTC
in fees.

(blocksize-in-bytes * fee-per-byte * Nblocks)/satoshis-in-btc => (1e6
* 50 * 144)/1e8 => 72

At the same time you will discover about 144*0.1=14.4 blocks per day.
Assuming the situation we see in the previous screenshot is what
happens when you have a mempool bigger than one day's worth of blocks,
you would get 20-12.5=7.5 extra BTC per block, which is 14.4*7.5=108
BTC, given your investment of 72 to spam the mempool. 32 btc extra
profit.

The big assumption here is that spamming 1 day of backlog in the
50satoshi/b range will get people to compete enough to push 7.5 btc of
fees in each block, but:

* https://jochen-hoenicke.de/queue/#30d this seems to confirm that
about half the mempool is in the 50satoshi/b range or less.
* https://blockchain.info/pools there are miners that control more than 10%
* if you get enough new real transactions, it's not necessary to spam
a full 144 blocks worth each day, probably just ~50 would be enough,
cutting the spam cost substantially
* other miners could be playing the same game, helping you spam and
further reduce the costs of the attack
* you actually get 10% of the fees back by avoiding mining your spam
transactions in your own blocks
* most of the spam transactions won't actually end up in blocks if
there is enough pressure coming from real usage

This seems to indicate that you would actually get much higher profit
margins than my estimates. **PLEASE** correct me if my calculations or
my assumptions are wrong.

You might also say that doing this would force users out of the
system, decreasing the value of btc and disincentivizing miners from
continuing. On the other hand, a backlogged mempool could create the
impression of high(er) usage and increase scarcity by slowing down
movements, which could actually push the price upwards.

Of course, it's impossible to prove that this is happening. But the
fact that it is profitable makes me believe that it is happening.

I see some solutions to this, all with their own downsides:

- increasing block size every time there is sustained pressure
this attack wouldn't work, but the downsides have already been
discussed to death.

- change POW
Not clear it would fix this, aside from stimulating terrible
infighting. Controlling 5 to 10% of the hashing power seems too easy,
and I don't think it would be practical to change pow every time that
happens, as it would prevent the development of a solid POW support.

- protocol level MAX transaction fee
I personally think this would totally invalidate the attack by making
the spam more expensive than the fees you would recover.
There already is a minimum fee accepted by the nodes, at 1 satoshi per
byte. The maximum fee could be N times the minimum, maybe 100-200.
Meaning a maximum of 1-2btc in total fee rewards when the block size
is 1mb. Of course the actual values need more analysis, but 2btc -
together with the deflationary structure - seems enough to continue
motivating miners, without giving unfair advantage.

Yes, this would make it impossible to spend your way out of a
congested mempool. But if the mempool stays congested after this
change, you could have a bigger confidence that it's coming from real
usage or from someone willfully burning money, making a block size
increase much more justified.

Hope to hear your opinion,
have a nice day.

oscar


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [bitcoin-dev]  what do you think about having a maximum fee rate?
  2017-12-22  8:26 [bitcoin-dev] what do you think about having a maximum fee rate? oscar
@ 2017-12-24  1:13 ` Damian Williamson
  2017-12-24 13:59   ` oscar
  0 siblings, 1 reply; 3+ messages in thread
From: Damian Williamson @ 2017-12-24  1:13 UTC (permalink / raw)
  To: oscar, Bitcoin Protocol Discussion

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

If all transactions pay the proposed max then fee there are still going to be an awful lot of never confirming transactions once the transaction bandwidth limit is surpassed, as I suppose that it roughly is now:

https://bitinfocharts.com/comparison/bitcoin-transactions.html


This is what I have been working on as an alternative:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015371.html


There is a previous thread, linked later on in the linked thread.


Regards,

Damian Williamson


________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of oscar via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Friday, 22 December 2017 7:26:12 PM
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] what do you think about having a maximum fee rate?

Hello,
I'm not a bitcoin developer, but I'd like to receive feedback on what
I think is a serious problem. Hope I'm not wasting your time.
I'm also sure this was already discussed, but google doesn't give me
any good result.

Let me explain: I think that the current incentive system doesn't
really align with the way miners are distributed (not very
decentralized, due to pools and huge asic producers).
I think big miners are incentivized to spam the network with low(ish)
fee transactions, thereby forcing regular users into paying extremely
high fees to be able to get their transactions confirmed.

Obviously this is the result of insufficient mining decentralization,
but as I will try to show, such an attack could be profitable even if
you are controlling just 5-10% of the hashing power, which could
always be easy for a big player and with some collusion.

Let's look at some numbers: https://i.imgur.com/sCn4eDG.png

[https://i.imgur.com/sCn4eDG.png]


These are 10 blocks mined yesterday, and they all have rewards hugely
exceeding the normal 12.5 mining output. Even taking the lowest value
of 20, it's a nice 60% extra profit for the miner. Let's say you
control 10% of the hashing power, and you spam enough transactions to
fill 144 blocks (1 day's worth) at 50 satoshi/byte, losing just 72 BTC
in fees.

(blocksize-in-bytes * fee-per-byte * Nblocks)/satoshis-in-btc => (1e6
* 50 * 144)/1e8 => 72

At the same time you will discover about 144*0.1=14.4 blocks per day.
Assuming the situation we see in the previous screenshot is what
happens when you have a mempool bigger than one day's worth of blocks,
you would get 20-12.5=7.5 extra BTC per block, which is 14.4*7.5=108
BTC, given your investment of 72 to spam the mempool. 32 btc extra
profit.

The big assumption here is that spamming 1 day of backlog in the
50satoshi/b range will get people to compete enough to push 7.5 btc of
fees in each block, but:

* https://jochen-hoenicke.de/queue/#30d this seems to confirm that
[https://jochen-hoenicke.de/queue/mempool-20170608.png]<https://jochen-hoenicke.de/queue/#30d>

Johoe's Mempool Size Statistics - jochen-hoenicke.de/queue<https://jochen-hoenicke.de/queue/#30d>
jochen-hoenicke.de
This page displays the number and size of the unconfirmed bitcoin transactions, also known as the transactions in the mempool. It gives a real-time view and shows how ...


about half the mempool is in the 50satoshi/b range or less.
* https://blockchain.info/pools there are miners that control more than 10%
Bitcoin Hashrate Distribution - Blockchain.info<https://blockchain.info/pools>
blockchain.info
A pie chart showing the hashrate distribution between the major bitcoin mining pools - Blockchain


* if you get enough new real transactions, it's not necessary to spam
a full 144 blocks worth each day, probably just ~50 would be enough,
cutting the spam cost substantially
* other miners could be playing the same game, helping you spam and
further reduce the costs of the attack
* you actually get 10% of the fees back by avoiding mining your spam
transactions in your own blocks
* most of the spam transactions won't actually end up in blocks if
there is enough pressure coming from real usage

This seems to indicate that you would actually get much higher profit
margins than my estimates. **PLEASE** correct me if my calculations or
my assumptions are wrong.

You might also say that doing this would force users out of the
system, decreasing the value of btc and disincentivizing miners from
continuing. On the other hand, a backlogged mempool could create the
impression of high(er) usage and increase scarcity by slowing down
movements, which could actually push the price upwards.

Of course, it's impossible to prove that this is happening. But the
fact that it is profitable makes me believe that it is happening.

I see some solutions to this, all with their own downsides:

- increasing block size every time there is sustained pressure
this attack wouldn't work, but the downsides have already been
discussed to death.

- change POW
Not clear it would fix this, aside from stimulating terrible
infighting. Controlling 5 to 10% of the hashing power seems too easy,
and I don't think it would be practical to change pow every time that
happens, as it would prevent the development of a solid POW support.

- protocol level MAX transaction fee
I personally think this would totally invalidate the attack by making
the spam more expensive than the fees you would recover.
There already is a minimum fee accepted by the nodes, at 1 satoshi per
byte. The maximum fee could be N times the minimum, maybe 100-200.
Meaning a maximum of 1-2btc in total fee rewards when the block size
is 1mb. Of course the actual values need more analysis, but 2btc -
together with the deflationary structure - seems enough to continue
motivating miners, without giving unfair advantage.

Yes, this would make it impossible to spend your way out of a
congested mempool. But if the mempool stays congested after this
change, you could have a bigger confidence that it's coming from real
usage or from someone willfully burning money, making a block size
increase much more justified.

Hope to hear your opinion,
have a nice day.

oscar
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
bitcoin-dev Info Page - Linux Foundation<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
lists.linuxfoundation.org
Bitcoin development and protocol discussion. This list is lightly moderated. - No offensive posts, no personal attacks. - Posts must concern development of bitcoin ...



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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [bitcoin-dev] what do you think about having a maximum fee rate?
  2017-12-24  1:13 ` Damian Williamson
@ 2017-12-24 13:59   ` oscar
  0 siblings, 0 replies; 3+ messages in thread
From: oscar @ 2017-12-24 13:59 UTC (permalink / raw)
  To: Damian Williamson; +Cc: Bitcoin Protocol Discussion

On Sun, Dec 24, 2017 at 2:13 AM, Damian Williamson <willtech@live•com.au> wrote:
> If all transactions pay the proposed max then fee there are still going to
> be an awful lot of never confirming transactions once the transaction
> bandwidth limit is surpassed

Yes obviously. That would be the unequivocal sign that it's time to
bump the block size.

Why not just bump now then? My main worry is that wasting space should
not be profitable for anybody. If it is, it's an encouragement to
waste space, and imho we have such an encouragement in place.

Fees should be allowed to get high enough as to discourage wasteful
usage of blockchain space, but not high enough as to make it
*profitable* to waste space, if you are a sufficiently big miner. The
fact that it is now profitable, and that such big miners exist, makes
me believe that a lot of blockchain space is wasted on purpose.

> This is what I have been working on as an alternative:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-December/015371.html

I read your proposal, but the value that I see in mine is that it is
extremely simple. It would be trivial to have nodes stop propagating
transactions with fees over the max, and miners can trivially reject
blocks where coinbase > block reward + max fee rate * block size, if
they are on board.

It would also be quite simple to adapt wallets, given that the fee
range is fixed. If nodes had an rpc method giving you some mempool
statistics, it would also be simple to correctly recommend fees
according to the time expected to first confirmation.

Sure, at some point, if there is real congestion, it would just start
always recommending the max fee. Again, this means that it's time to
bump the block size. I think this is ultimately unavoidable, but I
understand the reservations, and I agree that increasing the block
size without incentivizing efficient usage would be counterproductive.
I think the current fees are certainly incentivizing efficient usage
to users, but not to miners. My (maybe naive) idea is that it would be
possible to find an appropriate maximum fee value that would move
things towards efficient usage by both users and big miners.

This would work very well if coupled with some proposals I've read to
slowly increase the block size with a process similar to difficulty
adjustment, like adding 100kb if 95% of the last 2016 blocks were
full. Without max fees, a big miner could easily destroy this strategy
by always applying just enough pressure as to always skyrocket fees
and profit, while the blocksize slowly increases.

The way I see it, unbounded fees together with small blocks and big
miners introduce a terrible flaw in the incentives equilibrium.
I would really like an open discussion on this topic.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-12-24 13:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-22  8:26 [bitcoin-dev] what do you think about having a maximum fee rate? oscar
2017-12-24  1:13 ` Damian Williamson
2017-12-24 13:59   ` oscar

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox