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
191
192
193
194
195
196
197
198
199
200
201
202
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bbrelin@gmail.com>) id 1Z6e6Z-0003ve-DH
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 12:12:07 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.53 as permitted sender)
client-ip=74.125.82.53; envelope-from=bbrelin@gmail.com;
helo=mail-wg0-f53.google.com;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Z6e6U-0003kW-7g
for bitcoin-development@lists.sourceforge.net;
Sun, 21 Jun 2015 12:12:07 +0000
Received: by wguu7 with SMTP id u7so48667990wgu.3
for <bitcoin-development@lists.sourceforge.net>;
Sun, 21 Jun 2015 05:11:56 -0700 (PDT)
X-Received: by 10.180.104.197 with SMTP id gg5mr23063864wib.27.1434888716215;
Sun, 21 Jun 2015 05:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.154.137 with HTTP; Sun, 21 Jun 2015 05:11:36 -0700 (PDT)
In-Reply-To: <558679AA.9010308@sky-ip.org>
References: <CAJ2Ovpi_qYFqXZ9hWdobVj1Km04soXVm7GwN+M3Ay8yhZCHhGg@mail.gmail.com>
<558679AA.9010308@sky-ip.org>
From: Braun Brelin <bbrelin@gmail.com>
Date: Sun, 21 Jun 2015 14:11:36 +0200
Message-ID: <CAJ2Ovph8ijL8v0r-gK4NNt7zA7G-1eTTsk7ZWqbw3HqD8jbF7A@mail.gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=f46d041825bc38eb1d05190610d0
X-Spam-Score: -0.6 (/)
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
(bbrelin[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1Z6e6U-0003kW-7g
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Question regarding transactions with
NLOCKTIME > 0
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: Sun, 21 Jun 2015 12:12:07 -0000
--f46d041825bc38eb1d05190610d0
Content-Type: text/plain; charset=UTF-8
So, basically it sounds as though the wallet generating the transaction is
what is responsible for holding on to the transaction and then
only releasing it to the network when the NLOCKTIME value is less than or
equal to the current time. Does that sound right?
Braun
On Sun, Jun 21, 2015 at 10:45 AM, s7r <s7r@sky-ip.org> wrote:
> Hi
>
> I don't think that a transaction with nLockTime>0 will be accepted by
> nodes / relayed in the Bitcoin network, until its time expires (e.g.
> nLockTime==now). This means it obviously cannot be stored in a block,
> before its locktime expires. nLockTime is designed in a way that you,
> need to keep it offline (not broadcast it to the network because it
> won't be accepted or relayed by nodes) until the locktime expires, then
> you can broadcast it and it will be mined and included in a block, like
> a normal tx.
>
> This is exactly why Peter Todd and others are working on
> CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an
> enhancement to basic nLockTime which tends to offer to users the
> guarantee that if you have a transaction with nLockTime, the signer
> holding the private keys used to sign it cannot sign another one, with
> nLockTime 0 and broadcast it before the locktime for your tx expires.
>
> Cheers!
>
> On 6/21/2015 10:10 AM, Braun Brelin wrote:
> > Hi all,
> >
> > When a transaction with N_LOCKTIME>0 is created, does that transaction
> > get stored in a block on the blockchain or is it stored in the mempool
> > until the actual time (or block number) exceeds the current value? If
> > it is stored on the blockchain, how does that affect the concept of
> > pruning that is supposed to be going in to version 0.11? I.e. if I
> > create a transaction that doesn't take effect for 10 years, and that
> > transaction is stored in a block, does that block stay on the active
> > list for that period of time?
> >
> > Thanks,
> >
> > Braun Brelin
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
--f46d041825bc38eb1d05190610d0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So, basically it sounds as though the wallet generating th=
e transaction is what is responsible for holding on to the transaction and =
then<div>only releasing it to the network when the NLOCKTIME value is less =
than or equal to the current time.=C2=A0 Does that sound right? =C2=A0</div=
><div><br></div><div>Braun</div><div><br></div></div><div class=3D"gmail_ex=
tra"><br><div class=3D"gmail_quote">On Sun, Jun 21, 2015 at 10:45 AM, s7r <=
span dir=3D"ltr"><<a href=3D"mailto:s7r@sky-ip.org" target=3D"_blank">s7=
r@sky-ip.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I don't think that a transaction with nLockTime>0 will be accepted b=
y<br>
nodes / relayed in the Bitcoin network, until its time expires (e.g.<br>
nLockTime=3D=3Dnow). This means it obviously cannot be stored in a block,<b=
r>
before its locktime expires. nLockTime is designed in a way that you,<br>
need to keep it offline (not broadcast it to the network because it<br>
won't be accepted or relayed by nodes) until the locktime expires, then=
<br>
you can broadcast it and it will be mined and included in a block, like<br>
a normal tx.<br>
<br>
This is exactly why Peter Todd and others are working on<br>
CHECKLOCKTIMEVERIFY and RELATIVE CHECKLOCKTIMEVERIFY - this is an<br>
enhancement to basic nLockTime which tends to offer to users the<br>
guarantee that if you have a transaction with nLockTime, the signer<br>
holding the private keys used to sign it cannot sign another one, with<br>
nLockTime 0 and broadcast it before the locktime for your tx expires.<br>
<br>
Cheers!<br>
<div><div class=3D"h5"><br>
On 6/21/2015 10:10 AM, Braun Brelin wrote:<br>
> Hi all,<br>
><br>
> When a transaction with N_LOCKTIME>0 is created, does that transact=
ion<br>
> get stored in a block on the blockchain or is it stored in the mempool=
<br>
> until the actual time (or block number) exceeds the current value?=C2=
=A0 If<br>
> it is stored on the blockchain, how does that affect the concept of<br=
>
> pruning that is supposed to be going in to version 0.11?=C2=A0 I.e. if=
I<br>
> create a transaction that doesn't take effect for 10 years, and th=
at<br>
> transaction is stored in a block, does that block stay on the active<b=
r>
> list for that period of time?<br>
><br>
> Thanks,<br>
><br>
> Braun Brelin<br>
><br>
><br>
><br>
</div></div>> ----------------------------------------------------------=
--------------------<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/l=
ists/listinfo/bitcoin-development</a><br>
><br>
</blockquote></div><br></div>
--f46d041825bc38eb1d05190610d0--
|
