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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1Yn0Br-0002jx-G4
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Apr 2015 07:44:23 +0000
Received: from mail-wg0-f44.google.com ([74.125.82.44])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yn0Bp-0007mH-CM
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Apr 2015 07:44:23 +0000
Received: by wgin8 with SMTP id n8so141205055wgi.0
for <bitcoin-development@lists.sourceforge.net>;
Tue, 28 Apr 2015 00:44:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=r/YotED90W5QlJvBy6MVIOVXYDxeTNevWjC2mX01bDE=;
b=RGow2hgRRfCNTcHJoSroiGyKwgYxUOcprgUyZcXliEMYAlREfuVnWtLZ1u69CcY6lh
DZwnd71sRwaLyA9wzR4l+e0piO4C3mnVAc3pGOY/yDA9Q3LdEpP0mQ13XBvz6u3UJ7L8
50+4k5TSyS8PfPtvbQVDwGWAhlkP4Z7riSnEIeQ6BJU3y2xm1v4+8msmEMvIPy/F9uES
Zu0E+cQw4NuzAquMo0TDUiYlyEeJtT5eic6GYTl5WknjSTbN3HR8MF71VkMp6wALLawe
SGwLojI3fKIIAj+C6tgursEVunt5Yx33DcaRKVMdffiRcFxip35IAoxjbAwcLxSKCbtJ
hkAQ==
X-Gm-Message-State: ALoCoQnaTB1WahQpkefd7R65p0C7hbcTBk2Y/60Xl9myR7gJoJOr13wtvHtkuA3y4miuITKZ0aNg
MIME-Version: 1.0
X-Received: by 10.180.37.73 with SMTP id w9mr27239615wij.7.1430207055085; Tue,
28 Apr 2015 00:44:15 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:44:14 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:44:14 -0700 (PDT)
In-Reply-To: <20150427193526.GH5223@muck>
References: <20141001130826.GM28710@savin.petertodd.org>
<55075795.20904@bluematt.me>
<20150421075912.GA25282@savin.petertodd.org>
<CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com>
<CABm2gDovFzpL_7KFqPXxhu4VohRfcE5S_PLAUgjgo_b84GaYeQ@mail.gmail.com>
<20150427193526.GH5223@muck>
Date: Tue, 28 Apr 2015 09:44:14 +0200
Message-ID: <CABm2gDqTz9hDK0auje7OodKS935XFjcR818WsTb6FKDz=qO_SA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8f502ee87954ee0514c4077e
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Yn0Bp-0007mH-CM
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
proposal)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Apr 2015 07:44:23 -0000
--e89a8f502ee87954ee0514c4077e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
But anyway, yes, the non-relative cltv is much simpler in design and
doesn't have to wait for the other. On the other hand, I would upgrade it
to absolute cltv like you suggested and take the current height as a
parameter to verifyScript instead of using the nLockTime as reference.
If we know we're going to use it for rcltv/op_maturity, better put add soon
rather than later, specially if that will give us a more powerful cltv.
If we don't want that height param, we can leave it out of for op_maturity
too, but that's the wingle decision about rcltv/maturity that affects cltv
so better solve that first.
On Apr 27, 2015 9:35 PM, "Peter Todd" <pete@petertodd.org> wrote:
> On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Tim=C3=B3n wrote:
> > On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr=
ote:
> > > And a new softfork rule could enforce that all new CTxIn set nHeight
> > > to the correct height in which its corresponding prevout got into the
> > > chain.
> > > That would remove the need for the TxOutputGetter param in
> > > bitcoinconsensus_verify_script, but unfortunately it is not reorg saf=
e
> > > (apart from other ugly implementation details).
> >
> > Wait, wait, this can be made reorg-safe and more backards compatible.
> > The new validation rule at the tx validation level (currently in
> > main::CheckInputs()) would be
>
> <snip>
>
> So, seems to me that RCLTV opens up a whole rats nest of design
> decisions and compromises that CLTV doesn't. Yet CLTV itself is a big
> step forward, it's been implemented on Viacoin for the past few months
> with no issues found, and has an extremely simple and easy to audit
> implementation.
>
> I think I'm going to argue we implement it as-is in a soft-fork. Pieter
> Wuille's been working on a new way to handle soft-fork upgrades in the
> block nVersion field, so this would be a good opportunity to add
> something simple and well tested, and also make sure the new nVersion
> soft-fork mechanism works. Equally, doing both at the same time ensures
> we don't burn yet another version bit.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
>
--e89a8f502ee87954ee0514c4077e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Even if it's new and has not received any feedback, I th=
ink my solution to op_maturity is quite clean. <br>
But anyway, yes, the non-relative cltv is much simpler in design and doesn&=
#39;t have to wait for the other. On the other hand, I would upgrade it to =
absolute cltv like you suggested and take the current height as a parameter=
to verifyScript instead of using the nLockTime as reference.<br>
If we know we're going to use it for rcltv/op_maturity, better put add =
soon rather than later, specially if that will give us a more powerful cltv=
.<br>
If we don't want that height param, we can leave it out of for op_matur=
ity too, but that's the wingle decision about rcltv/maturity that affec=
ts cltv so better solve that first.</p>
<div class=3D"gmail_quote">On Apr 27, 2015 9:35 PM, "Peter Todd" =
<<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Apr 26, 201=
5 at 02:20:04PM +0200, Jorge Tim=C3=B3n wrote:<br>
> On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc=
> wrote:<br>
> > And a new softfork rule could enforce that all new CTxIn set nHei=
ght<br>
> > to the correct height in which its corresponding prevout got into=
the<br>
> > chain.<br>
> > That would remove the need for the TxOutputGetter param in<br>
> > bitcoinconsensus_verify_script, but unfortunately it is not reorg=
safe<br>
> > (apart from other ugly implementation details).<br>
><br>
> Wait, wait, this can be made reorg-safe and more backards compatible.<=
br>
> The new validation rule at the tx validation level (currently in<br>
> main::CheckInputs()) would be<br>
<br>
<snip><br>
<br>
So, seems to me that RCLTV opens up a whole rats nest of design<br>
decisions and compromises that CLTV doesn't. Yet CLTV itself is a big<b=
r>
step forward, it's been implemented on Viacoin for the past few months<=
br>
with no issues found, and has an extremely simple and easy to audit<br>
implementation.<br>
<br>
I think I'm going to argue we implement it as-is in a soft-fork. Pieter=
<br>
Wuille's been working on a new way to handle soft-fork upgrades in the<=
br>
block nVersion field, so this would be a good opportunity to add<br>
something simple and well tested, and also make sure the new nVersion<br>
soft-fork mechanism works. Equally, doing both at the same time ensures<br>
we don't burn yet another version bit.<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7<br>
</blockquote></div>
--e89a8f502ee87954ee0514c4077e--
|
