Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 68BEFC0012 for ; Wed, 16 Mar 2022 06:46:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 4796D40424 for ; Wed, 16 Mar 2022 06:46:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=chia.net Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT9U_68TC-vQ for ; Wed, 16 Mar 2022 06:46:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by smtp2.osuosl.org (Postfix) with ESMTPS id 0BD0E40138 for ; Wed, 16 Mar 2022 06:46:00 +0000 (UTC) Received: by mail-lj1-x235.google.com with SMTP id g24so618467lja.7 for ; Tue, 15 Mar 2022 23:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RoPomhW5ep8V400tvu2QeRY4ib5kLhsNm0XS01c/FRc=; b=wuEXBLvooftOdGkvLyq/YDxR24zW6dTUMTO2CqtZiOGYw+tA/OI0OsVvDxFhLocgVV eQvNMSuvT86EZBUNQQolwdLFqouWav94feZFnw6lGpApyQmIn4dmsRrUKukIoI2kRHCN JuOx27DMRpX7Xt+X+cs9i2EudawDowrb0+Jm0VbfF0Ku7tFjn0qPPkRKMOR+D6u3NMrV zJk8Dzl7KxmdwAcqzlV97JqrExybkfs3x8CAU9guO2+D+NNXKhnCbtyl8kt1GVjTL4md XKOPLtm03kD6m5TRyFqLpnkAWNp0nc52plDBBiXvkjDE2L+9LqYGGulEaESi6mJMOQR3 LljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RoPomhW5ep8V400tvu2QeRY4ib5kLhsNm0XS01c/FRc=; b=EoioUk0Oq8BOEyLwCDylwjMwHdaObCNLf0F2JpIJSJXy0+ykxQT4tlKVsOK5YouOpJ t9OuhyfpbTXdmMJPzGO16puJcp5qTiCgWa5cUSVZH+x0i1+E8kKKP0HNwFNoD2CQJU4G Ej/vqoTKuyJ7TVc3mpOvQ+ruDEWcRC/tlRI5v3ymL8vtszOWjYSUXc8XYHbdDYhb72Ob oKOpndLHG5PTGDxJFMHiQQ19BOn+YDslykhpj/rKS00mtFU70xWJP3BIBZXXg1CLrFwz 9c7e6Uyltn0EO8blVBT4ZsvB8w3EpFtwh6rXAvcWOqNRqVv3UKQe6QWBiksD3wo2GuTR Y+qw== X-Gm-Message-State: AOAM5302hJ6M0zuvsbVJ4WrZAB6Vg06J5glHrwTXbCahW9rOjuHZsJJa U+9w+aZ0hVrrvfUi6AkhphRVrZVCa9o97B6cg0rfoQ== X-Google-Smtp-Source: ABdhPJym8OaLw8k7Db4bn/3XJVHH0U8RSVzccUSouB2xkNfuMYA4VHgtU7N9U/jOQYEQojzjvknundZ2D0a6C/3ybSs= X-Received: by 2002:a2e:b5a7:0:b0:249:1e1f:dde9 with SMTP id f7-20020a2eb5a7000000b002491e1fdde9mr15156190ljn.45.1647413158844; Tue, 15 Mar 2022 23:45:58 -0700 (PDT) MIME-Version: 1.0 References: <20220308012719.GA6992@erisian.com.au> <20220310064717.GA7597@erisian.com.au> In-Reply-To: <20220310064717.GA7597@erisian.com.au> From: Bram Cohen Date: Tue, 15 Mar 2022 23:45:48 -0700 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="00000000000021add405da504484" X-Mailman-Approved-At: Wed, 16 Mar 2022 16:04:24 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] bitcoin scripting and lisp X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 06:46:02 -0000 --00000000000021add405da504484 Content-Type: text/plain; charset="UTF-8" On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns 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. --00000000000021add405da504484 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2022 at 10:47 PM Anthony T= owns <aj@erisian.com.au> wro= te:

To redo the singleton pattern in bitcoin's context, I think you'd h= ave
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 transa= ction is in the blockchain it could be pulled in automatically without havi= ng to charge vbytes for it.
=C2=A0
If softfork is just doing a best effort for whatev= er opcodes it knows
about, and otherwise succeeding, then it has to succeed, and your
script/output has become anyone-can-spend.

<= div>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.
=C2=A0

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.
--00000000000021add405da504484--