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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A3CB8DA2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 13:37:48 +0000 (UTC)
X-Greylist: delayed 00:05:22 by SQLgrey-1.7.6
Received: from mail.bluematt.me (static-100-38-11-146.nycmny.fios.verizon.net
[100.38.11.146])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 146AC7CB
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 6 Sep 2018 13:37:47 +0000 (UTC)
Received: from [IPv6:2607:fb90:13dc:5c95:3c82:1ed7:b899:7e6] (unknown
[172.56.2.140])
by mail.bluematt.me (Postfix) with ESMTPSA id 492881834CF;
Thu, 6 Sep 2018 13:32:25 +0000 (UTC)
Date: Thu, 06 Sep 2018 13:31:58 +0000
In-Reply-To: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----QK4OH3B8YS861OAM93PGRGNMAEYAIF"
Content-Transfer-Encoding: 7bit
To: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Alejandro Ranchal Pedrosa via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>,
bitcoin-dev@lists.linuxfoundation.org
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <8CA4E834-061C-4EE9-A69D-CAE69A08FE7D@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
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:38 +0000
Cc: TUCCI Sara <sara.tucci@cea.fr>,
=?ISO-8859-1?Q?=D6nder_G=DCRCAN?= <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 13:37:48 -0000
------QK4OH3B8YS861OAM93PGRGNMAEYAIF
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
I think a simple approach to what you want to accomplish is to simply have =
a multisig option with a locktime pre-signed transaction which is broadcast=
able at the 24h mark and has different spendability=2E This avoids introduc=
ing reorg-induced invalidity=2E
On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via bitcoin=
-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> 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=2E This way,
>taking the example shown in BIP 112:
>
>HASH160 <revokehash> EQUAL
>IF
> =C2=A0=C2=A0=C2=A0 <Bob's pubkey>
>ELSE
> =C2=A0=C2=A0=C2=A0 "24h" CHECKSEQUENCEVERIFY DROP
> =C2=A0=C2=A0=C2=A0 <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
> =C2=A0=C2=A0=C2=A0 <Bob's pubkey>
>ELSE
> =C2=A0=C2=A0=C2=A0 "-24h" CHECKSEQUENCEVERIFY DROP
> =C2=A0=C2=A0=C2=A0 <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=2E 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=2E
>
>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-Fee
>transaction, should they want to modify such payment=2E
>
>We would like to have a discussion about this before proposing the
>BIP, for which we are preparing the text=2E
>
>You can find our paper discussing it here:
>https://hal-cea=2Earchives-ouvertes=2Efr/cea-01867357 (find attached as
>well)
>
>Best,
>
>--=20
>Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiov=
anni
------QK4OH3B8YS861OAM93PGRGNMAEYAIF
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>I think a simple approach to what you want to acco=
mplish is to simply have a multisig option with a locktime pre-signed trans=
action which is broadcastable at the 24h mark and has different spendabilit=
y=2E This avoids introducing reorg-induced invalidity=2E<br><br><div class=
=3D"gmail_quote">On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Ped=
rosa via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; b=
order-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">Hello everyone,<br><br>We would like to propose a ne=
w BIP to extend OP_CSV (and/or OP_CLTV) in<br>order for these to allow and =
interpret negative values=2E This way,<br>taking the example shown in BIP 1=
12:<br><br>HASH160 <revokehash> EQUAL<br>IF<br> &l=
t;Bob's pubkey><br>ELSE<br> "24h" CHECKSEQUENCEVERIFY=
DROP<br> <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> <B=
ob's pubkey><br>ELSE<br> "-24h" CHECKSEQUENCEVERIFY D=
ROP<br> <Alice's pubkey><br>ENDIF<br>CHECKSIG<br><=
br>meaning that both would have ownership for the first 24 hours, but<br>af=
ter that only Bob would own such coins=2E Its implementation should<br>not =
be too tedious, and in fact it simply implies considering negative<br>value=
s that are at the moment discarded as for the specification of<br>BIP-112, =
leaving the sign bit unused=2E<br><br>This, we argue, an increase the fairn=
ess of the users, and can at times<br>be more cost-effective for users to d=
o rather than trying a Replace-By-Fee<br>transaction, should they want to m=
odify such payment=2E<br><br>We would like to have a discussion about this =
before proposing the<br>BIP, for which we are preparing the text=2E<br><br>=
You can find our paper discussing it here:<br><a href=3D"https://hal-cea=2E=
archives-ouvertes=2Efr/cea-01867357">https://hal-cea=2Earchives-ouvertes=2E=
fr/cea-01867357</a> (find attached as well)<br><br>Best,<br></pre></blockqu=
ote></div></body></html>
------QK4OH3B8YS861OAM93PGRGNMAEYAIF--
|
