From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
Date: Fri, 18 Feb 2022 07:34:52 +0000 [thread overview]
Message-ID: <8RVJuPI1U7Iw74uWuGwQyJIvJYBWzJM9RJZKNy_KXAMaFJP9uHmAaq8UOCJ2jxiM6n1CvyYrUXZ0TUWOPoZ5Ja6oCtLsf62qhS7aN_vkZMw=@protonmail.com> (raw)
In-Reply-To: <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
Good morning Dave,
> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
>
> > Whether [recursive covenants] is an issue or not precluding this sort
> > of design or not, I defer to others.
>
> For reference, I believe the last time the merits of allowing recursive
> covenants was discussed at length on this list[1], not a single person
> replied to say that they were opposed to the idea.
>
> I would like to suggest that anyone opposed to recursive covenants speak
> for themselves (if any intelligent such people exist). Citing the risk
> of recursive covenants without presenting a credible argument for the
> source of that risk feels to me like (at best) stop energy[2] and (at
> worst) FUD.
Let me try to give that a shot.
(Just to be clear, I am not an artificial intelligence, thus, I am not an "intelligent such people".)
The objection here is that recursion can admit partial (i.e. Turing-complete) computation.
Turing-completeness implies that the halting problem cannot be solved for arbitrary programs in the language.
Now, a counter-argument to that is that rather than using arbitrary programs, we should just construct programs from provably-terminating components.
Thus, even though the language may admit arbitrary programs that cannot provably terminate, "wise" people will just focus on using that subset of the language, and programming styles within the language, which have proofs of termination.
Or in other words: people can just avoid accepting coin that is encumbered with a SCRIPT that is not trivially shown to be non-recursive.
The counter-counter-argument is that it leaves such validation to the user, and we should really create automation (i.e. lower-level non-sentient programs) to perform that validation on behalf of the user.
***OR*** we could just design our language so that such things are outright rejected by the language as a semantic error, of the same type as `for (int x = 0; x = y; x++);` is a semantic error that most modern C compilers will reject if given `-Wall -Werror`.
Yes, we want users to have freedom to shoot themselves in the feet, but we also want, when it is our turn to be the users, to keep walking with two feet as long as we can.
And yes, you could instead build a *separate* tool that checks if your SCRIPT can be proven to be non-recursive, and let the recursive construct remain in the interpreter and just require users who don't want their feet shot to use the separate tool.
That is certainly a valid alternate approach.
It is certainly valid to argue as well, that if a possibly-recursive construct is used, and you cannot find a proof-of-non-recursion, you should avoid coins encumbered with that SCRIPT (which is just a heuristic that approximate a tool for proof-of-non-recursion).
On the other hand, if we have the ability to identify SCRIPTs that have some proof-of-non-recursion, why is such a tool not built into the interpreter itself (in the form of operations that are provably non-recursive), why have a separate tool that people might be too lazy to actually use?
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-02-18 7:35 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 17:20 [bitcoin-dev] " Russell O'Connor
2022-01-26 22:16 ` Jeremy
2022-01-27 4:20 ` James Lu
2022-01-27 19:16 ` Russell O'Connor
2022-01-28 0:18 ` James O'Beirne
2022-01-28 13:14 ` Michael Folkson
2022-01-28 14:17 ` Anthony Towns
2022-01-28 16:38 ` Jeremy
2022-01-28 14:13 ` Russell O'Connor
2022-01-28 15:14 ` James O'Beirne
2022-01-29 15:43 ` Russell O'Connor
2022-01-29 17:02 ` Jeremy Rubin
[not found] ` <CAD5xwhjHv2EGYb33p2MRS=VSz=ciGwAsiafX1yRHjxQEXfykSA@mail.gmail.com>
2022-01-29 17:14 ` Russell O'Connor
2022-01-31 2:18 ` Anthony Towns
2022-01-28 1:34 ` Anthony Towns
2022-01-28 13:56 ` Russell O'Connor
2022-02-01 1:16 ` Anthony Towns
2022-02-08 2:16 ` Russell O'Connor
2022-02-17 14:27 ` Anthony Towns
2022-02-17 14:50 ` Russell O'Connor
2022-02-08 3:40 ` Rusty Russell
2022-02-08 4:34 ` Jeremy Rubin
2022-02-11 0:55 ` [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " David A. Harding
2022-02-11 3:42 ` Jeremy Rubin
2022-02-11 17:42 ` James O'Beirne
2022-02-11 18:12 ` digital vagabond
2022-02-12 10:54 ` darosior
2022-02-12 15:59 ` Billy Tetrud
2022-02-17 15:15 ` Anthony Towns
2022-02-18 7:34 ` ZmnSCPxj [this message]
2022-02-23 11:28 ` ZmnSCPxj
2022-02-23 18:14 ` Paul Sztorc
2022-02-24 2:20 ` ZmnSCPxj
2022-02-24 6:53 ` Anthony Towns
2022-02-24 12:03 ` ZmnSCPxj
2022-02-26 5:38 ` Billy Tetrud
2022-02-26 6:43 ` ZmnSCPxj
2022-02-27 0:58 ` Paul Sztorc
2022-02-27 2:00 ` ZmnSCPxj
2022-02-27 7:25 ` ZmnSCPxj
2022-02-27 16:59 ` Billy Tetrud
2022-02-27 23:50 ` Paul Sztorc
2022-02-28 0:20 ` Paul Sztorc
2022-02-28 6:49 ` ZmnSCPxj
2022-02-28 7:55 ` vjudeu
2022-03-04 8:42 ` ZmnSCPxj
2022-03-04 13:43 ` vjudeu
2022-02-28 22:54 ` Paul Sztorc
2022-03-01 5:39 ` Billy Tetrud
2022-03-02 0:00 ` Paul Sztorc
2022-03-04 12:35 ` Billy Tetrud
2022-03-04 20:06 ` Paul Sztorc
2022-02-26 6:00 ` Anthony Towns
2022-02-15 8:45 ` [bitcoin-dev] " Rusty Russell
2022-02-15 18:57 ` Jeremy Rubin
2022-02-15 19:12 ` Russell O'Connor
2022-02-16 2:26 ` Rusty Russell
2022-02-16 4:10 ` Russell O'Connor
2022-02-14 2:40 [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was " Lucky Star
2022-02-26 7:47 Prayank
2022-02-26 16:18 ` Billy Tetrud
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='8RVJuPI1U7Iw74uWuGwQyJIvJYBWzJM9RJZKNy_KXAMaFJP9uHmAaq8UOCJ2jxiM6n1CvyYrUXZ0TUWOPoZ5Ja6oCtLsf62qhS7aN_vkZMw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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