Functionally, COHV is a proper subset of ANYPREVOUT (NOINPUT). The only
justification to do both is better space efficiency when making covenant.
With eltoo as a clear usecase of ANYPREVOUT, I’m not sure if we really want a
very restricted opcode like COHV. But these are my comments, anyway:
1.
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
Good morning Jeremy,
I believe I have caught the general point.
Indeed, I agree that this is useful, but it is *not* useful for these cases:
1. CoinJoin - the initial funding transaction must be signed by the
participants anyway after checking that the output is correct.
Further any spend t
> On 25 May 2019, at 4:59 AM, Jeremy wrote:
>
> Hi Johnson,
>
> As noted on the other thread, witness replay-ability can be helped by salting
> the taproot key or the taproot leaf script at the last stage of a congestion
> control tree.
>
The salt will be published when it is first spent.
Hi Johnson,
Thanks for the review. I do agree that OP_COSHV (note the pluralization --
it would also be possible to do a OP_COHV to do specific
outputs).
I think the point of OP_COSHV is that something like ANYPREVOUT is much
more controversial. OP_COSHV is a subset by design. The IF on ANYPREV
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
Hi Johnson,
As noted on the other thread, witness replay-ability can be helped by
salting the taproot key or the taproot leaf script at the last stage of a
congestion control tree.
I also think that chaperone signatures should be opt-in; there are cases
where we may not want them. OP_COSHV is com
ZmnSCIPxj,
I think you're missing the general point, so I'm just going to respond to
one point to see if that helps your understanding of why OP_COSHV is better
than just pre-signed.
The reason why MuSig and other distributed signing solutions are not
acceptable for this case is they all require
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
