Re: [bitcoin-dev] BIP Idea: Marginal Pricing

[Ben Kloester <benkloester@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4298 bytes --]

Something similar to this has been proposed  in this article by Ron Lavi,
Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html

They only discussed changing the fee structure, not removing the block size
limit, as far as I know.

    "Redesigning Bitcoin's fee market"
    https://arxiv.org/abs/1709.08881



*Ben Kloester*

On 30 November 2017 at 11:47, William Morriss via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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:
>
> ​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
>
> ​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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #1.2: Type: text/html, Size: 11065 bytes --]

[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]

[-- Attachment #3: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]

[-- Attachment #4: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]