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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1YxZ2S-0008ID-G7
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:58:20 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.78 as permitted sender)
client-ip=62.13.149.78; envelope-from=pete@petertodd.org;
helo=outmail149078.authsmtp.net;
Received: from outmail149078.authsmtp.net ([62.13.149.78])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YxZ2Q-0002Qr-MA for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:58:20 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAw9gG069064;
Wed, 27 May 2015 11:58:09 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAw5iN062290
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 27 May 2015 11:58:08 +0100 (BST)
Date: Wed, 27 May 2015 06:58:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20150527105805.GC25814@savin.petertodd.org>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
<20150527074713.GB22286@savin.petertodd.org>
<CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="hYooF8G/hrfVAmum"
Content-Disposition: inline
In-Reply-To: <CAAS2fgSjT-dtS8cNoRjvEhtBeG9SUi4OsKAAGkAf_WkxEyg=9g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 42832d3c-045f-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAUUFVQNAgsB AmMbWlVeVVV7WWs7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRhj d1kbC2dycQdEcX4+ ZEFhXHgVWEZydkQp
QR1JFWkDM3phaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNTk6 XB0EBig0WEADSSIp
JBEqYkIGFUAKO04u MFwnEUgVKxsbAQBb EkdRYmdHJlBJXCcy
EA5cVkNWFiBYSypG GXUA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YxZ2Q-0002Qr-MA
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
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: Wed, 27 May 2015 10:58:20 -0000
--hYooF8G/hrfVAmum
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, May 27, 2015 at 08:18:52AM +0000, Gregory Maxwell wrote:
> On Wed, May 27, 2015 at 7:47 AM, Peter Todd <pete@petertodd.org> wrote:
> > Equally this proposal is no more "consensus enforcement" than simply
> > increasing the fee (and possibly decreasing the absolute nLockTime) for
>=20
> You've misunderstood it, I think-- Functionally nlocktime but relative
> to each txin's height.
>=20
> But the construction gives the sequence numbers a rational meaning,
> they count down the earliest position a transaction can be included.
> (e.g. the highest possible sequence number can be included any time
> the inputs are included) the next lower sequence number can only be
> included one block later than the input its assigned to is included,
> the next lower one block beyond that. All consensus enforced. A
> miner could opt to not include the higher sequence number (which is
> the only one of the set which it _can_ include) it the hopes of
> collecting more fees later on the next block, similar to how someone
> could ignore an eligible locked transaction in the hopes that a future
> double spend will be more profitable (and that it'll enjoy that
> profit) but in both cases it must take nothing at all this block, and
> risk being cut off by someone else (and, of course, nothing requires
> users use sequence numbers only one apart...).
I understand that part.
I'm just saying it's not clear to me what's the functional difference in
practice between it and having both parties sign a decreasing absolute
nLockTime. For instance, you and I could setup a payment channel using
the following transaction t0:
1.0 BTC: PT -> 1.0 BTC: PT && (GM || <expiry> CLTV)
1.0 BTC: GM -> 1.0 BTC: GM && (PT || <expiry> CLTV)
After <expiry> both of us are guaranteed to get our funds back
regardless. I can then give you funds by signing my part of t1a:
t0.vout[0] <PT sig> <blank> -> 0.5 BTC: PT
t0.vout[1] <blank> <PT sig> -> 1.5 BTC: GM
nLockTime =3D <expiry - 1>
You can then give me funds with t1b:
t0.vout[0] <blank> <GM sig> -> 1.5 BTC: PT
t0.vout[1] <GM sig> <blank> -> 0.5 BTC: GM
nLockTime =3D <expiry - 2>
etc. etc. We can close the channel by signing a non-nLockTime'd tx at
any time. If you don't co-operate, I have to wait, and hope I get my tx
mined before you get yours.
What I'm not seeing is how the relative nLockTime that nSequence
provides fundamentally changes any of this.
--=20
'peter'[:-1]@petertodd.org
000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6
--hYooF8G/hrfVAmum
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVZaM4XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMWY5NDJlYjRiZmEwYWVjY2I2YTE0YzI2OGY0YzcyZDVm
ZmYxNzI3MGRhNzcxYjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftftgf9EKbJuGjp5nzDWU8VQha8Whov
5mGqMtoKDFoqbV/t4nZD93hP22X4uNo2ntZ9WNm75G27RqxGmDq7TIdocPNNKa4d
PAvtoQEMeKxzcLEB/dRs0HtQ5ebhLU59kY4FCiHGV3R9UhkuoxKVsMvGqoSTUCzL
PhIeHv53cAV+oS0WsYBk4lMJQ/lEc3P8dn13cO9neJZogwN1pGW9Qe1KOt31Ai7h
sSOVTXRBpxdiZwTQggMLk43eDTRvcOjRAo0msjJuuw3GlLyoVxAXt9D/E6s99AsU
YDJEjYZt4eio18KBz8IH5zXa+nJ+77FCdh8yQeQHx6zwN57yl1qZcvT/MmdxXg==
=iuIl
-----END PGP SIGNATURE-----
--hYooF8G/hrfVAmum--
|
