Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

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 usage by one TXO and one input, ending up with *more* bytes onchain, and a UTXO that will be removed later in (we hope) short time.
  I do not know if this is a good idea, to increase congestion by making unnecessary intermediate transaction outputs, at times when congestion is a problem.
* I cannot find a way to implement Decker-Russell-Osuntokun (or any offchain update mechanism) on top of this opcode, so I cannot support replacing `SIGHASH_NOINPUT` with this opcode.
  In particular, while the finite loop support by this opcode appears (at first glance) to be useable as the "stepper" for an offchain update mechanism, I cannot find a good way to short-circuit the transaction chain without `SIGHASH_NOINPUT` anyway.
* Channel factories created by this opcode do not, by themselves, support updates to the channel structure.
  But such simple "close only" channel factories can be done using n-of-n and a pre-signed offchain transaction (especially since the entities interested in the factory are known and enumerable, and thus can be induced to sign in order to enter the factory).
  More complex channel factories that can update the division of the factory to channels cannot be done without a multiparty offchain update mechanism such as Decker-Wattenhofer or Decker-Russell-Osuntokun.
  So, similarly to CoinJoin, I do not think it is much improved by this opcode.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, May 22, 2019 1:11 PM, Jeremy <jlrubin@mit.edu> wrote:

> 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 (e.g., via HTLC), whereas if the key was never known that might be a breach of contract for the payment provider.
>
> Best,
>
> Jeremy
>
> On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> > 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 can always insist on not cooperating to sign using the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIFY`.
> >
> > Regards,
> > ZmnSCPxj