📅 Original date posted:2022-07-14
📝 Original message:Fees and miner rewards are not needed at all for security at all since long
term holders can simply invest in mining to secure the value of their stake.
Isn't it enough that the protocol has a mechanism to secure value?
Sure fees *might* be enough.
But in the event that they are not, large holders can burn a bit to make
sure the hashrate stays high.
I know, I know it's a tax on the rich and it's not fair because smaller
holders are less likely to do it, but it's a miniscule tax even in the
worst case
On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 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.
>
> There is a smarter way. Just send 0.01 BTC per block to the timelocked
> outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that
> percentage will grow over time, as basic block reward will shrink, and we
> will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess
> what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it
> simply means you can lock 2,100 BTC in an endless circulation loop, and
> avoid this "tail supply attack".
>
> So, fortunately, even if "tail supply attackers" will win, we will still
> have a chance to counter-attack by burning those coins, or (even better) by
> locking them in an endless circulation loop, just to satisfy their
> malicious soft-fork, whatever amount it will require. Because even if it
> will be mandatory to timelock 0.01 BTC to the current block number plus
> 210,000, then it is still perfectly valid to move that amount endlessly,
> without taking it, just to resist this "tail supply attack".
>
>
> On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> > 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
>
> _______________________________________________
> 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/20220714/75951273/attachment-0001.html>;
Erik Aronesty [ARCHIVE] /
npub1y2…5taj0
2023-06-07 23:11:49
in reply to nevent1q…yujz
Author Public Key
npub1y22yec0znyzw8qndy5qn5c2wgejkj0k9zsqra7kvrd6cd6896z4qm5taj0Published at
2023-06-07 23:11:49Event JSON
{
"id": "c1b6f81bc47ceb0a975e34f42bd92051bb682a15f435eb72d61bd2790b987444",
"pubkey": "22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa",
"created_at": 1686179509,
"kind": 1,
"tags": [
[
"e",
"7243614b5a040fbb87601bd8f41b59830667774e947157f62a858774b716e8e6",
"",
"root"
],
[
"e",
"047e09b3943235d99aac0e94500af461c40b74af22923316d6173a41ca459031",
"",
"reply"
],
[
"p",
"8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32"
]
],
"content": "📅 Original date posted:2022-07-14\n📝 Original message:Fees and miner rewards are not needed at all for security at all since long\nterm holders can simply invest in mining to secure the value of their stake.\n\nIsn't it enough that the protocol has a mechanism to secure value?\n\nSure fees *might* be enough.\n\nBut in the event that they are not, large holders can burn a bit to make\nsure the hashrate stays high.\n\nI know, I know it's a tax on the rich and it's not fair because smaller\nholders are less likely to do it, but it's a miniscule tax even in the\nworst case\n\n\n\n\n\n\n\n\n\nOn Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e This specific approach would obviously not work as most of those outputs\n\u003e would be dust and the miner would need to waste an absurd amount of block\n\u003e space just to grab them, but maybe there's a smarter way to do it.\n\u003e\n\u003e There is a smarter way. Just send 0.01 BTC per block to the timelocked\n\u003e outputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that\n\u003e percentage will grow over time, as basic block reward will shrink, and we\n\u003e will have mandatory 0.01 BTC endlessly moved, until it will wrap. And guess\n\u003e what: if it will be 0.01 BTC per block, wrapped every 210,000 blocks, it\n\u003e simply means you can lock 2,100 BTC in an endless circulation loop, and\n\u003e avoid this \"tail supply attack\".\n\u003e\n\u003e So, fortunately, even if \"tail supply attackers\" will win, we will still\n\u003e have a chance to counter-attack by burning those coins, or (even better) by\n\u003e locking them in an endless circulation loop, just to satisfy their\n\u003e malicious soft-fork, whatever amount it will require. Because even if it\n\u003e will be mandatory to timelock 0.01 BTC to the current block number plus\n\u003e 210,000, then it is still perfectly valid to move that amount endlessly,\n\u003e without taking it, just to resist this \"tail supply attack\".\n\u003e\n\u003e\n\u003e On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e What about burning all fees and keep a block reward that will smooth out\n\u003e while keeping the ~21M coins limit ?\n\u003e\n\u003e This would be a hard fork afaict as it would go against the rules of the\n\u003e coinbase transaction following the usual halving schedule.\n\u003e\n\u003e However, if instead we added a rule that fees have to be sent to an anyone\n\u003e can spend output with a timelock we might be able to achieve a similar\n\u003e thing.\n\u003e\n\u003e Highly inefficient example:\n\u003e\n\u003e - Split blocks into 144 (about a day)\n\u003e - A mined block takes all the fees and distributes them equally into 144\n\u003e new outputs (anyone can spend) time locked to each of the 144 blocks of the\n\u003e next day.\n\u003e - Next day, for each block, we'd have available an amount equivalent to\n\u003e the previous day total fees / 144. So we deliver previous day's fees\n\u003e smoothed out.\n\u003e\n\u003e Notes:\n\u003e 144 is arbitrary in the example.\n\u003e This specific approach would obviously not work as most of those outputs\n\u003e would be dust and the miner would need to waste an absurd amount of block\n\u003e space just to grab them, but maybe there's a smarter way to do it.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Gino Pinuto via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e escreveu no dia quarta, 13/07/2022 à(s) 13:19:\n\u003e What about burning all fees and keep a block reward that will smooth out\n\u003e while keeping the ~21M coins limit ?\n\u003e\n\u003e\n\u003e Benefits :\n\u003e - Miners would still be incentivized to collect higher fees transaction\n\u003e with the indirect perspective to generate more reward in future.\n\u003e - Revenues are equally distributed over time to all participants and we\n\u003e solve the overnight discrepancy.\n\u003e - Increased velocity of money will reduce the immediate supply of bitcoin\n\u003e cooling down the economy.\n\u003e - Reduction of velocity will have an impact on miners only if it persevere\n\u003e in the long term but short term they will still perceive the buffered\n\u003e reward.\n\u003e\n\u003e\n\u003e I don't have ideas yet on how to elegantly implement this.\n\u003e\n\u003e\n\u003e\n\u003e On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e The emission curve lasts over 100 years because Bitcoin success state\n\u003e requires it to be entrenched globally.\n\u003e\n\u003e It effectively doesn't. The last 100 years from 2040-2140 only emits a\n\u003e pittance of about 0.4 of all bitcoin.\n\u003e\n\u003e What matters for proper distribution is the shape of the emission\n\u003e curve. If you emit 99% in the first year and 1% in the next 100 years,\n\u003e your emission \"lasts\" over 100 years, and you achieve a super low\n\u003e supply inflation rate immediately after 1 year, but it's obviously a\n\u003e terrible form of distribution.\n\u003e\n\u003e This is easy to quantify as the expected time of emission which would\n\u003e be 0.99 * 0.5yr + 0.01* 51yr = 2 years.\n\u003e Bitcoin is not much better in that the expected time of emission of an\n\u003e bitcoin satisfies x = 0.5*2yr + 0.5*(4+x) and thus equals 6 years.\n\u003e\n\u003e Monero appears much better since its tail emission yields an infinite\n\u003e expected time of emission, but if we avoid infinities by looking at\n\u003e just the soft total emission [1], which is all that is emitted before\n\u003e a 1% yearly inflation, then Monero is seen to actually be a lot worse\n\u003e than Bitcoin, due to emitting over 40% in its first year and halving\n\u003e the reward much faster. Ethereum is much worse still with its huge\n\u003e premine and PoS coins like Algorand are scraping the bottom with their\n\u003e expected emission time of 0.\n\u003e\n\u003e There's only one coin whose expected (soft) emission time is larger\n\u003e than bitcoin's, and it's about an order of magnitude larger, at 50\n\u003e years.\n\u003e\n\u003e [1]\n\u003e https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153\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\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\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220714/75951273/attachment-0001.html\u003e",
"sig": "3bb3cf735aeb827babf98bbef50ceb1e597c2dd50261554265340238a664e325bed0ccd73534bdee51c90a71b2b1715675f2013b7396a28768024045b9f76455"
}