Gregory Maxwell [ARCHIVE] on Nostr: đź“… Original date posted:2017-11-30 đź“ť Original message:This idea presumes that ...
đź“… Original date posted:2017-11-30
đź“ť Original message: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 at 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 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/b113f2f5/attachment.html>;
đź“ť Original message: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 at 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 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/b113f2f5/attachment.html>;