1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DE9B29D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 05:12:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A19A6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 05:12:10 +0000 (UTC)
Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com
[209.85.208.43]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4M5C74s023720
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 May 2019 01:12:08 -0400
Received: by mail-ed1-f43.google.com with SMTP id p27so1871402eda.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 21 May 2019 22:12:08 -0700 (PDT)
X-Gm-Message-State: APjAAAWF2DYVKjGBj0OH3DScJQWXfJunCsmoPlmMdVANTec/rR3QP+4q
FsdjL5TYm2HI3Bj2srylCQT1ulmxceJPERRXMB0=
X-Google-Smtp-Source: APXvYqwz/1jJ2MrOu/fm7bw1bwXnB8MX1ZiWWkPTnt+EHEee6cDyAbpjVhdJ8S5Hg/gcMBRrHQxVHImzM7b79bC0jB4=
X-Received: by 2002:a50:addc:: with SMTP id b28mr88735860edd.7.1558501927219;
Tue, 21 May 2019 22:12:07 -0700 (PDT)
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
X-Gmail-Original-Message-ID: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
Message-ID: <CAD5xwhixyvAA0zak86BwG3ZjinUJ37266K_wn_NCa-ECrVmouw@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000c0faba058973012e"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 22 May 2019 13:30:30 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY
proposal
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2019 05:12:12 -0000
--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'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 <<a href=3D"mailto:ZmnSCPxj@prot=
onmail.com">ZmnSCPxj@protonmail.com</a>> 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>
>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--
|
