From: Erik Aronesty <erik@q32•com>
To: "Russell O'Connor" <roconnor@blockstream•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Date: Sat, 14 May 2022 09:32:18 -0400 [thread overview]
Message-ID: <CAJowKgKfy7-2UsBoypHmPkGnMb5V+m7Mt3ek5scsEHwj0YW9wA@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoK=stZaPcTNfC_KdOxbQp=VyORwC3osSm3sTeQ0WZ4ejYQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation. The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>
I don't think this should be discounted. I think it's worthwhile to
willingly include possibly less-than-awesome, but proven perfectly-safe
opcodes, knowing we will have to validate them forever, even if new, cooler
and more widely-used ones replace them years from now.
I honestly don't think the development of the latter will happen without
some version of the former.
Personally I am satisfied:
- the safety of covenants, in general, is covered by how addresses are
generated
- fears of forced forward-encumbrance are not any worse than can be
easily done today
- ctv+apo, cat+csfs are fine, but we should pick ones that everyone
thinks are "good enough for everyone who cares about them"
- they are not an undue burden on nodes in terms of
validate-cpu-cycles-per-byte (have we proven this?)
- the complexity is low, code is easy to validate
- won't introduce DDOS attack vectors (also needs to be proven i think?)
- the game theory underpinning selfish miner support of the chain won't
be altered by causing a widespread use of on-chain leveraging instruments
(shorting bitcoin on-chain would be dangerous, for example)
>
[-- Attachment #2: Type: text/html, Size: 2076 bytes --]
prev parent reply other threads:[~2022-05-14 13:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-06 22:30 Jorge Timón
2022-05-07 3:06 ` ZmnSCPxj
2022-05-07 3:52 ` vjudeu
2022-05-07 13:31 ` Jorge Timón
2022-05-11 15:25 ` alicexbt
2022-05-11 16:03 ` vjudeu
2022-05-07 13:27 ` Jorge Timón
2022-05-07 14:08 ` ZmnSCPxj
[not found] ` <CABm2gDo1wTOoWcNgJ4mUgSB3KCtBSnjqe3nwVBSL+7=ziDJ==w@mail.gmail.com>
2022-05-07 22:28 ` ZmnSCPxj
2022-05-08 2:03 ` Nadav Ivgi
2022-05-08 2:19 ` ZmnSCPxj
2022-05-11 10:57 ` vjudeu
2022-05-11 11:42 ` ZmnSCPxj
2022-05-11 19:41 ` Russell O'Connor
2022-05-12 3:07 ` ZmnSCPxj
2022-05-12 10:48 ` Russell O'Connor
2022-05-13 21:43 ` Anthony Towns
2022-05-13 23:33 ` Russell O'Connor
2022-05-14 13:32 ` Erik Aronesty [this message]
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=CAJowKgKfy7-2UsBoypHmPkGnMb5V+m7Mt3ek5scsEHwj0YW9wA@mail.gmail.com \
--to=erik@q32$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=roconnor@blockstream$(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