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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id AE156C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 02:30:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 903484040C
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 02:30:17 +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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id uDmz7n4Y6vUD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 02:30:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp2.osuosl.org (Postfix) with ESMTPS id 898C3400C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 3 May 2021 02:30:15 +0000 (UTC)
Date: Mon, 03 May 2021 02:30:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1620009011;
bh=G1U1DKLWwrOMMaveb77zVEoXX3klJBdBTUQzY78ryg0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=ioQCaoHk76Y63DsXTG4Rc1I0Uc2sAHwcUXPAbgNXFHA6dUTXl5mXm6kY7fVrGUQ6d
BVVpUokPgRG08IxnEQtYCHUJ2AcHxYCMvKMaY+FHNEbl0gaR2mzVuzXqtaxfbOXGTp
nHiSR/O37XWDsGHcZK2mjvFx7PxSxMzK5fYUCVqU=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <y8kJCDDh8iJOVjnbBFCxPuMLz2yBxNF2kW_DuxIaC3OyMNSxNm_e3rZVKUR9aWpoq6xmRBSBuPU9lAF30eQXMsmFrP8ycSMxqi7LVJXeJ3A=@protonmail.com>
In-Reply-To: <3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.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>
<3mg9xnvKEhrXuQ5QriYQcLKmrhdYpO0hlxyRpJwZJZInyHCtva208PTZlIxglcq4afO8ftTFRBjRfG0ZEVPvIqxMJhHnFYpnPYTo_mp3qA0=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Billy Tetrud <billy.tetrud@gmail.com>
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: Mon, 03 May 2021 02:30:17 -0000
Good morning Billy, and list,
> - Using an opcode would greatly increase CPU usage because the script c=
ache would need to be reworked (and probably cannot be made to work).
> - Adding a field would greatly increase the code complexity to the leve=
l of SegWit, without all the important bugfixes+features (tx malleability, =
quadratic sighash, well-defined extensible outputs) that SegWit provides.
Sometimes, the only way out is through.
A general idea to get around this would be:
* Define a "hidden" field of a transaction, which is not existent in *any* =
serialization of the transaction.
* Set a default value for this field that would be compatible with pre-soft=
fork rules.
* Have an opcode that manipulates this field, carefully designed so it is i=
dempotent.
The above general idea is not original to me, I believe.
I think I have seen it elsewhere on the list, possibly in discussions aroun=
d sidechains, though my primary cache is unable to fetch and additional sea=
rches through unindexed storage is taking too long.
So, for this particular case, here is a (non-serious) proposal to implement=
a maximum block height on transactions.
* Create a new field `u32 nMaxHeight` on `CTransaction` that is not seriali=
zed in any transaction format.
* A block is not valid if any transaction in it has an `nMaxHeight` large=
r than the block height of the block.
* Default value is `0xFFFFFFFF`.
* Add a new opcode `OP_SETMAXHEIGHT` that replaces an existing `OP_NOP`.
* The opcode must be followed by an `OP_PUSH` of a 32-bit value, else scr=
ipt validation fails.
* This prevents using a computed value, instead the value must be given=
as a constant in the script text.
This is a precaution to reduce the risk that execution of the script =
at a different time or different computer or etc will result in a different=
value that the `OP_SETMAXHEIGHT` opcode uses, which can cause consensus di=
vergence.
If we figure out later that this precaution is not necessary, we can =
just use another `OP_NOP` for `OP_SETMAXHEIGHTFROMSTACK`.
* If the current `nMaxHeight` is larger than the given value, then the `n=
MaxHeight` is set to the given value.
The above avoids issues with opcodes --- the script interpreter can continu=
e to be executed in the only place it is in, i.e. at entry into the mempool=
.
It also avoids some of the code complexity with fields, since the field is =
non-existent in any serialization of the transaction, but is instead implie=
d by the scripts that the transaction causes to be executed, reducing the n=
eed to identify pre-softfork peers and baby-talk to them --- the baby-talk =
simply contains "parental bonuses" that are understood by upgraded nodes wh=
o are "in the know".
Additional complications, such as the need for an index of `nMaxHeight` for=
transactions in the mempool (to remove transactions whose `nMaxHeight` is =
now in the past), and the additional checks needed when receiving an in-blo=
ck transaction that is not in the mempool, are left to the reader.
Similar field and opcode for `CTransactionInput` for a relative-time max he=
ight are also left as an exercise to the reader.
> - You can do what you want with a second `nLockTime`d transaction that =
spends the output anyway.
The advantage of this functionality is that you can be safely offline at th=
e time the timeout occurs in any complicated timeout-based contract.
Typically, when using say an HTLC, the contractor who holds lien on the tim=
elock branch, has to be online at the time the timelock becomes valid, in o=
rder to impose a timeout on the hashlock branch.
However, if instead the hashlock branch includes an `OP_SETMAXHEIGHT`, then=
the contractor holding lien on the timelock branch does not have this risk=
.
However, the contractor holding the lien on the hashlock branch now has inc=
reased risk.
If the timeout is approaching, and suddenly there is high mempool usage at =
the time, then a claim of the hashlock branch may fall off the mempool due =
to `nMaxHeight` violation.
But the transaction claiming the hashlock branch has been published and the=
preimage has been published in mempools all over the world, thus the contr=
actor holding lien on the hashlock branch risks not being compensated for r=
evelation of the preimage.
Whereas with the current way things are, the timelock-holder is at risk, an=
d the hashlock-holder has reduced risk since even if the timeout arrives, t=
here is still the possibility that the hashlock branch is what gets confirm=
ed, whereas with `OP_SETMAXHEIGHT` the hashlock-holder has 0 chance of gett=
ing the hashlock branch confirmed in case of sudden spike in onchain usaage=
.
Thus it seems to me that this scheme does not really *improve* Bitcoin sign=
ificantly, it only moves risks from one participant to another in a two-par=
ticipant contract.
Thus, this proposal is not particularly serious.
Regards,
ZmnSCPxj
|
