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
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yy1V2-00039G-DS
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:21:44 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.53 as permitted sender)
client-ip=209.85.192.53; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f53.google.com;
Received: from mail-qg0-f53.google.com ([209.85.192.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yy1Uy-0006R0-Av
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 17:21:44 +0000
Received: by qgez61 with SMTP id z61so19523808qge.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 10:21:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.132.17 with SMTP id 17mr4905189qhe.36.1432833694791;
Thu, 28 May 2015 10:21:34 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 10:21:34 -0700 (PDT)
In-Reply-To: <556740D6.5040004@sky-ip.org>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
<CANEZrP0QMHp9PwBr=ekkujtA+=LXbgiL4xkXRSmcOGqaLJEp0g@mail.gmail.com>
<CAOG=w-s7JkB6SyEE0=KwmrasyH22aB2Zf3jBdKcXvrGoNhN_Nw@mail.gmail.com>
<CANEZrP0zKe7hK0KjiXN9M6CHnJxKZfW9myez3G+GWpr3fugBCg@mail.gmail.com>
<CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>
<CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
<20150528120434.GA31349@savin.petertodd.org>
<CAE-z3OX6pn8HpCXhsN1r_7rX9Wno_e-8dgnrzq0egQNk7N=r3w@mail.gmail.com>
<556740D6.5040004@sky-ip.org>
Date: Thu, 28 May 2015 18:21:34 +0100
Message-ID: <CAE-z3OX+eNfjyXw3MKOktLz4vDdep7qCG8dkJEUDRp5RyGq9MQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c07c72667d8205172797dd
X-Spam-Score: 3.3 (+++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1Yy1Uy-0006R0-Av
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
replacement via sequence numbers
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: Thu, 28 May 2015 17:21:44 -0000
--001a11c07c72667d8205172797dd
Content-Type: text/plain; charset=UTF-8
On Thu, May 28, 2015 at 5:22 PM, s7r <s7r@sky-ip.org> wrote:
> In this scenario, if channel is closed, Alice is the only one who can
> take the coins back after a relative locktime of 150 blocks. Bob is not
> able to do this.
>
Yes, Alice is assumed to be the one who funded the channel. It is a single
direction channel (Alice to Bob).
> How is Bob protected in this scenario?
Assuming the deposit is 1 BTC.
When the channel is created, Alice can broadcast the refund transaction
immediately and the get her money back 150 blocks later.
The full scriptPubKey for the refund transaction would be
OP_IF
<150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DROP <Alice's public key 2>
OP_CHECKSIGVERIFY
OP_ELSE
OP_2 <Alice's public key 3> <Bob's public key 2> OP_2
OP_CHECKMULTISIGVERIFY
OP_ENDIF
This means that Alice can spend the output after 150 blocks but with both
signatures Bob and Alice can spend the output without the delay.
She can send money to Bob by spending the non-locked output of the refund
transaction (0.01BTC for Bob and 0.99BTC for Alice).
Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC from the
refund transaction and is signed by Alice, but still requires his
signature. Only Bob can make the transaction valid.
It can be spent as soon as the refund transaction is broadcast.
He has the refund transaction, so he can start the process whenever he
wishes.
Assume the channel runs for a while, and Alice sends 0.3BTC total.
Bob has a transaction which pays him 0.3BTC and Alice 0.7BTC. He also has
some that pay him less than 0.3, but there is no point in him using those
ones.
Alice decides she wants to close the channel, so asks bob to sign his final
transaction and broadcast it and the refund transaction.
If Bob refuses to do that, then Alice can just broadcast the refund
transaction.
If Bob still refuses to broadcast his final transaction, then Alice gets
1BTC and he gets nothing, after 150 blocks.
This means he will send his final transaction before the 150 blocks have
passed. This gets him 0.3 and Alice 0.7.
Bob can close the channel immediately and Alice can force it to be closed
within 150 blocks (~1 day).
> If Alice sings a transaction
> which spends the output of the refund transaction and gives it to Bob,
> Bob can just add its signature and claim his slice of the output,
> without necessarily shipping the goods or delivering the services to Alice.
>
Protection against that type of fraud isn't covered by channels. They are
just to make sure money is handed over.
> Can you be more explicit here? It doesn't make sense for me.
>
Does the explanation above help?
With some risks.
>
As long as Bob is online and sees the refund transaction being broadcast by
Alice, then there is no risk to him.
Alice can close the transaction whenever she wants, so there is no holdup
risk for her.
> How do you apply a locktime path to a tx in the current network consensus?
>
I mean with OP_CHECKLOCKTIMEVERIFY.
She could say that TXA pays to her in 6 months.
If TXA ends up mutated after being broadcast, then she would have to wait
the 6 months. It's better than nothing and maybe Bob would sign the
mutated transaction.
--001a11c07c72667d8205172797dd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, May 28, 2015 at 5:22 PM, s7r <span dir=3D"ltr"><<a href=3D"m=
ailto:s7r@sky-ip.org" target=3D"_blank">s7r@sky-ip.org</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D""></s=
pan>In this scenario, if channel is closed, Alice is the only one who can<b=
r>
take the coins back after a relative locktime of 150 blocks. Bob is not<br>
able to do this.<br></blockquote><div><br></div><div>Yes, Alice is assumed =
to be the one who funded the channel.=C2=A0 It is a single direction channe=
l (Alice to Bob).<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><span class=3D"">
</span>How is Bob protected in this scenario?</blockquote><div><br></div><d=
iv>Assuming the deposit is 1 BTC.<br><br></div><div>When the channel is cre=
ated, Alice can broadcast the refund transaction immediately and the get he=
r money back 150 blocks later.<br></div><div><br></div><div></div><div>The =
full scriptPubKey for the refund transaction would be<br><br>OP_IF<br></div=
><div>=C2=A0=C2=A0=C2=A0 <150> OP_RELATIVE_CHECKLOCKTIME_VERIFY OP_DR=
OP <Alice's public key 2> OP_CHECKSIGVERIFY<br></div><div>OP_ELSE=
<br></div><div>=C2=A0=C2=A0=C2=A0 OP_2 <Alice's public key 3> <=
;Bob's public key 2> OP_2 OP_CHECKMULTISIGVERIFY<br></div><div>OP_EN=
DIF<br><br>This means that Alice can spend the output after 150 blocks but =
with=20
both signatures Bob and Alice can spend the output without the delay.<br><b=
r>She can send money to Bob by spending the non-locked output of the refund=
transaction (0.01BTC for Bob and 0.99BTC for Alice).<br></div><div><br></d=
iv><div>Bob has a transaction that pays him 0.01BTC and pays Alice 0.99BTC =
from the refund transaction and is signed by Alice, but still requires his =
signature.=C2=A0 Only Bob can make the transaction valid.<br><br>It can be =
spent as soon as the refund transaction is broadcast.<br><br></div><div>He =
has the refund transaction, so he can start the process whenever he wishes.=
<br></div><div><br></div><div>Assume the channel runs for a while, and Alic=
e sends 0.3BTC total.<br><br></div><div>Bob has a transaction which pays hi=
m 0.3BTC and Alice 0.7BTC.=C2=A0 He also has some that pay him less than 0.=
3, but there is no point in him using those ones.<br><br></div><div>Alice d=
ecides she wants to close the channel, so asks bob to sign his final transa=
ction and broadcast it and the refund transaction.<br><br></div><div>If Bob=
refuses to do that, then Alice can just broadcast the refund transaction.<=
br><br></div><div>If Bob still refuses to broadcast his final transaction, =
then Alice gets 1BTC and he gets nothing, after 150 blocks.<br><br></div><d=
iv>This means he will send his final transaction before the 150 blocks have=
passed.=C2=A0 This gets him 0.3 and Alice 0.7.<br><br></div><div>Bob can c=
lose the channel immediately and Alice can force it to be closed within 150=
blocks (~1 day).<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"> If Alice sings a transaction<br>
which spends the output of the refund transaction and gives it to Bob,<br>
Bob can just add its signature and claim his slice of the output,<br>
without necessarily shipping the goods or delivering the services to Alice.=
<br></blockquote><div><br></div><div>Protection against that type of fraud =
isn't covered by channels.=C2=A0 They are just to make sure money is ha=
nded over.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">
<span class=3D"">
</span>Can you be more explicit here? It doesn't make sense for me.<br>=
</blockquote><div><br></div><div>Does the explanation above help? <br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"">
</span>With some risks.<br></blockquote><div><br></div><div>As long as Bob =
is online and sees the refund transaction being broadcast by Alice, then th=
ere is no risk to him.<br><br></div><div>Alice can close the transaction wh=
enever she wants, so there is no holdup risk for her.<br></div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
How do you apply a locktime path to a tx in the current network consensus?<=
br></blockquote><div><br></div><div>I mean with OP_CHECKLOCKTIMEVERIFY.<br>=
<br></div><div>She could say that TXA pays to her in 6 months.=C2=A0 <br><b=
r></div><div>If TXA ends up mutated after being broadcast, then she would h=
ave to wait the 6 months.=C2=A0 It's better than nothing and maybe Bob =
would sign the mutated transaction.<br></div></div></div></div>
--001a11c07c72667d8205172797dd--
|
