From: Peter Todd <pete@petertodd•org>
To: James MacWhyte <macwhyte@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction fees for security
Date: Mon, 11 Jul 2022 20:31:19 -0400 [thread overview]
Message-ID: <YszA159sG+WFfYFi@petertodd.org> (raw)
In-Reply-To: <CAH+Axy46g=BDwgDMcs6afWqHiOEBCGo1VXUedC7qQYdJBBx8jQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote:
> On Tue, Jul 12, 2022 at 12:26 AM Peter Todd <pete@petertodd•org> wrote:
>
> > Anyway, designing protocols for "price go up forever" hopium is a bad idea.
> >
>
> I'm quite disappointed that this is what you've reduced my argument to. The
> price doesn't need hopium; if it stays between where it is now and the all
> time high, that is enough to make mining rewards appealing.
>
> Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo.
> The Pacific is big, but not *that* big.
>
> Certainly we should be designing protocols in anticipation of increased
> adoption, and not assuming the world will always be exactly as it is today?
We should design protocols that do reasonably well in *both* scenarios. Because
the future is unknown. Hell, I won't be surprised if further developments come
along that reduce demand for on-chain txs even further.
The fact is basing security budget in part on the total value of the coin being
secured very cleanly solves the problem of ensuring that there is sufficient
mining reward. Similarly, we also have to plan for the potential environment
where fee demand is very high. And we've done a good job of that, including
Lightning, replace-by-fee, etc.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-07-12 0:31 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 18:12 Bram Cohen
2022-07-11 18:38 ` micaroni
2022-07-11 18:43 ` Erik Aronesty
2022-07-11 19:45 ` vjudeu
2022-07-11 20:35 ` Russell O'Connor
2022-07-11 20:52 ` Erik Aronesty
2022-07-11 21:36 ` Peter Todd
2022-07-11 21:56 ` Peter Todd
2022-07-12 0:21 ` Russell O'Connor
2022-07-12 0:37 ` Peter Todd
2022-07-14 0:54 ` Anthony Towns
2022-07-11 21:18 ` Pox
2022-07-11 21:53 ` Peter Todd
2022-07-12 2:47 ` Bram Cohen
2022-07-11 22:19 ` James MacWhyte
2022-07-11 22:26 ` Peter Todd
2022-07-12 0:01 ` James MacWhyte
2022-07-12 0:31 ` Peter Todd [this message]
2022-07-13 0:38 ` Tom Harding
2022-07-13 12:18 ` Erik Aronesty
2022-07-11 23:29 ` Anthony Towns
2022-07-12 3:56 Peter
2022-07-12 11:57 ` Erik Aronesty
2022-07-12 15:08 ` Peter
2022-07-12 17:46 ` Ryan Grant
[not found] <mailman.82083.1657699581.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-07-13 9:43 ` John Tromp
2022-07-13 11:56 ` John Tromp
2022-07-13 12:11 ` Gino Pinuto
2022-07-13 13:29 ` Manuel Costa
2022-07-14 9:33 ` vjudeu
2022-07-14 9:57 ` Erik Aronesty
2022-07-14 11:42 ` Gino Pinuto
2022-07-14 16:01 ` Erik Aronesty
2022-07-14 16:27 ` Manuel Costa
2022-07-15 6:03 ` vjudeu
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=YszA159sG+WFfYFi@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=macwhyte@gmail$(echo .)com \
/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