Manuel Costa [ARCHIVE] on Nostr: š Original date posted:2022-07-13 š Original message:> What about burning all ...
š
Original date posted:2022-07-13
š Original message:> What about burning all fees and keep a block reward that will smooth out
while keeping the ~21M coins limit ?
This would be a hard fork afaict as it would go against the rules of the
coinbase transaction following the usual halving schedule.
However, if instead we added a rule that fees have to be sent to an anyone
can spend output with a timelock we might be able to achieve a similar
thing.
Highly inefficient example:
- Split blocks into 144 (about a day)
- A mined block takes all the fees and distributes them equally into 144
new outputs (anyone can spend) time locked to each of the 144 blocks of the
next day.
- Next day, for each block, we'd have available an amount equivalent to the
previous day total fees / 144. So we deliver previous day's fees smoothed
out.
Notes:
144 is arbitrary in the example.
This specific approach would obviously not work as most of those outputs
would be dust and the miner would need to waste an absurd amount of block
space just to grab them, but maybe there's a smarter way to do it.
Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia quarta, 13/07/2022 Ć (s) 13:19:
> What about burning all fees and keep a block reward that will smooth out
> while keeping the ~21M coins limit ?
>
> Benefits :
> - Miners would still be incentivized to collect higher fees transaction
> with the indirect perspective to generate more reward in future.
> - Revenues are equally distributed over time to all participants and we
> solve the overnight discrepancy.
> - Increased velocity of money will reduce the immediate supply of bitcoin
> cooling down the economy.
> - Reduction of velocity will have an impact on miners only if it persevere
> in the long term but short term they will still perceive the buffered
> reward.
>
> I don't have ideas yet on how to elegantly implement this.
>
>
> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > The emission curve lasts over 100 years because Bitcoin success state
>> requires it to be entrenched globally.
>>
>> It effectively doesn't. The last 100 years from 2040-2140 only emits a
>> pittance of about 0.4 of all bitcoin.
>>
>> What matters for proper distribution is the shape of the emission
>> curve. If you emit 99% in the first year and 1% in the next 100 years,
>> your emission "lasts" over 100 years, and you achieve a super low
>> supply inflation rate immediately after 1 year, but it's obviously a
>> terrible form of distribution.
>>
>> This is easy to quantify as the expected time of emission which would
>> be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
>> Bitcoin is not much better in that the expected time of emission of an
>> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>>
>> Monero appears much better since its tail emission yields an infinite
>> expected time of emission, but if we avoid infinities by looking at
>> just the soft total emission [1], which is all that is emitted before
>> a 1% yearly inflation, then Monero is seen to actually be a lot worse
>> than Bitcoin, due to emitting over 40% in its first year and halving
>> the reward much faster. Ethereum is much worse still with its huge
>> premine and PoS coins like Algorand are scraping the bottom with their
>> expected emission time of 0.
>>
>> There's only one coin whose expected (soft) emission time is larger
>> than bitcoin's, and it's about an order of magnitude larger, at 50
>> years.
>>
>> [1]
>> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20220713/a72fcc5e/attachment-0001.html>;
š Original message:> What about burning all fees and keep a block reward that will smooth out
while keeping the ~21M coins limit ?
This would be a hard fork afaict as it would go against the rules of the
coinbase transaction following the usual halving schedule.
However, if instead we added a rule that fees have to be sent to an anyone
can spend output with a timelock we might be able to achieve a similar
thing.
Highly inefficient example:
- Split blocks into 144 (about a day)
- A mined block takes all the fees and distributes them equally into 144
new outputs (anyone can spend) time locked to each of the 144 blocks of the
next day.
- Next day, for each block, we'd have available an amount equivalent to the
previous day total fees / 144. So we deliver previous day's fees smoothed
out.
Notes:
144 is arbitrary in the example.
This specific approach would obviously not work as most of those outputs
would be dust and the miner would need to waste an absurd amount of block
space just to grab them, but maybe there's a smarter way to do it.
Gino Pinuto via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
escreveu no dia quarta, 13/07/2022 Ć (s) 13:19:
> What about burning all fees and keep a block reward that will smooth out
> while keeping the ~21M coins limit ?
>
> Benefits :
> - Miners would still be incentivized to collect higher fees transaction
> with the indirect perspective to generate more reward in future.
> - Revenues are equally distributed over time to all participants and we
> solve the overnight discrepancy.
> - Increased velocity of money will reduce the immediate supply of bitcoin
> cooling down the economy.
> - Reduction of velocity will have an impact on miners only if it persevere
> in the long term but short term they will still perceive the buffered
> reward.
>
> I don't have ideas yet on how to elegantly implement this.
>
>
> On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> > The emission curve lasts over 100 years because Bitcoin success state
>> requires it to be entrenched globally.
>>
>> It effectively doesn't. The last 100 years from 2040-2140 only emits a
>> pittance of about 0.4 of all bitcoin.
>>
>> What matters for proper distribution is the shape of the emission
>> curve. If you emit 99% in the first year and 1% in the next 100 years,
>> your emission "lasts" over 100 years, and you achieve a super low
>> supply inflation rate immediately after 1 year, but it's obviously a
>> terrible form of distribution.
>>
>> This is easy to quantify as the expected time of emission which would
>> be 0.99 * 0.5yr + 0.01* 51yr = 2 years.
>> Bitcoin is not much better in that the expected time of emission of an
>> bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.
>>
>> Monero appears much better since its tail emission yields an infinite
>> expected time of emission, but if we avoid infinities by looking at
>> just the soft total emission [1], which is all that is emitted before
>> a 1% yearly inflation, then Monero is seen to actually be a lot worse
>> than Bitcoin, due to emitting over 40% in its first year and halving
>> the reward much faster. Ethereum is much worse still with its huge
>> premine and PoS coins like Algorand are scraping the bottom with their
>> expected emission time of 0.
>>
>> There's only one coin whose expected (soft) emission time is larger
>> than bitcoin's, and it's about an order of magnitude larger, at 50
>> years.
>>
>> [1]
>> https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20220713/a72fcc5e/attachment-0001.html>;