Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-21 📝 Original message:I agree a little bit, but ...
📅 Original date posted:2019-05-21
📝 Original message: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.
On Tue, May 21, 2019, 12:41 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190521/618bcea2/attachment-0001.html>;
📝 Original message: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.
On Tue, May 21, 2019, 12:41 PM Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190521/618bcea2/attachment-0001.html>;