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
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.
>
> Co
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 programmable
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
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
O
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 ar
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 woul
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 complicating
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 Scr
> 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 variab
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 and
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
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
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 lik
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 `SIGHASH_ANYPREVOUT`
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 f
16 matches
Mail list logo
