Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5C820C002D for ; Wed, 13 Jul 2022 13:29:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 29F2C82CA3 for ; Wed, 13 Jul 2022 13:29:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 29F2C82CA3 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=QU4+XF16 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQYpm__DK1xE for ; Wed, 13 Jul 2022 13:29:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C6BBC82C84 Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) by smtp1.osuosl.org (Postfix) with ESMTPS id C6BBC82C84 for ; Wed, 13 Jul 2022 13:29:56 +0000 (UTC) Received: by mail-wr1-x42f.google.com with SMTP id v16so15488464wrd.13 for ; Wed, 13 Jul 2022 06:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2HmPnY2FoNQgAQ9mctkrSfFeTIZ0hMtRPl+4KY1FhOw=; b=QU4+XF16cjAKndlMesgzESNAvIzW0r5L9jDV3Z8oRiIfPmB5SxF/VF+Hg8HokgHOOl wFenDP42q7hByRCDfpxCTSxaFBO3a3m0q3RBS7IDbfBZ8dzp2ToKBhYK6Op1L5K0ya9t jT9KOZiEpfKG7w/yw7lxA0oHvbpwuXI7dJfM3DPb/5/x3kKOFRR9UauJY8fBstGLHfvt Rjofgpwf6q6mgw0AP/2MNQltrKh6khwuRSHWnolbkMQ6uC+2NMr3Ef5PDUB/ynLb0Ln4 lXtzZ156J2+Q3ADAgMKBBVxVi2lCWbQVyJYOBxKCVxQcnLOYc4WPD3Z9gYc/6O71jJ9V U+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2HmPnY2FoNQgAQ9mctkrSfFeTIZ0hMtRPl+4KY1FhOw=; b=U06WcswdYTqB1i8mPdIJjWKQksnMCbcJ4oSHXmeEVNIudtstrQeMfa+5o3d2KwZKNS pkDV2iJDtLPVLpyfplI5SGtZi8z5mjo/ZjcAHfNG+Z/7E/YLN96GWWdLg6WG95bNwJ4q hX39UBPz7tsOLdlcYc2Zd8ZZz1fH6dOoZ5plZOg28Vb7JvKu/BP+bLY7eHKXtsX51wek U/W9SW9yg43hEsGBhpQXo/d6/9aIN5ET4ViJVklpYI8/hILRzHuxwy4ATEaxy0Hy93aj GzCsguIf1t4n8VKgy3pjPkKDqeiTFYQ6ybWgh/eOp1t6uFML/FOz5+YfGX4nOSYvcQjC rnTg== X-Gm-Message-State: AJIora/hOPXqGNQYkWAaqJOa9/bomHVPx9jfIjgeyAQMcqlaKrICVgQD CBOOofwOU+NKpPdqDS33s0p5I2AmktnKSRC6KnGApZlLtCY= X-Google-Smtp-Source: AGRyM1s5+ug1+nbzZbETPd5r+GGDm/1MDEPELh5jPS6hO8sm0p0vZ4PDPr85XP2HbwQDM003WdxJXxMJr4TshT3VRtU= X-Received: by 2002:a05:6000:1cc:b0:21d:a352:116b with SMTP id t12-20020a05600001cc00b0021da352116bmr3194575wrx.418.1657718994909; Wed, 13 Jul 2022 06:29:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Manuel Costa Date: Wed, 13 Jul 2022 14:29:43 +0100 Message-ID: To: Gino Pinuto , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000d4402305e3afc70c" X-Mailman-Approved-At: Wed, 13 Jul 2022 18:01:25 +0000 Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2022 13:29:58 -0000 --000000000000d4402305e3afc70c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 escreveu no dia quarta, 13/07/2022 =C3=A0(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 persever= e > 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@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 =3D 2 years. >> Bitcoin is not much better in that the expected time of emission of an >> bitcoin satisfies x =3D 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-1169a18= 8d153 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000d4402305e3afc70c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 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.

Howev= er, if instead we added a rule that fees have to be sent to an anyone can s= pend output with a timelock we might be able to achieve a similar thing.
Highly inefficient example:

- Split blocks into 144 (about a da= y)
- A mined block takes all the fees and distributes them equally into = 144 new outputs (anyone can spend) time locked=C2=A0to each of the 144 bloc= ks 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 pr= evious day's fees smoothed out.

Notes:
144 is a= rbitrary in the example.
This specific approach would obviously not work= as=C2=A0most of those outputs would be dust and the miner would need to wa= ste an absurd=C2=A0amount of block space just to grab them, but maybe there= 's a smarter way to do it.


Gino Pinuto via bitcoin-dev <= ;bitcoin-dev@lists= .linuxfoundation.org> escreveu no dia quarta, 13/07/2022 =C3=A0(s) 1= 3:19:
What about burning all fees and keep a block reward that wil= l smooth out while keeping the ~21M coins limit ?

Benefits :
- Miners would still = be incentivized to collect higher fees transaction with the indirect perspe= ctive to generate more reward in future.
- Revenues = are equally distributed over time to all participants and we solve the over= night discrepancy.
- Increased velocity of money wil= l reduce the immediate supply of bitcoin cooling down the economy.
- Reduction of velocity will have an impact on miners only i= f it persevere in the long term but short term they will still perceive the= buffered reward.

I don&= #39;t have ideas yet on how to elegantly implement this.


On Wed, 13 Jul = 2022, 12:08 John Tromp via bitcoin-dev, <bitcoin-dev@lists.linuxfoundati= on.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<= br> 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 =3D 2 years.
Bitcoin is not much better in that the expected time of emission of an
bitcoin satisfies x =3D 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<= br> years.

[1] https://= john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153 _______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000d4402305e3afc70c--