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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yxxyf-00019b-7N
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 13:36:05 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.181 as permitted sender)
client-ip=209.85.220.181; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f181.google.com;
Received: from mail-qk0-f181.google.com ([209.85.220.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yxxyd-0002Dg-G5
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 13:36:05 +0000
Received: by qkx62 with SMTP id 62so25649024qkx.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 06:35:58 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.202.130 with SMTP id x124mr3354514qha.9.1432820157973;
Thu, 28 May 2015 06:35:57 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 06:35:57 -0700 (PDT)
In-Reply-To: <20150528120434.GA31349@savin.petertodd.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>
Date: Thu, 28 May 2015 14:35:57 +0100
Message-ID: <CAE-z3OX6pn8HpCXhsN1r_7rX9Wno_e-8dgnrzq0egQNk7N=r3w@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11432f148b15050517247058
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: 1Yxxyd-0002Dg-G5
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 13:36:05 -0000
--001a11432f148b15050517247058
Content-Type: text/plain; charset=UTF-8
On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete@petertodd.org> wrote:
> For that matter, we probably don't want to treat this as a *version*
> change, but rather a *feature* flag.
I think it is still a version change. At the moment, the 4 bytes refer to
the sequence number and afterwards they mean something else.
For relative locktime verify, I think most use cases could be block count
based and don't need to be able to count very high.
I think the main benefit is that protocols can have one party trigger a
step while giving the other party guaranteed time to respond.
*Fast Channel Close*
This assumes that malleability is fixed.
Alice creates
TXA:
output (x) to [multisig A1 & B1]
Refund:
input TXA (signed by Alice)
Output [(A2 & relative_check_locktime(150)) OR (multisig A3 & B2)]
Alice sends Refund to Bob
Bob signs it and sends it back to Alice
Alice verifies the signature, adds her own and sends it to Bob.
She broadcasts TXA (would wait until Bob confirms acceptance).
This means that both Alice and Bob have the refund transaction and can use
it to close the channel (assuming TXA is not mutated).
Alice can send money to Bob by creating a transaction which spends the
output of the refund transaction (splitting the output x-b for Alice and b
for Bob), signing it and sending it to Bob.
Alice can force Bob to close the channel by broadcasting the refund
transaction. 150 blocks later, she gets the channel deposit if he doesn't
act.
If she had sent some money to Bob, he has 150 blocks to sign the
transaction that pays him the most money and broadcast it. Alice gets the
remainder of the deposit.
Alice cannot broadcast earlier version, since Bob doesn't send her the
signed versions.
This means that the channel doesn't need a defined end date. Either party
can close the channel whenever they want.
TXA could be protected against malleability by adding a locktime path.
This would only be for use if the transaction is mutated.
--001a11432f148b15050517247058
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, May 28, 2015 at 1:04 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>For that matter, we probably don't want to treat this as a *vers=
ion*<br>
change, but rather a *feature* flag. </blockquote><div><br></div><div>I thi=
nk it is still a version change.=C2=A0 At the moment, the 4 bytes refer to =
the sequence number and afterwards they mean something else.<br><br></div><=
div>For relative locktime verify, I think most use cases could be block cou=
nt based and don't need to be able to count very high.=C2=A0 <br><br></=
div><div>I think the main benefit is that protocols can have one party trig=
ger a step while giving the other party guaranteed time to respond.<br></di=
v><div><br></div><div></div><b>Fast Channel Close<br></b></div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">This assumes that mal=
leability is fixed.<br></div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">Alice creates<br></div><div class=3D"gmail_quote"><br></d=
iv><div class=3D"gmail_quote">TXA: <br>output (x) to [multisig A1 & B1]=
<br><br></div><div class=3D"gmail_quote">Refund: <br>input TXA (signed by A=
lice)<br></div><div class=3D"gmail_quote">Output [(A2 & relative_check_=
locktime(150)) OR (multisig A3 &=C2=A0 B2)]<br></div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">Alice sends Refund to Bob<br>=
<br></div><div class=3D"gmail_quote">Bob signs it and sends it back to Alic=
e<br><br></div><div class=3D"gmail_quote">Alice verifies the signature, add=
s her own and sends it to Bob.<br><br></div><div class=3D"gmail_quote">She =
broadcasts TXA (would wait until Bob confirms acceptance).<br><br></div><di=
v class=3D"gmail_quote">This means that both Alice and Bob have the refund =
transaction and can use it to close the channel (assuming TXA is not mutate=
d).<br><br></div><div class=3D"gmail_quote">Alice can send money to Bob by =
creating a transaction which spends the output of the refund transaction (s=
plitting the output x-b for Alice and b for Bob), signing it and sending it=
to Bob.<br><br></div><div class=3D"gmail_quote">Alice can force Bob to clo=
se the channel by broadcasting the refund transaction.=C2=A0 150 blocks lat=
er, she gets the channel deposit if he doesn't act.<br><br></div><div c=
lass=3D"gmail_quote">If she had sent some money to Bob, he has 150 blocks t=
o sign the transaction that pays him the most money and broadcast it.=C2=A0=
Alice gets the remainder of the deposit.<br><br></div><div class=3D"gmail_=
quote">Alice cannot broadcast earlier version, since Bob doesn't send h=
er the signed versions.<br><br></div><div class=3D"gmail_quote">This means =
that the channel doesn't need a defined end date.=C2=A0 Either party ca=
n close the channel whenever they want.<br><br></div><div class=3D"gmail_qu=
ote">TXA could be protected against malleability by adding a locktime path.=
=C2=A0 This would only be for use if the transaction is mutated.<br></div><=
/div></div>
--001a11432f148b15050517247058--
|
