nLockTime transaction got confirmed instantly.

[Mitchell]

Hello everyone,

I am currently redoing LockMyCoins (because of some bugs) and I could use some help. I created a nLockTime transaction with a correct sequence number and a valid timelock value. It should have been locked/delayed till 03/11/14 @ 12:00:00am UTC, but well, that didn't happen.

The raw tx:

Code:

0100000001cc923d65a09775c14f1bcdac924eb6d1793a3b17f085a3bb4f83fdcfbd016302010000008b48304502210096db026713c14c1302c7b291649f2bff4eb684dbf4ba8772eb8d54f1da9860a402203eeb7242c3c3bd826803c2fda8d7c979c3afe78fe29128420edff303b7380acc0141042da7f0a57b1fff48209abf56734ac1cd410975896951d8d73a716888c94f068493d1ccc7c1aa413ef9880085f83da1b038a20b410b6b3b975aa2ec72bef35989ffffffff0138082a00000000001976a914f572a7504275ee9c6dc9bc331454493b092a95d788ac00521e53

The transaction in a readable fashion:

Code:

Array
(
    [txid] => d1cab7df73e3389523068b6eed4d59546522150b76eb3a6e22cdaaa858c220e1
    [version] => 1
    [locktime] => 1394496000
    [vin] => Array
        (
            [0] => Array
                (
                    [txid] => 026301bdcffd834fbba385f0173b3a79d1b64e92accd1b4fc17597a0653d92cc
                    [vout] => 1
                    [scriptSig] => Array
                        (
                            [asm] => 304502210096db026713c14c1302c7b291649f2bff4eb684dbf4ba8772eb8d54f1da9860a402203eeb7242c3c3bd826803c2fda8d7c979c3afe78fe29128420edff303b7380acc01 042da7f0a57b1fff48209abf56734ac1cd410975896951d8d73a716888c94f068493d1ccc7c1aa413ef9880085f83da1b038a20b410b6b3b975aa2ec72bef35989
                            [hex] => 48304502210096db026713c14c1302c7b291649f2bff4eb684dbf4ba8772eb8d54f1da9860a402203eeb7242c3c3bd826803c2fda8d7c979c3afe78fe29128420edff303b7380acc0141042da7f0a57b1fff48209abf56734ac1cd410975896951d8d73a716888c94f068493d1ccc7c1aa413ef9880085f83da1b038a20b410b6b3b975aa2ec72bef35989
                        )
                    [sequence] => 4294967295
                )
        )
    [vout] => Array
        (
            [0] => Array
                (
                    [value] => 0.02754616
                    [n] => 0
                    [scriptPubKey] => Array
                        (
                            [asm] => OP_DUP OP_HASH160 f572a7504275ee9c6dc9bc331454493b092a95d7 OP_EQUALVERIFY OP_CHECKSIG
                            [hex] => 76a914f572a7504275ee9c6dc9bc331454493b092a95d788ac
                            [reqSigs] => 1
                            [type] => pubkeyhash
                            [addresses] => Array
                                (
                                    [0] => 1PNouGYhffbBMeSSXWrCR43g3FKdYD2bpo
                                )
                        )
                )
        )
)

Does anybody here know what went wrong or does the Bitcoin Network shit on nLockTime transactions?
Any help is highly appreciated.

IIRC if sequences is max value then nlocktime is "ignored".   

The sequence isn't the max value. Double checked that with other transactions (which didn't have nLockTime) that I generated at (give or take) the same moment.

EDIT: Just noticed that all these transactions have the same sequence number (4294967295). I generated them with Brainwallet, could that be the problem which causes transactions to confirm instantly instead of delaying them?

EDIT2: Apparently this is the reason why they went through. God freaking dammit. What if I simply deducted a 1 from the sequence number. Would that fix this problem or does the sequence number have to be a certain kind of number?

EDIT3: It seems that the sequence number is used for replacing a nLockTime transaction with a new one. I could set this number to 0 or 2132, because replacing a transaction isn't currently disabled, correct?

I am running low of caffine but I am pretty sure 4294967295 = 2^32 - 1 which is the max uint32 value.

On edit: Any value less than max sequence is valid for nlocktime I am just not sure if nodes will relay a tx with sequence value less than max (aka non-standard).

You are right and thanks a lot for confirming my theory. Now I can finally continue with this project.

[1538088599]

1538088599

[1538088599]

1538088599

[1538088599]

1538088599

[1538088599]

1538088599

[Remember remember the 5th of November]

Wasn't this feature disabled? Or maybe it was not implemented?

[Mitchell]

Wasn't this feature disabled? Or maybe it was not implemented?

There are a few transactions created with nLockTime as far as I know.
https://bitcointalk.org/index.php?topic=131443.0 = One of the threads I found about this subject.

[DeathAndTaxes]

IIRC if sequences is max value then nlocktime is "ignored".   

[Mitchell]

IIRC if sequences is max value then nlocktime is "ignored".   

The sequence isn't the max value. Double checked that with other transactions (which didn't have nLockTime) that I generated at (give or take) the same moment.

EDIT: Just noticed that all these transactions have the same sequence number (4294967295). I generated them with Brainwallet, could that be the problem which causes transactions to confirm instantly instead of delaying them?

EDIT2: Apparently this is the reason why they went through. God freaking dammit. What if I simply deducted a 1 from the sequence number. Would that fix this problem or does the sequence number have to be a certain kind of number?

EDIT3: It seems that the sequence number is used for replacing a nLockTime transaction with a new one. I could set this number to 0 or 2132, because replacing a transaction isn't currently disabled, correct?

[DeathAndTaxes]

I am running low of caffine but I am pretty sure 4294967295 = 2^32 - 1 which is the max uint32 value.

On edit: Any value less than max sequence is valid for nlocktime I am just not sure if nodes will relay a tx with sequence value less than max (aka non-standard).

[akkkx]

Source: https://en.bitcoin.it/wiki/Protocol_specification#tx

If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see NLockTime).

[Mitchell]

I am running low of caffine but I am pretty sure 4294967295 = 2^32 - 1 which is the max uint32 value.

On edit: Any value less than max sequence is valid for nlocktime I am just not sure if nodes will relay a tx with sequence value less than max (aka non-standard).

You are right and thanks a lot for confirming my theory. Now I can finally continue with this project.

Source: https://en.bitcoin.it/wiki/Protocol_specification#tx

If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time (see NLockTime).

Yes, I know. Thanks anyway. My question has been answered for now.

[luv2drnkbr]

How does using nLockTime keep your coins in a vault?  By definition, because the sequence number must be lower, any normal tx to spend those same inputs will have priority and thus your nLockTime tx is easily double spent.  It's really only useful for moving cold storage that you don't need.  Like say if you are about to die, you put 75% of your money (not all, so you still have day-to-day expenses covered) into an address and give your kin a signed nLockTime tx for a year from now so they'll get the money if and when you die but you can still spend it if you need it before then.

[Mitchell]

How does using nLockTime keep your coins in a vault?  By definition, because the sequence number must be lower, any normal tx to spend those same inputs will have priority and thus your nLockTime tx is easily double spent.  It's really only useful for moving cold storage that you don't need.  Like say if you are about to die, you put 75% of your money (not all, so you still have day-to-day expenses covered) into an address and give your kin a signed nLockTime tx for a year from now so they'll get the money if and when you die but you can still spend it if you need it before then.

That's why the website generates an address for you to send the coins to (sources will be public and the whole website is open source). Once you leave the website, the private key is gone forever and you have no way of reaching the coins you send. Yes, this does mean that people have to be careful about the time lock, the amount of coins they lock and how they interact with the website. I will try to reduce the risk of losing your coins with popup's, alerts, etc.

[jl2012]

How does using nLockTime keep your coins in a vault?  By definition, because the sequence number must be lower, any normal tx to spend those same inputs will have priority and thus your nLockTime tx is easily double spent.  It's really only useful for moving cold storage that you don't need.  Like say if you are about to die, you put 75% of your money (not all, so you still have day-to-day expenses covered) into an address and give your kin a signed nLockTime tx for a year from now so they'll get the money if and when you die but you can still spend it if you need it before then.

That's why the website generates an address for you to send the coins to (sources will be public and the whole website is open source). Once you leave the website, the private key is gone forever and you have no way of reaching the coins you send. Yes, this does mean that people have to be careful about the time lock, the amount of coins they lock and how they interact with the website. I will try to reduce the risk of losing your coins with popup's, alerts, etc.

Sorry but I can only see risks but not benefits with a project like this. How do I know whether the website is keeping the private key? How about a power outage?

[Mitchell]

How does using nLockTime keep your coins in a vault?  By definition, because the sequence number must be lower, any normal tx to spend those same inputs will have priority and thus your nLockTime tx is easily double spent.  It's really only useful for moving cold storage that you don't need.  Like say if you are about to die, you put 75% of your money (not all, so you still have day-to-day expenses covered) into an address and give your kin a signed nLockTime tx for a year from now so they'll get the money if and when you die but you can still spend it if you need it before then.

That's why the website generates an address for you to send the coins to (sources will be public and the whole website is open source). Once you leave the website, the private key is gone forever and you have no way of reaching the coins you send. Yes, this does mean that people have to be careful about the time lock, the amount of coins they lock and how they interact with the website. I will try to reduce the risk of losing your coins with popup's, alerts, etc.

Sorry but I can only see risks but not benefits with a project like this. How do I know whether the website is keeping the private key? How about a power outage?

It's all client sided and open source. The server doesn't store anything. It only provides the page's.

[kjj]

I am running low of caffine but I am pretty sure 4294967295 = 2^32 - 1 which is the max uint32 value.

On edit: Any value less than max sequence is valid for nlocktime I am just not sure if nodes will relay a tx with sequence value less than max (aka non-standard).

The issue isn't standardness, it is finalness.

If a transaction is not final because the sequence number is incrementable and the locktime has not yet been reached, no one is going to store or forward it for you.

[Boussac]

I am running low of caffine but I am pretty sure 4294967295 = 2^32 - 1 which is the max uint32 value.

On edit: Any value less than max sequence is valid for nlocktime I am just not sure if nodes will relay a tx with sequence value less than max (aka non-standard).

The issue isn't standardness, it is finalness.

If a transaction is not final because the sequence number is incrementable and the locktime has not yet been reached, no one is going to store or forward it for you.

Miners will keep the transaction in their mem pool in the hope that they will get the fee when it can be mined.
They will drop it if the fee is too low or if its double-spent in a standard tx before the nlocktime block.

[gmaxwell]

Miners will keep the transaction in their mem pool in the hope that they will get the fee when it can be mined.
They will drop it if the fee is too low or if its double-spent in a standard tx before the nlocktime block.

No one will today due to the trivial DOS attack that doing so enables.

[DeathAndTaxes]

Miners will keep the transaction in their mem pool in the hope that they will get the fee when it can be mined.
They will drop it if the fee is too low or if its double-spent in a standard tx before the nlocktime block.

No one will today due to the trivial DOS attack that doing so enables.

That gmax.  I knew it was something like that.  So if you create a nlocktime tx you will need to ensure you broadcast it after the lock time as prior to the lock time it will be dropped from the memory pool.

[Mitchell]

Keep talking guys. The more you talk, the more I know and the more information I can put up on the website. It is really helpful! ^^

[kjj]

Miners will keep the transaction in their mem pool in the hope that they will get the fee when it can be mined.
They will drop it if the fee is too low or if its double-spent in a standard tx before the nlocktime block.

No one will today due to the trivial DOS attack that doing so enables.

That gmax.  I knew it was something like that.  So if you create a nlocktime tx you will need to ensure you broadcast it after the lock time as prior to the lock time it will be dropped from the memory pool.

Presumably, some day in the future, miners will store non-final transactions for later mining.  This will probably be a pre-paid service to prevent the whole DOS thing.

Bitcoin is very immature still, and it is really visible in mining.  Most mining is dead simple, basically just diddling the parameters that sort transactions and cut the lists off at the desired block size.

Over time, marketplaces will develop, in parallel with the development of bitcoin software and services.  No one* is doing locked transactions, so no one* has an incentive to create services for them.  With no one* doing them, there is no functioning market to help us figure out what proper prices for such services should be.

* Approximately

[jl2012]

How does using nLockTime keep your coins in a vault?  By definition, because the sequence number must be lower, any normal tx to spend those same inputs will have priority and thus your nLockTime tx is easily double spent.  It's really only useful for moving cold storage that you don't need.  Like say if you are about to die, you put 75% of your money (not all, so you still have day-to-day expenses covered) into an address and give your kin a signed nLockTime tx for a year from now so they'll get the money if and when you die but you can still spend it if you need it before then.

That's why the website generates an address for you to send the coins to (sources will be public and the whole website is open source). Once you leave the website, the private key is gone forever and you have no way of reaching the coins you send. Yes, this does mean that people have to be careful about the time lock, the amount of coins they lock and how they interact with the website. I will try to reduce the risk of losing your coins with popup's, alerts, etc.

Sorry but I can only see risks but not benefits with a project like this. How do I know whether the website is keeping the private key? How about a power outage?

It's all client sided and open source. The server doesn't store anything. It only provides the page's.

The only useful case is probably for pathological gambler who wants to temporarily lock their money. However, destroying the key manually is still much safer than automatically. Also, with the transaction malleability in mind, the txid may be changed when the transaction is confirmed.