ZmnSCIPxj,
I think you're missing the general point, so I'm just going to respond to
one point to see if that helps your understanding of why OP_COSHV is better
than just pre-signed.
The reason why MuSig and other distributed signing solutions are not
acceptable for this case is they all require
Hi Johnson,
Thanks for the review. I do agree that OP_COSHV (note the pluralization --
it would also be possible to do a OP_COHV to do specific
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 ANYPREV
Good morning Jeremy,
I believe I have caught the general point.
Indeed, I agree that this is useful, but it is *not* useful for these cases:
1. CoinJoin - the initial funding transaction must be signed by the
participants anyway after checking that the output is correct.
Further any spend t
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.
Good morning Jeremy,
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Wednesday, May 22, 2019 4:10 PM, Jeremy wrote:
> > * I do not think CoinJoin is much improved by this opcode.
> > Typically, you would sign off only if one of the outputs of the CoinJoin
> > transact
On Wed, May 22, 2019 at 06:04:27AM +, ZmnSCPxj via bitcoin-dev wrote:
> * I do not think CoinJoin is much improved by this opcode.
I think (especially with cross-input sig aggregation) it makes it easier
to do a coinjoin during a high fee period -- if you're willing to wait
'til fees are lower
> * I do not think CoinJoin is much improved by this opcode.
> Typically, you would sign off only if one of the outputs of the
CoinJoin transaction is yours, and this does not really improve this
situation.
Coinjoin benefits a lot I think.
Coinjoin is improved because you can fit more users in
Good morning,
Some more comments.
* I do not think CoinJoin is much improved by this opcode.
Typically, you would sign off only if one of the outputs of the CoinJoin
transaction is yours, and this does not really improve this situation.
* Using this for congestion control increases blockchain
Morning,
Yes, in general, Bitcoin does not do anything to prevent users from
discarding their keys.
I don't think this will be fixed anytime soon.
There are some protocols where, though, knowing that a key was once known
to the recipients may make it legally valid to inflict a punitive measure
(
Good morning Jeremy,
>If a sender needs to know the recipient can remove the covenant before
>spending, they may request a signature of an challenge string from the
>recipients
The recipients can always choose to destroy the privkey after providing the
above signature.
Indeed, the recipients c
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!
G
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
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.
13 matches
Mail list logo
