path: root/81/d9daeafd88da02fc6da285d0c207c0ba48182f

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 28E0CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=3GgLQ@mail.gmail.com>
Date: Thu, 07 Jul 2022 14:15:34 +0200
Message-Id: <164907167-5b9b0e9ae97b67a0c53de69f7b92affd@pmq2v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;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 <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 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 <billy.tetrud@gmail.com> 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 <bitcoin-dev@lists.li=
nuxfoundation.org> 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 "<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, 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