summaryrefslogtreecommitdiff
path: root/fb/ef802409b079c80df697e362be603d8ea37e61
blob: 2d7f30233bda3148c36924fdeecca048697d440d (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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D4D37C000A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 04:24:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id BB3CB41860
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 04:24:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id jtyZZCZ7prcV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 04:24:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3BE7B40E66
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 16 Apr 2021 04:24:32 +0000 (UTC)
Date: Fri, 16 Apr 2021 04:24:28 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1618547069;
 bh=S3t+lqo8Vd6rNWMgqKl3I5GApL5BzWVIo6+wqZwySBI=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=AiEePOK8UhmHZOeutFK0FjUNKb28KIe2bokyN9CXEXBBX1V7LmpfmDMPKxXcPG8dp
 gQnhqYA+eM+B10GmKYbAomKmFhJfDXG2PPP7n9oPGqU0HAFlWDp4X0a3TqwBIMPwxN
 +6A9PCygnddWFu1fWuaLEwxEs4PySL4lSr4y/UFI=
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com>
In-Reply-To: <CAGpPWDZHKJ8BvD3TqrvP=5pxbAc0ez-ikJmO6a51WDad1xuLSw@mail.gmail.com>
References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@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>
 <CAD5xwhhZpQ9AQEFHgGYvPh2ad9HyQqq9WwEZje1H1siioB6eLQ@mail.gmail.com>
 <CAGpPWDZHKJ8BvD3TqrvP=5pxbAc0ez-ikJmO6a51WDad1xuLSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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, 16 Apr 2021 04:24:35 -0000

Good morning Billy,


> I've come across this argument before, and it seems kind of like Satoshi'=
s word here is held as gospel. I haven't heard any deep discussion of this =
topic, and I even asked a question on the bitcoin SE about it. Sorry to hij=
ack this conversation, but I'm very curious if there's something more to th=
is or if the thinking was simply decided that OP_BLOCKNUMBER wasn't useful =
enough to warrant the (dubious) potential footgun of people accepting sub-6=
-block transactions from a transaction that uses an expired spend-path?

Another argument I have encountered has to do with the implementation of Bi=
tcoin Core.

As an optimization, SCRIPT is evaluated only when a transaction enters the =
mempool.
It is not evaluated at any other time.
Indeed, when accepting a new block, if a transaction in that block is in th=
e mempool, its SCRIPT is not re-evaluated.

If the max-blockheight-constraint is implemented as a SCRIPT opcode, then a=
t each block, every SCRIPT in every transaction in the mempool must be re-e=
valuated, as the SCRIPT might not reject.
During times of high chain bloat, there will be large numbers of transactio=
ns in the mempool, only a tiny fraction will be removed at each block befor=
e the mempool finally clears, leading to effective O(n^2) CPU time spent (n=
 blocks are needed in order to empty a mempool with n transactions, each bl=
ock triggers re-evaluation of SCRIPT of n transactions in the mempool).
That O(n^2) assumes a single SCRIPT is O(1), which is untrue as well (but i=
s generally approached in practice as most transactions are simple singlesi=
g or `OP_CHECKMULTISIG` affairs).

That is, the mempool assumes that once a SCRIPT accepts, it will always acc=
ept in the future.
Thus, any SCRIPT opcode cannot change from "accept" (because at the current=
 blockheight the max-block is not yet reached) to "reject" (because the max=
-block constraint is now violated).

Thus, we cannot use an opcode to impose the max-block cosntraint.

The alternative is to add a new field `maxtime` to the transaction.
Then possibly, we can have an `OP_CHECKMAXTIMEVERIFY` opcode that checks th=
at the field has a particular value.
Then the mempool can have a separate index according to `maxtime` fields, w=
here it can remove the indexed transactions at each block.
The index will be likely O(log n), and the filtering at each block would be=
 O(n log n), which is an improvement.
Note in particular that the index itself would require O(n) storage.

However, adding a new field to the transaction format would require techniq=
ues similar to what was used in SegWit, i.e. post-maxtime nodes have to "ba=
by talk" to pre-maxtime nodes and pretend transactions do not have this fie=
ld, in much the same way post-SegWit nodes "baby talk" to pre-SegWit nodes =
and pretend transactions do not have a `witness` field.
We would then need a third Merkle Tree to hold the "really real" transactio=
n ID that contains the `maxtime` field as well.

Thus, it seems to me that the tradeoffs are simply not good enough, when yo=
u can get 99% of what you need using just another transaction with `nLockTi=
me`:

* Using an opcode would greatly increase CPU usage because the script cache=
 would need to be reworked (and probably cannot be made to work).
* Adding a field would greatly increase the code complexity to the level of=
 SegWit, without all the important bugfixes+features (tx malleability, quad=
ratic sighash, well-defined extensible outputs) that SegWit provides.
* You can do what you want with a second `nLockTime`d transaction that spen=
ds the output anyway.

Indeed, it is helpful to realize *why* `OP_CHECKLOCKTIMEVERIFY` and `OP_CHE=
CKSEQUENCEVERIFY` work the way they are implemented.
They are typically discussed and described as if they were imposing time-ba=
sed constraints, but the *real* implementation only imposes constraints on =
`nLockTime` and `nSequence` fields --- the SCRIPT interpreter itself does n=
ot look at the block that the transaction is in (because that is not availa=
ble, as the SCRIPT interpreter is invoked at mempool entry, when the transa=
ction *has* no block it is contained in).
There is instead a separate layer (the entry into the mempool) that impleme=
nts the *actual* time-based cosntraints, based on the fields and not the SC=
RIPT opcodes.

Regards,
ZmnSCPxj

>
> On Fri, Apr 9, 2021 at 5:55 AM Jeremy via bitcoin-dev <bitcoin-dev@lists.=
linuxfoundation.org> wrote:
>
> > 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 i=
nputs (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.=C2=A0
> >
> > 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=3D1786.msg22119#msg22119=
:
> > >
> > > > We can't safely do OP_BLOCKNUMBER.=C2=A0 In the event of a block ch=
ain reorg after a segmentation, transactions need to be able to get into th=
e chain in a later block.=C2=A0 The OP_BLOCKNUMBER transaction and all its =
dependants would become invalid.=C2=A0 This wouldn't be fair to later owner=
s of the coins who weren't involved in the time limited transaction.
> > > >
> > > > nTimeLock does the reverse.=C2=A0 It's an open transaction that can=
 be replaced with new versions until the deadline.=C2=A0 It can't be record=
ed until it locks.=C2=A0 The highest version when the deadline hits gets re=
corded.=C2=A0 It could be used, for example, to write an escrow transaction=
 that will automatically permanently lock and go through unless it is revok=
ed before the deadline.=C2=A0 The feature isn't enabled or used yet, but th=
e support is there so it could be implemented later.
> > >
> > > Unfortunately, limiting the maximum block height for a specific trans=
action would have exactly the same problem as cited above for OP_BLOCKNUMBE=
R.
> > >
> > > 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 hei=
ght 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
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev