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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1YxuYh-0008NI-4l
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 09:57:03 +0000
X-ACL-Warn:
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxuYf-0001yL-Pg
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 09:57:03 +0000
Received: by ieczm2 with SMTP id zm2so34241135iec.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 02:56:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=F06pwZJl/MrEXjVNV6Fb4vlj0DqyhtMKFmI56M5xShM=;
b=O+t3nbJHHQllNn1fE8qjXz/aeNxSxUIYUYImNTgD2PZYlVUr1tL4TtzJmNFzQoMiyK
DRDYGXWg+CFf8Qcb8FU4jqRuAL23YsYrEXkkXRkU459aT+Wrwo4E7gjvVvEKKa8LDHcy
vuvn1cptp6gmrJ7b27upZ5T0KFSCPVBLYNgLlCo8yO97rnr/L1E1l3CTK+LCXO6ccPUv
T9+Z4RMwR3MwV3LPYzSisQfgLXH+ngpq3ppVRmPXcsQvnakWx+mDcfEISvCbD1Gr8X50
yZsARl7QGvwM6gzlUyujQ9BCzvwkPfqCEVh/rIGSVlNzJCNw4TMtoISn/Cfx2wg0Z7ua
VR5Q==
X-Gm-Message-State: ALoCoQk9646rP14fw9svHd9l4Hwl8AsRvJ5p4OETw5LhnHJo/OJ5u8RgDAzf350oQBItKddMnZPt
X-Received: by 10.42.176.8 with SMTP id bc8mr8056822icb.22.1432807016408; Thu,
28 May 2015 02:56:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.197 with HTTP; Thu, 28 May 2015 02:56:36 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <CANEZrP0zKe7hK0KjiXN9M6CHnJxKZfW9myez3G+GWpr3fugBCg@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>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 28 May 2015 02:56:36 -0700
Message-ID: <CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=90e6ba6e86423ec12505172161ea
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YxuYf-0001yL-Pg
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: Thu, 28 May 2015 09:57:03 -0000
--90e6ba6e86423ec12505172161ea
Content-Type: text/plain; charset=UTF-8
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.
>
--90e6ba6e86423ec12505172161ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I have no problem with modifying the proposal to have the =
most significant bit signal use of the nSequence field as a relative lock-t=
ime. That leaves a full 31 bits for experimentation when relative lock-time=
is not in use. I have adjusted the code appropriately:<br><br><a href=3D"h=
ttps://github.com/maaku/bitcoin/tree/sequencenumbers">https://github.com/ma=
aku/bitcoin/tree/sequencenumbers</a><br></div><div class=3D"gmail_extra"><b=
r><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"_blank">m=
ike@plan99.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><span class=3D""><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra">Mike, this proposal was purposefully constructed to maintain as we=
ll 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 select=
ed by miners before the later transactions mature. Did I fail in some way t=
o capture 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>
--90e6ba6e86423ec12505172161ea--
|
