MIME-Version: 1.0
References: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
 <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
In-Reply-To: <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
From: Giuseppe B <beppeben2030@gmail.com>
Date: Thu, 7 Jul 2022 16:10:31 +0200
Message-ID: <CABrXkXrRX5Zd01ikWOcmxEwXdw4k10WfspOhOu8xKi_JU23Q0A@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="000000000000a9cde405e337a6d0"
Cc: "Corey Haddad <corey3@gmail.com>,
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Precedence: list

--000000000000a9cde405e337a6d0
Content-Type: text/plain; charset="UTF-8"

It's the first time I read about the security budget and it definitely
sounds scary to me.
If it only takes a few million dollars to attack BTC and make it completely
unusable for one day, I suppose it's only a matter of time before some
hedge fund actually does it, using a short position to profit from the huge
panic sell wave and global loss of confidence that would result from it.
It seems even cheaper to do than the recent attack to Terra, unless I'm
missing something.


On Wed, Jul 6, 2022, 1:10 PM <vjudeu@gazeta.pl> wrote:

> > If the only realistic (fair, efficient & proportionate) way to pay for
> Bitcoin's security was by having some inflation scheme that violated the 21
> million cap, then agreeing to break the limit would probably be what makes
> sense, and in the economic interest of its users and holders.
>
> So, Paul Sztorc was right again, there are three options: Enormous Block
> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come
> From Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png.
> And I think using Merged Mining is the best option. More about that:
> https://www.truthcoin.info/blog/security-budget-ii-mm/
>
> > Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient.
>
> Yes, that's also possible, RSK uses that. And making some kind of
> soft-fork for that is also possible, but I don't know if miners will agree
> to send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY
> OP_DROP OP_TRUE".
>
> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Bitcoin's finite supply is the main argument for people investing in it,
> the whole narrative around bitcoin is based on its finite supply. While it
> has its flaws and basically condemns bitcoin to be only used as a store >of
> value (and not as a currency), I don't think it's worth questioning it at
> this point.
> >
> >Just my 2 sats.
> >
> >Giuseppe.
>
>
> A finite supply alone is not enough to give something value, as it must
> also be useful in some way. In the case of Bitcoin, various forms of
> cryptographic security must all work - and work together - to make Bitcoin
> useful. If the only realistic (fair, efficient & proportionate) way to pay
> for Bitcoin's security was by having some inflation scheme that violated
> the 21 million cap, then agreeing to break the limit would probably be what
> makes sense, and in the economic interest of its users and holders.
>
> There will always be competitive pressures with respect to efficiency, and
> both being over-secured and under-secured would be economically inefficient
> for a crypto currency, and thereby laving room for a more optimally-secured
> competitor to gain ground. Currently there is zero feedback in the Bitcoin
> system between what we might think is the optimum amount of security and
> what actually exists. There is also zero agreement on how much security
> would constitute such an optimum. Figuring out how much security is needed,
> or even better, figuring out a way to have a market mechanism to answer
> that question, will be an important project.
>
> Another option, if we were to decide we are over-secured in the short
> term, would be to soft-fork in a reduction in the current and near-future
> mining rewards, by somehow locking the coins in a contract that deprived
> the miner of the full reward, and then using that contract to pay the
> rewards out far in the future, should at some point we feel the security
> budget was insufficient. Anthony Towns presented a form of this concept in
> greater detail at a Scaling Bitcoin conference some years ago. While this
> solution, if employed, would only work for some finite amount of time, it
> is possible that could give additional decades before the accumulated
> security budget was exhausted.
>
>
> Corey
>

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

<div dir=3D"auto"><div dir=3D"auto">It&#39;s the first time I read about th=
e security budget and it definitely sounds scary to me.</div><div dir=3D"au=
to">If it only takes a few million dollars to attack BTC and make it comple=
tely unusable for one day, I suppose it&#39;s only a matter of time before =
some hedge fund actually does it, using a short position to profit from the=
 huge panic sell wave and global loss of confidence that would result from =
it.=C2=A0</div><div dir=3D"auto">It seems even cheaper to do than the recen=
t attack to Terra, unless I&#39;m missing something.=C2=A0</div><div><br><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, =
Jul 6, 2022, 1:10 PM  &lt;<a href=3D"mailto:vjudeu@gazeta.pl">vjudeu@gazeta=
.pl</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; If the only=
 realistic (fair, efficient &amp; proportionate) way to pay for Bitcoin&#39=
;s security was by having some inflation scheme that violated the 21 millio=
n cap, then agreeing to break the limit would probably be what makes sense,=
 and in the economic interest of its users and holders.<br>
<br>
So, Paul Sztorc was right again, there are three options: Enormous Block Si=
ze Increases, Violate 21M Coin Limit, or &gt;50% Miner Fee-Revenues Come Fr=
om Merged Mining: <a href=3D"https://www.truthcoin.info/images/sb-trilemma.=
png" rel=3D"noreferrer noreferrer" target=3D"_blank">https://www.truthcoin.=
info/images/sb-trilemma.png</a>. And I think using Merged Mining is the bes=
t option. More about that: <a href=3D"https://www.truthcoin.info/blog/secur=
ity-budget-ii-mm/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://=
www.truthcoin.info/blog/security-budget-ii-mm/</a><br>
<br>
&gt; Another option, if we were to decide we are over-secured in the short =
term, would be to soft-fork in a reduction in the current and near-future m=
ining rewards, by somehow locking the coins in a contract that deprived the=
 miner of the full reward, and then using that contract to pay the rewards =
out far in the future, should at some point we feel the security budget was=
 insufficient.<br>
<br>
Yes, that&#39;s also possible, RSK uses that. And making some kind of soft-=
fork for that is also possible, but I don&#39;t know if miners will agree t=
o send some coinbase reward to &quot;&lt;futureBlockNumber&gt; OP_CHECKLOCK=
TIMEVERIFY OP_DROP OP_TRUE&quot;.<br>
<br>
On 2022-07-06 06:29:18 user Corey Haddad 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;Bitcoin&#39;s finite supply is the main argument for people investing i=
n it, the whole narrative around bitcoin is based on its finite supply. Whi=
le it has its flaws and basically condemns bitcoin to be only used as a sto=
re &gt;of value (and not as a currency), I don&#39;t think it&#39;s worth q=
uestioning it at this point.=C2=A0<br>
&gt;<br>
&gt;Just my 2 sats.=C2=A0<br>
&gt;<br>
&gt;Giuseppe.=C2=A0<br>
<br>
<br>
A finite=C2=A0supply alone is not enough to give something value, as it mus=
t also be useful in some way. In the case of Bitcoin, various=C2=A0forms of=
 cryptographic=C2=A0security=C2=A0must all work - and work together - to ma=
ke Bitcoin useful. If the only realistic (fair, efficient &amp; proportiona=
te) way to pay for Bitcoin&#39;s security=C2=A0was by having some inflation=
 scheme=C2=A0that violated the 21 million cap, then agreeing to break the l=
imit would probably be what makes sense, and in the economic interest of it=
s users and holders.<br>
<br>
There will always be competitive=C2=A0pressures with respect to efficiency,=
 and both being over-secured and under-secured would be economically ineffi=
cient for a crypto currency, and thereby laving room for a more optimally-s=
ecured competitor to gain ground. Currently there is zero feedback in the B=
itcoin system between what we might think is the optimum amount of security=
 and what actually exists. There is also zero agreement on how much securit=
y would constitute such an optimum. Figuring out how much security is neede=
d, or even better, figuring out a way to have a market mechanism to answer =
that question, will be an important project.<br>
<br>
Another option, if we were to decide we are over-secured in the short term,=
 would be to soft-fork in a reduction in the current and near-future mining=
 rewards, by somehow locking the coins in a contract that deprived the mine=
r of the full reward, and then using that contract to pay the rewards out f=
ar in the future, should at some point we feel the security budget was insu=
fficient. Anthony Towns presented a form of this concept in greater detail =
at a Scaling Bitcoin conference some years ago. While this solution, if emp=
loyed, would only work for some finite amount of time, it is possible that =
could give additional decades before the accumulated security budget was ex=
hausted.=C2=A0<br>
<br>
<br>
Corey<br>
</blockquote></div></div></div>

--000000000000a9cde405e337a6d0--