diff options
| author | John Carvalho <john@synonym.to> | 2022-07-07 14:24:39 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-07-07 13:24:54 +0000 |
| commit | 6e37d13d431fe07a276edbeed606ac63a96eb128 (patch) | |
| tree | 2d7f5fe386ef28346c517123fb970052b9abed35 | |
| parent | 8f13c858001f416a2b33c2936efb654336cc9c65 (diff) | |
| download | pi-bitcoindev-6e37d13d431fe07a276edbeed606ac63a96eb128.tar.gz pi-bitcoindev-6e37d13d431fe07a276edbeed606ac63a96eb128.zip | |
Re: [bitcoin-dev] Bitcoin covenants are inevitable
| -rw-r--r-- | f3/daed18051967252313aa8e8528600f1ea168b8 | 695 |
1 files changed, 695 insertions, 0 deletions
diff --git a/f3/daed18051967252313aa8e8528600f1ea168b8 b/f3/daed18051967252313aa8e8528600f1ea168b8 new file mode 100644 index 000000000..bb9d3ab0e --- /dev/null +++ b/f3/daed18051967252313aa8e8528600f1ea168b8 @@ -0,0 +1,695 @@ +Return-Path: <john@synonym.to> +Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 11D2DC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 13:24:54 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp3.osuosl.org (Postfix) with ESMTP id E779F60C30 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 13:24:53 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E779F60C30 +Authentication-Results: smtp3.osuosl.org; + dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com + header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256 + header.s=20210112 header.b=ZlQk60EF +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.897 +X-Spam-Level: +X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_NONE=0.001] autolearn=ham autolearn_force=no +Received: from smtp3.osuosl.org ([127.0.0.1]) + by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id CW0lWTXTsE-A + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 13:24:52 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E78F560A70 +Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com + [IPv6:2607:f8b0:4864:20::42e]) + by smtp3.osuosl.org (Postfix) with ESMTPS id E78F560A70 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 7 Jul 2022 13:24:51 +0000 (UTC) +Received: by mail-pf1-x42e.google.com with SMTP id e16so6581846pfm.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 07 Jul 2022 06:24:51 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=synonym-to.20210112.gappssmtp.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to; + bh=uh3d5jXDLw5A5GNp4MiWm02laFBX6h3aR2NRFzpYJ/4=; + b=ZlQk60EFYXL9VWCkvmKCMrG+k+TGxX4E0MoY2OOTfdRptrVLZPtwucrWucjooMDp0H + 1ApXqyGn1Yp5XEnX9PwwsgUr4FAYaoS3FIr+1S/dO6eLNc82FuR5GISfkd+W2ozY0c91 + qqbY70eY2NrHsT90VWIvg/e8RmnY/SxXr+4/5zgz9QhoT+oUo6fTrwnwRNkLiCyKDbQG + wqJVQ980j9PZ9JylLAhhSsi9lgrAy6UmANoyBoG5INlms5rubqgm//Pd+TcuDhLP73Xs + C9xQpzjMM06UW+UeZEQIQh/WGVQm+cFYYbN8BOY0WLBn9qfA6LuKJczTT2riv/mbrDEe + gE/g== +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=uh3d5jXDLw5A5GNp4MiWm02laFBX6h3aR2NRFzpYJ/4=; + b=6GImAih0m1q9I8OZ5fYhcd95arRJlmN7R+r27uoXwxjah9C0ofbZtt5j8A3d6i/i7t + qFKv/DspMPaJIxeqJTy1ieNthlclCQZltLbh3SBSYYMMYv2hJh44xFVtlQJNN/l61/LW + jxrNWfuSb2l4H00iyX0yvfKkkXaVhBXCL9WjxtxaFoPNnSKt6TIXaL2Ht7YpXmrQtp6q + MYFv4PiNYItKwjxKiO9M8aEu+RzPsm1TYAYnYSmgwlD8GI1MFyCDZZb+srONys6OR8QL + O5Vn1MyeTDWNOo5XHE05Fr5axTu2oudb25K7NTRwe/+ixB/jPXzYvwS+qOXi858U5LwN + 9rqA== +X-Gm-Message-State: AJIora+SP49H7GLSR0inw8/wRQDqDXkf1TNyptly1YGD8lEKftURzLRc + EUrLpIrMLwoYxtxb4Q7fqkHC3MpedL/L6HaS1kxg2gZwmzQ3ZNrX +X-Google-Smtp-Source: AGRyM1u07y1YsEsKPwRFZ/UbLMmFJgPBrjzED176pTUlP8h3Lxtq926hOlZKpgAgaPfL4voPHH6ORvEZnPpXa6FWxo0= +X-Received: by 2002:a17:90b:3ec5:b0:1ef:688:8568 with SMTP id + rm5-20020a17090b3ec500b001ef06888568mr5287544pjb.38.1657200290405; Thu, 07 + Jul 2022 06:24:50 -0700 (PDT) +MIME-Version: 1.0 +References: <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org> +From: John Carvalho <john@synonym.to> +Date: Thu, 7 Jul 2022 14:24:39 +0100 +Message-ID: <CAHTn92wR+D=2FLAc7vhhm4kNT6NwDfyKdRj32=E9H3UJ4QcE+Q@mail.gmail.com> +To: bitcoin-dev@lists.linuxfoundation.org +Content-Type: multipart/alternative; boundary="000000000000a1b84b05e33702f5" +X-Mailman-Approved-At: Thu, 07 Jul 2022 13:55:43 +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: Thu, 07 Jul 2022 13:24:54 -0000 + +--000000000000a1b84b05e33702f5 +Content-Type: text/plain; charset="UTF-8" + +Billy, + +Proof of work and the difficulty adjustment function solve literally +everything you are talking about already. + +Bitcoin does not need active economic governanance by devs or meddlers. + +Please stop spamming this list with this nonsensical thread. + +Love, + +John + + +On Thu, Jul 7, 2022 at 1:00 PM < +bitcoin-dev-request@lists.linuxfoundation.org> wrote: + +> Send bitcoin-dev mailing list submissions to +> bitcoin-dev@lists.linuxfoundation.org +> +> To subscribe or unsubscribe via the World Wide Web, visit +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> or, via email, send a message with subject or body 'help' to +> bitcoin-dev-request@lists.linuxfoundation.org +> +> You can reach the person managing the list at +> bitcoin-dev-owner@lists.linuxfoundation.org +> +> When replying, please edit your Subject line so it is more specific +> than "Re: Contents of bitcoin-dev digest..." +> +> +> Today's Topics: +> +> 1. Re: Bitcoin covenants are inevitable (Billy Tetrud) +> +> +> ---------------------------------------------------------------------- +> +> Message: 1 +> Date: Wed, 6 Jul 2022 17:46:15 -0700 +> From: Billy Tetrud <billy.tetrud@gmail.com> +> To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion +> <bitcoin-dev@lists.linuxfoundation.org> +> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable +> Message-ID: +> <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2= +> 3GgLQ@mail.gmail.com> +> Content-Type: text/plain; charset="utf-8" +> +> @Corey +> +> > Currently there is zero feedback in the Bitcoin system between what we +> might think is the optimum amount of security and what actually exists. +> +> I basically agree with this. The pedantic part of my mind does want to +> point out that the link between block subsidy and bitcoin's price does +> actually give somewhat of a feedback loop, in that the higher the price, +> the more valuable bitcoin is as a whole (at least as viewed by the active +> market), and therefore the more investment in security is appropriate. +> However, in the long run when the subsidy reduces to insignificance, we +> basically lose this link. And even with this link, it's not very direct. +> Fees retain only a little bit of this behavior, because presumably a more +> valuable bitcoin is more valuable to spend, but the link to security is +> very tenuous there. +> +> > There is also zero agreement on how much security would constitute such +> an optimum. +> +> This is really step 1. We need to generate consensus on this long before +> the block subsidy becomes too small. Probably in the next 10-15 years. I +> wrote a paper +> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity> +> that uses a framework for thinking about how much security bitcoin might +> need. The concept is that we should figure out what bitcoin's bottlenecks +> are, and figure out the minimum requirements we want to place on running a +> node based on how many (public) nodes we think we need and what percentage +> of machines out there are likely to run a node. The goals I chose to +> explore in that paper are totally up for debate, and I think its an +> important debate to have. But they are basically a first stab at setting up +> what we would need to determine optimum security. I would very much +> appreciate your review of that part of the paper, Corey. +> +> > 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. +> +> My thoughts on this are that we will need to periodically make some +> software change to adjust a *target amount of investment in security*, +> because the components of bitcoin's blockchain security are not all +> predictable. Many unpredictable things factor into bitcoin's security (eg +> miner behavior, pools, how many people generally run public nodes on their +> own, what features require running public nodes, value of bitcoin, etc. +> +> The primary mechanism we have to change how much security we have is to +> change the block size, which changes how much fees miners can collect each +> block. This isn't a linear thing. Its probably a parabola with a peak, +> where at that peak, making the block either smaller and larger would both +> reduce total fees paid. This is because when blocksize is higher, more +> transactions (and thus more fees) can be collected, but at the same time +> average fees will be lower. The pull of those two forces should define that +> parabola. +> +> So my suggestion here would be that we should target a certain amount of +> security and have programmatic adjustments to the block size in order to +> stay near enough to the parabolic maximum so that we pay miners enough to +> give us sufficient blockchain security. Conversely, it should also attempt +> to minimize how much "extra" security we pay for. It would be wasteful to +> pay 3 times as much for 3 times the security we actually need. Such a thing +> is a very real form of devaluation that basically represents a tax on +> bitcoin and users of bitcoin. And its very possible for the position of +> this parabola to change over time. We could never say with certainty +> whether we're on one side of the parabola's maximum or the other. This +> would make it rather complex to track well. +> +> Additionally, there's no clear trustless way to determine the market value +> of bitcoin at any given time, which makes it difficult to maintain this +> target over time. As the market value of bitcoin changes, that target could +> become quite inaccurate. This implies that we would need to do periodic +> adjustments to the target, either through periodic forks or through some +> other mechanism for changing the target. +> +> If there were a good trustless way to determine the market value of +> bitcoin, we would have to "manually" change this target potentially much +> less often. Transaction fees kind of have an association with market value. +> Perhaps some kind of analysis can be done on that to make a reasonable +> prediction of what market value is based on fees. Or maybe blocks can +> commit to a market price similarly to how they commit to a timestamp (which +> is also only verifiable to an approximation and can only be verified close +> to when it was mined but not eg years later). +> +> +> +> +> On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> 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 +> > +> -------------- next part -------------- +> An HTML attachment was scrubbed... +> URL: < +> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220706/d5a48a69/attachment-0001.html +> > +> +> ------------------------------ +> +> Subject: Digest Footer +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> +> ------------------------------ +> +> End of bitcoin-dev Digest, Vol 86, Issue 7 +> ****************************************** +> +-- +-- +John Carvalho +CEO, Synonym.to <http://synonym.to/> + +Schedule: https://calendly.com/bitcoinerrorlog +Chat: https://t.me/bitcoinerrorlog +Social: https://twitter.com/bitcoinerrorlog + +--000000000000a1b84b05e33702f5 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">Billy,</div><div dir=3D"auto"><br></div><div dir=3D"auto"= +>Proof of work and the difficulty adjustment function solve literally every= +thing you are talking about already.</div><div dir=3D"auto"><br></div><div = +dir=3D"auto">Bitcoin does not need active economic governanance by devs or = +meddlers.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Please stop sp= +amming this list with this nonsensical thread.</div><div dir=3D"auto"><br><= +/div><div dir=3D"auto">Love,=C2=A0</div><div dir=3D"auto"><br></div><div di= +r=3D"auto">John</div><div dir=3D"auto"><br></div><div><br><div class=3D"gma= +il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jul 7, 2022 at 1:00= + PM <<a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bi= +tcoin-dev-request@lists.linuxfoundation.org</a>> wrote:<br></div><blockq= +uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi= +dth:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,= +204,204)">Send bitcoin-dev mailing list submissions to<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda= +tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +<br> +To subscribe or unsubscribe via the World Wide Web, visit<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma= +ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li= +sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br> +or, via email, send a message with subject or body 'help' to<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin= +uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati= +on.org</a><br> +<br> +You can reach the person managing the list at<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux= +foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o= +rg</a><br> +<br> +When replying, please edit your Subject line so it is more specific<br> +than "Re: Contents of bitcoin-dev digest..."<br> +<br> +<br> +Today's Topics:<br> +<br> +=C2=A0 =C2=A01. Re: Bitcoin covenants are inevitable (Billy Tetrud)<br> +<br> +<br> +----------------------------------------------------------------------<br> +<br> +Message: 1<br> +Date: Wed, 6 Jul 2022 17:46:15 -0700<br> +From: Billy Tetrud <<a href=3D"mailto:billy.tetrud@gmail.com" target=3D"= +_blank">billy.tetrud@gmail.com</a>><br> +To: <a href=3D"mailto:vjudeu@gazeta.pl" target=3D"_blank">vjudeu@gazeta.pl<= +/a>,=C2=A0 Bitcoin Protocol Discussion<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= +undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g= +t;<br> +Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable<br> +Message-ID:<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeC= +G2=3D<a href=3D"mailto:3GgLQ@mail.gmail.com" target=3D"_blank">3GgLQ@mail.g= +mail.com</a>><br> +Content-Type: text/plain; charset=3D"utf-8"<br> +<br> +@Corey<br> +<br> +>=C2=A0 Currently there is zero feedback in the Bitcoin system between w= +hat we<br> +might think is the optimum amount of security and what actually exists.<br> +<br> +I basically agree with this. The pedantic part of my mind does want to<br> +point out that the link between block subsidy and bitcoin's price does<= +br> +actually give somewhat of a feedback loop, in that the higher the price,<br= +> +the more valuable bitcoin is as a whole (at least as viewed by the active<b= +r> +market), and therefore the more investment in security is appropriate.<br> +However, in the long run when the subsidy reduces to insignificance, we<br> +basically lose this link. And even with this link, it's not very direct= +.<br> +Fees retain only a little bit of this behavior, because presumably a more<b= +r> +valuable bitcoin is more valuable to spend, but the link to security is<br> +very tenuous there.<br> +<br> +> There is also zero agreement on how much security would constitute suc= +h<br> +an optimum.<br> +<br> +This is really step 1. We need to generate consensus on this long before<br= +> +the block subsidy becomes too small. Probably in the next 10-15 years. I<br= +> +wrote a paper<br> +<<a href=3D"https://github.com/fresheneesz/quantificationOfConsensusProt= +ocolSecurity" rel=3D"noreferrer" target=3D"_blank">https://github.com/fresh= +eneesz/quantificationOfConsensusProtocolSecurity</a>><br> +that uses a framework for thinking about how much security bitcoin might<br= +> +need. The concept is that we should figure out what bitcoin's bottlenec= +ks<br> +are, and figure out the minimum requirements we want to place on running a<= +br> +node based on how many (public) nodes we think we need and what percentage<= +br> +of machines out there are likely to run a node. The goals I chose to<br> +explore in that paper are totally up for debate, and I think its an<br> +important debate to have. But they are basically a first stab at setting up= +<br> +what we would need to determine optimum security. I would very much<br> +appreciate your review of that part of the paper, Corey.<br> +<br> +> Figuring out how much security is needed, or even better, figuring out= + a<br> +way to have a market mechanism to answer that question, will be an<br> +important project.<br> +<br> +My thoughts on this are that we will need to periodically make some<br> +software change to adjust a *target amount of investment in security*,<br> +because the components of bitcoin's blockchain security are not all<br> +predictable. Many unpredictable things factor into bitcoin's security (= +eg<br> +miner behavior, pools, how many people generally run public nodes on their<= +br> +own, what features require running public nodes, value of bitcoin, etc.<br> +<br> +The primary mechanism we have to change how much security we have is to<br> +change the block size, which changes how much fees miners can collect each<= +br> +block. This isn't a linear thing. Its probably a parabola with a peak,<= +br> +where at that peak, making the block either smaller and larger would both<b= +r> +reduce total fees paid. This is because when blocksize is higher, more<br> +transactions (and thus more fees) can be collected, but at the same time<br= +> +average fees will be lower. The pull of those two forces should define that= +<br> +parabola.<br> +<br> +So my suggestion here would be that we should target a certain amount of<br= +> +security and have programmatic adjustments to the block size in order to<br= +> +stay near enough to the parabolic maximum so that we pay miners enough to<b= +r> +give us sufficient blockchain security. Conversely, it should also attempt<= +br> +to minimize how much "extra" security we pay for. It would be was= +teful to<br> +pay 3 times as much for 3 times the security we actually need. Such a thing= +<br> +is a very real form of devaluation that basically represents a tax on<br> +bitcoin and users of bitcoin. And its very possible for the position of<br> +this parabola to change over time. We could never say with certainty<br> +whether we're on one side of the parabola's maximum or the other. T= +his<br> +would make it rather complex to track well.<br> +<br> +Additionally, there's no clear trustless way to determine the market va= +lue<br> +of bitcoin at any given time, which makes it difficult to maintain this<br> +target over time. As the market value of bitcoin changes, that target could= +<br> +become quite inaccurate. This implies that we would need to do periodic<br> +adjustments to the target, either through periodic forks or through some<br= +> +other mechanism for changing the target.<br> +<br> +If there were a good trustless way to determine the market value of<br> +bitcoin, we would have to "manually" change this target potential= +ly much<br> +less often. Transaction fees kind of have an association with market value.= +<br> +Perhaps some kind of analysis can be done on that to make a reasonable<br> +prediction of what market value is based on fees. Or maybe blocks can<br> +commit to a market price similarly to how they commit to a timestamp (which= +<br> +is also only verifiable to an approximation and can only be verified close<= +br> +to when it was mined but not eg years later).<br> +<br> +<br> +<br> +<br> +On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev <<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +<br> +> > If the only realistic (fair, efficient & proportionate) way t= +o pay for<br> +> Bitcoin's security was by having some inflation scheme that violat= +ed the 21<br> +> million cap, then agreeing to break the limit would probably be what m= +akes<br> +> sense, and in the economic interest of its users and holders.<br> +><br> +> So, Paul Sztorc was right again, there are three options: Enormous Blo= +ck<br> +> Size Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues = +Come<br> +> From Merged Mining: <a href=3D"https://www.truthcoin.info/images/sb-tr= +ilemma.png" rel=3D"noreferrer" target=3D"_blank">https://www.truthcoin.info= +/images/sb-trilemma.png</a>.<br> +> And I think using Merged Mining is the best option. More about that:<b= +r> +> <a href=3D"https://www.truthcoin.info/blog/security-budget-ii-mm/" rel= +=3D"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 s= +hort<br> +> term, would be to soft-fork in a reduction in the current and near-fut= +ure<br> +> mining rewards, by somehow locking the coins in a contract that depriv= +ed<br> +> the miner of the full reward, and then using that contract to pay the<= +br> +> rewards out far in the future, should at some point we feel the securi= +ty<br> +> budget was insufficient.<br> +><br> +> Yes, that's also possible, RSK uses that. And making some kind of<= +br> +> soft-fork for that is also possible, but I don't know if miners wi= +ll agree<br> +> to send some coinbase reward to "<futureBlockNumber> OP_CHE= +CKLOCKTIMEVERIFY<br> +> OP_DROP OP_TRUE".<br> +><br> +> On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +> >Bitcoin's finite supply is the main argument for people invest= +ing in it,<br> +> the whole narrative around bitcoin is based on its finite supply. Whil= +e it<br> +> has its flaws and basically condemns bitcoin to be only used as a stor= +e >of<br> +> value (and not as a currency), I don't think it's worth questi= +oning it at<br> +> this point.<br> +> ><br> +> >Just my 2 sats.<br> +> ><br> +> >Giuseppe.<br> +><br> +><br> +> A finite supply alone is not enough to give something value, as it mus= +t<br> +> also be useful in some way. In the case of Bitcoin, various forms of<b= +r> +> cryptographic security must all work - and work together - to make Bit= +coin<br> +> useful. If the only realistic (fair, efficient & proportionate) wa= +y to pay<br> +> for Bitcoin's security was by having some inflation scheme that vi= +olated<br> +> the 21 million cap, then agreeing to break the limit would probably be= + what<br> +> makes sense, and in the economic interest of its users and holders.<br= +> +><br> +> There will always be competitive pressures with respect to efficiency,= + and<br> +> both being over-secured and under-secured would be economically ineffi= +cient<br> +> for a crypto currency, and thereby laving room for a more optimally-se= +cured<br> +> competitor to gain ground. Currently there is zero feedback in the Bit= +coin<br> +> system between what we might think is the optimum amount of security a= +nd<br> +> what actually exists. There is also zero agreement on how much securit= +y<br> +> would constitute such an optimum. Figuring out how much security is ne= +eded,<br> +> or even better, figuring out a way to have a market mechanism to answe= +r<br> +> that question, will be an important project.<br> +><br> +> Another option, if we were to decide we are over-secured in the short<= +br> +> term, would be to soft-fork in a reduction in the current and near-fut= +ure<br> +> mining rewards, by somehow locking the coins in a contract that depriv= +ed<br> +> the miner of the full reward, and then using that contract to pay the<= +br> +> rewards out far in the future, should at some point we feel the securi= +ty<br> +> budget was insufficient. Anthony Towns presented a form of this concep= +t in<br> +> greater detail at a Scaling Bitcoin conference some years ago. While t= +his<br> +> solution, if employed, would only work for some finite amount of time,= + it<br> +> is possible that could give additional decades before the accumulated<= +br> +> security budget was exhausted.<br> +><br> +><br> +> Corey<br> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">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= +/mailman/listinfo/bitcoin-dev</a><br> +><br> +-------------- next part --------------<br> +An HTML attachment was scrubbed...<br> +URL: <<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/= +attachments/20220706/d5a48a69/attachment-0001.html" rel=3D"noreferrer" targ= +et=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attach= +ments/20220706/d5a48a69/attachment-0001.html</a>><br> +<br> +------------------------------<br> +<br> +Subject: Digest Footer<br> +<br> +_______________________________________________<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> +<br> +<br> +------------------------------<br> +<br> +End of bitcoin-dev Digest, Vol 86, Issue 7<br> +******************************************<br> +</blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" = +data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><span style=3D"color:rg= +b(34,34,34)">--</span><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" st= +yle=3D"color:rgb(34,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D= +"ltr">CEO,=C2=A0<a href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204= +)" target=3D"_blank">Synonym.to</a><br><div><font size=3D"1"><br>Schedule:= +=C2=A0<a href=3D"https://calendly.com/bitcoinerrorlog" style=3D"color:rgb(1= +7,85,204)" target=3D"_blank">https://calendly.com/bitcoinerrorlog</a><br></= +font></div><div><font size=3D"1">Chat:=C2=A0<a href=3D"https://t.me/bitcoin= +errorlog" style=3D"color:rgb(17,85,204)" target=3D"_blank">https://t.me/bit= +coinerrorlog</a></font></div><div><font size=3D"1">Social:=C2=A0<a href=3D"= +https://twitter.com/bitcoinerrorlog" style=3D"color:rgb(17,85,204)" target= +=3D"_blank">https://twitter.com/bitcoinerrorlog</a></font></div></div></div= +></div></div> + +--000000000000a1b84b05e33702f5-- + |