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:

​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

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

Hi All,

Auction theory is a well-studied problem in the economics literature. Currently what bitcoin has is Generalized first-price auction, where winning bidders pay their full bids. Alternatively, two approaches are potentially viable, which are Generalized second-price auction and Vickrey–Clarke–Groves auction. Generalized second-price auction, where winning bidders pay their next highest bids, reduces (but not eliminate) the need for bidders to strategize by allowing them to bid closer to their reservation price. Vickrey–Clarke–Groves auction, a more sophisticated system that considers all bids in relation to one another, elicit truthful bids from bidders, but may not maximize miners' fees as the other two systems will.

Due to one result called Revenue Equivalence, the choice of fee design will not impact miners' fees unless the outcomes of the auction changes (i.e, the highest bidders do not always win). In addition, the sole benefit of second-price auction over first-price auction is to spare people's mental troubles from strategizing, rather than actually saving mining fees, because in equilibrium the fees bidders pay remain the same. Therefore, in balance, I do not see substantial material benefits arising from switching to a different fee schedule.

Best,

Chenxi Cai

________________________________ From: bitcoin-dev-bounces@lists•linuxfoundation•org <bitcoin-dev-bounces@lists•linuxfoundation•org> on behalf of William Morriss via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> Sent: Wednesday, November 29, 2017 5:47 PM To: bitcoin-dev@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

On Wed, Nov 29, 2017 at 9:52 PM, Chenxi Cai <Chenxi_Cai@live•com> wrote:

> Hi All,
>
>
> Auction theory is a well-studied problem in the economics literature.
> Currently what bitcoin has is Generalized first-price auction, where
> winning bidders pay their full bids. Alternatively, two approaches are
> potentially viable, which are Generalized second-price auction and Vickrey–Clarke–Groves
> auction. Generalized second-price auction, where winning bidders pay their
> next highest bids, reduces (but not eliminate) the need for bidders to
> strategize by allowing them to bid closer to their reservation
> price. Vickrey–Clarke–Groves auction, a more sophisticated system that
> considers all bids in relation to one another, elicit truthful bids from
> bidders, but may not maximize miners' fees as the other two systems will.
>
>
> Due to one result called Revenue Equivalence, the choice of fee design
> will not impact miners' fees unless the outcomes of the auction changes
> (i.e, the highest bidders do not always win). In addition, the sole benefit
> of second-price auction over first-price auction is to spare people's
> mental troubles from strategizing, rather than actually saving mining fees,
> because in equilibrium the fees bidders pay remain the same. Therefore, in
> balance, I do not see substantial material benefits arising from switching
> to a different fee schedule.
>
>
> Best,
>
> Chenxi Cai
>
>

Changing the bidding system to the marginal price allows us to supersede the block size limit, which changes the outcome of the auction, as different transactions are included.

On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester@gmail•com> wrote:

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

Thanks. Marginal pricing is equivalent to the "Monopolistic Price Mechanism" discussed in https://arxiv.org/abs/1709.08881. The mechanism is the same, including the block size adjustment, but as you noted the prior discussion only concerns the fee structure.

It looks like the prior proposal broke down because of Peter Todd's concern with out-of-band payments (https://lists.linuxfoundation.org/pipermail/ bitcoin-dev/2017-September/015103.html). Restated, miners can circumvent the system through out of band payments. Mark Friedenbach argues that out-of-band payments are penalized in part because the end-user could have just as easily bid higher instead of paying OOB. Peter Todd argues that a miner could mine only out-of-band transactions. Such transactions could have no on-chain fees and thus be disregarded by other miners.

I believe this OOB scenario is imaginary. Either it would be more profitable for a miner to mine fairly, or cheaper for the end-user to pay the fee in-band. Consider MINFEE to the the effective fee paid for the block mined by the OOB-incentivized miner. Consider MARKFEE to the the market fee collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB. Then, For a user to prefer OOB: MINFEE+OOB<MARKFEE For a miner to prefer OOB: MINFEE+OOB>MARKFEE It is impossible for both scenarios to be true. As previously argued by Mark Friedenbach, the system disincentivizes OOB tx fees.

I don't think there is any more centralization pressure with marginal fees than before. What prevents miners from colluding to move tx fees OOB is the value of the on-band pending tx fees. The hashpower of individual miners is not impressive compared to the entire network, so individual miners could not offer a service to speed up confirmation that would be superior to simply doing a RBP. OOB fees are perhaps a symptom of the current setup, wherein there is no penalty for arbitrarily favoring individual transactions with lower fees.

This idea presumes that the protocol has any ability to regulate fees. I believe the locally optimal strategy for both miners and payers alike is to accept (pay) zero fees natively in the protocol and instead accept (pay) their actual fees out-of-band or via OP_TRUE outputs which the miner can simply collect. Then the miner sets the fee threshold to ~0 and selects transactions on the basis of out of band fees.

Miners today already accept out-of-band fees, and as far back as at least 2011 there were miners that would also accept fees in the form of additional transaction outputs which they were able to spend.

On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

>
>
> This idea presumes that the protocol has any ability to regulate fees. I
> believe the locally optimal strategy for both miners and payers alike is to
> accept (pay) zero fees natively in the protocol and instead accept (pay)
> their actual fees out-of-band or via OP_TRUE outputs which the miner can
> simply collect.  Then the miner sets the fee threshold to ~0 and selects
> transactions on the basis of out of band fees.
>
> Miners today already accept out-of-band fees, and as far back as at least
> 2011 there were miners that would also accept fees in the form of
> additional transaction outputs which they were able to spend.
>
>
>
> On Thu, Nov 30, 2017 at 12:47 AM, 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
>>
>>
>

The main issue that I see with this proposal is that miners can still spam the network for free even with high sat/byte fee levels. They can first choose the sat/byte rate that maximize their profit, and then include a lot of spam transactions at that rate that will only pay fees to themselves, effectively spamming the chain for free and increasing the cost of running a node.

On 30 Nov 2017 03:40, "Ben Kloester via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:

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

On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:

> I believe this OOB scenario is imaginary. Either it would be more profitable

Out of band fees are a reality even today-- and have for most of Bitcoin's life--, without a system that has any particular incentive for them.

> for a miner to mine fairly, or cheaper for the end-user to pay the fee
> in-band. Consider MINFEE to the the effective fee paid for the block mined
> by the OOB-incentivized miner. Consider MARKFEE to the the market fee
> collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB.
> Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by Mark
> Friedenbach, the system disincentivizes OOB tx fees.

This kind of analysis seems to imagine that a single decision maker is making a globally optimal decision and that also people are somehow forced to only make one choice. Both are untrue in this case (and most other economic circumstances). Instead, participants can take the best of multiple choices and will often act locally for their own best interest even when it reduces revenue for their industry in total.

Concretely: as a user with competent wallet software, I would be automatically drafting two transactions-- one paying OOB and one paying min fee, at equivalent expected rates. Miners would construct blocks which locally maximized their revenue. It is far from clear that use of the minfee scheme is an equilibrium-- in fact I think it is clearly not an equilibrium: a user that writes both transactions will always pay equal or less fees for the transactions where they do both (even if all users doing this causes users collectively to pay higher fees), a miner who considers both will always make equal or greater fee income on a block by block basis (even if it lowers miner income collectively when all do this).

(If it were in fact preferred by users and miners alike: why doesn't it already exist? Since the existence of OOB fees cannot be eliminated, as far as we know, any use of MINFEE would be inherently voluntary-- so in one sense we already 'have' voluntary minfee, but no one uses it.)

Ignoring the possibility of evasion, there are some other concerns that you might want to consider:

I believe the idea converts variance in fee willingness into variance in capacity for the network. If rich uncle bill wants to waste money with uneconomically high fees, with a constant flow of transactions, he'll effectively knock out a large number of participants. You could argue that bill could spend those same fees in spam to displace the same amount of transactions while also using more capacity; but I UncleBill isn't trying to attack the capacity of the system. It's just collateral damage. I worry also about related strategies that arise in that world: For example, lets imagine that world consisted of a couple unclebill who will pay high fees, and the unwashed masses that will not and pay a much lower consistent feerate. Honest conformance with your protocol would result in miners either processing only the UncleBill txn or processing all of them at the lower rate, whichever is more profitable. Super-rational behavior might be for a majority of hashpower to collude to only permit high fee-rate transactions every other block and only permit low feerate in the others, and then the network processes all unclebills in one block (at full rate), and all the unwashed in the others. From a fee perspective it arguably isn't any worse than today, but I believe it significantly handicaps your capacity limiting argument.

> wherein there is no penalty for arbitrarily favoring individual transactions with lower fees

Nor does a MINFEE system; since the user can near costlessly construct as many variations of their transaction as they like.

> The hashpower of individual miners is not impressive compared to the entire network,

That is unfortunately not the reality of Bitcoin today.

On 11/29/2017 10:13 PM, William Morriss via bitcoin-dev wrote:

> On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester@gmail•com
> <mailto:benkloester@gmail.com>> wrote:
>
>     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 <https://arxiv.org/abs/1709.08881>
>
>     *Ben Kloester*
>
> Thanks. Marginal pricing is equivalent to the "Monopolistic Price
> Mechanism" discussed in https://arxiv.org/abs/1709.08881
> The mechanism is the same, including
> the block size adjustment, but as you noted the prior discussion only
> concerns the fee structure.
>
> It looks like the prior proposal broke down because of Peter Todd's
> concern with out-of-band payments
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015103.html).
> Restated, miners can circumvent the system through out of band payments.
> Mark Friedenbach argues that out-of-band payments are penalized in part
> because the end-user could have just as easily bid higher instead of
> paying OOB. Peter Todd argues that a miner could mine only out-of-band
> transactions. Such transactions could have no on-chain fees and thus be
> disregarded by other miners.
>
> I believe this OOB scenario is imaginary. Either it would be more
> profitable for a miner to mine fairly, or cheaper for the end-user to
> pay the fee in-band.
> Consider MINFEE to the the effective fee paid for
> the block mined by the OOB-incentivized miner. Consider MARKFEE to the
> the market fee collected by non-OOB-incentivized miners. Call the OOB
> effective tx fee OOB. Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by
> Mark Friedenbach, the system disincentivizes OOB tx fees.

Bitcoin is neutral on how miners are paid. The benefit of on-chain fee payment is that a fee can be paid with no communication between the miner and the merchant, preserving anonymity. It also serves as a convenience that anonymous fees are published, as it provides a basis for anonymous fee estimation. There is no centralization pressure that arises from side fees.

https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy

> I don't think there is any more centralization pressure with marginal
> fees than before. What prevents miners from colluding to move tx fees
> OOB is the value of the on-band pending tx fees. The hashpower of
> individual miners is not impressive compared to the entire network, so
> individual miners could not offer a service to speed up confirmation
> that would be superior to simply doing a RBP. OOB fees are perhaps a
> symptom of the current setup, wherein there is no penalty for
> arbitrarily favoring individual transactions with lower fees.

It is clear that charging min fee won't maximize total miner's fees because it ignores heterogeneity in willingness to pay among bidders within the same block. Also, spamming can still occur by setting a large number of transactions to the min fee. Competition between spammers might drive up the min fee, which is really where the positive effect comes from in this model.

A two-part pricing scheme involving a fixed fee per transaction plus variable fee per byte is likely to work much better. The fixed fee component raises the cost of micro-transactions substantially and deters spamming of the mempool. Also, revenue is not lost from people with higher willingness to pay.

Chenxi

________________________________ From: William Morriss <wjmelements@gmail•com> Sent: Wednesday, November 29, 2017 11:05 PM To: Chenxi Cai Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing

On Wed, Nov 29, 2017 at 9:52 PM, Chenxi Cai <Chenxi_Cai@live•com<mailto:Chenxi_Cai@live.com>> wrote:

Hi All,

Auction theory is a well-studied problem in the economics literature. Currently what bitcoin has is Generalized first-price auction, where winning bidders pay their full bids. Alternatively, two approaches are potentially viable, which are Generalized second-price auction and Vickrey–Clarke–Groves auction. Generalized second-price auction, where winning bidders pay their next highest bids, reduces (but not eliminate) the need for bidders to strategize by allowing them to bid closer to their reservation price. Vickrey–Clarke–Groves auction, a more sophisticated system that considers all bids in relation to one another, elicit truthful bids from bidders, but may not maximize miners' fees as the other two systems will.

Due to one result called Revenue Equivalence, the choice of fee design will not impact miners' fees unless the outcomes of the auction changes (i.e, the highest bidders do not always win). In addition, the sole benefit of second-price auction over first-price auction is to spare people's mental troubles from strategizing, rather than actually saving mining fees, because in equilibrium the fees bidders pay remain the same. Therefore, in balance, I do not see substantial material benefits arising from switching to a different fee schedule.

Best,

Chenxi Cai

Changing the bidding system to the marginal price allows us to supersede the block size limit, which changes the outcome of the auction, as different transactions are included.

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@lists•linuxfoundation•org [bitcoin-dev-bounces@lists•linuxfoundation•org] on behalf of William Morriss via bitcoin-dev [bitcoin-dev@lists•linuxfoundation•org] Sent: Wednesday, November 29, 2017 7:47 PM To: bitcoin-dev@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

I also am for the idea of removing blocksize limits if it is workable, however, would propose an alternative method for selecting transactions to be included in a block.

Some of the issues discussed in other replies to this thread are valid.

Alternative proposal:

Provide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the pool (also on a curve) out to n days (n=30 ?), the transaction weight serving as the likelihood of a transaction being included in the current block, and then use an uncapped block size. The curve allows that the higher a fee allows a transaction to be much more likely to be included, the highest fee gets 100%, and, transactions at the n days limit get near 100%. Would need protocol enforcement since, as I understand, no miner would mine more transactions than are necessary to meet min blocksize. Other than that it should function fine. Non-urgent transactions pay a lower fee, people choose fees from fee recommendation based on how many days before a tx begins confirmation, all transactions are eventually included in the blockchain.

Regards,

Damian Williamson

________________________________ From: bitcoin-dev-bounces@lists•linuxfoundation•org <bitcoin-dev-bounces@lists•linuxfoundation•org> on behalf of William Morriss via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> Sent: Thursday, 30 November 2017 11:47:43 AM To: bitcoin-dev@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