From: Corey Haddad <corey3@gmail•com>
To: Giuseppe B <beppeben2030@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Wed, 6 Jul 2022 00:28:50 -0400 [thread overview]
Message-ID: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com> (raw)
In-Reply-To: <CABrXkXpPCL7dN0Fs6rzjqMJnYrFZcH-=30P-fSYecnxyAT=KYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]
>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
[-- Attachment #2: Type: text/html, Size: 2512 bytes --]
next prev parent reply other threads:[~2022-07-06 4:29 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.9.1654344003.14400.bitcoin-dev@lists.linuxfoundation.org>
2022-06-04 12:27 ` John Carvalho
2022-06-04 13:48 ` Keagan McClelland
2022-06-04 16:12 ` alicexbt
2022-06-06 13:02 ` Erik Aronesty
2022-06-12 3:36 ` Peter Todd
2022-06-12 13:02 ` Erik Aronesty
2022-06-12 16:35 ` Corey Haddad
2022-06-12 19:16 ` alicexbt
2022-06-19 10:31 ` Peter Todd
2022-06-19 15:54 ` Manuel Costa
2022-06-19 18:26 ` Kate Salazar
2022-06-19 22:35 ` Erik Aronesty
2022-06-21 19:00 ` Keagan McClelland
2022-06-21 20:10 ` Eric Voskuil
2022-06-23 19:17 ` Peter Todd
2022-06-28 3:55 ` Billy Tetrud
2022-06-28 16:23 ` Alex Lee
2022-06-28 23:22 ` Peter Todd
2022-06-29 5:02 ` Alex Lee
2022-06-28 23:20 ` Peter Todd
2022-06-29 10:44 ` Kate Salazar
2022-06-30 15:25 ` Billy Tetrud
2022-07-03 9:43 ` Peter Todd
2022-07-03 10:30 ` Giuseppe B
2022-07-06 4:28 ` Corey Haddad [this message]
2022-07-06 11:10 ` vjudeu
2022-07-07 0:46 ` Billy Tetrud
2022-07-07 12:15 ` vjudeu
2022-07-07 14:05 ` Erik Aronesty
2022-07-07 14:10 ` Giuseppe B
2022-07-08 5:03 ` Billy Tetrud
2022-06-30 17:04 ` Erik Aronesty
[not found] <mailman.9.1657195203.20624.bitcoin-dev@lists.linuxfoundation.org>
2022-07-07 13:24 ` John Carvalho
2022-07-07 14:12 ` Peter Todd
2022-07-07 16:24 ` Eric Voskuil
2022-07-07 17:37 ` Erik Aronesty
2022-07-07 19:57 ` Eric Voskuil
2022-07-07 21:11 ` Erik Aronesty
2022-07-08 0:28 ` Eric Voskuil
2022-07-08 4:59 ` vjudeu
2022-07-08 7:26 ` John Carvalho
2022-07-08 15:14 ` Erik Aronesty
2022-07-14 4:55 ` Billy Tetrud
2022-07-07 22:06 ` Anthony Towns
2022-07-07 22:02 ` Corey Haddad
2022-06-03 18:39 alicexbt
2022-06-04 0:29 ` micaroni
2022-06-04 18:43 ` Jorge Timón
2022-06-05 4:18 ` alicexbt
2022-06-08 3:51 ` Billy Tetrud
2022-06-08 9:22 ` Jorge Timón
2022-06-09 4:30 ` Billy Tetrud
2022-06-09 0:03 ` Ryan Grant
2022-07-19 4:44 ` Anthony Towns
2022-07-19 14:46 ` alicexbt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com' \
--to=corey3@gmail$(echo .)com \
--cc=beppeben2030@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox