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
|
Return-Path: <a.ranchalpedrosa@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BF41CFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Sep 2018 07:07:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90257786
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 7 Sep 2018 07:07:30 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id f21-v6so13614423wmc.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Sep 2018 00:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:cc:references:from:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=MS6XCKMAZbXYD7LKl3O3yDIHklJ5xEDc9/IwY8HybBM=;
b=MwIxuDvEcQOZZtnuZUoLA9ZdGK3iDveJOXFoglULB+y9t77AAXlSuwGm5JF9KHdA2y
w2Aix+0D6G2pIpUffATDReeBKoHns93TERBRO7s0ax3IBMHuZUBwBExu8rm51sMxemxp
prTq+rJojuFZ03VkhGQRQC9x+cQE+qEhgln1h3+ObrffZkaiUc/wQ1F65z7Uj0BSo1wa
5gLdxuE1BdAAp4O+lNYN5L0lKN4q0MmmPf200LPxmAJ/dgFFgReEbN0Q0UmBCBTLL1G4
l2IdYUq5lrgukHDtP+kp5mYSelqPN3v8jO9go5WT1mvUICuV0mSqZMlvG7KqtaMovJWC
ktpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:cc:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=MS6XCKMAZbXYD7LKl3O3yDIHklJ5xEDc9/IwY8HybBM=;
b=q8QVsAmJeQpjuPAK1iF0RQq/YgQWLkAqNuYyP0rZQxlE1GUAKhVGGs4b1KxuGyUZzG
l4puvm8iWjuvzLQddJ/MqLGEj/OGU9ZsUeHr7mvtyEegr29eudlzUKS2Y5jmc9OLAOUt
vJfaIsoG2n0Yey+8dtB5Y1gsG/2NBoNisowNEcS7WjFm485iEbI1WPvjqZeFSkq6mxWm
x+jezvfrtBRBX2usZkoNaADMc/KkxauZxVmXmMaptul+3uAJu2Zo4eW7tlWMhA6P7MRt
iDrUlOoYrXs4o1BB9yE1ilbafbetPNDWiTtDmt32tT7Penha7YXIlX80W1Z+c/TFO7YY
SdMw==
X-Gm-Message-State: APzg51BFBixBg4XoaxM5VUXN0/11NN3cyYYHsg6n0XwGhm1KuGiFXnuo
3QSZZRicm6nVntNIQ9sfysq6fTUa
X-Google-Smtp-Source: ANB0VdZe2HnDEVhpb44QseziEEdbBjKy5t3foSnig5MkXida/EM1QS9zfnS36LqUCHe/+7v7JmoMwA==
X-Received: by 2002:a1c:f611:: with SMTP id
w17-v6mr4143425wmc.143.1536304048650;
Fri, 07 Sep 2018 00:07:28 -0700 (PDT)
Received: from [10.192.86.228] (clients-xsf-96.upc.es. [147.83.201.96])
by smtp.googlemail.com with ESMTPSA id
v5-v6sm5697666wru.60.2018.09.07.00.07.26
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 07 Sep 2018 00:07:27 -0700 (PDT)
To: Matt Corallo <lf-lists@mattcorallo.com>
References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com>
<8CA4E834-061C-4EE9-A69D-CAE69A08FE7D@mattcorallo.com>
<CABaiX-2L9oVdta=aRH91uE=iPRv4cX6zU0=+oF+2oWqnu=64YQ@mail.gmail.com>
<029a8e95-a265-451d-5417-957d685fa9ce@mattcorallo.com>
From: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com>
Message-ID: <14a4d701-54d3-34b0-8eed-07efafd0061c@gmail.com>
Date: Fri, 7 Sep 2018 09:07:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
Thunderbird/57.0
MIME-Version: 1.0
In-Reply-To: <029a8e95-a265-451d-5417-957d685fa9ce@mattcorallo.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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: Fri, 07 Sep 2018 13:43:39 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 07 Sep 2018 07:07:39 -0000
Yes I agree with what you mean but this requires Alice to broadcast an
additional transaction. Also, Alice is supposed to be able to 'cancel'
the transaction in the first 24hours, not after them.
Best,
Alejandro.
On 9/6/18 6:33 PM, Matt Corallo wrote:
> I think you misunderstood my proposal. What you'd do is the transaction
> is spendable by either Bob OR (Bob AND Alice) and before
> broadcast/during construction/whatever sign a new transaction that
> spends it and is only spendable by Alice, but is timelocked for 24
> hours. At the 24h mark, Alice broadcasts the transaction and once it is
> confirmed only Alice can claim the money.
>
> On 09/06/18 10:59, Alejandro Ranchal Pedrosa wrote:
>> Dear Matt,
>>
>> Notice that what you suggest has some substantial differences. With your
>> suggestion of a multisig option with a 24h timelock, once you give Alice
>> the chance to spend that UTXO without a negative timelock (as we argue),
>> by means of, say, a transaction that she can use, you cannot enforce
>> that this is not used by Alice after the 24hs. Perhaps it is possible,
>> tweaking the Lightning Channel design of Breach Remedy txs, to penalize
>> Alice if she does this, but this requires Bob to check the Blockchain in
>> case he needs to publish a proof-of-fraud, think of adding extra funds
>> to the transaction to account for penalization, etc.
>>
>> Feel free to correct me if I got it wrong in your email.
>>
>> Best,
>> Alejandro.
>>
>>
>> On Thu, Sep 6, 2018 at 3:32 PM Matt Corallo <lf-lists@mattcorallo.com
>> <mailto:lf-lists@mattcorallo.com>> wrote:
>>
>> 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 broadcastable at the 24h mark and has different
>> spendability. This avoids introducing reorg-induced invalidity.
>>
>> On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via
>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>> <mailto: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-Fee
>> 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,
>>
|
