Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z6iVv-00033m-80 for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 16:54:35 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.214.176 as permitted sender) client-ip=209.85.214.176; envelope-from=jgarzik@bitpay.com; helo=mail-ob0-f176.google.com; Received: from mail-ob0-f176.google.com ([209.85.214.176]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z6iVt-0000RJ-Vg for bitcoin-development@lists.sourceforge.net; Sun, 21 Jun 2015 16:54:35 +0000 Received: by obbkm3 with SMTP id km3so7666726obb.1 for ; Sun, 21 Jun 2015 09:54:28 -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=83A8cpFG7Xxz4IEsFlcz+70FjOwGLm5Wg462o/PoqBo=; b=dNKFRGj4/sIWPbLLRxtt+VdtwFKx9UM+7/txiaUZzXh2RuTef0K8hmVJyLnk8DAluT YNKh+f0w5Lt1FuumE81dbQq6VVObYZ2FXeTvkIk/dYTJyjZNasa8e9KvXxJjgYYbQ2om VlkZK1ko2Hwyx4XHltrbVl7BYIoYr0PWilt8nblT+qpnNmeLlvwsu73obOeaUVFNR9vW 8f7i0mDOULT/XdML3+GzesrkZ7mY3wAUwCh9qlgfCteHlL2txz1AivGjnAenc9lopN9o Y9ZHherwL8Sv0VcvKl1LhbOOgrK9SqB4WSQQ1RRieFn3YmsQhwNOTVfOoYrUEZ2zW4bt GwUA== X-Gm-Message-State: ALoCoQk5pPcYQWeMpROgjnI8UbJMUTNOwt13LYmPZsQufhK5or9NdHUnKr7jLU39Acgvrze1KtpJ X-Received: by 10.60.156.130 with SMTP id we2mr21925809oeb.24.1434905668527; Sun, 21 Jun 2015 09:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Sun, 21 Jun 2015 09:54:08 -0700 (PDT) In-Reply-To: References: <558679AA.9010308@sky-ip.org> From: Jeff Garzik Date: Sun, 21 Jun 2015 09:54:08 -0700 Message-ID: To: Braun Brelin Content-Type: multipart/alternative; boundary=089e01182852a8c4fd05190a0280 X-Spam-Score: -0.5 (/) 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 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 0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z6iVt-0000RJ-Vg Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2015 16:54:35 -0000 --089e01182852a8c4fd05190a0280 Content-Type: text/plain; charset=UTF-8 Yes, that is correct. The network will not relay until locktime reaches "maturity", i.e. it can be confirmed into a block. The wallet holds onto the transaction -- or simply does not generate -- until it can be confirmed. On Sun, Jun 21, 2015 at 5:11 AM, Braun Brelin wrote: > 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 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 >> > >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e01182852a8c4fd05190a0280 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, that is correct.=C2=A0 The network will not relay unt= il locktime reaches "maturity", i.e. it can be confirmed into a b= lock.

The wallet holds onto the transaction -- or simply= does not generate -- until it can be confirmed.

On Sun, Jun 21, 2015 at 5:11 AM,= Braun Brelin <bbrelin@gmail.com> wrote:
So, basically it sounds as though the walle= t generating the transaction is what is responsible for holding on to the t= ransaction and then
only releasing it to the network when the NLOCKTIME= value is less than or equal to the current time.=C2=A0 Does that sound rig= ht? =C2=A0

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 b= y
nodes / relayed in the Bitcoin network, until its time expires (e.g.
nLockTime=3D=3Dnow). 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 transact= ion
> 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?=C2= =A0 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?=C2=A0 I.e. if= I
> create a transaction that doesn't take effect for 10 years, and th= at
> 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/l= ists/listinfo/bitcoin-development
>


-----------------------------------------------------------= -------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development




--
Jeff Garzik
Bitcoin core developer and open sourc= e evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e01182852a8c4fd05190a0280--