<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 27, 2019 at 3:21 AM Anthony Towns &lt;<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O&#39;Connor via bitcoin-dev wrote:<br>
&gt; Bitcoin Script appears designed to be a flexible programmable system that<br>
&gt; provides generic features to be composed to achieve various purposes.<br>
<br>
Counterpoint: haven&#39;t the flexibly designed parts of script mostly been<br>
a failure -- requiring opcodes to be disabled due to DoS vectors or<br>
consensus bugs, and mostly not being useful in practice where they&#39;re<br>
still enabled in BTC or on other chains where they have been re-enabled<br>
(eg, Liquid and BCH)?<br></blockquote><div><br></div><div>You may have a point.  However, I&#39;m still inclined to think that problem is that you want some subset of concatenation, arithmetic, CHECKDATASIG, transaction reflection and/or covenants in order to create particularly useful programs.<br></div><div><br></div><div>A while ago, I was designing a moderately sophisticated Script for Elements Alpha to see if I could implement a toy game, but ultimately I was thwarted due to the fact that Elements Alpha didn&#39;t support multiplication.</div><div>I did briefly consider using repeated additions and nested if statements to implement multiplication since I was expecting my numbers to be 11 or less, but ultimately I decided to just continue my work on an alternative to Script rather than trying to work around the missing multiplication.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Instead, I propose that, for the time being, we simply implement OP_CAT and<br>
&gt; OP_CHECKSIGFROMSTACKVERIFY.<br>
<br>
FWIW, I&#39;d like to see CAT enabled, though I&#39;m less convinced about a<br>
CHECKSIG that takes the message from the stack. I think CAT&#39;s plausibly<br>
useful in practice, but a sig against data from the stack seems more<br>
useful in theory than in practice. Has it actually seen use on BCH or<br>
Liquid, eg?  (Also, I think BCH&#39;s name for that opcode makes more sense<br>
than Elements&#39; -- all the CHECKSIG opcodes pull a sig from the stack,<br>
after all)<br>
<br>
&gt; * Transaction introspection including:<br>
&gt; + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the<br>
&gt; nature of the construction.<br>
<br>
I think simulating an ANYPREVOUT sig with a data signature means checking:<br>
<br>
    S1 P CHECKSIG -- to check S1 is a signature for the tx<br>
<br>
    S1 H_TapSighash(XAB) P CHECKDATASIG<br>
         -- to pull out the tx data &quot;X&quot;, &quot;A&quot;, &quot;B&quot;)<br>
<br>
    S2 H_TapSighash(XCB) Q CHECKDATASIG<br>
         -- for the ANYPREVOUT sig, with A changed to C to<br>
            avoid committing to prevout info<br>
<br>
    X SIZE 42 EQUALVERIFY<br>
    B SIZE 47 EQUALVERIFY<br>
         -- to make sure only C is replaced from &quot;XCB&quot;<br>
<br>
So to get all those conditions checked, I think you could do:<br>
<br>
   P 2DUP TOALT TOALT CHECKSIGVERIFY<br>
   SIZE 42 EQUALVERIFY<br>
   &quot;TapSighash&quot; SHA256 DUP CAT SWAP CAT TOALT<br>
   SIZE 47 EQUALVERIFY TUCK<br>
   CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT<br>
   CHECKDATASIGVERIFY<br>
   SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG<br>
<br>
Where the stack elements are, from top to bottom:<br>
<br>
   S1: (65B) signature by P of tx<br>
   X:  (42B) start of TapSighash spec<br>
   B:  (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,<br>
             key_version, codesep_pos)<br>
   A:  (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,<br>
             scriptPubKey and outpoint)<br>
   C:   (1B) alternate middle (different spend_type)<br>
   S2: (64B) signature of &quot;XCB&quot; by key Q<br>
<br>
So 298B for the witness data, and 119B or so for the script (if I&#39;ve not<br>
made mistakes), versus &quot;P CHECKSIGVERIFY Q CHECKSIG&quot; and S2 and S1 on<br>
the stack, for 132B of witness data and 70B of script, or half that if<br>
the chaperone requirement is removed.<br></blockquote><div><br></div><div>I haven&#39;t checked your details but the above looks about correct to me.</div><div><br></div><div>So what I was thinking is that we could add CHECKDATASIG first, and then people could get started on actually using ANYPREVOUT in practice and we can take our time to debate the merits of the chaperone vs non-chaperone, and possibly learn something about actual use before making a decision.  There is no doubt that using ANYPREVOUT directly uses less weight, but they seem close enough to that it the simulation is usable, though perhaps far enough apart that we would want to eventually add ANYPREVOUT.  However, do keep in mind that our goal is not to minimize the weight of specific redemption policies.  The weight of implementing any particular redemption policy in Script is somewhat arbitrary to begin with anyways, being dependent on the choices made for the Script language operations and its encoding.  Again, if our goal were to minimize weight for specific redemption policies we should abandon SCRIPT and directly use a language similar to Miniscript, and/or just directly implement an enumeration of policies.</div><div><br></div><div>However, my proposal CHECKSIGFROMSTACK (aka CHECKDATASIG) proposal was based on my argument that CHECKDATASIG covenant abilities wouldn&#39;t be controversial since it was limited to self-recursion and had less than 64-bits of state space.  But ZmnSCPxj has shown that my conclusions were hasty and that self-recursion has access to arbitrarily large amounts of state space.  In light of this, it would appear that self-recursive covenants is nearly as powerful as arbitrary recursive covenants, and therefore is nearly as controversial.</div><div><br></div><div>So, while I do think that we should add support for recursive covenants to Bitcoin, we probably not ready to add it yet given the controversy around the far more innocent ANYPREVOUT.  I do think it would be useful to add support for CAT and CHECKDATASIG in order to implement MPC with penalties, but perhaps we should support that via a HASH_tapdata digest function rather than SHA256, in order to avoid any accidental covenants.  Of course doing so would no longer count as &quot;an alternative&quot; proposal to ANYPREVOUT or COSHV, and simply &quot;an additional&quot; proposal.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I think you&#39;d need to complicate it a bit further to do the<br>
ANYPREVOUTANYSCRIPT variant, where you retain the commitment to<br>
amount/nseq but drop the commitment to tapleaf_hash.<br>
<br>
&gt; I feel that this style of generic building blocks truly embodies what is meant<br>
&gt; by &quot;programmable money&quot;.<br>
<br>
For practical purposes, this doesn&#39;t seem like a great level of<br>
abstraction to me. It&#39;s certainly better at &quot;permissionless innovation&quot;<br>
though.<br>
<br>
You could make these constructions a little bit simpler by having a<br>
&quot;CHECK_SIG_MSG_VERIFY&quot; opcode that accepts [sig msg key], and does &quot;sig<br>
key CHECKSIGVERIFY&quot; but also checks the the provided msg was what was<br>
passed into bip-schnorr.<br></blockquote><div><br></div><div>The whole point is to keep the functionality simple and let users program what they want.  What we don&#39;t want to do is tailor an opcode for the specific use case we have in mind, because that just comes at the expense of all the use cases we don&#39;t have in mind.<br></div></div></div>