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
|
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 <mark@friedenbach.org>) id 1Yxzto-0007XU-RV
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 15:39:12 +0000
X-ACL-Warn:
Received: from mail-ig0-f174.google.com ([209.85.213.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yxztl-00074A-0z
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 15:39:12 +0000
Received: by igbpi8 with SMTP id pi8so116999005igb.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 08:39:03 -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=Cpw1CXDjHGpZ1sFy0Kk9wfIA/Dw66ra5rCCgnjR9m5k=;
b=OcyKJLnarlHms2/mGr2+z7s5/oWsDV+tO3E+HwoE7UThUuAggicqrPb7YSULi8tcoq
FcPi3H6p2eifTVyeWjylhCrns3tPVdPBflnkjGB89SidQ4RF7WPmM1RX+kd3xVaYfd32
gzjdu5YunjZDtOC+q1ip8DdnTJWG9SfKObBcqMuYfoy4nC/mQzYhjaBRIXUR/oUpZypO
v6xNrxu/5dkaL986yRpV8sN6rMcyfh3CyYznLk82bttyhRmbZvEKCQsi06+/ZBfYMh9d
Yoynw6vc8/OL1WscamTZeNtcF0PcewaBThPetWvJbARJH1XxR5AWhJbWCx4CmjWFOg4V
CiYw==
X-Gm-Message-State: ALoCoQnzu5I9xLFHWEyZMpo+99zSrK8sjIRx+O86OeVTmIlB+hkYfvMRZGAVceWk7HM0A/o5ZKNB
X-Received: by 10.107.3.210 with SMTP id e79mr4289174ioi.50.1432827543639;
Thu, 28 May 2015 08:39:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.197 with HTTP; Thu, 28 May 2015 08:38:43 -0700 (PDT)
X-Originating-IP: [50.0.37.37]
In-Reply-To: <CAE-z3OXO++0n+UVKe1KYyGv=GyHrZ-MsJtYELk+KC6cEV2UbHQ@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>
<CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
<CAOG=w-tQyrc8ncAFauDObmBYn3uSwBcLoWVqruaV6PcTUFbTKg@mail.gmail.com>
<CAE-z3OXO++0n+UVKe1KYyGv=GyHrZ-MsJtYELk+KC6cEV2UbHQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 28 May 2015 08:38:43 -0700
Message-ID: <CAOG=w-vY7WHso90mtzhSRiuTLVfahMv1Xr6p_AZvyh4krxPLSg@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f8ef0c36f710517262836
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: 1Yxztl-00074A-0z
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 15:39:12 -0000
--001a113f8ef0c36f710517262836
Content-Type: text/plain; charset=UTF-8
Oh ok you mean a semantic difference for the purpose of explaining. It
doesn't actually change the code.
Regarding saving more bits, there really isn't much room if you consider
time-based relative locktimes and long-lived channels on the order of a
year or more.
On Thu, May 28, 2015 at 8:18 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> Why 3? Do we have a version 2?
>>
> I meant whatever the next version is, so you are right, it's version 2.
>
>> As for doing it in serialization, that would alter the txid making it a
>> hard fork change.
>>
> The change is backwards compatible (since there is no restrictions on
> sequence numbers). This makes it a soft fork.
>
> That doesn't change the fact that you are changing what a field in the
> transaction represents.
>
> You could say that the sequence number is no longer encoded in the
> serialization, it is assumed to be 0xFFFFFFFF for all version 2+
> transactions and the relative locktime is a whole new field that is the
> same size (and position).
>
> I think keeping some of the bytes for other uses is a good idea. The
> entire top 2 bytes could be ignored when working out relative locktime
> verify. That leaves them fully free to be set to anything.
>
> It could be that if the MSB of the bottom 2 bytes is set, then that
> activates the rule and the top 2 bytes are ignored.
>
> Are there any use-cases which need a RLTV of more than 8191 blocks delay
> (that can't be covered by the absolute version)?
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a113f8ef0c36f710517262836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Oh ok you mean a semantic difference for the purpose =
of explaining. It doesn't actually change the code.<br><br></div>Regard=
ing saving more bits, there really isn't much room if you consider time=
-based relative locktimes and long-lived channels on the order of a year or=
more.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Thu, May 28, 2015 at 8:18 AM, Tier Nolan <span dir=3D"ltr"><<a href=3D=
"mailto:tier.nolan@gmail.com" target=3D"_blank">tier.nolan@gmail.com</a>>=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cla=
ss=3D"gmail_extra"><div><span class=3D"">On Thu, May 28, 2015 at 3:59 PM, M=
ark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:mark@friedenbach.or=
g" target=3D"_blank">mark@friedenbach.org</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><p dir=3D"ltr">Why 3? Do we have a version 2?</p></b=
lockquote></span>I meant whatever the next version is, so you are right, it=
's version 2. <br></div><div class=3D"gmail_quote"><span class=3D""><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex">
<p dir=3D"ltr">As for doing it in serialization, that would alter the txid =
making it a hard fork change.</p></blockquote></span><div>The change is bac=
kwards compatible (since there is no restrictions on sequence numbers).=C2=
=A0=C2=A0 This makes it a soft fork.<br><br>That doesn't change the fac=
t that you are changing what a field in the transaction represents.<br><br>=
</div><div>You could say that the sequence number is no longer encoded in t=
he serialization, it is assumed to be 0xFFFFFFFF for all version 2+ transac=
tions and the relative locktime is a whole new field that is the same size =
(and position).<br><br></div><div>I think keeping some of the bytes for oth=
er uses is a good idea.=C2=A0 The entire top 2 bytes could be ignored when =
working out relative locktime verify.=C2=A0 That leaves them fully free to =
be set to anything.=C2=A0 <br><br>It could be that if the MSB of the bottom=
2 bytes is set, then that activates the rule and the top 2 bytes are ignor=
ed.<br><br></div><div>Are there any use-cases which need a RLTV of more tha=
n 8191 blocks delay (that can't be covered by the absolute version)?=C2=
=A0 <br></div></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>
--001a113f8ef0c36f710517262836--
|
