summaryrefslogtreecommitdiff
path: root/a5/d8964b70c4e3ac2c955030ced48ee181a7da06
blob: 6e18c4b001824582c3eaf7f3f079961cd95a472d (plain)
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
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6CAB3C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 15:54:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 4DC6983F11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 15:54:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level: 
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2r5H2SEECqGb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 15:54:54 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 20A7583F0C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  9 Apr 2021 15:54:53 +0000 (UTC)
Received: from mail-io1-f44.google.com (mail-io1-f44.google.com
 [209.85.166.44]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 139Fsq2R027092
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 9 Apr 2021 11:54:52 -0400
Received: by mail-io1-f44.google.com with SMTP id x16so6410511iob.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 09 Apr 2021 08:54:52 -0700 (PDT)
X-Gm-Message-State: AOAM531prRnp/0TqMShJgwpuCT62i37pJ5qIxDvi83QmA7RsLD48Dff1
 J/jbXVWOmiy0JQ+ARe9tK48YQu6geuXkO23bD9U=
X-Google-Smtp-Source: ABdhPJxXaJE8fxCPJQdyc/gBXMRXD0y5JJnY0T6tr350XjNB9V/c9Cxg9qT8mfz7KxzvSDIiz4Tiqp0Vxh4wIwTVkic=
X-Received: by 2002:a02:cba7:: with SMTP id v7mr12670790jap.123.1617983691937; 
 Fri, 09 Apr 2021 08:54:51 -0700 (PDT)
MIME-Version: 1.0
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org>
 <C623794E-F061-4C7A-B05D-378798ED2BF7@friedenbach.org>
 <201709190309.08669.luke@dashjr.org>
 <CAA2B000-6C54-4AD7-B931-43C99D615A61@friedenbach.org>
 <CAKzdR-phAarTY16BOnC95BPN0qMNEE_XZ9H-XmFeeaBc2V1U5w@mail.gmail.com>
 <3385CE20-C1BA-40DD-8FC3-8F53F3350717@friedenbach.org>
 <CAKzdR-pnvystx5H+P+OCXm73aVmWdyesCymerSgx=pCuXx+YGA@mail.gmail.com>
 <9FD4AF03-28A5-4B8A-9C12-CBCB1BC2E22C@friedenbach.org>
 <CAKzdR-r6u4J+_T5X516A=-tLWZ8zFFFsRokReiJndDE_S64OqQ@mail.gmail.com>
 <CAPg+sBi+WnzpJkcG6XACdpqqz9ZA3rHX8+H9b5eExUdgXaeiWQ@mail.gmail.com>
 <CAJowKg+kbnExgKt7H8GD6Kc-iLJEOvZhtw0uVbophhLCszvOHg@mail.gmail.com>
 <CAMZUoKmQyV67dhWS_+t1CmqNYT490_7g3WwKgxB-jiYfje+F+Q@mail.gmail.com>
In-Reply-To: <CAMZUoKmQyV67dhWS_+t1CmqNYT490_7g3WwKgxB-jiYfje+F+Q@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 9 Apr 2021 08:54:39 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com>
Message-ID: <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000035e16c05bf8c2f8e"
Subject: Re: [bitcoin-dev] maximum block height on transaction
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: Fri, 09 Apr 2021 15:54:55 -0000

--00000000000035e16c05bf8c2f8e
Content-Type: text/plain; charset="UTF-8"

You could accomplish your rough goal by having:



tx A: desired expiry at H
tx B: nlocktime H, use same inputs as A, create outputs equivalent to
inputs (have to be sure no relative timelocks)

Thus after a timeout the participants in A can cancel the action using TX B.

The difference is the coins have to move, without knowing your use case
this may or may not help you.

On Fri, Apr 9, 2021, 4:40 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> From https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119:
>
> We can't safely do OP_BLOCKNUMBER.  In the event of a block chain reorg
>> after a segmentation, transactions need to be able to get into the chain in
>> a later block.  The OP_BLOCKNUMBER transaction and all its dependants would
>> become invalid.  This wouldn't be fair to later owners of the coins who
>> weren't involved in the time limited transaction.
>>
>> nTimeLock does the reverse.  It's an open transaction that can be
>> replaced with new versions until the deadline.  It can't be recorded until
>> it locks.  The highest version when the deadline hits gets recorded.  It
>> could be used, for example, to write an escrow transaction that will
>> automatically permanently lock and go through unless it is revoked before
>> the deadline.  The feature isn't enabled or used yet, but the support is
>> there so it could be implemented later.
>>
>
> Unfortunately, limiting the maximum block height for a specific
> transaction would have exactly the same problem as cited above for
> OP_BLOCKNUMBER.
>
> On Fri, Apr 9, 2021 at 7:21 AM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> is there any way to specify a maximum block height on a transaction?
>>
>> ie: this tx is only valid if included in a block with a certain height or
>> less
>>
>> i feel like this would be useful
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">You could accomplish your rough goal by having:<div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">tx A: desired expiry at H</div><div dir=3D"auto">tx B: n=
locktime H, use same inputs as A, create outputs equivalent to inputs (have=
 to be sure no relative timelocks)</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Thus after a timeout the participants in A can cancel the action=
 using TX B.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The differe=
nce is the coins have to move, without knowing your use case this may or ma=
y not help you.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Fri, Apr 9, 2021, 4:40 AM Russell O&#39;Conno=
r via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>From <a href=3D"https://bitcoin=
talk.org/index.php?topic=3D1786.msg22119#msg22119" target=3D"_blank" rel=3D=
"noreferrer">https://bitcointalk.org/index.php?topic=3D1786.msg22119#msg221=
19</a>:</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div>We can&#39;t safely do OP_BLOCKNUMBER.=C2=A0 In the event of a bloc=
k chain reorg after a segmentation, transactions need to be able to get int=
o the chain in a later block.=C2=A0 The OP_BLOCKNUMBER transaction and all =
its dependants would become invalid.=C2=A0 This wouldn&#39;t be fair to lat=
er owners of the coins who weren&#39;t involved in the time limited transac=
tion.<br><br>nTimeLock does the reverse.=C2=A0 It&#39;s an open transaction=
 that can be replaced with new versions until the deadline.=C2=A0 It can&#3=
9;t be recorded until it locks.=C2=A0 The highest version when the deadline=
 hits gets recorded.=C2=A0 It could be used, for example, to write an escro=
w transaction that will automatically permanently lock and go through unles=
s it is revoked before the deadline.=C2=A0 The feature isn&#39;t enabled or=
 used yet, but the support is there so it could be implemented later.</div>=
</blockquote><div><br></div><div>Unfortunately, limiting the maximum block =
height for a specific transaction would have exactly the same problem as ci=
ted above for OP_BLOCKNUMBER.<br></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 9, 2021 at 7:21 AM Erik Arones=
ty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">is there any way to specify a maximum block height on a transaction?<br=
>
<br>
ie: this tx is only valid if included in a block with a certain height or l=
ess<br>
<br>
i feel like this would be useful<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000035e16c05bf8c2f8e--