path: root/f3/e3b94014360e1b743f3f47c65d49e5a3b38970

Return-Path: <manecosta@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5C820C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 13 Jul 2022 13:29:56 +0000 (UTC)
Received: by mail-wr1-x42f.google.com with SMTP id v16so15488464wrd.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <mailman.82083.1657699581.8511.bitcoin-dev@lists.linuxfoundation.org>
 <CAOU__fz=AiWyOMvbLxpQZTho5QJJCUvwmcVB06gyoEwzy02vdg@mail.gmail.com>
 <CAA3CggEVmx+97TE05Oe3ViFHLC0ejmuRX7L_tMWrRVhYsxaF9w@mail.gmail.com>
In-Reply-To: <CAA3CggEVmx+97TE05Oe3ViFHLC0ejmuRX7L_tMWrRVhYsxaF9w@mail.gmail.com>
From: Manuel Costa <manecosta@gmail.com>
Date: Wed, 13 Jul 2022 14:29:43 +0100
Message-ID: <CAAxiurZhzhPNuysoaByiLCdRpeyxz8S+onnoGTWC+MpanDFB_Q@mail.gmail.com>
To: Gino Pinuto <gino.pinuto@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org>
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

<div dir=3D"ltr"><div dir=3D"ltr">&gt; What about burning all fees and keep=
 a block reward that will smooth out while keeping the ~21M coins limit ?<b=
r><br>This would be a hard fork afaict as it would go against the rules of =
the coinbase transaction following the usual halving schedule.<br><br>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.<br=
><br>Highly inefficient example:<br><br>- Split blocks into 144 (about a da=
y)<br>- 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.<br>- Next day, for each block, we&#39;d have available =
an amount equivalent to the previous day total fees / 144. So we deliver pr=
evious day&#39;s fees smoothed out.</div><div><br>Notes:</div><div>144 is a=
rbitrary in the example.<br>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=
&#39;s a smarter way to do it.<br><br></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">Gino Pinuto via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; escreveu no dia quarta, 13/07/2022 =C3=A0(s) 1=
3:19:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"auto"><div>What about burning all fees and keep a block reward that wil=
l smooth out while keeping the ~21M coins limit ?<div dir=3D"auto"><br></di=
v><div dir=3D"auto">Benefits :</div><div dir=3D"auto">- Miners would still =
be incentivized to collect higher fees transaction with the indirect perspe=
ctive to generate more reward in future.</div><div dir=3D"auto">- Revenues =
are equally distributed over time to all participants and we solve the over=
night discrepancy.</div><div dir=3D"auto">- Increased velocity of money wil=
l reduce the immediate supply of bitcoin cooling down the economy.</div><di=
v dir=3D"auto">- 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.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I don&=
#39;t have ideas yet on how to elegantly implement this.</div><br><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 13 Jul =
2022, 12:08 John Tromp via bitcoin-dev, &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">&gt; The emission curve lasts over 100 years because Bitcoin success =
state requires it to be entrenched globally.<br>
<br>
It effectively doesn&#39;t. The last 100 years from 2040-2140 only emits a<=
br>
pittance of about 0.4 of all bitcoin.<br>
<br>
What matters for proper distribution is the shape of the emission<br>
curve. If you emit 99% in the first year and 1% in the next 100 years,<br>
your emission &quot;lasts&quot; over 100 years, and you achieve a super low=
<br>
supply inflation rate immediately after 1 year, but it&#39;s obviously a<br=
>
terrible form of distribution.<br>
<br>
This is easy to quantify as the expected time of emission which would<br>
be 0.99 * 0.5yr + 0.01* 51yr =3D 2 years.<br>
Bitcoin is not much better in that the expected time of emission of an<br>
bitcoin satisfies x =3D 0.5*2yr + 0.5*(4+x) and thus equals 6 years.<br>
<br>
Monero appears much better since its tail emission yields an infinite<br>
expected time of emission, but if we avoid infinities by looking at<br>
just the soft total emission [1], which is all that is emitted before<br>
a 1% yearly inflation, then Monero is seen to actually be a lot worse<br>
than Bitcoin, due to emitting over 40% in its first year and halving<br>
the reward much faster. Ethereum is much worse still with its huge<br>
premine and PoS coins like Algorand are scraping the bottom with their<br>
expected emission time of 0.<br>
<br>
There&#39;s only one coin whose expected (soft) emission time is larger<br>
than bitcoin&#39;s, and it&#39;s about an order of magnitude larger, at 50<=
br>
years.<br>
<br>
[1] <a href=3D"https://john-tromp.medium.com/a-case-for-using-soft-total-su=
pply-1169a188d153" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a188d153</a><b=
r>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
 target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d4402305e3afc70c--