Date: Mon, 27 May 2019 17:21:28 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20190527072128.lbzeo6h23qgxvhsy@erisian.com.au>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
Precedence: list

On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Bitcoin Script appears designed to be a flexible programmable system that
> provides generic features to be composed to achieve various purposes.

Counterpoint: haven't the flexibly designed parts of script mostly been
a failure -- requiring opcodes to be disabled due to DoS vectors or
consensus bugs, and mostly not being useful in practice where they're
still enabled in BTC or on other chains where they have been re-enabled
(eg, Liquid and BCH)?

> Instead, I propose that, for the time being, we simply implement OP_CAT and
> OP_CHECKSIGFROMSTACKVERIFY.

FWIW, I'd like to see CAT enabled, though I'm less convinced about a
CHECKSIG that takes the message from the stack. I think CAT's plausibly
useful in practice, but a sig against data from the stack seems more
useful in theory than in practice. Has it actually seen use on BCH or
Liquid, eg?  (Also, I think BCH's name for that opcode makes more sense
than Elements' -- all the CHECKSIG opcodes pull a sig from the stack,
after all)

> * Transaction introspection including:
> + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the
> nature of the construction.

I think simulating an ANYPREVOUT sig with a data signature means checking:

    S1 P CHECKSIG -- to check S1 is a signature for the tx

    S1 H_TapSighash(XAB) P CHECKDATASIG
         -- to pull out the tx data "X", "A", "B")

    S2 H_TapSighash(XCB) Q CHECKDATASIG
         -- for the ANYPREVOUT sig, with A changed to C to
	    avoid committing to prevout info

    X SIZE 42 EQUALVERIFY
    B SIZE 47 EQUALVERIFY
         -- to make sure only C is replaced from "XCB"

So to get all those conditions checked, I think you could do:

   P 2DUP TOALT TOALT CHECKSIGVERIFY
   SIZE 42 EQUALVERIFY
   "TapSighash" SHA256 DUP CAT SWAP CAT TOALT
   SIZE 47 EQUALVERIFY TUCK
   CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT
   CHECKDATASIGVERIFY
   SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG
   
Where the stack elements are, from top to bottom:

   S1: (65B) signature by P of tx
   X:  (42B) start of TapSighash spec
   B:  (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,
             key_version, codesep_pos)
   A:  (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,
             scriptPubKey and outpoint)
   C:   (1B) alternate middle (different spend_type)
   S2: (64B) signature of "XCB" by key Q

So 298B for the witness data, and 119B or so for the script (if I've not
made mistakes), versus "P CHECKSIGVERIFY Q CHECKSIG" and S2 and S1 on
the stack, for 132B of witness data and 70B of script, or half that if
the chaperone requirement is removed.

I think you'd need to complicate it a bit further to do the
ANYPREVOUTANYSCRIPT variant, where you retain the commitment to
amount/nseq but drop the commitment to tapleaf_hash.

> I feel that this style of generic building blocks truly embodies what is meant
> by "programmable money".

For practical purposes, this doesn't seem like a great level of
abstraction to me. It's certainly better at "permissionless innovation"
though.

You could make these constructions a little bit simpler by having a
"CHECK_SIG_MSG_VERIFY" opcode that accepts [sig msg key], and does "sig
key CHECKSIGVERIFY" but also checks the the provided msg was what was
passed into bip-schnorr.

Cheers,
aj