From: Bram Cohen <bram@chia•net>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] bitcoin scripting and lisp
Date: Tue, 15 Mar 2022 23:45:48 -0700 [thread overview]
Message-ID: <CAHUJnBDX5_HkocD4DMT05g59aWyrYMt=dDEBS_3hraJMoVOSXA@mail.gmail.com> (raw)
In-Reply-To: <20220310064717.GA7597@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns <aj@erisian•com.au> wrote:
>
> To redo the singleton pattern in bitcoin's context, I think you'd have
> to pass in both the full tx you're spending (to be able to get the
> txid of its parent) and the full tx of its parent (to be able to get
> the scriptPubKey that your utxo spent) which seems klunky but at least
> possible (you'd be able to drop the witness data at least; without that
> every tx would be including the entire history of the singleton).
>
Yes that's the idea. Since the parent transaction is in the blockchain it
could be pulled in automatically without having to charge vbytes for it.
> If softfork is just doing a best effort for whatever opcodes it knows
> about, and otherwise succeeding, then it has to succeed, and your
> script/output has become anyone-can-spend.
>
That can be alleviated by when things call untrusted code they can wrap it
in a guard which can be the soft fork opcode itself.
>
> On the other hand, if you could tell the softfork op that you only wanted
> ops up-to-and-including the 118 softfork, then it could reject fakeopcode
> and fail the script, which I think gives the desirable behaviour.
>
A simple approach to versioning like that may be more expedient. Soft
forking in CLVM isn't implemented yet.
[-- Attachment #2: Type: text/html, Size: 1984 bytes --]
next prev parent reply other threads:[~2022-03-16 6:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.30513.1646355894.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-03-07 6:26 ` Bram Cohen
2022-03-07 22:56 ` ZmnSCPxj
2022-03-09 2:24 ` Bram Cohen
2022-03-08 1:27 ` Anthony Towns
2022-03-08 3:06 ` ZmnSCPxj
2022-03-09 3:07 ` Bram Cohen
2022-03-09 14:30 ` ZmnSCPxj
2022-03-16 6:40 ` Bram Cohen
2022-03-16 15:09 ` ZmnSCPxj
2022-03-11 4:46 ` Anthony Towns
2022-03-16 6:52 ` Bram Cohen
2022-03-16 14:54 ` ZmnSCPxj
2022-03-19 17:34 ` Bram Cohen
2022-03-22 23:37 ` Anthony Towns
2022-03-09 2:54 ` Bram Cohen
2022-03-10 6:47 ` Anthony Towns
2022-03-16 6:45 ` Bram Cohen [this message]
2022-03-04 1:04 Anthony Towns
2022-03-04 23:10 ` ZmnSCPxj
[not found] ` <CAD5xwhiZx+dp46Gn23tQRKc5PgJHmaJ_HC-38VB5WdJjWVVc4g@mail.gmail.com>
2022-03-05 13:41 ` Jeremy Rubin
2022-03-05 20:10 ` Russell O'Connor
2022-03-05 23:20 ` ZmnSCPxj
2022-03-06 2:09 ` Russell O'Connor
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='CAHUJnBDX5_HkocD4DMT05g59aWyrYMt=dDEBS_3hraJMoVOSXA@mail.gmail.com' \
--to=bram@chia$(echo .)net \
--cc=aj@erisian$(echo .)com.au \
--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