Fees are too low by a factor of 32 - Marginal Transaction Costs

[phelix]

According to Gavin's "back-of-the-envelope calculations for marginal cost of transactions fees" the fees should be higher by a factor of 32.

https://gist.github.com/gavinandresen/5044482

Let's say at a price of $1000 per BTC and a standard TX of 250bytes:
Actual cost for miners according to Gavin's estimate: 0.0008 BTC       $0.80
Currently paid (relayed?) by Satoshi client:               0.000025 BTC    $0.025

Please correct me if I got the numbers wrong.

I would expect large pools to stick their heads together and get much faster network propagation than in the estimate. Any new measurements on this?

$0.80 per TX is not "free" not matter how large the quotation marks.



(edited: invite for correction, clarity, bla)

[1715243193]

1715243193

[1715243193]

1715243193

[1715243193]

1715243193

[minerva]

Perhaps the current system is subsidizing miners by minting new Bitcoin.

[d'aniel]

Perhaps the current system is subsidizing miners by minting new Bitcoin.

Actually, it's this minting that's the source of the "cost" * of transactions.  There is a drop in expected revenue for a miner by including an extra transaction due to increased orphan probability, and this drop is proportional to the revenue from the block.

OTOH, mining is a zero sum game, and there are other possible equilibria than "miners individually maximize revenues", which could be reinforced through block discouraging schemes.  For example, miners might find it in their collective interest to keep fees lower than orphan "costs" in order to stay competitive with alternative payment systems.

Though there's plenty of low hanging fruit that can be tackled first to bring orphan rates way down, so hopefully this kind of thing won't be necessary.  E.g. a new block's transactions are currently re-broadcast with the block to peers, even if they've already seen them.

* It's not a cost, it's a drop in expected revenues, which may or may not lead to a drop in expected profits, depending on the behaviour of the rest of the network.

[phelix]

OTOH, mining is a zero sum game, and there are other possible equilibria than "miners individually maximize revenues", which could be reinforced through block discouraging schemes.  For example, miners might find it in their collective interest to keep fees lower than orphan "costs" in order to stay competitive with alternative payment systems.

Hmm... I think we are on the safe side if we consider miners greedy and short sighted. There is already one mining protocol that allows the miner himself (instead of the pool operator) to decide on included TXs.


Contacted cdecker about his blocksize propagation delay measurement. He says it might have dropped a little to maybe 70ms/kb in the meantime. There are interesting statistics on propagation here: http://bitcoinstats.com/network/propagation/


I tried to estimate cost per kb another way:

Data from blockchain.info for the last 30 days:
5292 blocks, average block size 195kb
46 orphaned blocks --> 0.87% orphans (not sure how many they miss - 10%?)

From above site:
The measured block propagation time is about 6 seconds.
I assume the minimum propagation time for an empty block is 1 second (similar to the tx propagation time).
I used 50% numbers as I expect pools to be among the first 50% due to their high number of connections.

Throwing all this together I calculate an orphan rate of 1% and a size delay of only 26ms/kb.

My explanation is that pools have high bandwidths and are well connected so that the actual delay per kb for miners is much lower than for normal nodes.

Jgarzik was writing about a fast miner backbone connection...  as far as I know it is not yet working, though.

[JimiQ84]

fees are not low, but block reward is way too high. Also, there is an idea, that block should contain only tx hashes (32B) instead of full txs. This should drastically lower "drop in expected revenue" per transaction.

[t3a]

From Gavins Github:

According to measurements from Christin Decker and Roger Wattenhofer: "each kilobyte in size costs an additional 80ms delay until a majority knows about the block."

80ms seems high. I'm not sure about the Bitcoin network topology, but if it is as efficient a possible, then it should take log_6(X/2) sends to get the block to 50% of the nodes where X is the number of nodes connected.

If I'm interpreting http://bitcoinstatus.rowit.co.uk/ correctly, there are 15k nodes connected right now.

log_6(15000/2) = 5 sends.

Does it really take 80 seconds to send 1mb from person A to person B to person C to person D to person E?

[Realpra]

Well we probably have a factor of 32 too many miners too so that will work out nicely when the subsidy ends.

[Schleicher]

Does it really take 80 seconds to send 1mb from person A to person B to person C to person D to person E?

If one of these persons is me, then yes, probably.
It takes about 30 seconds to upload 1 MB with my internet connection.

[d'aniel]

OTOH, mining is a zero sum game, and there are other possible equilibria than "miners individually maximize revenues", which could be reinforced through block discouraging schemes.  For example, miners might find it in their collective interest to keep fees lower than orphan "costs" in order to stay competitive with alternative payment systems.

Hmm... I think we are on the safe side if we consider miners greedy and short sighted. There is already one mining protocol that allows the miner himself (instead of the pool operator) to decide on included TXs.

For sure, that's much simpler, and I mentioned low hanging fruit to enable us to keep doing this.  I only brought this up to point out that if the block reward (in $) continues to rise faster than we can lower block propagation times, then Bitcoin would become uncompetitive with alternate payments systems under the "greedy and short sighted" miner strategy, but that there alternative strategies that could be implemented.

[t3a]

Since the cost of $0.80 is from competition, there is a solution to these costs.

Simply have bitcoind add a penalty of 80ms * (num transactions seen by client - num transactions in block).

This will make transactions cheaper while keeping mining power constant.

[deepceleron]

OTOH, mining is a zero sum game, and there are other possible equilibria than "miners individually maximize revenues", which could be reinforced through block discouraging schemes.  For example, miners might find it in their collective interest to keep fees lower than orphan "costs" in order to stay competitive with alternative payment systems.

Hmm... I think we are on the safe side if we consider miners greedy and short sighted. There is already one mining protocol that allows the miner himself (instead of the pool operator) to decide on included TXs.

For sure, that's much simpler, and I mentioned low hanging fruit to enable us to keep doing this.  I only brought this up to point out that if the block reward (in $) continues to rise faster than we can lower block propagation times, then Bitcoin would become uncompetitive with alternate payments systems under the "greedy and short sighted" miner strategy, but that there alternative strategies that could be implemented.

The block reward cannot be changed, it is one of the fundamental trusts of Bitcoin. About the only type of change that might acquire future consensus would be something like a change to half-reward 5 minute blocks, and then you would need an overwhelming case for change, such as doubling confirmation and blockchain protection speed, with zero orphan impact because now even outhouses in India have 1TB/s fiber.

There is no assumption in the digital cash white paper that Bitcoin was suitable for free micro transactions, which has been over-promised by self-promoters. Bitcoin has some self-adjusting economics:

-Miner's reward of gathering all available paid fees into uncapped block size is balanced by the risk of orphan; miners can specify their own threshold if they feel that they would rather not include 0.0001 fee transactions.
-The block size limit provides guidance and self-promotes increased fees on a busy network.

It may take $10 fees to timely transfer alongside millions of dollars worth of bitcoin transfers globally per minute, but such a scenario is what we call a success.

[justusranvier]

New block messages that only list transaction hashes instead of the full transactions themselves = problem solved (pretty much).

[d'aniel]

The block reward cannot be changed, it is one of the fundamental trusts of Bitcoin.

I never suggested messing with the inflation schedule.  That would indeed be stupid.  I pointed out that miners could collectively discourage blocks that don't conform to some rough consensus on fee policy.  This would lead to a different equilibrium than the one you mentioned, which could potentially be more profitable for the miners.

Example: the block reward (measured in $) rises faster than block propagation/orphan rates can be lowered.  Fees become uncompetitive because they are determined by the expected revenue loss due to a transaction's marginal orphan probability.  Bitcoin begins losing market share to Altcoin.  Miners collectively realize that if they all agree to keep their fees competitive, then they can contain this loss of market share, and earn more revenue.  Cheating needs to be discouraged, so miners agree to not build directly on top of blocks that violate the consensus fee policy.  This raises the orphan rates of cheaters to the point where cheating lowers expected revenues.  Notice that no individual miner is at a relative disadvantage because the higher overall orphan rate is spread proportionally amongst them all, and difficulty has adjusted downward to compensate for the higher overall orphan rate, making blocks concomitantly easier to find (i.e. mining is a zero sum game).

New block messages that only list transaction hashes instead of the full transactions themselves = problem solved (pretty much).

That's pretty much what I expect as well, but you never know.

[phelix]

Since the cost of $0.80 is from competition, there is a solution to these costs.

Simply have bitcoind add a penalty of 80ms * (num transactions seen by client - num transactions in block).

This will make transactions cheaper while keeping mining power constant.

This is not possible since miners connect directly to each other and use modified clients.

[...]
  I pointed out that miners could collectively discourage blocks that don't conform to some rough consensus on fee policy.  This would lead to a different equilibrium than the one you mentioned, which could potentially be more profitable for the miners.

Example: the block reward (measured in $) rises faster than block propagation/orphan rates can be lowered.  Fees become uncompetitive because they are determined by the expected revenue loss due to a transaction's marginal orphan probability.  Bitcoin begins losing market share to Altcoin.  Miners collectively realize that if they all agree to keep their fees competitive, then they can contain this loss of market share, and earn more revenue.  Cheating needs to be discouraged, so miners agree to not build directly on top of blocks that violate the consensus fee policy.  This raises the orphan rates of cheaters to the point where cheating lowers expected revenues.  Notice that no individual miner is at a relative disadvantage because the higher overall orphan rate is spread proportionally amongst them all, and difficulty has adjusted downward to compensate for the higher overall orphan rate, making blocks concomitantly easier to find (i.e. mining is a zero sum game).

Somewhat ugly but might work.

There is no assumption in the digital cash white paper that Bitcoin was suitable for free micro transactions, which has been over-promised by self-promoters. Bitcoin has some self-adjusting economics:
[...]
It may take $10 fees to timely transfer alongside millions of dollars worth of bitcoin transfers globally per minute, but such a scenario is what we call a success.

It's interesting how a high price puts a limit on growth of small TXs. I wonder if Satoshi has foreseen all this.

New block messages that only list transaction hashes instead of the full transactions themselves = problem solved (pretty much).

That's pretty much what I expect as well, but you never know.

Is anybody working on this? What happens if a miner is missing one of the hashed TXs?

I guess if a block is signed by an entity that has found a couple of correct blocks in the past it would be safe for a pool to start building on the block message and postpone verification a little...

Hopefully this does not foster centralization too much.

[justusranvier]

Is anybody working on this? What happens if a miner is missing one of the hashed TXs?

All nodes need to verify all blocks, not just miners.

If a message comes through with an unknown transaction hash, the node receive it would need to ask it's peers if anyone else has seen it.

I guess if a block is signed by an entity that has found a couple of correct blocks in the past it would be safe for a pool to start building on the block message and postpone verification a little...

That would never happen. Nobody is going to build on a block which they can not verify as valid.

Any miner stupid enough to try that would open themselves up to a loss of revenue by being tricked to building on an invalid fork.

Nodes that routinely pass along invalid blocks would be blacklisted by their peers.

Hopefully this does not foster centralization too much.

It does the opposite.

[phelix]

Is anybody working on this? What happens if a miner is missing one of the hashed TXs?

All nodes need to verify all blocks, not just miners.

If a message comes through with an unknown transaction hash, the node receive it would need to ask it's peers if anyone else has seen it.

Exactly... so it might cause a delay.

I guess if a block is signed by an entity that has found a couple of correct blocks in the past it would be safe for a pool to start building on the block message and postpone verification a little...

That would never happen. Nobody is going to build on a block which they can not verify as valid.

Any miner stupid enough to try that would open themselves up to a loss of revenue by being tricked to building on an invalid fork.

Why would they not trust a signed new block message from a large well known pool for say two seconds? I think this is would not be a problem. Small unknown miners on the other hand might have to wait.

Hopefully this does not foster centralization too much.

It does the opposite.

Why? Because it allows small miners to propagate their blocks faster?

(edited)

[t3a]

Since the cost of $0.80 is from competition, there is a solution to these costs.

Simply have bitcoind add a penalty of 80ms * (num transactions seen by client - num transactions in block).

This will make transactions cheaper while keeping mining power constant.

This is not possible since miners connect directly to each other and use modified clients.

So wouldn't this mean that it doesn't take 80ms per kb to propogate because the miners will instantly have new blocks and will start mining on the new ones?