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
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Return-Path: <jlrubin@mit.edu>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 323C6C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 17:47:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 1F29586C7F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 17:47:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DWcADFrpLYM8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 17:47:51 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 1545286C7C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 3 Sep 2020 17:47:50 +0000 (UTC)
Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com
[209.85.218.52]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 083Hlmor020774
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 3 Sep 2020 13:47:49 -0400
Received: by mail-ej1-f52.google.com with SMTP id p9so5036079ejf.6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 03 Sep 2020 10:47:49 -0700 (PDT)
X-Gm-Message-State: AOAM531cV/a8gQTfKdzxbmD+AdDf/0ojeyO2a5jBsNvVGjf+4FMDiF9v
dWd2x+p5IT48UGvXVBOPMYlMaJjNvTGcC6iKsvo=
X-Google-Smtp-Source: ABdhPJwCwll8rB1FfbaaKYDKtNHxVGK9SMLF03N8glhO3o01NSS+NIDoquaCmyKhP5vM+V6smIfyXBKq67iwx6WWZwU=
X-Received: by 2002:a17:907:728e:: with SMTP id
dt14mr3383610ejc.4.1599155268308;
Thu, 03 Sep 2020 10:47:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
<CAMZUoKkS77GwTW0B+cbh5BE5koB5oR4zbvEFmufAH7rN+CkR+w@mail.gmail.com>
<CAD5xwhi115pHK4J4=WDX=xbusxG_qP-oOWYNsD4z1Hh7JZ1yzQ@mail.gmail.com>
<CAD5xwhiQiCZJ18fqJKsW8Z5g2x4TxSyQeNf0+qEkr-UcLat-1A@mail.gmail.com>
<CAD5xwhj-WGBLGCi4nKE_5D+cYL134Xn4iux03co+s_iHtHhGZw@mail.gmail.com>
<20191214122546.5e72eb93@simplexum.com>
<CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
<20200214161826.5d334196@simplexum.com>
<CAD5xwhg9xx780i8e=Y9jpj4GBfcjEf+MQ_ap9osi2n6ZQMTN3Q@mail.gmail.com>
<20200903194223.7e763393@simplexum.com>
<CAD5xwhgb8xoZXue=R4ktENGLffvBQOKNBUsfZS+DZXBSK4NezA@mail.gmail.com>
In-Reply-To: <CAD5xwhgb8xoZXue=R4ktENGLffvBQOKNBUsfZS+DZXBSK4NezA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 3 Sep 2020 10:47:35 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgazN5H6HiFFHP9WgJuBOS9Tot+ri1gd6wea_XFU7w5SA@mail.gmail.com>
Message-ID: <CAD5xwhgazN5H6HiFFHP9WgJuBOS9Tot+ri1gd6wea_XFU7w5SA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000b5585505ae6c5985"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 03 Sep 2020 17:47:52 -0000
--000000000000b5585505ae6c5985
Content-Type: text/plain; charset="UTF-8"
It's also not something that's trivial to set up in any scheme because you
have to have an ordering around when you set up the tx intended to be the
inverse lock before you create the tx using it.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Thu, Sep 3, 2020 at 10:34 AM Jeremy <jlrubin@mit.edu> wrote:
> CTV does not enable this afaiu because it does not commit to the inputs
> (otherwise there's a hash cycle for predicting the output's TXID.
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov <dp@simplexum.com> wrote:
>
>> Just had an idea that an an "inverse timelock" can be made
>> almost-certainly automatic: a revocation UTXO shall become
>> anyone-can-spend after a timeout, and bear some non-dust amount.
>>
>> Before the timelock expiration, it shall be spendable only along with
>> the covenant-locked 'main' UTXO (via a signature or mutual covenant)
>>
>> This way, after a timeout expires, a multitude of entities will be
>> incentivized to spend this UTXO, because this would be free money for
>> them. It will probably be spend by a miner, as they can always replace
>> the spending transaction with their own and claim the amount.
>>
>> After the revocation UTXO is spent, the covenant path that commits to
>> having it in the inputs will be unspendable, and this would effectively
>> constitute an "inverse timelock".
>>
>>
>>
--000000000000b5585505ae6c5985
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It's=
also not something that's trivial to set up in any scheme because you =
have to have an ordering around when you set up the tx intended to be the i=
nverse lock before you create the tx using it.</div><div class=3D"gmail_def=
ault" 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"><br clear=3D"all"></di=
v><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_s=
ignature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin=
" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRu=
bin" target=3D"_blank"></a></div></div></div><br></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Sep 3, 2020 at 10:=
34 AM Jeremy <<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">CTV does not enable this afaiu becaus=
e it does not commit to the inputs (otherwise there's a hash cycle for =
predicting the output's TXID.</div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b=
r clear=3D"all"></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov <<a href=3D"mail=
to:dp@simplexum.com" target=3D"_blank">dp@simplexum.com</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Just had an idea tha=
t an an "inverse timelock" can be made<br>
almost-certainly automatic: a revocation UTXO shall become<br>
anyone-can-spend after a timeout, and bear some non-dust amount.<br>
<br>
Before the timelock expiration, it shall be spendable only along with<br>
the covenant-locked 'main' UTXO (via a signature or mutual covenant=
)<br>
<br>
This way, after a timeout expires, a multitude of entities will be<br>
incentivized to spend this UTXO, because this would be free money for<br>
them. It will probably be spend by a miner, as they can always replace<br>
the spending transaction with their own and claim the amount.<br>
<br>
After the revocation UTXO is spent, the covenant path that commits to<br>
having it in the inputs will be unspendable, and this would effectively<br>
constitute an "inverse timelock".<br>
<br><br>
</blockquote></div></div>
</blockquote></div></div>
--000000000000b5585505ae6c5985--
|
