diff options
| author | Giuseppe B <beppeben2030@gmail.com> | 2022-07-07 16:10:31 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-07 14:10:46 +0000 |
| commit | e8c77871758cb4ad1a41f75c4a0f1a6aeb942001 (patch) | |
| tree | 20da46b6d71d8ab000230a0e5dc8902ac510b457 | |
| parent | 3bb778603f26fa8246ebdd47c180ab547cb8955d (diff) | |
| download | pi-bitcoindev-e8c77871758cb4ad1a41f75c4a0f1a6aeb942001.tar.gz pi-bitcoindev-e8c77871758cb4ad1a41f75c4a0f1a6aeb942001.zip | |
Re: [bitcoin-dev] Bitcoin covenants are inevitable
| -rw-r--r-- | b3/03c02f4a1528e5993e6c479cb96d103680dbcc | 267 |
1 files changed, 267 insertions, 0 deletions
diff --git a/b3/03c02f4a1528e5993e6c479cb96d103680dbcc b/b3/03c02f4a1528e5993e6c479cb96d103680dbcc new file mode 100644 index 000000000..5ca3674e1 --- /dev/null +++ b/b3/03c02f4a1528e5993e6c479cb96d103680dbcc @@ -0,0 +1,267 @@ +Return-Path: <beppeben2030@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 78056C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 14:10:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 4BF5741B30 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 14:10:46 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4BF5741B30 +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=KIx4KdtE +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.837 +X-Spam-Level: +X-Spam-Status: No, score=-1.837 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_ENVFROM_END_DIGIT=0.25, 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 xRBUbSj2XHDF + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 14:10:44 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6A20541A60 +Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com + [IPv6:2a00:1450:4864:20::530]) + by smtp4.osuosl.org (Postfix) with ESMTPS id 6A20541A60 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 14:10:44 +0000 (UTC) +Received: by mail-ed1-x530.google.com with SMTP id e15so2372725edj.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 07 Jul 2022 07:10:44 -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=cIBfebWLcHNDtmhNCUDncFOTYQ76gZDbirzAiVvqDLc=; + b=KIx4KdtED207PAwFX0rhD584LWnbW9pxQdMO396bdZMSdVu+yOJpLL3L+Yuf3tDnO+ + uU5eN9gz4NaK9ww4zV4H6q0QGOp4L5tepM3HhKAPNnUmzTg43NZu6lj0IOHH/gXhTW1V + NdBTutzBaBbqCs7eBxuESYEVx+HBa/v8MtTkpb5UNxy1Qp4+OM3xl/mS1G8g+dDhSln1 + wG6AosX1dID/imMIKDIDgewNnShhU7kUKJQ456WMef9G5Mkt0M6xoYxlIlO8Dy0ZiRht + eWwAZK56Rhs0gisMLuabHqyvHNVyTcizeB0RMHrN51mK8v4CLS4Mmrw7UoQ2JSRxbhkz + B/kQ== +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=cIBfebWLcHNDtmhNCUDncFOTYQ76gZDbirzAiVvqDLc=; + b=xxOKCRbaFiq1bhp/E+rq4z/OIjHYs9XmJOb6nBZtT8xxfwOETqKTyHT0my/DYxpVXr + jlximWz8SxUBrEEM3ECT7uFi3HLlLAIu/3Ej1yW2ApDub1b2HmOPuDCb3oUh5rr1OZ+y + 3BwpJ3o3yN5yvvuFrXKqSELKAuc9HHxCj2d8DCF/gVcGoNofnqoLmoTFbkbvMwm2CQuC + ujodsZ/kIfBicIWFBpjo6EAwW0TwK63H4opGEwgxe4k5yUtlGFkEchOEavIh+WTV5l53 + 6uah3+yUrNU6GqCZvTECOBZyCfHRThJLcENuIL0PsGSS3xsLAQpM+g8sHXnruULETXDy + TvrA== +X-Gm-Message-State: AJIora/VRqXDHUogoRS9GPt/4/ZW9k5IzH2d93hkSCGL23FjQ28AGrJY + dtWPuFjy8kkj/BmKorqIon0Agv7uQiEA2GlvD98= +X-Google-Smtp-Source: AGRyM1vfJt508BSz/sq3t9iFG7yV2EYT16l9KOlVlCZIGVsbUeLzCEe0x8KDwbMZ2so3xOJIR7iol4H/4BPUwWNOhyg= +X-Received: by 2002:a50:eb45:0:b0:437:7686:6048 with SMTP id + z5-20020a50eb45000000b0043776866048mr64386148edp.264.1657203042404; Thu, 07 + Jul 2022 07:10:42 -0700 (PDT) +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" +X-Mailman-Approved-At: Thu, 07 Jul 2022 14:43:20 +0000 +Cc: "Corey Haddad <corey3@gmail.com>, + Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org> +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: Thu, 07 Jul 2022 14:10:46 -0000 + +--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'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'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'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 <<a href=3D"mailto:vjudeu@gazeta.pl">vjudeu@gazeta= +.pl</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> If the only= + realistic (fair, efficient & proportionate) way to pay for Bitcoin'= +;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 >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> +> 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'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 t= +o send some coinbase reward to "<futureBlockNumber> OP_CHECKLOCK= +TIMEVERIFY OP_DROP OP_TRUE".<br> +<br> +On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <<a href=3D"mai= +lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefer= +rer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +>Bitcoin'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 >of value (and not as a currency), I don't think it's worth q= +uestioning it at this point.=C2=A0<br> +><br> +>Just my 2 sats.=C2=A0<br> +><br> +>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 & proportiona= +te) way to pay for Bitcoin'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-- + |