MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
In-Reply-To: <VU6YVz_dc9U4BhGd6WWNvYLS-DI1lBE14tpYdXEyIufTZ2OvqQfcWh6RVelCLWTQMWqiNsSf_AM3Pq2hzn3G62RIQwceLx54rRmD-zHCdNU=@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Tue, 21 May 2019 22:11:55 -0700
Message-ID: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000c0faba058973012e"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
	proposal
Precedence: list

--000000000000c0faba058973012e
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000c0faba058973012e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Morning,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Yes, in g=
eneral, Bitcoin does not do anything to prevent users from discarding their=
 keys.<br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:#000000"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:#000000">I don&#39;t think this will be fixed anytime soon.</div><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:#000000"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">T=
here 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.<br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#00000=
0"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:#000000">Best,</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy<br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Tue, May 21, 2019 at 7:52 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Good morning Jeremy,<br>
<br>
&gt;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 reci=
pients<br>
<br>
The recipients can always choose to destroy the privkey after providing the=
 above signature.<br>
Indeed, the recipients can always insist on not cooperating to sign using t=
he taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIF=
Y`.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000c0faba058973012e--