đź“… Original date posted:2017-11-30
đź“ť Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0003.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0004.png>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0005.png>;
Ben Kloester [ARCHIVE] /
npub1hz…ug52u
2023-06-07 18:07:57
in reply to nevent1q…c09h
Author Public Key
npub1hzpahez9uhvlsfge4xvu3tkz492dwdwhpznykp455s6fg5x5thpqeug52uSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:07:57Event JSON
{
"id": "7b54d5fcf39f74b3f5d934b2f8d03384269ccc43d3e7f506b06163feb747eaf9",
"pubkey": "b883dbe445e5d9f82519a999c8aec2a954d735d708a64b06b4a4349450d45dc2",
"created_at": 1686161277,
"kind": 1,
"tags": [
[
"e",
"28c779e9b96a29fd7050dceda73e16e990fc124cd5c52b97bd3876b390f92116",
"",
"root"
],
[
"e",
"11afb3a33b0eacb4e10b08609c0ef5b4377a53d84a428a630e559824fbb2b44a",
"",
"reply"
],
[
"p",
"53e17bca70f12d2a13ad9c9f47ae959ad2630ece06c110c1618d8da1894b7818"
]
],
"content": "📅 Original date posted:2017-11-30\n📝 Original message:Something similar to this has been proposed in this article by Ron Lavi,\nOr Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html\n\nThey only discussed changing the fee structure, not removing the block size\nlimit, as far as I know.\n\n \"Redesigning Bitcoin's fee market\"\n https://arxiv.org/abs/1709.08881\n\n\n\n*Ben Kloester*\n\nOn 30 November 2017 at 11:47, William Morriss via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Comrades,\n\u003e\n\u003e Long term, tx fees must support hash power by themselves. The following is\n\u003e an economic approach to maximize total fee collection, and therefore\n\u003e hashpower.\n\u003e\n\u003e *Goals*\n\u003e Maximize total transaction fees\n\u003e Reduce pending transaction time\n\u003e Reduce individual transaction fees\n\u003e\n\u003e *Challenges*\n\u003e Validators must agree on the maximum block size, else miners can cheat and\n\u003e include extra transactions.\n\u003e Allowing too many transactions per block will increase the cost of the\n\u003e mining without collecting much income for the network.\n\u003e\n\u003e\n\u003e *Problem*\n\u003e In the transaction market, users are the demand curve, because they will\n\u003e transact less when fees are higher, and prefer altcoins. The block size is\n\u003e the supply curve, because it represents miners' willingness to accept\n\u003e transactions.\n\u003e Currently, the supply curve is inelastic:\n\u003e\n\u003e ​Increasing the block size will not affect the inelasticity for any fixed\n\u003e block size. The downsides of a fixed block size limit are well-known:\n\u003e - Unpredictable transaction settlement time\n\u003e - Variable transaction fees depending on network congestion\n\u003e - Frequent overpay\n\u003e\n\u003e *Proposal*\n\u003e 1. Miners implicitly choose the market sat/byte rate with the cheapest-fee\n\u003e transaction included in their block. Excess transaction fees are refunded\n\u003e to the inputs.\n\u003e 2. Remove the block size limit, which is no longer necessary.\n\u003e\n\u003e *Benefits*\n\u003e - Dynamic block size limit regulated by profit motive\n\u003e - Transaction fees maximized for every block\n\u003e - No overpay; all fees are fair\n\u003e\n\u003e ​Miners individually will make decisions to maximize their block-reward\n\u003e profit.\n\u003e Miners are incentivized to ignore low-fee transactions because they would\n\u003e shave the profits of their other transactions and increase their hash time.\n\u003e Users and services are free to bid higher transaction fees in order to\n\u003e reach the next block, since their excess bid will be refunded.\n\u003e\n\u003e The block size limit was added as a spam-prevention measure, but in order\n\u003e for an attacker to spam the network with low-fee transactions, they would\n\u003e have to offset the marginal cost of reducing the price with their own\n\u003e transaction fees. Anti-spam is thus built into the marginal system without\n\u003e the need for an explicit limit.\n\u003e\n\u003e Rarely, sections of the backlog would become large enough to be\n\u003e profitable. This means every so many blocks, lower-fee transactions would\n\u003e be included en masse after having been ignored long enough. Low-fee\n\u003e transactions thus gain a liveness property not previously enjoyed: low-fee\n\u003e transactions will eventually confirm. Miners targeting these transactions\n\u003e would be at a noteworthy disadvantage because they would be hashing a\n\u003e larger block. I predict that this scheme would result in two markets: a\n\u003e backlog market and a real-time market. Users targeting the backlog market\n\u003e would match the price of the largest backlog section in order to be\n\u003e included in the next backlog block.\n\u003e\n\u003e *Examples*\n\u003e\n\u003e Scenario 1\n\u003e Sat/byte Bytes Reward\n\u003e 400 500000 200000000\n\u003e 300 700000 210000000\n\u003e 200 1000000 200000000\n\u003e 100 1500000 150000000\n\u003e 50 5000000 250000000\n\u003e 20 10000000 200000000\n\u003e A miner would create a 5MB block and receive 0.25 BTC\n\u003e\n\u003e Scenario 2\n\u003e Sat/byte Bytes Reward\n\u003e 400 600000 240000000\n\u003e 300 700000 210000000\n\u003e 200 1000000 200000000\n\u003e 100 1800000 180000000\n\u003e 50 4000000 200000000\n\u003e 20 10000000 200000000\n\u003e A miner would create a 600KB block and receive 0.24 BTC\n\u003e\n\u003e Thanks,\n\u003e William Morriss\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: fixedblocksize.png\nType: image/png\nSize: 18199 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0003.png\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: marginal.png\nType: image/png\nSize: 21403 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0004.png\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: fixedblocksize.png\nType: image/png\nSize: 18199 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171130/a56fd415/attachment-0005.png\u003e",
"sig": "c1e4648c0fd0f7ac3753c7b196f015b2c80d216c38260832cf8d9e12cca4147f1ccfe03e33b535e1339acdfa39c5c02af32b7af0829e44e090fd3ac8e2f5b136"
}