From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3BFEFC002D for ; Wed, 6 Jul 2022 11:10:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 07D0B833C6 for ; Wed, 6 Jul 2022 11:10:38 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 07D0B833C6 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=JtZa3t+y X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aJUj_p-0MwM for ; Wed, 6 Jul 2022 11:10:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 378E4831F8 Received: from smtpo92.poczta.onet.pl (smtpo92.poczta.onet.pl [213.180.149.145]) by smtp1.osuosl.org (Postfix) with ESMTPS id 378E4831F8 for ; Wed, 6 Jul 2022 11:10:35 +0000 (UTC) Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LdGzm22V1zlg9hF; Wed, 6 Jul 2022 13:10:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1657105828; bh=OAjukh4IObVJ7OMnZMNugb93yFjNLLSbZk1k/G+mV7I=; h=From:To:In-Reply-To:Date:Subject:From; b=JtZa3t+yyhremz0xIsqKGN27JNiZfdp4jpjdweV8DEdQ3jC2oCrlTHxYqPF11P5h6 NzrsnlUwvZB40Vs2LY8Xaipdg8qjWITJpw+HDhvQOjrGR+qzCAAcB0phZ9kUWlF2ZU OSj3jRIUqlHstqJPUjlpglJ0X77W2pvyjpv6T4U4= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ; Wed, 06 Jul 2022 13:10:28 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "Corey Haddad , Bitcoin Protocol Discussion" , Giuseppe B , Bitcoin Protocol Discussion In-Reply-To: Date: Wed, 06 Jul 2022 13:10:27 +0200 Message-Id: <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;2 X-Mailman-Approved-At: Wed, 06 Jul 2022 11:12:56 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2022 11:10:38 -0000 > If the only realistic (fair, efficient & proportionate) way to pay for Bi= tcoin's security was by having some inflation scheme that violated the 21 m= illion cap, then agreeing to break the limit would probably be what makes s= ense, and in the economic interest of its users and holders. 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 From = Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I thi= nk using Merged Mining is the best option. More about that: https://www.tru= thcoin.info/blog/security-budget-ii-mm/ > Another option, if we were to decide we are over-secured in the short ter= m, would be to soft-fork in a reduction in the current and near-future mini= ng rewards, by somehow locking the coins in a contract that deprived the mi= ner 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 in= sufficient. 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 s= ome coinbase reward to " OP_CHECKLOCKTIMEVERIFY OP_DROP = OP_TRUE". On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev wrote: >Bitcoin's finite supply is the main argument for people investing in it, t= he whole narrative around bitcoin is based on its finite supply. While it h= as 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 t= his point.=C2=A0 > >Just my 2 sats.=C2=A0 > >Giuseppe.=C2=A0 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 & proportionate) = 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 limit wo= uld probably be what makes sense, and in the economic interest of its users= and holders. 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. 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 Corey