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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E876C273
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Nov 2015 08:10:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com
[209.85.220.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 426B3115
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Nov 2015 08:10:54 +0000 (UTC)
Received: by padhx2 with SMTP id hx2so108303725pad.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Nov 2015 00:10:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=user-agent:in-reply-to:references:mime-version:content-type
:content-transfer-encoding:subject:from:date:to:cc:message-id;
bh=kNF3mQnSaBbca8wuRBqdntE4DHsbzMWvnuPVYBxcWSI=;
b=uBh4CQfGCQBMX7FAGDwDEwFS3ZwyeU85CuES9aUqa6ohzid8rYIN1CwHi/9eGwKzsp
KpQQD9/bnjapwQ5YLZrw7I/MYembWcAZeGam++SH2ORXo6ADdNhubtWqMKpLyiwcg3CT
9xWBVZUMBdUseF/LoUixvLHD35j2X6MvfNrjWj/NrkOHovpb+C1+Nv+d6ox5KIZyBxRj
lQDBXAiXqMrCffugVXt5mvX2v3AOxPI23pRZXL0zwi8ZUTVYc9VxaTV431Xsm+CdQU89
o6HnqXSJwKh8dezjTuZV/QO9TiJgPLQK4kzmmtiGrZ1vYOquHVdsWBS+QQnLAxdgwao2
8pEQ==
X-Received: by 10.66.150.165 with SMTP id uj5mr65856616pab.23.1448611853699;
Fri, 27 Nov 2015 00:10:53 -0800 (PST)
Received: from [192.168.1.19] (ip72-207-65-162.sd.sd.cox.net. [72.207.65.162])
by smtp.gmail.com with ESMTPSA id
79sm32106794pfb.67.2015.11.27.00.10.52
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 27 Nov 2015 00:10:53 -0800 (PST)
User-Agent: K-9 Mail for Android
In-Reply-To: <87ziy0qeca.fsf@rustcorp.com.au>
References: <eme59eddfb-c410-4af4-b496-e3301ac9db85@platinum>
<87ziy0qeca.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL"
Content-Transfer-Encoding: 8bit
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Fri, 27 Nov 2015 00:10:49 -0800
To: Rusty Russell <rusty@rustcorp.com.au>,
Mark Friedenbach <mark@friedenbach.org>, Btc Drak <btcdrak@gmail.com>
Message-ID: <B412CC14-0FD7-47E3-8A34-EB73198ED041@gmail.com>
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative name for CHECKSEQUENCEVERIFY (BIP112)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 27 Nov 2015 08:10:55 -0000
------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense.
It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin.
HOWEVER...there might be ways around this issue using segwit.
I've been pondering the possibility of adding an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash.
Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (https://github.com/sipa/bitcoin/tree/segwit) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well.
I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications.
Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed.
This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to.
If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits.
I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet.
- Eric
On November 26, 2015 8:02:45 PM PST, Rusty Russell <rusty@rustcorp.com.au> wrote:
>Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>writes:
>>>From an app developer's perspective, I think it is pretty blatantly
>> clear that relative timelock is *the* critical exposed functionality
>> intended here.
>
>As someone who actually developed scripts using CSV, I agree with Mark
>(and Matt). The relative locktime stuff isn't in this opcode, it's in
>the nSequence calculation.
>
>So, I vote to keep CSV called as it is.
>
>Thanks,
>Rusty.
------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>After reading Rusty's post, I admit there's something to be said for the fact that both the script and the nSequence field play a combined role, and thus, making the interaction between the two more clear in the naming make sense.<br>
<br>
It is somewhat unfortunate that currently, we can't just have a dedicated field for the purpose of relative locktime (or minimum age) without having to repurpose the only unused 32 bits in the txin.<br>
<br>
HOWEVER...there might be ways around this issue using segwit.<br>
<br>
I've been pondering the possibility of adding an extra input vector to the prunable extra data that comprises the witness. Witness structures can provide additional data that is used in transaction validation but does not contribute to the tx hash.<br>
<br>
Currently, the signature checking opcodes in the script already do this implicitly for computing the hash that is signed (but not the tx hash used in block merkletrees)...and this is the principal cause of undesirable malleability issues. Clearly the signatures themselves cannot contribute to the hash they are signing. So segwit makes this separation explicit by moving the signatures to a structure external to the script. Pieter Wuille's implementation (<a href="https://github.com/sipa/bitcoin/tree/segwit">https://github.com/sipa/bitcoin/tree/segwit</a>) generalizes this idea using a script witness structure that is a vector of arbitrary inputs. Clearly moving the signatures into such structure is an important feature...but other types of input to the script could be placed here as well.<br>
<br>
I had considered the possibility of placing a minimum age (relative locktime) field in the input vector that could be checked for mempool acceptance without having to evaluate the script. Of course, the location of such a field would have to be known by the mempool and cannot be an arbitrary element of a generic input vector, which adds some minor but surmountable complications.<br>
<br>
Greg Maxwell pointed out, however, that signing opcodes that sign hashes discarding this data would make it trivial for anyone to change this field without signing anything. The nSequence fields of txins, being part of the tx serialization that gets hashed, is therefore always signed.<br>
<br>
This led me to consider the possibility of adding extra opcodes to the script that can incorporate additional data in the hash that gets signed. This data would go in another structure that does not contribute to the tx hash but is outside the witness. Then we could add extra prunable data fields that the signer can commit to.<br>
<br>
If I've missed something critical in the above analysis, someone please correct me...but it seems that such a mechanism would allow adding extra prunable signed data fields to transactions, which might ultimately remove scarcity of tx data that we can repurpose via soft forks. If this is the case, I would suggest turning the nSequence field into a dedicated min age/rlt field to simplify the semantics and avoid ugliness in trying to reclaim unused bits.<br>
<br>
I may be overlooking something important here, but unless there's a reason such data cannot be made prunable, I haven't been able to poke a hole yet.<br>
<br>
- Eric<br>
<br>
<br><br><div class="gmail_quote">On November 26, 2015 8:02:45 PM PST, Rusty Russell <rusty@rustcorp.com.au> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">From an app developer's perspective, I think it is pretty blatantly <br /></blockquote> clear that relative timelock is *the* critical exposed functionality <br /> intended here.<br /></blockquote><br />As someone who actually developed scripts using CSV, I agree with Mark<br />(and Matt). The relative locktime stuff isn't in this opcode, it's in<br />the nSequence calculation.<br /><br />So, I vote to keep CSV called as it is.<br /><br />Thanks,<br />Rusty.<br /></pre></blockquote></div></body></html>
------OVHWZ4BGG7YYUBLF60ZC8DA7JB2HWL--
|
