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
|
Return-Path: <vizeet@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 34FB4F0B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 16:15:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com
[209.85.218.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87F16713
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 16:15:12 +0000 (UTC)
Received: by mail-oi0-f41.google.com with SMTP id 13-v6so21690481ois.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 06 Sep 2018 09:15:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=X0c/5rbdLRxu2vCd0+fdWbA41yD9TbXf//R9Rroo0nw=;
b=mjhcfa7zBHmv9FrpALoUAVOYsDzUqVyYFSR05choZITIgRfM7c03DrR81S1+NMz4+/
/NfDwJnNq2ITvgVU5HJ5qr5qJxnbqWg58cavoCpb+b1KNtZRxWq2+P15dFc0szXU0gtr
1bw8NnOdNdWkCsve7OUdLYSNX4nFd0h+PBD5Yg0+mdaMJWT9XqsBGy0qua049DtlUtwu
664YdRr0tYL3ksS1zOx+cklnyVS56+wukhPFHwcJUAxuZF8eCRHTkRcORXqg2P1myMYw
VpiBTE0YzAjo8gFzrjpXT3UnkjjnS2QIFKU8xycjbhXeVvH4rMZC1yuRnw2v8hGp2qtY
+Vag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=X0c/5rbdLRxu2vCd0+fdWbA41yD9TbXf//R9Rroo0nw=;
b=ttoSpppJq61aoFIxpN4DV8ZA/ko/1Qi1Dy4qydk2SRBP7ET49/4DK52s08Hg+tcrWv
Fd2ZwN2idei9pzl5ZhvcHhMh4xd8zJO3LqMX3HXhr68r0NgUdYhZhUUpZORTPtBX5Jz9
LyKJh8sa9dh3iTlaDowY5B7CVSK/cH17j6RX2FMkHN2JDVO398DdtgCwcgtipPRY5XgX
izJP1CfO0DNINyb6ovkkCyzJjRyT1Svq8FqOxPjZB4N7dUge80NKxUDMhnaLDKBCimt0
wWQgYU/ud8CFW0IHTuD88D3XPAUAOPuhLfETZOakVidIofRwb426Qs8OsIzSDtiKWWmj
i+5Q==
X-Gm-Message-State: APzg51D3WDuQ5YO2YsJUcR4HSY7zt3HX16dW2uvovJj3Gq42hKi/SIid
vBatbrHoQBWWZvGS/CUlACG7r5ZOR9UnEfZ3qiA=
X-Google-Smtp-Source: ANB0VdaycWMiVPNZMXzNCRQFTo6GqL7xvg88HNUJWir6H4Blrfu2n8HUt/y0Hof2bWlMzZXMF8ftjX50v6NasOfhUXw=
X-Received: by 2002:aca:3744:: with SMTP id
e65-v6mr3743931oia.12.1536250511660;
Thu, 06 Sep 2018 09:15:11 -0700 (PDT)
MIME-Version: 1.0
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
In-Reply-To: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
From: vizeet srivastava <vizeet@gmail.com>
Date: Thu, 6 Sep 2018 21:44:59 +0530
Message-ID: <CAEmwXH=BZgceLogi+QTA3sLdy8gVFW=wCdt5f9ZS6br=4ktcdg@mail.gmail.com>
To: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000089c9b057536326c"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 06 Sep 2018 16:20:51 +0000
Cc: TUCCI Sara <sara.tucci@cea.fr>,
=?UTF-8?B?w5ZuZGVyIEfDnFJDQU4=?= <Onder.GURCAN@cea.fr>
Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are
'cancellable'
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 06 Sep 2018 16:15:13 -0000
--000000000000089c9b057536326c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I feel it is breaking a principle that if a transaction is valid it remains
valid. There might be dangerous repercussions to breaking that rule. For
instance chain of transaction become invalid which might lead to losses.
On Thu 6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in
> order for these to allow and interpret negative values. This way,
> taking the example shown in BIP 112:
>
> HASH160 <revokehash> EQUAL
> IF
> <Bob's pubkey>
> ELSE
> "24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
> ENDIF
> CHECKSIG
>
> that gives ownership only to Bob for the first 24 hours and then to
> whichever spends first, we basically propose using the negative bit value=
:
>
> HASH160 <revokehash> EQUAL
> IF
> <Bob's pubkey>
> ELSE
> "-24h" CHECKSEQUENCEVERIFY DROP
> <Alice's pubkey>
> ENDIF
> CHECKSIG
>
> meaning that both would have ownership for the first 24 hours, but
> after that only Bob would own such coins. Its implementation should
> not be too tedious, and in fact it simply implies considering negative
> values that are at the moment discarded as for the specification of
> BIP-112, leaving the sign bit unused.
>
> This, we argue, an increase the fairness of the users, and can at times
> be more cost-effective for users to do rather than trying a Replace-By-Fe=
e
> transaction, should they want to modify such payment.
>
> We would like to have a discussion about this before proposing the
> BIP, for which we are preparing the text.
>
> You can find our paper discussing it here:
> https://hal-cea.archives-ouvertes.fr/cea-01867357 (find attached as well)
>
> Best,
>
> --
> Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiov=
anni
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000089c9b057536326c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I feel it is breaking a principle that if a transaction i=
s valid it remains valid. There might be dangerous repercussions to breakin=
g that rule. For instance chain of transaction become invalid which might l=
ead to losses.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu =
6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello e=
veryone,<br>
<br>
We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in<br>
order for these to allow and interpret negative values. This way,<br>
taking the example shown in BIP 112:<br>
<br>
HASH160 <revokehash> EQUAL<br>
IF<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <Bob's pubkey><br>
ELSE<br>
=C2=A0=C2=A0=C2=A0=C2=A0 "24h" CHECKSEQUENCEVERIFY DROP<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <Alice's pubkey><br>
ENDIF<br>
CHECKSIG<br>
<br>
that gives ownership only to Bob for the first 24 hours and then to<br>
whichever spends first, we basically propose using the negative bit value:<=
br>
<br>
HASH160 <revokehash> EQUAL<br>
IF<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <Bob's pubkey><br>
ELSE<br>
=C2=A0=C2=A0=C2=A0=C2=A0 "-24h" CHECKSEQUENCEVERIFY DROP<br>
=C2=A0=C2=A0=C2=A0=C2=A0 <Alice's pubkey><br>
ENDIF<br>
CHECKSIG<br>
<br>
meaning that both would have ownership for the first 24 hours, but<br>
after that only Bob would own such coins. Its implementation should<br>
not be too tedious, and in fact it simply implies considering negative<br>
values that are at the moment discarded as for the specification of<br>
BIP-112, leaving the sign bit unused.<br>
<br>
This, we argue, an increase the fairness of the users, and can at times<br>
be more cost-effective for users to do rather than trying a Replace-By-Fee<=
br>
transaction, should they want to modify such payment.<br>
<br>
We would like to have a discussion about this before proposing the<br>
BIP, for which we are preparing the text.<br>
<br>
You can find our paper discussing it here:<br>
<a href=3D"https://hal-cea.archives-ouvertes.fr/cea-01867357" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://hal-cea.archives-ouvertes.fr/cea=
-01867357</a> (find attached as well)<br>
<br>
Best,<br>
<br>
-- <br>
Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiovan=
ni<br>
<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>
--000000000000089c9b057536326c--
|
