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
|
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 <tier.nolan@gmail.com>) id 1YxzZT-00037G-K0
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 15:18:11 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.173 as permitted sender)
client-ip=209.85.220.173; envelope-from=tier.nolan@gmail.com;
helo=mail-qk0-f173.google.com;
Received: from mail-qk0-f173.google.com ([209.85.220.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxzZS-00056v-Lb
for bitcoin-development@lists.sourceforge.net;
Thu, 28 May 2015 15:18:11 +0000
Received: by qkhg32 with SMTP id g32so28186645qkh.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 28 May 2015 08:18:05 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.107.165 with SMTP id h34mr3743104qgf.63.1432826285168;
Thu, 28 May 2015 08:18:05 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Thu, 28 May 2015 08:18:05 -0700 (PDT)
In-Reply-To: <CAOG=w-tQyrc8ncAFauDObmBYn3uSwBcLoWVqruaV6PcTUFbTKg@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>
Date: Thu, 28 May 2015 16:18:05 +0100
Message-ID: <CAE-z3OXO++0n+UVKe1KYyGv=GyHrZ-MsJtYELk+KC6cEV2UbHQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1139594ec0ac55051725dd3e
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
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YxzZS-00056v-Lb
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:18:11 -0000
--001a1139594ec0ac55051725dd3e
Content-Type: text/plain; charset=UTF-8
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)?
--001a1139594ec0ac55051725dd3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div>On Thu, May 28, 2015 at 3:=
59 PM, Mark Friedenbach <span dir=3D"ltr"><<a href=3D"mailto:mark@friede=
nbach.org" target=3D"_blank">mark@friedenbach.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">Why 3? Do we have a version 2=
?</p></blockquote>I meant whatever the next version is, so you are right, i=
t's version 2. <br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-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><div>The change is backwards =
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 fact 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 the ser=
ialization, 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 p=
osition).<br><br></div><div>I think keeping some of the bytes for other use=
s is a good idea.=C2=A0 The entire top 2 bytes could be ignored when workin=
g 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 byt=
es is set, then that activates the rule and the top 2 bytes are ignored.<br=
><br></div><div>Are there any use-cases which need a RLTV of more than 8191=
blocks delay (that can't be covered by the absolute version)?=C2=A0 <b=
r></div></div></div></div>
--001a1139594ec0ac55051725dd3e--
|
