Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
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>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Precedence: list

> 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