Date: Wed, 22 May 2019 06:04:27 +0000
To: Jeremy <jlrubin@mit.edu>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CljXxJhTEILR7KZxgZ3o_yJm66XeySWzUY3abCm01blY9yX3AmMczvu41CAm9dr4ZQTDCTQqEM1D4MhEaGASuM54l51DaJmZSKv0eqtPjEo=@protonmail.com>
In-Reply-To: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
	<CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
	proposal
Precedence: list

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 a=
nd 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 un=
necessary intermediate transaction outputs, at times when congestion is a p=
roblem.
* I cannot find a way to implement Decker-Russell-Osuntokun (or any offchai=
n update mechanism) on top of this opcode, so I cannot support replacing `S=
IGHASH_NOINPUT` with this opcode.
  In particular, while the finite loop support by this opcode appears (at f=
irst glance) to be useable as the "stepper" for an offchain update mechanis=
m, 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 u=
pdates to the channel structure.
  But such simple "close only" channel factories can be done using n-of-n a=
nd a pre-signed offchain transaction (especially since the entities interes=
ted in the factory are known and enumerable, and thus can be induced to sig=
n in order to enter the factory).
  More complex channel factories that can update the division of the factor=
y 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 opc=
ode.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
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 disca=
rding 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 rec=
ipients
> >
> > 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 usi=
ng the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHV=
ERIFY`.
> >
> > Regards,
> > ZmnSCPxj