path: root/f6/e42f8cb40f281fa693f9c5c6c5d459563e06ca

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D83F6C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 05:04:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id AA0E9423D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 05:04:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AA0E9423D3
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=Fv7JAxhG
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MONEY_PERCENT=0.01]
 autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Sg7FmErlcwop
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 05:03:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 532CC423D0
Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com
 [IPv6:2607:f8b0:4864:20::934])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 532CC423D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  8 Jul 2022 05:03:57 +0000 (UTC)
Received: by mail-ua1-x934.google.com with SMTP id f10so2397259uam.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 07 Jul 2022 22:03:57 -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
 :cc; bh=j1w5JZHrt35uAaCwl/IAeduzYdFCqJoN0TSKSsddqXs=;
 b=Fv7JAxhGvC6aRVGkOVgbG9idO1eWNxmDNNU1YoMDJFMPBZR0BRCk7Nzd+bdJxlfyTk
 gyQUPBKGvDBEyMT1jy/kmuYdVBlCe1U72ljXHfDBMoy6oXLcvvjIEf4Mdq82g3SXSwiD
 iSCgNLqh4SRu6O8jN6vX2oGZwbmzw8WKPveuML1lRhUd7Ua+4kqPtajMaSNLtx1JUns3
 Qe8BVahSTqkGOCedhAlRjeVU6lQLdJaztgZyItezW0cbnwEoQWrbTR7uRhvTEWWDrKKe
 FHAOTZYQZIXkLXIiBeVzRcLgIb5WHYinsISGvx2XumZsm7i9dGu2Oavez7rBMriezIO0
 RAFA==
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:cc;
 bh=j1w5JZHrt35uAaCwl/IAeduzYdFCqJoN0TSKSsddqXs=;
 b=4vq1yRX/HYVTeF08J+5lpvUH5zwzuVjs6ldyBo9xT4WxpiK7kMKafuTVfJAfnGbUdI
 93gddejzJMkWVfaMoh6VeJkwUp6UMlW7XyhM+4VbgiRx+NV1UEDtEbKtDJ5fVFnh0yI9
 LAsHFZX8N7+B4GZHNZzMlqVluzbGESBKjroausipt7DugbMES0mdt2+iiT7pzaA0dF+0
 TB64tP2leTvd2775pxQU8AlBF03ixKIH40WwHW4opWsQm3Cuq4tWTEynYu/ejqIhiHq9
 9gR2oqHUCktjQaaESsqloQeJVgdoHOMltAGsuioUPBKVGcYCgjyYmyJg0yH5Mqj1Qqv3
 7sxQ==
X-Gm-Message-State: AJIora9gypcsr5wwdPuLR17aIw7cbADU7DFLLP+MlLzq4xiLq1P7cBPD
 SIE29dv5uv246ZEJaPVCo94d3HR2NsiaaZ38G94=
X-Google-Smtp-Source: AGRyM1ubohjNV2HD32dGu/TMX1NbmPzCky1r24B8bsQaR0UtUMku4CiS1Q1ZTgGUAa15JEwfY/0XQGR5BLYXcveC/6Y=
X-Received: by 2002:ab0:487:0:b0:379:6745:cd1f with SMTP id
 7-20020ab00487000000b003796745cd1fmr552313uaw.67.1657256636010; Thu, 07 Jul
 2022 22:03:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
 <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
 <CABrXkXrRX5Zd01ikWOcmxEwXdw4k10WfspOhOu8xKi_JU23Q0A@mail.gmail.com>
In-Reply-To: <CABrXkXrRX5Zd01ikWOcmxEwXdw4k10WfspOhOu8xKi_JU23Q0A@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 8 Jul 2022 00:03:40 -0500
Message-ID: <CAGpPWDZqB6323_FUsAGCq1rNw5SuY3Re3qhsjAjea3vaYLQ-cA@mail.gmail.com>
To: Giuseppe B <beppeben2030@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000001757aa05e34421b9"
X-Mailman-Approved-At: Fri, 08 Jul 2022 08:48:24 +0000
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
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: Fri, 08 Jul 2022 05:04:01 -0000

--0000000000001757aa05e34421b9
Content-Type: text/plain; charset="UTF-8"

@vjudeu
> better to allow transaction joining.. to make fees more smoothly

I'm not familiar with RSK transaction joining. However, I don't think this
addresses the issues Corey brought up - which is that the
appropriate amount of security (ie miner revenue) isn't linked with any
bitcoin market behavior. It sounds like you're suggesting something that
could smooth out the fee market and potentially lower fees, however it
doesn't sound like a mechanism that could be used to target a particular
security level.

>  I think the market should adjust fees, and finding the right balance
between on-chain and off-chain should be left to the users, just by
providing them options like transaction joining

The market has an incentive to minimize fees. So I don't see how this would
be sufficient if it ends up that miner revenue from fees is too low.

@Erik
> I think perhaps you're  underestimating the degree to which utility can
be added to the main chain to encourage fees.

It seems you've misinterpreted me to be saying that fees will be too low. I
have no idea if fees will be too low or not. And you might be right that
fees are likely to remain high enough. However, fees might also remain *too
high* which itself could be a problem. As I noted above, since market
forces all incentivize driving fees down, what do we do if that force
drives it below a sufficient level? How will we know when that happens
until we know what the sufficient level of security is (eg in terms of
total miner revenue).

@Guiseppe
> If it only takes a few million dollars to attack BTC and make it
completely unusable for one day

It would take much more than a few million to 51% attack bitcoin. Bitcoin's
blockchain security is primarily based on the capital cost of buying up a
massive amount of hashpower. The ongoing maintenance and electricity costs
of mining are actually not very relevant to security because all those
ongoing costs are directly offset by mining revenues. Its the upfront costs
that serve as the primary barrier an attacker must surpass. Acquiring the
mining hardware, finding places where energy costs are low enough, setting
up the equipment, etc. To do that costs billions of dollars, not millions.


On Thu, Jul 7, 2022 at 9:44 AM Giuseppe B via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr">@<span style=3D"color:rgb(32,33,36);font-size:0.875rem;let=
ter-spacing:0.2px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif=
;white-space:nowrap">vjudeu</span><div>&gt; better to allow transaction joi=
ning.. to make fees more smoothly</div><div><br></div><div>I&#39;m not fami=
liar with RSK transaction=C2=A0joining. However, I don&#39;t think this add=
resses the issues Corey brought up - which is that the appropriate=C2=A0amo=
unt of security (ie miner revenue) isn&#39;t linked with any bitcoin market=
 behavior. It sounds like you&#39;re suggesting something that could smooth=
 out the fee market and potentially lower fees, however it doesn&#39;t soun=
d like a mechanism that could be used to target a particular security level=
.</div><div><br></div><div>&gt;=C2=A0 I think the market should adjust fees=
, and finding the right balance between on-chain and off-chain should be le=
ft to the users, just by providing them options like transaction joining</d=
iv><div><br></div><div>The market has an incentive to minimize fees. So I d=
on&#39;t see how this would be sufficient if it ends up that miner revenue =
from fees is too low.=C2=A0</div><div><br></div><div>@Erik<br></div><div>&g=
t; I think perhaps you&#39;re=C2=A0 underestimating the degree to which uti=
lity can be added to the main chain to encourage fees.</div><div><br></div>=
<div>It seems you&#39;ve misinterpreted me to be saying that fees will be t=
oo low. I have no idea if fees will be too low or not. And you might be rig=
ht that fees are likely to remain high enough. However, fees might also rem=
ain *too high* which itself could be a problem. As I noted above, since mar=
ket forces all incentivize driving fees down, what do we do if that force d=
rives it below a sufficient level? How will we know when that happens until=
 we know what the sufficient level of security is (eg in terms of total min=
er revenue).</div><div><br></div><div>@Guiseppe<br></div><div>&gt; If it on=
ly takes a few million dollars to attack BTC and make it completely unusabl=
e for one day</div><div><br></div><div>It would take much more than a few m=
illion to 51% attack bitcoin. Bitcoin&#39;s blockchain security is primaril=
y based on the capital cost of buying up a massive amount of hashpower. The=
 ongoing maintenance and electricity costs of mining are actually not very =
relevant to security because all those ongoing costs are directly offset by=
 mining revenues. Its the upfront costs that serve as the primary barrier a=
n attacker must surpass. Acquiring the mining hardware, finding places wher=
e energy costs are low enough, setting up the equipment, etc. To do that co=
sts billions of dollars, not millions.=C2=A0</div><div><br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Ju=
l 7, 2022 at 9:44 AM Giuseppe B via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"auto"><div dir=3D"auto">It&#39;s the first time I=
 read about the security budget and it definitely sounds scary to me.</div>=
<div dir=3D"auto">If it only takes a few million dollars to attack BTC and =
make it completely unusable for one day, I suppose it&#39;s only a matter o=
f time before some hedge fund actually does it, using a short position to p=
rofit from the huge panic sell wave and global loss of confidence that woul=
d result from it.=C2=A0</div><div dir=3D"auto">It seems even cheaper to do =
than the recent attack to Terra, unless I&#39;m missing something.=C2=A0</d=
iv><div><br><br><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"=
 target=3D"_blank">vjudeu@gazeta.pl</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">&gt; If the only realistic (fair, effici=
ent &amp; proportionate) way to pay for Bitcoin&#39;s security was by havin=
g 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 int=
erest 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" rel=3D"noreferrer" target=3D"_bl=
ank">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>
_______________________________________________<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>

--0000000000001757aa05e34421b9--