Topic: Delayed transactions (using nTimeLock) - page 2. (Read 13520 times)

No.  IsStandard() returns false for any tx which is not final (next block is less than lock value) or if it doesn't have max sequence value.  They won't be relayed or stored by any client by default.

I have been looking into some features like the ability to delay payments. In principle, transactions have a lock time that can be used to delay transactions.


I've been interested in this too, there seems to be a way for semi noobs like myself to implent, but I wouldn't dare try it with real Bitcoin.
Some posters seem to say yes Locktime is supported other answers suggest no, or that its difficult/unreliable.

Here's a link to a site that seems to show how to do it

http://brainwallet.org/#tx

So they will not be store the transaction in memory / broadcast (it to other nodes) before XX Specified Block?

My impression from playing around with it in on testnet, was that the QT client default behaviour was to store a lock_time transaction in memory until said block, but would not accept a higher seq. num replacement for it.

I guess what I'm really asking is along the lines of something like this: suppose someone creates a Lock_time transaction open until a certain XX block, now if a certain event doesn't happen before said XX block, they want to cancel the transaction by broadcasting a replacement set to close at an earlier block (and suppose there is someone willing to accept the higher sequence transaction and mine it) is there a chance that a major pool will in fact receive the first (lower sequence version) of the transaction, store it in memory until said XX block but not accept the higher sequence replacement?

They don't.

No one will accept your transaction until it is final (nLocktime in the past and/or nSequence at maximum).

What's the current status on major mining pools accepting Lock_time transactions / higher sequence number replacements?

Interesting to see this post because this is just what was on my mind too! Maybe it's the finnish winter and grimness? Well, I don't have anything useful to say but this topic cleared things up, very nice!

Very interesting topic. I've been investigating the possibility of building a dead man's switch. I really love that idea: a dead man's switch to transfer your coins to a location where your inheritors can access them.

First I thought it's possible to create a completely 3rd party independent dead man's switch by creating a time locked transaction which you could replace with a longer time lock if you're still alive. That would not require a program to do anything for you after death. This is apparently not possible due to the DDOS issues of replacing tx.

Now the best I can come up with is multiple types of dead man switches where you need to have a server set up to broadcast the transaction after death. That is okay, but not as rock solid. It's probably the best we can do since anything else requires that the transaction can be broadcast before time of death.

etotheipi, I don't think this is the case anymore.  Time-locked transactions can't be introduced into the blockchain until the time expires, right?

Also, I believe that transaction replacement is not a problem now because time-locked transactions are non-standard and not relayed until the lock_time is reached.  Therefore, replacement isn't needed because nodes aren't storing the locked transactions in their mempools.

Given that, I also think that the Mike Hearn example "Dominent Assurance Contracts" that Aakselrod put on the bitcoin wiki page is wrong when it says "The scheme requires the use of multisignature transactions, nLockTime and transaction replacement which means it won't work until these features are available on the Bitcoin network".  Since locked transactions aren't relayed and stored in the mempools, it seems like you can implement this scheme today even though transaction replacement is not available because you should be able to push the transaction that completes the contract because no locked transaction will be in a mempool to conflict.

Could someone confirm this?

I think the no replacement version is at least not terribly worse. Replacement requires miners cooperate in a very specific way, which is costly to them, but can't be enforced, even if someone is offering higher fees if they break the rules.  Somehow, I suspect any protocol that really counted on that wouldn't be very trustworthy.  The best thing that I really can say about the sequence numbers is that you can build protocols where a sequence violation creates proof that your counterparty cheated which could be showed to other people.

n4ru, you can use 'delayed transactions' fine, they're valid on the network once their lock expires. This is adequate for many uses.

I don't think the no-replacement based version is better, it's much more limited. Fortunately it's worse in ways that don't tend to matter for a large class of apps.

However, the resource management issues still exist. Given the complexity of resolving them, I expect them to exist for quite some time until someone working full time is able to focus on it.

If you're thinking of the 'Contracts' page on the wiki, almost none of them use tx-replacement, and the ones that did were insecure because tx replacement is just another type of zero-conf transaction. For micropayments specifically a much better and secure mechanism that doesn't use tx-replacement was developed and is what bitcoinj implements.

Note that nLockTime'd transactions are only non-standard until the locktime expires, at which point they can be broadcast and mined normally.

Frankly nSequence-based replacement shows that Satoshi was human just like the rest of us... it's an awful mechanism that just can't be made secure and opens up DoS attacks if you try.

This is extremely saddening to hear and utterly destroys many of the cool things "smart contracts" promised.

So this will never be a feature in Bitcoin?

Time-in-the-future transactions are non-standard (as of 0.8?  I can never remember when things happened...)

Why: because there is a fill-up-memory denial of service attack, and it really isn't reasonable to expect the entire network to store your timelocked transactions "forever".

Even in the past, the statement "unspendable by the sender because of replacement not being implemented" was not true.  Wait long enough and only a subset of the network will have the timelocked transaction (because new nodes, old nodes restarting, etc). Broadcast a double-spending version without a timelock and it will get mined fairly soon.

I've been looking into this recently as a way to "store" coins for the future. From what I've read, this feature isn't specifically intended to be used this way, but *can* theoretically be done this way.

If we use lock_time to and set a date in the future, am I correct in thinking it now has the following properties?

1) It is unspendable by the receiver until the time is reached (or is it, but will just be unconfirmed?).
2) It is unspendable by the sender *because of replacement not being implemented*.
3) The transaction will propagate through the network until we reach lock_time, after which it is mined.

Basically, I'd like to know how I can properly craft a transaction to send coins to an address that can't be spent before a certain time.

Also, can lock_time be renewed or extended/refreshed? I believe I read somewhere it could be.

EDIT: It seems I'm unable to set sequence to anything but UINT_MAX without it being rejected by the network? Am I doing something wrong here or missing something?
EDIT2: Ah crap. That feature was disabled in 0.8 wasn't it? Is there no way to do a delayed transaction right now?

Thanks for the comments scrubadub,

This post is basically a snippet of a larger discussion that is happening here: https://bitcointalksearch.org/topic/m.2213559


Ideally it won't have to come to this.  What we're trying to do is figure out a clever way to set (in advance) an amount of time that coins must persist in a wallet as soon as a withdrawal request is made.  There are a couple potential solutions, but it might look like the coins would broadcast some kind of "intention to send" in the blockchain without actually leaving the wallet yet.  I offer some ideas in that other thread as to how this could be done.  While pending, any new withdrawal request would just override the previous and nodes would recognize the pending request, refusing to send the full amount until the specified amount of time has passed.  Once out of the owners wallet, they are well and truly sent.  No double spending or chargebacks allowed.

Your ideas too are interesting, but you're right when designing these constraints you have to make sure that an attacker can't also take advantage of them turning your coins against you or locking you out.  Hopefully I address this adequately in the discussion link there.

I like your usecase, I agree it has the potential to stop a lot of hacking attempts, though it somewhat goes against the idea that once bitcoins are sent they are gone.
Would they have to go in the block chain? If the pending transaction was somehow prevented from being confirmed for say 24 hours or so, the owner would still see there is a pending transaction and could send a new version of a transaction to change the destination (it would have to be in the memory pool for that length of time). Though like you point out, only if there is a way to always force transactions from not entering the block chain for a set period of time, and if there is always a way to +1 the version number, otherwise an attacker would just use the highest version.

It might be cool to allow users to set that the bulk of their coins can not be spent without X days of wait time. And maybe another percent of their coins couldn't be confirmed without Y hours of wait time (all determined by the owner). Then if the user wanted to make a large purchase they would just choose to not renew their X days of wait time (or shorten it) on the bulk of their coins.

This would also prevent the transaction from sitting in the memory pool for a length of time. Say a user locks some amount of their coins for 4 days, they could renew this 4 day lock every 24 hours. So if an attacker knew the private keys they would constantly be unable to post a transaction until they prevented the user from locking their coins. However this could obviously go the other way, an attacker could constantly lock your coins from your own use, basically destroying those coins.

I'm not sure how you might achieve this within today's constraints but it is interesting.

An example I've been wondering about:

Say you have bitcoins at an address and you want the coins to display the following properties (possibly due to output scripts needing to be satisfied):
1.) The coins can be spent, but the pending transaction is broadcast and a specified amount of time must pass before the coins actually leave your wallet.
2.) Sending the transaction again overrides the first, and again renews the pending withdrawal time.
3.) A failsafe address is added that allows the coins to immediately be spent to it.  (very important)

Useful for several reasons:
Transaction mistakes happen all the time by human-error.  This allows users a window of time to change something before it becomes irreversible if they messed up a detail (like the amount, miner fee, or destination)
If a thief obtains the private key to an address and attempts to import/spend the coins, they too are subject to the same constraints that make withdrawals pending for the amount of time the owner originally specified.  Any attempt to spend the coins will notify the owner, and he can send to a failsafe address (which likely has a private key stored elsewhere).  A whole chain of such addresses set up so that the job of hacking 1 wallet becomes the job of hacking many.  
Unlike multi-sig, which just makes hacking many private keys necessary, "pending withdrawals + failsafe" allows the owner to be notified that his private key has been obtained if the thief ever attempts to spend his coins.  

Unfortunately as etotheipi points out, there is currently no functionality that allows successive pending withdrawals to replace each other in the blockchain.  I'm sure that other major changes would need to take place.
Just an interesting idea, I'm wondering if anyone else has comment on it.

Thanks for the input, I have a few questions. Hopefully you can clarify a few things for me.


I'm not sure I understand how this would work, but could the sender still just release a new version of the payment?
Sender addy A ---> Receiver addy B (maybe with a locktime, or unsigned output)
Both the sender and receiver have to sign it before it is added to the blockchain. So the sender can just refuse to sign the transaction until they want the coins to be spendable, but this requires the sender to be alive/remember his keys/sign the transaction at the time he wants it to be spendable.
Plus couldn't he just refuse to sign the transaction and keep the coins?

In my example #2 I was going for a way that the sender "fires and forgets" a transaction with coins, and no matter what the receiver will have those coins available to him, after some amount of time.


We wouldn't have to take over the nLockTime parameter and change its meaning from today. Could we just come up with a new parameter scrubadubLockTime (or whatever) that is treated differently and would work for case #2. Would this prevent a hard fork?

Again I would suggest that the transaction is added to a block immediately, but the receiver can not spend those coins until the scrubadubLockTime expires, so the parent transaction would have to be checked when the receiver tries to spend them. And there is nothing the sender can do to get the coins back since they are in the blockchain.


Who controls the address that Tx1 is being sent to? An escrow service of some kind or the sender, or is it just some dead address that no one is supposed to have access to (how can you know that someone doesnt control the private keys)?
Ok so after Tx1 is sent, both parties sign the transaction and it goes into a block. Like you say the sender (and receiver?) dont have control over the coins at this point.
Who creates this Tx2? wouldn't they have to know the private keys of the output from Tx1? So whoever can create a Tx2 with nlocktime without it being final could update that transaction to remove those restrictions right?

I read through the contracts wiki again, I think you were describing the escrow example, but I'm not sure it fulfills my #2 transaction example. https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
Could you be a little more verbose in your example for me?

Thanks

scrubadub, as long as out-of-band communication is ok, you can get the behavior of #2 by using a chain of transactions. No need for a hard fork.

1. Create a transaction Tx1 that spends the amount to an output requiring two pubkeys (sender and receiver). Broadcast.
2. Create a transaction Tx2 that spends the output of Tx1 to an address controlled by the receiver. Add preferred nLockTime, and set the sequence number to < UINT_MAX to not make it final. Sign and send to the receiver.

The receiver waits until Tx1 is in a block, and so the possibility of a Finney attack is gone. The sender has no control over the coins anymore. The coins are spendable to the receiver after nLockTime by first broadcasting Tx2.

A similar one to this and other fun constructs can be found in the article Contracts on the wiki

Mike, isn't this what you meant? Why do you say the risk of a Finney is reduced, and not gone?

// Fredrik

Well, the purpose of nLockTime isn't really to literally lock coins for a particular time, it's intended as part of contract negotiation to allow you to use the memory pool as a kind of race resolver. Whilst you can lock some coins for a long period of time, indeed the risk is that somebody finney attacks you. You can reduce the risk by requiring both parties to sign for the output, for example, but there isn't really a good way to do what you want short of a hard forking rule change. And I don't see any use cases that would justify that.