From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B2514FF0 for ; Fri, 24 May 2019 19:27:44 +0000 (UTC) X-Greylist: delayed 00:15:02 by SQLgrey-1.7.6 Received: from sender4-of-o59.zoho.com (sender4-of-o59.zoho.com [136.143.188.59]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0F7EF4 for ; Fri, 24 May 2019 19:27:43 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1558725159; cv=none; d=zoho.com; s=zohoarc; b=Ger06Co46VUgGfx7bpeLybJEHda458JcFQQ/aYCnzsCioDt1pX+C7KRckkGCgq28MtvuR/qe6gwPOvFqQH8iRk5wFAijscTK5r++zwECO81A5+tayGOom0mpsNiu/eUdXhz5Wz0U+d0H/sUkCYALdOcs1Pl2bRy29ee8rLuFxOU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1558725159; h=Content-Type:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=zxwufjXJDHuXOtyLVAGQRNSlTFdzdrg5TGNkpP17Ngo=; b=EjCYLP5UwXMJBcA6nK0ogTk5W2M8Q5BEUWB4T0ALI7+aMNCrVvprec1/YfEelQHj8eqz/U0kW5huCmnSdKNuhN0LIji5ebHD1bkqb/B3WO45h9M+y1DpjLuAdanvtfU/Bh5B8MkBqczz47gID1EXfoLiDdQfDCCXDq4Wpkl419I= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [192.168.1.2] (1-64-133-115.static.netvigator.com [1.64.133.115]) by mx.zohomail.com with SMTPS id 1558725156855194.0009829475515; Fri, 24 May 2019 12:12:36 -0700 (PDT) From: Johnson Lau Content-Type: multipart/alternative; boundary="Apple-Mail=_0F589C2A-70B6-4046-9EF7-5EAC5FCD4AB2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 25 May 2019 03:12:32 +0800 References: To: Jeremy , bitcoin-dev In-Reply-To: Message-Id: <52AFAB05-040B-4310-9328-96E14A779D60@xbt.hk> X-Mailer: Apple Mail (2.3445.104.11) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 25 May 2019 12:05:39 +0000 Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 19:27:44 -0000 --Apple-Mail=_0F589C2A-70B6-4046-9EF7-5EAC5FCD4AB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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=9Cfirst= 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 = wrote: >=20 > Hello bitcoin-devs, >=20 > 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. >=20 > 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 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. >=20 > The BIP draft is here: > = https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-cos= hv.mediawiki = >=20 > The BIP proposes to deploy the change simultaneously with Taproot as = an OPSUCCESS, but it could be deployed separately if needed. >=20 > 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. >=20 > Best regards, >=20 > Jeremy Rubin > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_0F589C2A-70B6-4046-9EF7-5EAC5FCD4AB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 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=9Cfirst 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-Ma= y/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.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 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-checkoutputshashver= ify/bip-coshv.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<= /a>.  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<= br class=3D"">

= --Apple-Mail=_0F589C2A-70B6-4046-9EF7-5EAC5FCD4AB2--