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

From: Federico Tenga <federicotenga@gmail•com>
To: Ben Kloester <benkloester@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Idea: Marginal Pricing
Date: Thu, 30 Nov 2017 10:37:57 +0100	[thread overview]
Message-ID: <CAP=-fx7gGhR1G+kGZuS8OLgRk1KWGcNz8EDX=6KuhRaOrpPCVA@mail.gmail.com> (raw)
In-Reply-To: <CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com>

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

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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

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

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