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] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

2019-05-25 Thread Jeremy via bitcoin-dev
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

Re: [bitcoin-dev] Safety of committing only to transaction outputs

2019-05-25 Thread Jeremy via bitcoin-dev
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

Re: [bitcoin-dev] Safety of committing only to transaction outputs

2019-05-25 Thread Johnson Lau via bitcoin-dev
> 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.

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

2019-05-25 Thread Jeremy via bitcoin-dev
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

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] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

2019-05-25 Thread ZmnSCPxj via bitcoin-dev
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

Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

2019-05-25 Thread Johnson Lau via bitcoin-dev
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:

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