From: William Morriss <wjmelements@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing
Date: Wed, 29 Nov 2017 16:47:43 -0800 [thread overview]
Message-ID: <CADpM8jr_RrbPXLx6Up8HMW-fv=noFLjy817dfsFdYTg216Pu7w@mail.gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3386 bytes --]
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
[-- Attachment #1.2: Type: text/html, Size: 8926 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 --]
next reply other threads:[~2017-11-30 0:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 0:47 William Morriss [this message]
2017-11-30 2:38 ` [bitcoin-dev] BIP Idea: Marginal Pricing Ben Kloester
2017-11-30 6:13 ` William Morriss
2017-11-30 11:40 ` Gregory Maxwell
2017-11-30 12:03 ` Eric Voskuil
2017-11-30 9:37 ` Federico Tenga
2017-11-30 5:52 ` Chenxi Cai
2017-11-30 6:05 ` William Morriss
[not found] ` <CY4PR1201MB0197936CBE467B38DCC26DC986380@CY4PR1201MB0197.namprd12.prod.outlook.com>
2017-11-30 16:15 ` Chenxi Cai
[not found] ` <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
2017-11-30 9:12 ` Gregory Maxwell
2017-12-01 7:58 ` Ryan J Martin
2017-12-02 3:55 ` Damian Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CADpM8jr_RrbPXLx6Up8HMW-fv=noFLjy817dfsFdYTg216Pu7w@mail.gmail.com' \
--to=wjmelements@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox