path: root/38/456df1a8a1285cb993f027c7ab7a3bcec41a56

Delivery-date: Wed, 11 Dec 2024 22:15:40 -0800
Received: from mail-qt1-f192.google.com ([209.85.160.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCTP33FZ3YMBBA775G5AMGQE44JVYSQ@googlegroups.com>)
	id 1tLcU7-0002o5-Sf
	for bitcoindev@gnusha.org; Wed, 11 Dec 2024 22:15:40 -0800
Received: by mail-qt1-f192.google.com with SMTP id d75a77b69052e-46788c9c217sf6096951cf.2
        for <bitcoindev@gnusha.org>; Wed, 11 Dec 2024 22:15:39 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1733984133; cv=pass;
        d=google.com; s=arc-20240605;
        b=g59ZoZlO8fec1ecs3/jlLXQZzzCZosl1nlGaFMgMdBEPjsH7QBtW8CNFKux50nSyDF
         mICRaeHcwsTP/PDZtodRHSPpkcGRymup9/KCHqQsYN7yzS/wi7DOuIFH6WJzGwJf5b8Q
         KY5PBFqmpSsWUtwues5flaNMZg/zOPyky+wlZlEqQvL6gZTPWc0YAkAnAJaDXFFXXjxn
         gay+t/dS9INvTUcXrpahz5f3F5CTpeN/CxEbOHk/I3cQWHwMXiS641xVD8nnqzGeuryj
         c/yBQ7iZ0hPkowFAp/+UZxlkDi0rymm1DmSRHX8/uy1ETQTJXPNmPzVXQQeialFVI0Mf
         H+5g==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature;
        bh=Bizd721vOJFozecfSavza3s+D75SO/7+cVCPAtdsgoE=;
        fh=zitupQkknjo6slWdiOd9RgxEIUiUIlK1jh50Gq1Celo=;
        b=BOYKoQAGMlndyREhrJcdnRh2/PPytgPPqnOgwflbrC7d5J96dJa7D52/Qwx6sjIUeo
         eZ2jzqapDFiE74vie/B+rA44NqbM4qUrnAI/hNbYzkA9njCmSqDnPGbkv0lRbbrVW7il
         xUkP0p65VvUw2wc9VEskS1APTTthC5X+mhbCQ6iD6gEBvvQijpTxLzuRyZkAR6/9Hd5q
         bF84bvI9+sFf3Ys89yu651qgrRMrsBIHaXI3+m2AFO5iv/llhYWehFPsBp6TB5v0vFa0
         UTBkuz32jLCf/X6FYhm4Vq2fnDYjjzwWDZzO5ykssxXi4hFVkKWj15ZYoP7W78pmxWa0
         fjyA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@l2iterative-com.20230601.gappssmtp.com header.s=20230601 header.b=OaVkUlwu;
       spf=pass (google.com: domain of weikeng.chen@l2iterative.com designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=weikeng.chen@l2iterative.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1733984133; x=1734588933; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Bizd721vOJFozecfSavza3s+D75SO/7+cVCPAtdsgoE=;
        b=W49xvogInnMpDBCRSWJxdr1yMY6lOchK7jP6TyMsdlcRS2/438UC/vgc9249epaeYb
         59MMRZrMb5KSJ1KVCJWmAFSgCm+Hh0RlyIOGS4SBeZjqgymuB/iwdbJiSBBA+90zTJn2
         kKhDN1fAEAIo+ZfrwIkNxVZDdFe6nhHpYP5amWM/2hOPyzCegeY6XNFjbB3kqEFs6jit
         JMIld3qQo3HUwZ4lwify8NH5zDMxJd4Zg2HVHi6c0PcYdFsUX44N5o4NwgP5Be/KiJyv
         V1fdvPhUQV0TwkD1R9qxi3ZgFLfxhXZ6ohr5v0XsidmPBOjmgmF9j23boN8mVb1AOJST
         79Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1733984133; x=1734588933;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=Bizd721vOJFozecfSavza3s+D75SO/7+cVCPAtdsgoE=;
        b=XJa2OKsa7zZTb+SDToIEzmf6rBzYZuyHvP8ycUSy9voiqg1rJAYmokVRFl8a6YJxfh
         MeEJO37dXAJP2xNbAnjT2ilajP+uPHGSnF8kWEIu77YZv/uXaSVyWWiCfYL2mhTq1L8+
         kvwWdHMXAFrL4QNpIspsN15gH33807T1ey9brSfvdZ6jhgbHmj0hnuU7Io6gTicg0Qnz
         FgG3SOtsVuLewJEnaQ96fdSsh04jh+qZ4VhX1K1HdLr7DM5vAw405GRRh3mjB3tjEkGC
         l+SWZx7/iRuc5r8/z6xYxZArIP27HxsfxlFp/WK5rwYu31KWQY+Z92ld9SPoRErnYMN5
         uD5g==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWTx05LN3iZvhd2wUvaKTPHsBKBj8lMxOP6kwX0U4n+Ov4bEMlXQE9UuhQsjAkGNb0w+QvnYZq0ZKn3@gnusha.org
X-Gm-Message-State: AOJu0Yx9TipEHkfjaozazjOcLvugAFAbtrtsioxbig5ZNrLLBk35k/Y4
	krgQuhASmJxiCzoj3Mre3BUnmnh6wAq/QbqKYwwkTld54vK/OF36
X-Google-Smtp-Source: AGHT+IEsp2uGMhfzxn1KJ15I9nIFfHUm+A4y6+SGdjkIdla53+7Qm9ZlBtM0fn+Lv3uBwW3v0Ro7uQ==
X-Received: by 2002:ac8:574e:0:b0:467:86c0:4bff with SMTP id d75a77b69052e-46796281971mr37737751cf.51.1733984133332;
        Wed, 11 Dec 2024 22:15:33 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:1102:b0:465:2fdd:88a5 with SMTP id
 d75a77b69052e-46795bf2a10ls1384321cf.0.-pod-prod-09-us; Wed, 11 Dec 2024
 22:15:30 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCV/6GldaTizT2FYGYW5isTQz+RN0o2VAAK0cw3NGjeHs/ndlenBkj1xGR4A+2OzFqA96lrsPBpvm8Pr@googlegroups.com
X-Received: by 2002:a05:622a:7408:b0:467:7745:f0a9 with SMTP id d75a77b69052e-46796154950mr37565491cf.4.1733984130733;
        Wed, 11 Dec 2024 22:15:30 -0800 (PST)
Received: by 2002:a05:620a:351:b0:7b6:67a8:4fcd with SMTP id af79cd13be357-7b6f3238accms85a;
        Wed, 11 Dec 2024 19:17:27 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCUyc9Ep4/PO3Jkc4lJJoIH1IsZJ3ExBBT54FpYRBupUYlMnzen8+zy3jzGIvtW7mDBizfX57ACAtIzj@googlegroups.com
X-Received: by 2002:a05:6000:144d:b0:386:1ab1:ee34 with SMTP id ffacd0b85a97d-3864ce4b02cmr3465012f8f.9.1733973445516;
        Wed, 11 Dec 2024 19:17:25 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1733973445; cv=none;
        d=google.com; s=arc-20240605;
        b=D2kiEkol9DAdH5JnMElKlKEinYtsfP3m4dGV6Ar1apkIJ0ksXQh4rHIAdECRw58LDw
         SHmDUrkulxTbcgFwauBni0Pn9A4p0lqoirI9OY4y3jbQcyu21IdyxjNxIUS44ZN+emJZ
         NffN7LLq5BZ9izPBNYTs/sly7jAUjln3u3HJXqfyc7ZysvHXEbpPAcxmaXX28D4QKkFs
         aAtgWym8db1N7AQZsJYH16qC66f7cjJX2kAGTJZjWyvvAoQ1J2yghrZjUpo0WdgG1SPv
         71X0O5suZ1oe1nsRo9u1bT+HYEoidkjU4RVP0K2LkANrXoYLSsGcVsORILki/2HQLO9G
         cUlw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=9yWe9Qh+Tz+Xvk4V+nGh6ZIKJf+xTHvR64efJRRYS/E=;
        fh=bAOe1ElzgQ0liRG6IjBa00BmR17TP2E/rsN1I37RWvY=;
        b=iRkbHESqVbmvwWIEyAIoWO86FGxmiuEQRsvpELexF7/D74C0b0rDBrKwZMukiDFlW3
         o1wliMslfSb8XswwkRqrxiULUZQA+YtCxgHR5P+U6xpCVlv4rVQ6v7NddgFQHw1a1OEq
         SEKYBLlnkc7sHLVuEI/2Yz5i0NqscLkTlqwiqlbpgfTeIxdY8JAy9LPfvQXRPTAsVxfx
         fQ0/U5Jb0eicOJMP0q8jp1n1OCw0oOesmnUPDPk8gogPvRA4jvDCTpffgZbbvzQNQeok
         Nyyfrt2H7huq7qMnqzruvIE69B/qfJN/TVrNywUMFuDwyqkNmyVooqQyDricVl5c5rwG
         zI6Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@l2iterative-com.20230601.gappssmtp.com header.s=20230601 header.b=OaVkUlwu;
       spf=pass (google.com: domain of weikeng.chen@l2iterative.com designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=weikeng.chen@l2iterative.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com. [2a00:1450:4864:20::131])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-387824fc81csi43620f8f.6.2024.12.11.19.17.24
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 11 Dec 2024 19:17:24 -0800 (PST)
Received-SPF: pass (google.com: domain of weikeng.chen@l2iterative.com designates 2a00:1450:4864:20::131 as permitted sender) client-ip=2a00:1450:4864:20::131;
Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-54026562221so143154e87.1
        for <bitcoindev@googlegroups.com>; Wed, 11 Dec 2024 19:17:24 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCUN5G0GnjRnc/NzGW5QMhVXUncji0PwUFqGhgyDWX/nsD5ToDedtzZwaca/YWhPtxGQLjoGWo7bGaYh@googlegroups.com
X-Gm-Gg: ASbGnctFqyVbPkQdccc6TiWYO6ce6RB3VC3C28vMRpZKSLZeuI7J26IOSA4aExN1YIB
	o9sHfZZrAIFTo1EA5dFc+FmRJu/5y1Q4TvbQa
X-Received: by 2002:a05:6512:2348:b0:540:1d37:e79 with SMTP id
 2adb3069b0e04-5402a5e542bmr1533882e87.27.1733973443889; Wed, 11 Dec 2024
 19:17:23 -0800 (PST)
MIME-Version: 1.0
References: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com>
 <Z1dAQ8pSIqn8XA56@camus> <Z1dp0Jtbrkcf7Roi@console> <87ttbccrql.fsf@rustcorp.com.au>
In-Reply-To: <87ttbccrql.fsf@rustcorp.com.au>
From: Weikeng Chen <weikeng.chen@l2iterative.com>
Date: Thu, 12 Dec 2024 11:17:12 +0800
Message-ID: <CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ@mail.gmail.com>
Subject: Re: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why
 it should be a real opcode
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Brandon Black <freedom@reardencode.com>, Andrew Poelstra <apoelstra@wpsoftware.net>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000002c6c8006290a27a7"
X-Original-Sender: weikeng.chen@l2iterative.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@l2iterative-com.20230601.gappssmtp.com header.s=20230601
 header.b=OaVkUlwu;       spf=pass (google.com: domain of weikeng.chen@l2iterative.com
 designates 2a00:1450:4864:20::131 as permitted sender) smtp.mailfrom=weikeng.chen@l2iterative.com;
       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.7 (/)

--0000000000002c6c8006290a27a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I was mostly thinking about the names atm. OP_RETURN_TRUE may be a name
less confusing than OP_SUCCESS. It helps if one day we nickname/alias
OP_RETURN as OP_RETURN_FALSE.

This could eventually become an opcode BIP proposal that is pretty
causal---if a major soft fork happens (like the one that adds tapscript),
it could be piggybacked into it, otherwise, it would just stay as a
proposal as there is no urgency since it doesn't enhance the ability of
Bitcoin script (you can emulate it), but more to avoid bugs in code and for
clarity.

On Thu, Dec 12, 2024 at 10:54=E2=80=AFAM Rusty Russell <rusty@rustcorp.com.=
au>
wrote:

> Brandon Black <freedom@reardencode.com> writes:
> > Hey list,
> >
> > On 2024-12-09 (Mon) at 19:08:51 +0000, Andrew Poelstra wrote:
> >> On Mon, Dec 09, 2024 at 05:27:54AM -0800, Weikeng Chen wrote:
> >> > When I am implementing fraud proofs in Bitcoin script, I find it
> useful to
> >> > have an opcode "OP_SUCCESS" that will mark the execution to be
> successful
> >> > without running the rest of the script, if this opcode is being
> executed.
> >> > This is useful for writing code for fraud proofs such as BitVM, wher=
e
> the
> >> > verifier wins if it finds one mismatch, and the verifier does not
> need to
> >> > show the other mismatches.
> >> >
> >> > This OP_SUCCESS is weaker version of the OP_SUCCESSx in the Taproot
> >> > upgrade, which marks the execution as successful for the mere
> presence of
> >> > OP_SUCCESSx anywhere in the script. Rusty Russell in a 2023 article,
> >> > "Covenants: Examining ScriptPubkeys in Bitcoin Script", also
> mentioned
> >> > about the usefulness of such an opcode.
> >> >
> >> > <snip>
> >>
> >> In short, for purpose of softforking upgrade mechanism, the existing
> >> SUCCESS codes give us way more freedom of action.
> >>
> >> But it sounds like you want a "weak SUCCESS" opcode in order to use th=
e
> >> success semantics, not as an upgrade mechanism. Maybe it makes sense t=
o
> >> propose that one of the existing OP_SUCCESSx opcodes should be
> >> softforked to become OP_WEAK_SUCCESS?
> >
> > An alternative that Rusty Russel has discussed wanting as part of his
> > script restoration work is "OP_SEGMENT" which would split the script
> > execution for purposes of SUCCESS checking, allowing (for example) a
> > prefix to be required to execute before an arbitrary user provided
> > script that might contain an OP_SUCCESS.
> >
> > It occurred to me today when thinking about Weikeng's post that we can
> > slightly weaken the existing OP_SUCCESS behavior while retaining
> > essentially all of its benefits in practice without introducing
> > OP_SEGMENT by leveraging OP_CODESEPARATOR. Redefine OP_SUCCESS with a
> > soft fork from "make the script unconditionally valid" to "make the
> > script segment unconditionally valid", and define a script segment as
> > "each lexicographic section of the script containing no
> > OP_CODESEPARATOR".
> >
> > The script interpreter can perform SUCCESS checking as it currently doe=
s
> > until it encounters an OP_CODESEPARATOR. Each OP_CODESEPARATOR gets a
> > "SUCCESS" flag defaulted to false and SUCCESS checking now sets that
> > flag to true on the most recently encountered OP_CODESEPARATOR.
> >
> > During script execution, whenever an OP_CODESEPARATOR is popped (not
> > executed) its "SUCCESS" flag value is copied to the interpreter state.
> > After this state setting conditional, if the interpreter "SUCCESS" flag
> > is true, and fExec is true, the script immediately succeeds.
>
> Beware success inside branches?  This is why I preferred to segment the
> script and scan for OP_SUCCESS and evaluate each part in order (if you
> have part of an if statement inside one segment, you fail as expected).
> This is actually not that different inside Bitcoin's script.cpp.
>
> But that's kind of a detail.  IMHO there's nothing fundamentally wrong
> with runtime success opcodes, in fact several proposals work better if
> you allow them (e.g. "undefined bit patterns in operand to OP_TXHASH
> cause immediate success" lets you reserve some bits for future
> extension).
>
> (Also: OP_CODESEPARATOR is cursed, so I chose a different name :)
>
> Cheers,
> Rusty.
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ%40mail.gmail.com.

--0000000000002c6c8006290a27a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I was mostly thinking about the names atm. OP_RETURN_TRUE =
may be a name less confusing than OP_SUCCESS. It helps if one day we nickna=
me/alias OP_RETURN as OP_RETURN_FALSE.<div><br></div><div>This could eventu=
ally become an opcode BIP proposal that is pretty causal---if a major soft =
fork happens (like the one that adds tapscript), it could be piggybacked in=
to it, otherwise, it would just stay as a proposal as there is no urgency s=
ince it doesn&#39;t enhance the ability of Bitcoin script (you can emulate =
it), but more to avoid bugs in code and for clarity.</div></div><br><div cl=
ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a=
ttr">On Thu, Dec 12, 2024 at 10:54=E2=80=AFAM Rusty Russell &lt;<a href=3D"=
mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">Brandon Black &lt;<a hre=
f=3D"mailto:freedom@reardencode.com" target=3D"_blank">freedom@reardencode.=
com</a>&gt; writes:<br>
&gt; Hey list,<br>
&gt;<br>
&gt; On 2024-12-09 (Mon) at 19:08:51 +0000, Andrew Poelstra wrote:<br>
&gt;&gt; On Mon, Dec 09, 2024 at 05:27:54AM -0800, Weikeng Chen wrote:<br>
&gt;&gt; &gt; When I am implementing fraud proofs in Bitcoin script, I find=
 it useful to <br>
&gt;&gt; &gt; have an opcode &quot;OP_SUCCESS&quot; that will mark the exec=
ution to be successful <br>
&gt;&gt; &gt; without running the rest of the script, if this opcode is bei=
ng executed. <br>
&gt;&gt; &gt; This is useful for writing code for fraud proofs such as BitV=
M, where the <br>
&gt;&gt; &gt; verifier wins if it finds one mismatch, and the verifier does=
 not need to <br>
&gt;&gt; &gt; show the other mismatches.<br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; This OP_SUCCESS is weaker version of the OP_SUCCESSx in the T=
aproot <br>
&gt;&gt; &gt; upgrade, which marks the execution as successful for the mere=
 presence of <br>
&gt;&gt; &gt; OP_SUCCESSx anywhere in the script. Rusty Russell in a 2023 a=
rticle, <br>
&gt;&gt; &gt; &quot;Covenants: Examining ScriptPubkeys in Bitcoin Script&qu=
ot;, also mentioned <br>
&gt;&gt; &gt; about the usefulness of such an opcode. <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; &lt;snip&gt;<br>
&gt;&gt; <br>
&gt;&gt; In short, for purpose of softforking upgrade mechanism, the existi=
ng<br>
&gt;&gt; SUCCESS codes give us way more freedom of action.<br>
&gt;&gt; <br>
&gt;&gt; But it sounds like you want a &quot;weak SUCCESS&quot; opcode in o=
rder to use the<br>
&gt;&gt; success semantics, not as an upgrade mechanism. Maybe it makes sen=
se to<br>
&gt;&gt; propose that one of the existing OP_SUCCESSx opcodes should be<br>
&gt;&gt; softforked to become OP_WEAK_SUCCESS?<br>
&gt;<br>
&gt; An alternative that Rusty Russel has discussed wanting as part of his<=
br>
&gt; script restoration work is &quot;OP_SEGMENT&quot; which would split th=
e script<br>
&gt; execution for purposes of SUCCESS checking, allowing (for example) a<b=
r>
&gt; prefix to be required to execute before an arbitrary user provided<br>
&gt; script that might contain an OP_SUCCESS.<br>
&gt;<br>
&gt; It occurred to me today when thinking about Weikeng&#39;s post that we=
 can<br>
&gt; slightly weaken the existing OP_SUCCESS behavior while retaining<br>
&gt; essentially all of its benefits in practice without introducing<br>
&gt; OP_SEGMENT by leveraging OP_CODESEPARATOR. Redefine OP_SUCCESS with a<=
br>
&gt; soft fork from &quot;make the script unconditionally valid&quot; to &q=
uot;make the<br>
&gt; script segment unconditionally valid&quot;, and define a script segmen=
t as<br>
&gt; &quot;each lexicographic section of the script containing no<br>
&gt; OP_CODESEPARATOR&quot;.<br>
&gt;<br>
&gt; The script interpreter can perform SUCCESS checking as it currently do=
es<br>
&gt; until it encounters an OP_CODESEPARATOR. Each OP_CODESEPARATOR gets a<=
br>
&gt; &quot;SUCCESS&quot; flag defaulted to false and SUCCESS checking now s=
ets that<br>
&gt; flag to true on the most recently encountered OP_CODESEPARATOR.<br>
&gt;<br>
&gt; During script execution, whenever an OP_CODESEPARATOR is popped (not<b=
r>
&gt; executed) its &quot;SUCCESS&quot; flag value is copied to the interpre=
ter state.<br>
&gt; After this state setting conditional, if the interpreter &quot;SUCCESS=
&quot; flag<br>
&gt; is true, and fExec is true, the script immediately succeeds.<br>
<br>
Beware success inside branches?=C2=A0 This is why I preferred to segment th=
e<br>
script and scan for OP_SUCCESS and evaluate each part in order (if you<br>
have part of an if statement inside one segment, you fail as expected).<br>
This is actually not that different inside Bitcoin&#39;s script.cpp.<br>
<br>
But that&#39;s kind of a detail.=C2=A0 IMHO there&#39;s nothing fundamental=
ly wrong<br>
with runtime success opcodes, in fact several proposals work better if<br>
you allow them (e.g. &quot;undefined bit patterns in operand to OP_TXHASH<b=
r>
cause immediate success&quot; lets you reserve some bits for future<br>
extension).<br>
<br>
(Also: OP_CODESEPARATOR is cursed, so I chose a different name :)<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAHNroFfAiBMFnUPxqAV-spGB_Nt2juf6-8J3bGAJbDQKM_w2bQ%40mail.g=
mail.com</a>.<br />

--0000000000002c6c8006290a27a7--