I agree a little bit, but I think that logic is somewhat infectious. If we're going to do covenants, we should also do it as a part of a more comprehensive new scripting system that gives us other strong benefits for our ability to template scripts. And so on. I'm excited to see what's possible!
Given that this is very simple to implement and has obvious deployable big wins with few controversial drawbacks, it makes more sense to streamline adoption of something like this for now and work on a more comprehensive solution without urgency.
The design is also explicitly versioned so short of an eventual full redesign it should be easy enough to add more flexible features piecemeal as they come up and their use cases are strongly justified as I have shown here for certified post dated utxo creation.
Lastly I think that while these are classifiable as covenants in implementation, they are closer in use to multisig pre-signed scripts, without the requirement of interactive setup. We should think of these as 'certified checks' instead, which can also describe a pre-signed design satisfactorily. With true covenants we don't want require the satisfying conditions to be 'computationally enumerable' (e.g. we can't in computational limits enumerate all public keys if the covenant expresses a spend must be to a public key). And if the covenant is computationally enumerable, then we should use this construct and put the spending paths into a Huffman encoded taproot tree.
If we're going to do covenants (and I think we should), then I think we
need to have a flexible solution that provides more features than just
this, or we risk adding it only to go through all the effort again when
people ask for a better solution.
Matt
On 5/20/19 8:58 PM, Jeremy via bitcoin-dev 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
>
> 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
>