From: Manuel Costa <manecosta@gmail.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
Date: Sun, 19 Jun 2022 16:54:03 +0100 [thread overview]
Message-ID: <CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com> (raw)
In-Reply-To: <Yq77CnxOhr615ip8@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]
"Long time listener, first time caller". Just sharing my 2 sats:
While I find it stimulating, I think this discussion (and other similar
doom-like scenarios) is somewhat irrelevant in practice.
When the time comes and if we start seeing issues with block rewards being
too low to maintain acceptable security, we're going to have multiple
solutions being implemented for it, and definitely a hard fork to
indefinitely maintain some degree of block subsidy is going to be within
them.
If it is indeed confirmed that the original chain is now insecure,
consensus should eventually coalesce in one of the hard forks that can
actually keep moving forward with some degree of security assurance.
I feel like people sometimes think of these systems as when they fail
there's a full loss, but that's not the case as the history is not lost,
and so we can move forward from that history with multiple alternatives and
allow the social/economic consensus to dictate which one becomes the new
accepted chain.
The genie is out of the box, and some chain whose history is prefixed by
Bitcoin's current chain history will always exist.
The only type of problems we should truly be worrying about are ones that
might invalidate the security of the history itself, like a cryptographic
breakthrough (quantum computing for example) that would turn some or all
utxos into "anyone can spend".
Transitions might be disorderly and filled with drama and discussion as the
"block size wars" in 2017, but anyone who doesn't want to "vote", can
always just keep their utxos frozen in place while the drama sorts itself
out, and maintain whatever holdings they previously had on the new accepted
chain.
Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreveu
no dia domingo, 19/06/2022 à(s) 11:32:
> On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
> > Hi Peter,
> >
> > > Only because the block reward goes away. If it was made to continue
> > > indefinitely - most likely with an inflation hard fork - demand for
> block space
> > > would not be critical to Bitcoin's security.
> >
> >
> > I am not completely against your proposal although 100% sure this will
> not have "consensus" to be implemented. I think if bitcoin doesn't have
> enough demand for block space, it should die. I will be sad if bitcoin
> doesn't exist but it should be a lesson for all the people opposing soft
> forks based on drama and politics instead of technical review.
> >
> > I don't see anything wrong with users paying 100x fees for opening and
> closing LN channels.
>
> The PoW security of Bitcoin benefits all Bitcoin users, proportional to the
> value of BTC they hold; if Bitcoin blocks aren't reliably created the
> value of
> *all* BTC goes down. It doesn't make sense for the entire cost of that
> security
> to be paid for on a per-tx basis. And there's a high chance paying for it
> on a
> per-tx basis won't work anyway due to lack of consistent demand.
>
> It would be extremely unfortunate if one of the very few decentralized
> ways to
> store value died simply because we couldn't find a way to pay to keep it
> secure.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4284 bytes --]
next prev parent reply other threads:[~2022-06-19 15:54 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 ` [bitcoin-dev] Bitcoin covenants are inevitable 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 [this message]
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
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='CAAxiura7-TTUOg=vuH8q+orX+LVED74f+NvaYqVve3j--CjTMQ@mail.gmail.com' \
--to=manecosta@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pete@petertodd.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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