path: root/0c/777053eaa330feaef3f612e008959c0faadb3e

Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 093A7C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:57:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id DFDE740112
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:57:58 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DFDE740112
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
 header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
 header.s=20210112 header.b=2i+p3PHe
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id GGWp2EqQf3ne
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:57:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1173440B57
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com
 [IPv6:2a00:1450:4864:20::234])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 1173440B57
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 09:57:56 +0000 (UTC)
Received: by mail-lj1-x234.google.com with SMTP id 19so1557440ljz.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 14 Jul 2022 02:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20210112.gappssmtp.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=hIIWBPUWULjy6Iuh5oXCz2a0e//RuyPSeOJs6S+BjBk=;
 b=2i+p3PHeqclSqUP18rGSy5fzSFu+CcPVxg0PVWLHedsZy38OZVleV9WcoOnSYqPYa7
 jxeZP3x5rO9F1+dujRybkWEqFCWjPW6M/0urtjKAvAGZSFNT5gUWlHq+pM5LlKq4YjKV
 y2NxgRpnoaKpv2O7Cf9teBFMV1GhM3zWFrp9cTrSk4ofHLk9sUpOctFLRhAejglTCZQZ
 c1nrtoPk0QHNium7kf9/MNfiXnK3awKCtsnGm+l6tUBCj+rK+mpa+T1QgPLNb4EvVW6a
 /oR5VgzzycHPZHu2sEjApK2VFMMZPdUyhW963j+Q01ePBmHUcoac6GsnhNhEyB4IFW2J
 uKLA==
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=hIIWBPUWULjy6Iuh5oXCz2a0e//RuyPSeOJs6S+BjBk=;
 b=sOgmaAiAosFplkwF719TGMWPRMjUyNkWXp/XAZJhR828uAqYfT4FC2DFCu6YVxNQCm
 C2D0cv+qq/0l3i5MjckSK4cMPDMO3AyjdSet2aAI79DKYIdKKhKoZeCZZksi02sAKMry
 r1zJYH1Tf1b1Y7UZYvCotQHyKxY/MRu+DxZUnQyfEkVsb1PBJsJfDBdbfXbHDd0AaK+J
 /vtMnsmTg12oGKUx7/Me0UpI9rKrqG8K3e7gEJ1wRx8a4TaZeTufMBbchC8E5a+SZnnN
 IDZ5aix3xailYu4omI6rmzvHUnfpV7FJXUOZQKTscpsNgHd4Uybz7XDnewpsIYllkdIl
 RjMQ==
X-Gm-Message-State: AJIora9F5SpveFZOA0FcmODVthSMh8ROSuo4kn0KHe622/Oi7x+HV1II
 xAvtn7iZpP6jAx/1eWpMyI5ugQCIaAt62xDRiu42MRn+n9/0
X-Google-Smtp-Source: AGRyM1tYUp73rZ5o7tVX1zEulauzmMM/Sc2WDl3qXh3Lr7Kdnm4qs1bemYMmgMYwNXxGLkjTmfZThupPB8HatgscNFU=
X-Received: by 2002:a2e:980e:0:b0:25d:53f0:642c with SMTP id
 a14-20020a2e980e000000b0025d53f0642cmr4107395ljj.405.1657792674567; Thu, 14
 Jul 2022 02:57:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAAxiurZhzhPNuysoaByiLCdRpeyxz8S+onnoGTWC+MpanDFB_Q@mail.gmail.com>
 <164548764-bff50cb79078c9964aa8ac1e51c13070@pmq5v.m5r2.onet>
In-Reply-To: <164548764-bff50cb79078c9964aa8ac1e51c13070@pmq5v.m5r2.onet>
From: Erik Aronesty <erik@q32.com>
Date: Thu, 14 Jul 2022 05:57:41 -0400
Message-ID: <CAJowKgL3eg9aRxkbLiVUyMoMapFUnSBMpA1mnrxB=3fx1fsu0w@mail.gmail.com>
To: vjudeu <vjudeu@gazeta.pl>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007a9a6105e3c0efac"
X-Mailman-Approved-At: Thu, 14 Jul 2022 10:52:13 +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: Thu, 14 Jul 2022 09:57:59 -0000

--0000000000007a9a6105e3c0efac
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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@lists.linuxfoundation.org> wrote:

> > This specific approach would obviously not work as most of those output=
s
> 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 gue=
ss
> 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@lists.linuxfoundation.org> wrote:
> > What about burning all fees and keep a block reward that will smooth ou=
t
> 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 anyon=
e
> 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 t=
he
> 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-1169a188=
d153
> _______________________________________________
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000007a9a6105e3c0efac
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">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 v=
alue of their stake.<div dir=3D"auto"><br></div><div dir=3D"auto">Isn&#39;t=
 it enough that the protocol has a mechanism to secure value?</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Sure fees *might* be enough.=C2=A0=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">But in the event tha=
t they are not, large holders can burn a bit to make sure the hashrate stay=
s high.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I know, I know i=
t&#39;s a tax on the rich and it&#39;s not fair because smaller holders are=
 less likely to do it, but it&#39;s a miniscule tax even in the worst case<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><br><div dir=3D"auto"><br></div></=
div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_at=
tr">On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; This spec=
ific approach would obviously not work as most of those outputs would be du=
st and the miner would need to waste an absurd amount of block space just t=
o grab them, but maybe there&#39;s a smarter way to do it.<br>
<br>
There is a smarter way. Just send 0.01 BTC per block to the timelocked outp=
uts. 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 m=
andatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if i=
t 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 &quo=
t;tail supply attack&quot;.<br>
<br>
So, fortunately, even if &quot;tail supply attackers&quot; will win, we wil=
l still have a chance to counter-attack by burning those coins, or (even be=
tter) by locking them in an endless circulation loop, just to satisfy their=
 malicious soft-fork, whatever amount it will require. Because even if it w=
ill 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, withou=
t taking it, just to resist this &quot;tail supply attack&quot;.<br>
<br>
<br>
On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer=
rer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; What about burning all fees and keep a block reward that will smooth o=
ut while keeping the ~21M coins limit ?<br>
<br>
This would be a hard fork afaict as it would go against the rules of the co=
inbase transaction following the usual halving schedule.<br>
<br>
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 thin=
g.<br>
<br>
Highly inefficient example:<br>
<br>
- Split blocks into 144 (about a day)<br>
- A mined block takes all the fees and distributes them equally into 144 ne=
w outputs (anyone can spend) time locked=C2=A0to each of the 144 blocks 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 previous day&#39;s fees s=
moothed out.<br>
<br>
Notes:<br>
144 is arbitrary in the example.<br>
This specific approach would obviously not work as=C2=A0most of those outpu=
ts would be dust and the miner would need to waste an absurd=C2=A0amount of=
 block space just to grab them, but maybe there&#39;s a smarter way to do i=
t.<br>
<br>
<br>
<br>
<br>
Gino Pinuto via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxf=
oundation.org</a>&gt; escreveu no dia quarta, 13/07/2022 =C3=A0(s) 13:19:<b=
r>
What about burning all fees and keep a block reward that will smooth out wh=
ile keeping the ~21M coins limit ?<br>
<br>
<br>
Benefits :<br>
- Miners would still be incentivized to collect higher fees transaction wit=
h the indirect perspective to generate more reward in future.<br>
- Revenues are equally distributed over time to all participants and we sol=
ve the overnight discrepancy.<br>
- Increased velocity of money will reduce the immediate supply of bitcoin c=
ooling down the economy.<br>
- 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 rewar=
d.<br>
<br>
<br>
I don&#39;t have ideas yet on how to elegantly implement this.<br>
<br>
<br>
<br>
On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, &lt;<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferre=
r">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&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" target=3D"_blank" =
rel=3D"noreferrer">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>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>

--0000000000007a9a6105e3c0efac--