From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 28E0CC002D for ; Thu, 7 Jul 2022 12:15:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id E235F419B6 for ; Thu, 7 Jul 2022 12:15:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E235F419B6 Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=MfjfjVZU X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 E28vZvQ0-Y57 for ; Thu, 7 Jul 2022 12:15:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6BEE5419B2 Received: from smtpo92.poczta.onet.pl (smtpo92.poczta.onet.pl [213.180.149.145]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6BEE5419B2 for ; Thu, 7 Jul 2022 12:15:42 +0000 (UTC) Received: from pmq2v.m5r2.onet (pmq2v.m5r2.onet [10.174.32.68]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4LdwNR1bQSzlg9p7; Thu, 7 Jul 2022 14:15:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1657196135; bh=7vKtWdnYNBvMbXsS55eU28Do/8ybKt07Qd69b8ozbzg=; h=From:Cc:To:In-Reply-To:Date:Subject:From; b=MfjfjVZUdZA+pw5iB85a8YSD6/FiUIbmQYOUeLDUuqbVazeBBGzoMQUEmedeET1vj 1t191ksNMRaNFAw6Q8k4DjfBGa22Pt7HxocEOfeSKlxlwO7WyhVfW09YgVs+Bn4Y+l fqxgu4iGyj/QP6QQn+hs3nHpNjbOmqTo5EPmrhTQ= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq2v.m5r2.onet via HTTP id ; Thu, 07 Jul 2022 14:15:35 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: Billy Tetrud , Bitcoin Protocol Discussion In-Reply-To: Date: Thu, 07 Jul 2022 14:15:34 +0200 Message-Id: <164907167-5b9b0e9ae97b67a0c53de69f7b92affd@pmq2v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;3 X-Mailman-Approved-At: Thu, 07 Jul 2022 12:58: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: Thu, 07 Jul 2022 12:15:46 -0000 > The primary mechanism we have to change how much security we have is to c= hange the block size, which changes how much fees miners can collect each b= lock. 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 transactio= ns (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. I think it would be better to allow transaction joining, and lock some coin= s to the future block numbers in case of peaks, to make fees more smoothly,= like it is in RSK. So, if there is 0.01 BTC fee for some transaction, it d= oes not matter if that is paid by some single user, or by a million users, = one satoshi each, that comes on-chain as a single transaction to serve all = of them. > Transaction fees kind of have an association with market value. They will be more important in the future, because when all coins will be m= ined, then miners will earn nothing, if there will be no on-chain transacti= ons. On the other hand, people will switch to other networks, if on-chain f= ees will be too high. So, I think the market should adjust fees, and findin= g the right balance between on-chain and off-chain should be left to the us= ers, just by providing them options like transaction joining. I think such = features will be created anyway, if not supported directly, then they will = come as no-forks, and if that won't succeed, then I expect some centralized= websites will start doing that anyway. On 2022-07-07 02:46:29 user Billy Tetrud wrote: @Corey > Currently there is zero feedback in the Bitcoin system between what we m= ight 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 poin= t 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 v= aluable bitcoin is as a whole (at least as viewed by the active market), an= d therefore the more investment in security is appropriate. However, in the= long run when the subsidy reduces to insignificance, we basically lose thi= s link. And even with this link, it's not very direct. Fees retain only a l= ittle bit of this behavior, because presumably a more valuable bitcoin is m= ore valuable to spend, but the link to security is very tenuous there. = > There is also zero agreement on how much security would constitute such a= n optimum. = This is really step 1. We need to generate consensus on this long before th= e block subsidy becomes too small. Probably in the next 10-15 years. I wrot= e a paper that uses a framework for thinking about how much security bitcoi= n might need. The concept is that we should figure out what bitcoin's bottl= enecks are, and figure out the minimum requirements we want to place on run= ning a node based on how many (public) nodes we think we need and what perc= entage 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 import= ant 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 y= our 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 importan= t project. My thoughts on this are that we will need to periodically make some softwar= e 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, poo= ls, 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 cha= nge the block size, which changes how much fees miners can collect each blo= ck. This isn't a linear thing. Its probably a parabola with a peak, where a= t that peak, making the block either smaller and larger would both reduce t= otal 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 w= ill 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 se= curity 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 mi= nimize 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 an= d 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 on= e side of the parabola's maximum or the other. This would make it rather co= mplex 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 tar= get over time. As the market value of bitcoin changes, that target could be= come quite inaccurate. This implies that we would need to do periodic adjus= tments to the target, either through periodic forks or through some other m= echanism 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 ofte= n. 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 o= f what market value is based on fees. Or maybe blocks can commit to a marke= t price similarly to how they commit to a timestamp (which is also only ver= ifiable to an approximation and can only be verified close to when it was m= ined but not eg years later). = = On Wed, Jul 6, 2022 at 4:13 AM vjudeu via bitcoin-dev wrote: > 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. = > >Just my 2 sats. = > >Giuseppe. = A finite supply alone is not enough to give something value, as it must als= o be useful in some way. In the case of Bitcoin, various forms of cryptogra= phic security must all work - and work together - to make Bitcoin useful. I= f the only realistic (fair, efficient & proportionate) way to pay for Bitco= in's security was by having some inflation scheme that violated the 21 mill= ion cap, then agreeing to break the limit would probably be what makes sens= e, 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-secure= d competitor to gain ground. Currently there is zero feedback in the Bitcoi= n 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 wou= ld 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 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. = Corey _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev