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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Yxv50-0002eb-Ec
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 10:30:26 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yxv4y-0004xn-A6
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 10:30:26 +0000
Received: by qkdn188 with SMTP id n188so22071959qkd.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 03:30:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.202.130 with SMTP id x124mr2313028qha.9.1432809018853;
Thu, 28 May 2015 03:30:18 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 03:30:18 -0700 (PDT)
In-Reply-To: <CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.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>
Date: Thu, 28 May 2015 11:30:18 +0100
Message-ID: <CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11432f14998e76051721d8fc
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: 1Yxv4y-0004xn-A6
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 10:30:26 -0000
--001a11432f14998e76051721d8fc
Content-Type: text/plain; charset=UTF-8
Can you update it so that it only applies to transactions with version
number 3 and higher. Changing the meaning of a field is exactly what the
version numbers are for.
You could even decode version 3 transactions like that.
Version 3 transactions have a sequence number of 0xFFFFFFFF and the
sequence number field is re-purposed for relative lock time.
This means that legacy transactions that have already been signed but have
a locktime in the future will still be able to enter the blockchain
(without having to wait significantly longer than expected).
On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark@friedenbach.org>
wrote:
> I have no problem with modifying the proposal to have the most significant
> bit signal use of the nSequence field as a relative lock-time. That leaves
> a full 31 bits for experimentation when relative lock-time is not in use. I
> have adjusted the code appropriately:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> Mike, this proposal was purposefully constructed to maintain as well as
>>> possible the semantics of Satoshi's original construction. Higher sequence
>>> numbers -- chronologically later transactions -- are able to hit the chain
>>> earlier, and therefore it can be reasonably argued will be selected by
>>> miners before the later transactions mature. Did I fail in some way to
>>> capture that original intent?
>>>
>>
>> Right, but the original protocol allowed for e.g. millions of revisions
>> of the transaction, hence for high frequency trading (that's actually how
>> Satoshi originally explained it to me - as a way to do HFT - back then the
>> channel concept didn't exist).
>>
>> As you point out, with a careful construction of channels you should only
>> need to bump the sequence number when the channel reverses direction. If
>> your app only needs to do that rarely, it's a fine approach.And your
>> proposal does sounds better than sequence numbers being useless like at the
>> moment. I'm just wondering if we can get back to the original somehow or at
>> least leave a path open to it, as it seems to be a superset of all other
>> proposals, features-wise.
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11432f14998e76051721d8fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>Can you update it so that it only applies t=
o transactions with version number 3 and higher.=C2=A0 Changing the meaning=
of a field is exactly what the version numbers are for.<br><br></div>You c=
ould even decode version 3 transactions like that.=C2=A0 <br><br></div>Vers=
ion 3 transactions have a sequence number of 0xFFFFFFFF and the sequence nu=
mber field is re-purposed for relative lock time.=C2=A0 <br><br></div>This =
means that legacy transactions that have already been signed but have a loc=
ktime in the future will still be able to enter the blockchain (without hav=
ing to wait significantly longer than expected).<br></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Thu, May 28, 2015 at 10:56 AM, =
Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.o=
rg" target=3D"_blank">mark@friedenbach.org</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">I have no problem with modifying t=
he proposal to have the most significant bit signal use of the nSequence fi=
eld as a relative lock-time. That leaves a full 31 bits for experimentation=
when relative lock-time is not in use. I have adjusted the code appropriat=
ely:<br><br><a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumber=
s" target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers<=
/a><br></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Wed, May 27, 2015 at 10:39 AM, Mike =
Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_b=
lank">mike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><span><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra">Mike, this proposal was purposefully constructed to maintain as well a=
s possible the semantics of Satoshi's original construction. Higher seq=
uence numbers -- chronologically later transactions -- are able to hit the =
chain earlier, and therefore it can be reasonably argued will be selected b=
y miners before the later transactions mature. Did I fail in some way to ca=
pture that original intent?<br></div></div>
</blockquote></div><br></div></span><div class=3D"gmail_extra">Right, but t=
he original protocol allowed for e.g. millions of revisions of the transact=
ion, hence for high frequency trading (that's actually how Satoshi orig=
inally explained it to me - as a way to do HFT - back then the channel conc=
ept didn't exist).</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">As you point out, with a careful construction of channels =
you should only need to bump the sequence number when the channel reverses =
direction. If your app only needs to do that rarely, it's a fine approa=
ch.And your proposal does sounds better than sequence numbers being useless=
like at the moment. I'm just wondering if we can get back to the origi=
nal somehow or at least leave a path open to it, as it seems to be a supers=
et of all other proposals, features-wise.</div></div>
</blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a11432f14998e76051721d8fc--
|
