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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <s7r@sky-ip.org>) id 1Yy0aM-0007Bd-0U
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 16:23:10 +0000
Received-SPF: neutral (sog-mx-1.v43.ch3.sourceforge.com: 162.222.225.12 is
neither permitted nor denied by domain of sky-ip.org)
client-ip=162.222.225.12; envelope-from=s7r@sky-ip.org;
helo=outbound.mailhostbox.com;
Received: from outbound.mailhostbox.com ([162.222.225.12])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Yy0aC-0004OS-Sv for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 16:23:09 +0000
Received: from [0.0.0.0] (wannabe.torservers.net [96.47.226.22])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id 4C1E01A1307;
Thu, 28 May 2015 16:22:50 +0000 (GMT)
Message-ID: <556740D6.5040004@sky-ip.org>
Date: Thu, 28 May 2015 19:22:46 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Tier Nolan <tier.nolan@gmail.com>
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>
In-Reply-To: <CAE-z3OX6pn8HpCXhsN1r_7rX9Wno_e-8dgnrzq0egQNk7N=r3w@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.1 cv=csZm6AMi c=1 sm=1 tr=0
a=IDjeRzmlOBd3L0IU5xujrg==:117 a=IDjeRzmlOBd3L0IU5xujrg==:17
a=ZDnEzkWgAAAA:8 a=-NIMs_s3AAAA:8 a=QrohdLjRRo4A:10 a=N659UExz7-8A:10
a=bvjBBkZ6AAAA:8 a=oFieLWjVAAAA:8 a=FP58Ms26AAAA:8
a=eoo-DVQCglk4cEbRlrAA:9
a=V12MXM33GK4mToT5:21 a=UhofJ-r-RwoYzK2p:21 a=pILNOxqGKmIA:10
X-CTCH-RefID: str=0001.0A020203.556740DB.01A6, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.8 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [162.222.225.12 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1Yy0aC-0004OS-Sv
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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
Reply-To: s7r@sky-ip.org
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 16:23:10 -0000
On 5/28/2015 4:35 PM, Tier Nolan wrote:
> On Thu, May 28, 2015 at 1:04 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>=20
> For that matter, we probably don't want to treat this as a *version=
*
> change, but rather a *feature* flag.=20
>=20
>=20
> 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.
>=20
> 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.=20
>=20
> I think the main benefit is that protocols can have one party trigger a
> step while giving the other party guaranteed time to respond.
>=20
> *Fast Channel Close
> *
>=20
> This assumes that malleability is fixed.
>=20
Indeed. This is very important for refunds.
> Alice creates
>=20
> TXA:
> output (x) to [multisig A1 & B1]
>=20
> Refund:
> input TXA (signed by Alice)
> Output [(A2 & relative_check_locktime(150)) OR (multisig A3 & B2)]
>=20
> Alice sends Refund to Bob
>=20
> Bob signs it and sends it back to Alice
>=20
> Alice verifies the signature, adds her own and sends it to Bob.
>=20
> She broadcasts TXA (would wait until Bob confirms acceptance).
>=20
> This means that both Alice and Bob have the refund transaction and can
> use it to close the channel (assuming TXA is not mutated).
>=20
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.
> 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 an=
d
> b for Bob), signing it and sending it to Bob.
>=20
> 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.
>=20
How is Bob protected in this scenario? 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 Alic=
e.
> 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.
>=20
Can you be more explicit here? It doesn't make sense for me.
> Alice cannot broadcast earlier version, since Bob doesn't send her the
> signed versions.
>=20
> This means that the channel doesn't need a defined end date. Either
> party can close the channel whenever they want.
>=20
With some risks.
> TXA could be protected against malleability by adding a locktime path.=20
> This would only be for use if the transaction is mutated.
>=20
How do you apply a locktime path to a tx in the current network consensus=
?
>=20
> -----------------------------------------------------------------------=
-------
>=20
>=20
>=20
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
|
