Question regarding transactions with NLOCKTIME > 0

Question regarding transactions with NLOCKTIME > 0
2015-06-21  8:45 ` s7r
  
From: Braun Brelin @ 2015-06-21  7:10 UTC (permalink / raw)
  To: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 669 bytes --]

 permalink raw reply	[|nested]
2015-06-21  7:10 [Bitcoin-development] Question regarding transactions with NLOCKTIME > 0 Braun Brelin

  2015-06-21 12:11   ` Braun Brelin
  
From: s7r @ 2015-06-21  8:45 UTC (permalink / raw)
  To: Braun Brelin, Bitcoin Dev

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
> 



 permalink raw reply	[|nested]
2015-06-21  8:45 ` s7r

  2015-06-21 12:32     ` s7r
  2015-06-21 16:54     ` Jeff Garzik
  
From: Braun Brelin @ 2015-06-21 12:11 UTC (permalink / raw)
  To: s7r;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]

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
> >
>

[-- Attachment #2: Type: text/html, Size: 3041 bytes --]

 permalink raw reply	[|nested]
2015-06-21 12:11   ` Braun Brelin

  2015-06-21 16:54     ` Jeff Garzik
  
From: s7r @ 2015-06-21 12:32 UTC (permalink / raw)
  To: Braun Brelin;  Bitcoin Dev

Hi,

Well, depends on your model and what you want to achieve. That would
depend on each wallet, I couldn't confirm nor deny that this is or isn't
true. You have to check with your wallet how it handles transactions
with nLockTime. Maybe you are the one who generates the nLockTime
transaction,  but that needs to be broadcasted by the payee (your
recipient) when the locktime expires?

One way I would use nLockTime is to have the tx generated, and keep it
somewhere not related to my wallet(s) until the nLockTime expires, then
I can broadcast it to the network by /sendrawtransaction and have it
mined and included into a block.


On 6/21/2015 3:11 PM, 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 <s7r@sky-ip•org
> <mailto: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
>     <mailto:Bitcoin-development@lists•sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>     >
> 
> 



 permalink raw reply	[|nested]
2015-06-21 12:11   ` Braun Brelin
  2015-06-21 12:32     ` s7r

  
From: Jeff Garzik @ 2015-06-21 16:54 UTC (permalink / raw)
  To: Braun Brelin;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]

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 <bbrelin@gmail•com> 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 <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
>> >
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/

[-- Attachment #2: Type: text/html, Size: 4489 bytes --]

 permalink raw reply	[|nested]