wrote: > 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=E2=80=99m not sure if we r= eally > want a very restricted opcode like COHV. But these are my comments, anywa= y: > > 1. The =E2=80=9Cone input=E2=80=9D rule could be relaxed to =E2=80=9Cfirs= t input=E2=80=9D rule. This > allows adding more inputs as fees, as an alternative to CPFP. In case the > value is insufficient to pay the required outputs, it is also possible to > rescue the UTXO by adding more inputs. > > 2. While there is no reason to use non-minimal push, there is neither a > reason to require minimal push. Since minimal push is never a consensus > rule, COHV shouldn=E2=80=99t be a special case. > > 3. As I suggested in a different post ( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.h= tml), > the argument for requiring a prevout binding signature may also be > applicable to COHV > > On 21 May 2019, at 4:58 AM, Jeremy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello bitcoin-devs, > > Below is a link to a BIP Draft for a new opcode, > OP_CHECKOUTPUTSHASHVERIFY. This opcode enables an easy-to-use trustless > congestion control techniques via a rudimentary, limited form of covenant > which does not bear the same technical and social risks of prior covenant > designs. > > Congestion control allows Bitcoin users to confirm payments to many users > in a single transaction without creating the UTXO on-chain until a later > time. This therefore improves the throughput of confirmed payments, at th= e > expense of latency on spendability and increased average block space > utilization. The BIP covers this use case in detail, and a few other use > cases lightly. > > The BIP draft is here: > > https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-co= shv.mediawiki > > The BIP proposes to deploy the change simultaneously with Taproot as an > OPSUCCESS, but it could be deployed separately if needed. > > An initial reference implementation of the consensus changes and tests > which demonstrate how to use it for basic congestion control is available > at https://github.com/JeremyRubin/bitcoin/tree/congestion-control. The > changes are about 74 lines of code on top of sipa's Taproot reference > implementation. > > Best regards, > > Jeremy Rubin > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --0000000000006f77070589a826b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Johnson,

Thanks = for the review. I do agree that OP_COSHV (note the pluralization -- it woul= d also be possible to do a OP_COHV <index> <hash> to do specifi= c 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 ANYPREVOUT is substantial, discussion I've seen shows that the s= afety of ANYPREVOUT is far from fully agreed. (I'll respond to your oth= er email on the subject too). OP_COSHV is also proposed specifically as a c= ongestion control mechanism, and so keeping it very easy to verify and mini= mal data (optimizations allow reducing it to just OP_COSHV with no 32 byte = argument) suggest this approach is preferable.

In an earlier vers= ion, rather than have it be the first input restriction, I had implemented = it an an only one input restriction. This makes it easier to work with SIGH= ASH_SINGLE. This works by having the PrecomputedData have a atomic test_fla= g. However I felt that the statefulness between verifications was not great= and so I simplified it.

There actually is a reason to require minima= l push -- maybe we can change the rule to be non-minimal pushes are ignored= , because we can later extend it with a different rule. This seems a little= error prone. There's also no reason to not just treat OP_COSHV as a pu= shdata 32 itself, and drop the extra byte if we don't care about versio= ning later.

Requiring a signature actually makes COSHV less useful. S= o I'm against that -- such a signature prevents using OP_COSHV for non-= interactive setups/uncoordinated setups where the txids are unstable. It al= so makes building the trees more expensive. If you want this feature, a bet= ter thing to do would be to always tweak leaf nodes of the tx tree entropy = so that it's unique per key and doesn't impose extra data at every = node, only the leafs of the expansion tree.

<= div>

--
@JeremyRubin

On Fri, May 24, 2019 at 12:13= PM Johnson Lau <jl2012@xbt.hk> = wrote:

Functionally, COHV is a proper subset of A= NYPREVOUT (NOINPUT). The only justification to do both is better space effi= ciency when making covenant.

With eltoo as a clear useca= se of ANYPREVOUT, I=E2=80=99m not sure if we really want a very restricted = opcode like COHV. But these are my comments, anyway:

1. The =E2=80=9Cone input=E2=80=9D rule could be relaxed to =E2=80=9Cfir= st input=E2=80=9D rule. This allows adding more inputs as fees, as an alter= native to CPFP. In case the value is insufficient to pay the required outpu= ts, it is also possible to rescue the UTXO by adding more inputs.

2. While there is no reason to use non-minimal push, there = is neither a reason to require minimal push. Since minimal push is never a = consensus rule, COHV shouldn=E2=80=99t be a special case.

3. As I suggested in a different post (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963= .html), the argument for requiring a prevout binding signature may also= be applicable to COHV

On 21 May= 2019, at 4:58 AM, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> wrote:

Hello bitcoi= n-devs,

Below is a link to a BIP Draft for a new opcode, OP_CHECKOUTPUTSHASHVER= IFY. This opcode enables an easy-to-use trustless congestion control techni= ques via a rudimentary, limited form of covenant which does not bear the sa= me technical and social risks of prior covenant designs.

Congestion control allows Bitcoin us= ers to confirm payments to many users in a single transaction without creat= ing the UTXO on-chain until a later time. This therefore improves the throu= ghput of confirmed payments, at the expense of latency on spendability and = increased average block space utilization. The BIP covers this use case in = detail, and a few other use cases lightly.

The BIP draft is here:
https://github.com/JeremyRubin/bips/blob= /op-checkoutputshashverify/bip-coshv.mediawiki
=
The BIP proposes to deploy the change simultan= eously with Taproot as an OPSUCCESS, but it could be deployed separately if= needed.

An initia= l reference implementation of the consensus changes and=C2=A0 tests which d= emonstrate how to use it for basic congestion control is available at https://github.com/JeremyRubin/bitcoin/tree/congestion-control= .=C2=A0 The changes are about 74 lines of code on top of sipa's Tap= root reference implementation.

Best regards,

Jeremy Rubin
_______________________________________________
bitcoin-dev mailing list=
bitcoin-dev@lists.linuxfoundation.org
https://= lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--0000000000006f77070589a826b9--