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"
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
 fees for security
Precedence: list

--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--