nLockTime

[penguin_brian]

Hello,

I am trying to understand nLockTime. I believe it is an optional attribute, normally not set, on transactions. https://en.bitcoin.it/wiki/Protocol_specification

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

Were NLockTime points to https://en.bitcoin.it/wiki/NLockTime

nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.

I thought I understood, but then I read discussions here, however then I read the following from https://greenaddress.it/en/faq/:

But! We have solved this issue by providing nLockTime transactions which essentially make deposits 'expire' after some time, which allows redeeming them without our intervention after this pre-set period of time. It is enabled by default when you have email notifications and two factor enabled.

This allows you to keep your ease of mind even in case GreenAddress.it disappears with its keys.

It also means that every time the funds expire the user has to re-transfer them. This can be automated on login and notified in advance via email or manually done.

Which rather confuses me. Just how does this work?

Thanks

[1715539955]

1715539955

[1715539955]

1715539955

[1715539955]

1715539955

[dree12]

Hello,

I am trying to understand nLockTime. I believe it is an optional attribute, normally not set, on transactions. https://en.bitcoin.it/wiki/Protocol_specification

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

Were NLockTime points to https://en.bitcoin.it/wiki/NLockTime

nLockTime is a parameter that can be attached to a transaction, that mandates a minimal time (specified in either unix time or block height), that before this time, the transaction cannot be accepted into a block.

I thought I understood, but then I read discussions here, however then I read the following from https://greenaddress.it/en/faq/:

But! We have solved this issue by providing nLockTime transactions which essentially make deposits 'expire' after some time, which allows redeeming them without our intervention after this pre-set period of time. It is enabled by default when you have email notifications and two factor enabled.

This allows you to keep your ease of mind even in case GreenAddress.it disappears with its keys.

It also means that every time the funds expire the user has to re-transfer them. This can be automated on login and notified in advance via email or manually done.

Which rather confuses me. Just how does this work?

Thanks

Basically, GreenAddressIt will send a transaction with nLockTime whenever someone makes a deposit. This transaction sends the funds back to the depositor. The nLockTime transaction effectively acts as a deposit expiry: after this time, it will be included in a block and the depositer will get the funds back.

GreenAddressIt works by using multi-factor transactions. Both the user and GreenAddressIt must sign for a transaction to be made from deposited funds. This allows the recipient to disregard the possibility of a double spend since GreenAddressIt has to authorize a double spend, which it won't do if the site is honest. To prevent a database loss or owner disappearance from destroying the funds, the nLockTime transactions are made returning funds to the depositor's address.

[penguin_brian]

Basically, GreenAddressIt will send a transaction with nLockTime whenever someone makes a deposit. This transaction sends the funds back to the depositor. The nLockTime transaction effectively acts as a deposit expiry: after this time, it will be included in a block and the depositer will get the funds back.

Oh, ok. That makes sense. Almost anyway.

Not sure where the funds get sent to in this transaction. There doesn't appear to be any setting for a return address.

Also not sure why you need to run special code to redeem the transaction. Guessing this might be somehow related to the previous point, in the previous paragraph.

GreenAddressIt works by using multi-factor transactions. Both the user and GreenAddressIt must sign for a transaction to be made from deposited funds. This allows the recipient to disregard the possibility of a double spend since GreenAddressIt has to authorize a double spend, which it won't do if the site is honest. To prevent a database loss or owner disappearance from destroying the funds, the nLockTime transactions are made returning funds to the depositor's address.

Looks like GreenAddress is going to provide the option for enforced spending limits and delayed payments in the future. Interesting.

So all outgoing transactions from GreenAddress get signed by two signatures, right? If so, what is this "Instant Confirmation" checkbox for when making outgoing transactions?

Also assuming that GreenAddress must keep copies of both private keys, the passphrase looks to short to have an encoded private key, and yet that appears to be all I require to gain access to my account. If so, am a bit unclear how this is any better then having them hold just one private key.


Thanks

[penguin_brian]

Oh, ok. That makes sense. Almost anyway.

Not sure where the funds get sent to in this transaction. There doesn't appear to be any setting for a return address.

Also not sure why you need to run special code to redeem the transaction. Guessing this might be somehow related to the previous point, in the previous paragraph.

Sorry to answer my own question here. Suspect it has something to do with "determistic wallets" and BIP0032 here.

So all outgoing transactions from GreenAddress get signed by two signatures, right? If so, what is this "Instant Confirmation" checkbox for when making outgoing transactions?

Still unclear here.

Also assuming that GreenAddress must keep copies of both private keys, the passphrase looks to short to have an encoded private key, and yet that appears to be all I require to gain access to my account. If so, am a bit unclear how this is any better then having them hold just one private key.

The website says it doesn't have to keep your private key.

Possibly related to BIP0039, guess I really need to read this.