Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-06-13 Thread Tamas Blummer via bitcoin-dev
ZmnSCPxj already observed in [1] that these ops would enable introspection of any field of the transactions and make both `OP_CHECKLOCKTIMEVERIFY` and `OP_CHECKSEQUENCEVERIFY` superfluous. There is much more to this as enumerated in generic terms by Russel O’Connor below and I would like to add

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-30 Thread Russell O'Connor via bitcoin-dev
On Mon, May 27, 2019 at 3:21 AM Anthony Towns wrote: > 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. > >

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-30 Thread ZmnSCPxj via bitcoin-dev
Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, May 27, 2019 3:21 PM, Anthony Towns via bitcoin-dev wrote: > 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

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-27 Thread Anthony Towns via bitcoin-dev
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

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-26 Thread Russell O'Connor via bitcoin-dev
Allowing multiple inputs is certainly better than the 1 restriction COSHV. However, I agree on your preference for a RISC+CISC approach. Which is why instead of COSHV or CHECK_TXID_TEMPLACE_DATA we should do the more RISC-y thing and begin adding transaction reflection primitives, starting with

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-25 Thread Jeremy via bitcoin-dev
What do you think about having it be OP_CHECK_TXID_TEMPLATE_DATA where the hash checked is the TXID of the transaction with the inputs set to ... (maybe appended to the fee paid)? This allows for a variable number of inputs to be allowed (e.g., one, two, etc). This also fixes potential bugs

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-25 Thread Jeremy via bitcoin-dev
Hi Russell, Thanks for this detailed comparison. The COSHV BIP does include a brief comparison to OP_CHECKSIGFROMSTACKVERIFY and ANYPREVOUT, but this is more detailed. I think that the power from CHECKSIGFROMSTACKVERIFY is awesome. It's clearly one of the more flexible options available and

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-25 Thread Russell O'Connor via bitcoin-dev
In order of escalating scope of amendments to OP_COSHV, I suggest 1) Peeking at surrounding data surrounding data should definitely be replaced by a pushdata-like op-code that uses the subsequent 32-bytes directly. The OP_SUCCESSx upgrade path specifically allows for this, and avoids

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
On Wed, May 22, 2019 at 5:01 PM Russell O'Connor wrote: > In concert, these two operations enable: > > * Oracle signature verification, including discrete log contracts. > Jonas informs me that I've misunderstood how discreet log contracts work. The DLC signatures are not directly checked by

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread ZmnSCPxj via bitcoin-dev
> For better or for worse, without an OP_PUBKEYTWEEK operation available, the > more interesting recursive-covenants remain largely out of reach, with the > exception of a recursive covenant that is only able to send back to its own > address, possibly abusing its own TXO value as a state

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread ZmnSCPxj via bitcoin-dev
Good morning Jimmy, ‐‐‐ Original Message ‐‐‐ On Friday, May 24, 2019 1:36 AM, Jimmy Song via bitcoin-dev wrote: > Hi Russell, > > This is probably a dumb question, but I'd like to get some clarity on your > proposal. > > OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
Hello ZmnSCPxj, I agree that adding OP_CHECKSIGFROMSTACK doesn't preclude adding shortcuts such as `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`, and I agree we ought to support such operations directly, especially if we see widespread use of these constructions in practice. I think it is

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-24 Thread Russell O'Connor via bitcoin-dev
Hi Jimmy, The message could really be anything. For example, in discreet log contracts, AFAIU, you might have a specific public key from a trusted third party (the Oracle) that is signs the closing price of corn in BTC on 2019-05-23 with a particular nonce dedicated to that product-date pair, in

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-23 Thread Jimmy Song via bitcoin-dev
Hi Russell, This is probably a dumb question, but I'd like to get some clarity on your proposal. OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey. Presumably, the message would then have to get constructed as part of the Script execution. What would such a message look

Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-23 Thread ZmnSCPxj via bitcoin-dev
Good morning Russell, While I am sympathetic to this argument from first principles, as I understand it, it requires that provided witness inputs will become larger, compared to "shortcuts" like `SIGHASH_ANYPREVOUT` and `OP_CHECKOUTPUTSHASHVERIFY`. For instance, to simulate

[bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK

2019-05-23 Thread Russell O'Connor via bitcoin-dev
Recently there have been some tapscript proposals, SIGHASH_ANYPREVOUT and OP_CHECKOUTPUTHASHVERIFY, that aim to enable particular new features for Bitcoin via new Script operations. However, I think that these proposals miss the mark when it comes to how they approach Bitcoin Script and language