From: Johnson Lau <jl2012@xbt•hk>
To: Jeremy <jlrubin@mit•edu>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal
Date: Sat, 25 May 2019 03:12:32 +0800 [thread overview]
Message-ID: <52AFAB05-040B-4310-9328-96E14A779D60@xbt.hk> (raw)
In-Reply-To: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]
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. The “one input” rule could be relaxed to “first input” 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’t be a special case.
3. As I suggested in a different post (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016963.html <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•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-checkoutputshashverify/bip-coshv.mediawiki <https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/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 <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
[-- Attachment #2: Type: text/html, Size: 5172 bytes --]
next prev parent reply other threads:[~2019-05-24 19:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-20 20:58 Jeremy
2019-05-21 19:41 ` Matt Corallo
2019-05-22 1:47 ` Jeremy
2019-05-22 2:51 ` ZmnSCPxj
2019-05-22 5:11 ` Jeremy
2019-05-22 6:04 ` ZmnSCPxj
2019-05-22 8:10 ` Jeremy
2019-05-23 3:45 ` ZmnSCPxj
2019-05-24 21:15 ` Jeremy
2019-05-25 3:56 ` ZmnSCPxj
2019-05-22 20:49 ` Anthony Towns
2019-05-23 17:42 ` [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party Tamas Blummer
2019-05-23 19:03 ` Jorge Timón
2019-05-23 19:10 ` Tamas Blummer
2019-05-23 19:05 ` Nathan Cook
2019-05-23 19:18 ` Tamas Blummer
2019-05-23 19:21 ` Nathan Cook
2019-05-23 19:45 ` Tamas Blummer
2019-05-23 19:54 ` Tamas Blummer
2019-05-23 20:07 ` Nathan Cook
2019-05-23 19:45 ` Pieter Wuille
2019-05-23 20:26 ` Tamas Blummer
2019-05-24 8:36 ` Natanael
2019-05-24 16:23 ` Tamas Blummer
2019-05-24 8:15 ` Johnson Lau
2019-05-24 19:12 ` Johnson Lau [this message]
2019-05-24 20:36 ` [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52AFAB05-040B-4310-9328-96E14A779D60@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jlrubin@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox