📝 Original message: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 at lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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 at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 at gmail.com>
> To: vjudeu at gazeta.pl, Bitcoin Protocol Discussion
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
> Message-ID:
> <CAGpPWDbKjSXKHaUcevzG1DtdP-WksO3Ak+1J2JWTeCG2=
> 3GgLQ at 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 at 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:
.> > 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220707/ebd12f96/attachment-0001.html>;