[bitcoin-dev] BIP Idea: Marginal Pricing

Fri Dec 1 07:58:01 UTC 2017

Interesting thoughts William, however much of what you describe already exists:
"I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block."
This happens with users deciding to pay (essentially) a fee smaller or larger than the 1999th tx in the mempool. If user is willing to pay more than the 1999th highest fee tx in mempool (or whatever tx byte 1,000,000 in a mempool ranked by tx fee) then they will get to be on the next block. This is a simplification but you get the idea.

Further, Greg Maxwell's one reply covers alot of the biggest pitfalls well. Especially that much of this already happens and that behavior in response to such a change could be hairy to predict. So I'm not sure that---what is basically--- a multi-unit Vickrey auction is the best way to go... but it is an interesting idea worth further examination.

Second, minimizing invididual user tx fees and maximizing total tx fees are essentially incompatible within the current development structure. Even if the block limit is increased to 3mb the same problem will eventually occur. While I agree it would be ideal to maximize social benefit (i.e. maximize both consumer and producer surplus) through more simple protocol changes---at least in the medium term, that isn't on the table so it is better to move on.

  This is not an easy optimization problem to solve though. The difficulty is trying to model a market like bitcoin; the only thing that comes close is electricity markets. With 2,000 tx in the pool, users aren't willing to pay shit to send a tx; there is always a miner to process it. So at 2,000tx per 10 min (3.333 txps, 1mb/10min,etc) and below users price elasticity is flat. Once the pool has >2,000 tx in it, especially for any extended amount of time, users price elasticity is about as elastic as a brick and goes near vertical. This creates a situation where miners are always better off when there is a significant backlog (this can be seen in miners revenue from tx fees anytime there is an ongoing backlog).
Simply put, it would take some very large blocks to have total fees/block exceed total fees/block for constrained size blocks given the near vertical price elasticity users face when there is a backlog.

So I suspect that the multi-unit Vickrey would potentially do some to help this, but likely not much:
Users willingness to pay is what they pay---no surplus. Miner elasticity is more or less flat but we can call their willingness to accept whatever the lowest fee tx is in a block. Say it is 180 sat/b (NL), and the highest tx fee in a block (NH)is 320 sat/b. If you subtract each tx in the block (N) greater than NL
and sum the result you get surplus to miners:  Σ(N1,2...- NL)
So, yes, the multi-unit Vickrey simply shifts the surplus to users. However, a case could be made that since---as mentioned in an earlier reply, the optimal strategy for miners is to accept zero fees (given their flat elasticity), and therefore all fees are surplus benefit to miners---shifting this surplus over to consumers could create some good effects. Primarily pushing users' price elasticity away from near vertical inelasticity as it would take some of the upward pressure off rapidly increasing fees in a backlog scenario.
It would be interesting to see a simulation of how this would play out, but without that this is too risky to implement.

Regards,
Ryan J. Martin (tunafizz / ohituna)

________________________________
From: bitcoin-dev-bounces at lists.linuxfoundation.org [bitcoin-dev-bounces at lists.linuxfoundation.org] on behalf of William Morriss via bitcoin-dev [bitcoin-dev at lists.linuxfoundation.org]
Sent: Wednesday, November 29, 2017 7:47 PM
To: bitcoin-dev at lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing

Comrades,

Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.

Goals
Maximize total transaction fees
Reduce pending transaction time
Reduce individual transaction fees

Challenges
Validators must agree on the maximum block size, else miners can cheat and include extra transactions.
Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.

Problem
In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.
Currently, the supply curve is inelastic:
[cid:ii_jalpxsnl1_1600a3d9def1eaff]
Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:
- Unpredictable transaction settlement time
- Variable transaction fees depending on network congestion
- Frequent overpay

Proposal
1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.
2. Remove the block size limit, which is no longer necessary.

Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; all fees are fair
[cid:ii_jalqir4g2_1600a4c89811347a]
Miners individually will make decisions to maximize their block-reward profit.
Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.
Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.

The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.

Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.

Examples

Scenario 1
Sat/byte        Bytes   Reward
400     500000  200000000
300     700000  210000000
200     1000000 200000000
100     1500000 150000000
50      5000000 250000000
20      10000000        200000000
A miner would create a 5MB block and receive 0.25 BTC

Scenario 2
Sat/byte        Bytes   Reward
400     600000  240000000
300     700000  210000000
200     1000000 200000000
100     1800000 180000000
50      4000000 200000000
20      10000000        200000000
A miner would create a 600KB block and receive 0.24 BTC

Thanks,
William Morriss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: fixedblocksize.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: fixedblocksize.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: marginal.png
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171201/d32a6976/attachment-0005.png>