Topic: Delayed transactions (using nTimeLock) (Read 13507 times)

Take a look at BIP65, perhaps that would be useful.

I understood that locktime was disabled to prevent DDOSing the system with millions of delayed dust transactions, now that fees are semi significant, or at least not free, maybe it can be turned on again, because DDOSing the network would now involve some significant cost.

Delayed transactions have great potential for, guaranteed future payments, pensions, investment payouts, all guaranteed because they are in the blockchain.

Well, they can if they don't care about making a payment quickly.  But they can sort of do that now.  A double spend of the same coins has a similar effect, given that miners will reliably select the version with higher fees given the choice, and the network will rapidly transmit a tx with minimum fees while it sharply limits the volume of tx with low fees. 

Given the amount of discussion we see about confirmation times already, I doubt it would be a major problem anyhow.


As I said, I'm experimenting here.  This stuff got left out of Bitcoin for reasons that are likely to be good reasons. Given the flak generated over the block size debate, I'd estimate there is a zero percent chance of this getting into bitcoin core within the next ten years.   I've made a very complicated attack surface by making "normal" tx that could not get included into both sides a fork or added to a fork after a reorg. There's likely to be a DoS vulnerability lurking in there somewhere, although I think the normal fork-resolution mechanism can take the strain.

I had a particular use case in mind with nSpendableHeight.  It's a way to give the user a choice about whether a tx is obviously unspendable until a certain height, (ie, anyone can tell it's unspendable until a given block) or whether that information should be kept private until the coins are spent and a script including a hypothetical OP_LOADCHAINHEIGHT is revealed.

That said, you have a point. when I think about the way scripts work in Bitcoin, I think you could also make the script stored in the transaction readable to make the spendable-height information public if you wanted to.   Either way, it adds a lot of CPU time to the job of checking transactions, because you have to connect additional context to tell whether a tx is valid.

I sort of like the idea of an alt that deliberately does things too dangerous for bitcoin just to see if anyone finds a real attack point.

Interesting experimentation. One problem I see with a theoretical nLastTime param is that it gives a way to replace a transaction with a higher fee if it doesn't get included in the next few blocks or so. So, everyone and their brother could broadcast their transactions with ridiculously low fees and then just replace them later if necessary. It seems like it could increase bandwidth required a lot and reduce the fees paid to miners a lot as well, which is not good for the long-term security of the chain.

Adding a nSpendableHeight height param to every TxOut seems unnecessary. Just use the soft-fork OP_CHECKLOCKTIMEVERIFY to basically put nSpendableHeight into the redeem script when it needs it. This way you won't be bloating the blockchain for all the usual cases where you don't care about havin an nSpendableHeight. https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

I've been experimenting.  

I hacked the Bitcoin 0.10 code to handle some extended attributes for transaction admissibility.  It seems to "work"  on my two-machine testnet, but I haven't really yet considered all the attack surfaces rigorously.

In transaction.h I added nLastTime to go along with nLockTime.  While nLockTime is the earliest block in which a transaction would be accepted, nLastTime is the last block in which a transaction would be accepted.  So that, if it hasn't happened by block height nLastTime, you can be absolutely dead certain that, absent a reorg that goes back before that block height, it will never happen.   Then I added IsAliveTx to go along with IsFinalTx and put calls to it in ContextualCheckBlock and IsStandardTx to make the code enforce it.

I added a new member variable named nSpendableHeight in the txOut, which gives a minimum block height which must be reached before a tx spending that output can be accepted into a block, and hacked IsFinalTx to check the inputs and make sure each has reached its spendable height.  It is not at all clear that nLockTime is needed at all if nSpendableHeight is implemented, but I haven't gone to get rid of nLockTime yet.  

In txIn, there was a variable named nSequence, which was connected to an old scheme for transaction replacement that was never implemented, in part because it was a bad idea.  nLastTime allows a tx in the mempool to be replaced (after it could no longer be included in any later block in the block chain) so it wasn't needed and I got rid of it.  

Each of these required a whole bunch of changes in serialization stuff, but that's not all that important.  

Currently, which tx are admissible in a given block depends on which tx have been in previous blocks and which other tx are in the current block, and, in a nonstandard tx, on the block height being at least the nLockTime minimum.  With the changes I added, it also depends on the block height not having exceeded a given nLastTime and on the txOuts that the tx is trying to spend all having reached their nSpendableHeight.  

.....

So I can now make a transaction that pays someone 100 testcoins, but in 10 different txouts of 10 testcoins each, which become spendable at different block heights corresponding to one payment every two weeks for five months.  The receiver  can prepare tx in advance that spend those coins, but the tx won't become valid to include in a block until the coins become spendable.  

So he could make a tx spending one of those outputs, hand it to somebody he owes money, and once the txOut becomes spendable the creditor could broadcast the prepared tx and get paid.   This is approximately the same thing that any "useful" implementation of nLockTime does, so I think nLockTime is truly redundant and probably ought to be removed given an nSpendableHeight on a txOut.

And I can also make a tx that spends 10 testcoins to a given address IF AND ONLY IF it is mined prior to a given block height - and once that block height passes, be absolutely certain that that tx will never get into any later block, so spend those 10 coins in a different way with absolute confidence.  

One issue is that in a reorg, transactions that were valid on one side of the fork cannot necessarily be included on the other side of the fork.  This makes confirmation depth much more important in this test chain than it is in current Bitcoin code - and also makes it more compute-intensive and messy to correctly handle tx in the event of a reorg;  you could wind up with a lot of tx in the mempool that will never become valid on the new branch.

As yet I've only provided ways to specify these values using the RPC interface; hacking QT is its own pain in the arse.

Great. That's what I thought but was getting worried something I could not see may have changed.

Thanks again DeathAndTaxes.

nlocktime is supported.   It is not standard until after the locktime.  That means if you create a nlocktime txn with a future locktime most (virtually all) nodes will not relay the txn but nlocktime is supported by the network.  There are multiple examples of nlocktime txns in the blockchain and many concepts like payment channels are not possible without nlocktime.

I've just found a few posts saying nLockTime is not supported dated for around 2013 (here is one example), but according to this thread the above is true. Can I confirm that this is still the case?

I haven't seen the full thread, but this might be usefull:
I had received a bitcoin transaction with ID debf6be54ada7a9b8ed5f46048140be7055216319be09c0ff6db5310f73b4ba8 on 1-3-2014. (this is the date when my bitcoin-qt had received this transaction) This transaction has however only been received a few days ago by the blockchain. The adress (1SochiWwFFySPjQoi2biVftXn8NRPCSQC) has been used to send 1 satochi to a lot of adresses with this being the first one I've received that confirmed itself.

EDIT: the other transactions currently have ID 60559f8bbbcd9d2f04e5e65ce98a332d0d1894377cf157def9cfeacb6e44defe and ID 6cbe3bca51eee4918ab4493f82aa25baae1f341c6ee791d2fef4a711db52fc4b. Both of these are received on 14-2-2014

Just yesterday we released a proof of concept smart contract for handling timelock functionality:

https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction

The idea is, that there are N oracles (three right now, up to 15 in the future), handled by independent and trustworthy individuals. You create an M of N multisig address, requiring at least 50% of oracles to sign the transaction, and then broadcast the request for signing to them.

As of now, the system runs on just three nodes that were set up by ourselves, but if anyone wants to join in, let me know.


It would be quite easy to do a similar contract within Orisi. The timelock part is ready, but what you could also add is a "timelock extension" mechanism - if a signed message gets posted to oracles before timelock expires, the timelock gets extended by the next X amount of time.

That way, as long as you post a message, the money will be locked on an account. You could also prepeare a special message kind for withdrawing the money to a different account.

Here's a whitepaper about our system: https://github.com/orisi/wiki/wiki/Orisi-White-Paper

There is so much potential here, it should at least be attempted!

I can see the point that the network would need to somehow handle and keep track of a transaction that might not actually complete for years.
having delayed transactions might be very useful for any number of reasons, for example as a pension, if Bitcoin really is a deflationary currency, then it's reasonable to assume huge gains in 10 or 20 yrs time.
The problem is we might get tempted to spend them on the way up.
Having some of our coins timelocked in a transaction might also be a way of passing on an inheritence to your children without the huge fees normally associated with pension providers.
But you would then end up with a situation where  there are millions of transactions being handled by the Bitcoin network, that are not going to mature for years, so I can see it would burden the bitcoin network.

I wonder if some sort of side chain mechanism could do this, or maybe a new coin could handle this.
Let's suppose we wished to set up a pension fund that would receive BTC then begin paying out 5% per annum at some time in the future, let's say 10 yrs.
So we send BTC to an address, the associated private key is Hashed into a new coin in a seperate Network to 'mature'.
At the determined locktime, eg in 10 yrs, it's unhashed and released back onto the Bitcoin network as a payment, (possibly a fractional payment as part of a pension or inheritence for your children).

Could a New coin / network be made to handle that.

A possible scenario might be to send BTc to an address with a Bitmessage attached stating maturity date and fractional release at maturity.
Eg, in 10 yrs time release any accrued funds at rate of 1% per month.

As far as the Bitcoin network is concerned it's simply a single transaction.
It's then hashed to be part of a new coin, the new coin network, doesn't really have to worry that much about being overloaded or DDOS'd because it's sole purpose is to handle and keep track of maturing future bitcoin payments. Perhaps there could be a minimum entry into this new coin network so it too can't be DDOS'd with dust.

Any body up for making PensionCoin / InvestmentCoin  








  

Yes that would work however it would be rather inefficient.  User would need to locate a number of relay providers, create multiple modified copies of the same base tx and send a copy to each relay provider.

Thanks for the detailed comments. For a) I can see how that is true when using anyone-can-spend outputs (OP_TRUE), but how could the miner change the destination if it worked like I described?
1. User negotiates with n number of nlocktime-relay nodes and receives their fee address
2. User creates n number of tx's, each with a standard fee and an output to the nlocktime-relay's address

(I'm just realizing that I don't know at a low level how transactions fees are added to transactions, the tx fee wiki didn't have much. Are they just anyone-can-spend outputs?)

Using this method the outputs are fully defined and signed in the tx (except for the normal fee), so the miners couldn't modify the output to the nlocktime-relay anymore than they can modify outputs of blocks today (I think).

There are obvious downsides like the negotiation and manually broadcasting the nlocktime'd transaction to each relay, but still possible.

however you are one step ahead of me with (b) and I don't have a great response.
With a theoretical hardfork this nlocktime'd fee being paid could be unlocked a certain number of blocks before the rest of the transaction is unlocked and broadcast. Maybe it could be a somewhat complex system where it costs the nlocktime'd fee slowly becomes available so these nlocktime relays can slowly drain this fee. But if you're sending this to 10,000 nlocktime relays they all leach off a fee... bleh

The better option is to come up with a new nlocktime since we're basically trying to solve usecase #2 from here. Where (with a hardfork and a new lock time construct) we could insert the locked tx's into blocks, but not let them be spendable until the lock expires. Solves a lot of the broadcasting issues, and seems like the more needed usecase for locked txs.

This is true but not because you can't do the nlocktime before the service has the transaction but because of malleability. There's some ongoing effort to reduce all sources of malleability other than the ones the sender is capable of (which wouldn't be a problem in this 2of2 case)

See this white paper http://ghgreenaddress.files.wordpress.com/2014/04/greenaddressp2sh2of2hd-61.pdf and the BIP70 extension proposal http://permalink.gmane.org/gmane.comp.bitcoin.devel/5628

It probably would be overly complicated (given the very small window , limited scope, and limited utility of the attack) but one could make this (almost) trustless by having the service sign first.

So
1) user spends some coins
2) service partially signs first
3) offline user partially signs but doesn't broadcast the tx yet.
At this point only the user has the final tx and hash
4) User provides the service but the hash but the not tx
5) Service creates and partially signs the "refund" ntimelock tx.
6) User verifies the refund tx is valid and broadcasts the tx from #3 to the network.

Even here in theory the service could detect the relayed tx, mutate it and broadcast it to one or more miners hoping that a variant of the tx is what ends up in the block (and thus makes the refund tx invalid) but this is a very difficult attack to pull off as it is very likely the users tx broadcast in #6 will win the race to all miners.  Optimally bitcoin will eventually have immutable txids (can be done via a softfork and then eventually deprecation of non-canonical forms in a future block via a hard fork).   With immutable txs, I am not aware of any attack vector.


Yes although it goes by block time so keep in in mind block times can be "fudged" by up to two hours.  In most applications this will not be an issue as the locktime will be sufficiently far in the future.  

I hadn't realized that lock_time could be used in this way with a green-address signer to prevent the "hostage situation."  I see Lawrence (tryexcept) has already considered this with his greenaddress site.  This sounds quite promising.  

I'm trying to wrap my mind around how this would work.  If a depositor sends 1 BTC to the 2-of-2 address and receives back a (non-broadcast) locked-TX that spends those coins back to him at some point in the future, then that locked-TX is only valid for the original 1 BTC output he deposited in the 2-of-2 address.  If the depositor then spends 0.1 BTC from the 2-of-2 address at a retail store, as soon as that 0.1 BTC TX is mined, the original locked-TX becomes invalid.  To resolve this, the green-address signer produces a new timelocked-TX that spends the remaining 0.9 BTC change to the depositor.  

It seems to me that this still can't be made completely trustless.  The locked-TX that spends the coins back to the depositor must refer to the hash of the most recent TX, which isn't known until it's fully signed.  So it's possible (but obviously unlikely as there's no benefit to green-address signer) that a new locked-TX is never sent and the coins could still end up somehow in limbo.  

On a different note, I also noticed that the wiki says that the lock_time value will be interpreted as UNIX time rather than block height if lock_time >= 500000000.  Is this supported?  

I like how you are thinking. try greenaddress.com 

There are two issues with a system like that
a) Bitcoin has no mechanism for detecting the first broadcaster.  Say you hold the tx for five years, and then you broadcast it, the miner including it in a block could simply take credit.  There may be a novel way to avoid this but it isn't a solved problem.  The reverse is also true.  A node could collect a fee in advance but then could simply delete the tx without loss.

b) The fee system is designed to prevent attacks which degrade the performance of the network.  With a finalized tx the tx will eventually end up in a block and thus the network can be assured the fee means a real cost to the user.  An attacker trying to degrade the network would need to a pay a steep fee to do so.   With locktime transactions the fee doesn't guarantee a cost.   A user could spam the network with millions, potentially billions of future txs all with hefty fee and then end up paying for none of them by creating another tx prior to the locktime and broadcasting that making all those held txs invalid and thus the fees promised, never paid.

Still Locktime is a useful tool even when the tx is not relayed.  I will give just one example.  Say I operated a "green address' type site.  You have 1 key, I have 1 key.  The address requires 2 of 2.  I can't spend your coins without your permission and if a merchant trusts me to not approve a double spend then they can trust 0-confirm payments from you.  That would be a very useful service but while I can't steal your funds (2 of 2 remember) I can hold them hostage.  This could be for malicious reasons, governmental interference, or just due to incompetence (if I lose my key your funds are lost forever).  LockTime can be used to end that "stalemate", after each transaction I provide you a future locked tx which sends your coins back to an address you control.   If either one of us loses our key or refuses to sign a tx eventually that locktimed tx will become finalized and you can simply broadcast it to the network to recover your coins.  That LockedTimed tx acts like a "voucher" to recover all your coins in the event of a problem but one which can only be used in the future.  That is just one example but it shows how LockTimed tx don't need to be broadcast to the network prior to their LockTime to be useful.  Other nodes don't need to hold the locked tx because you have a very strong incentive to hold your own locked tx (i.e. in this case it lets you recover your coins).


 

It seems like a simple incentive problem. What if when a user creating a tx that is locked in the future, could offer a reward for either a node storing the tx until the lock expires (then it will broadcast it). Instead of only having a fee that goes to the miner of the block, an additional fee could go to the node that stores and eventually broadcasts the transaction.

I guess the naive approach would be for someone creating this future tx to create multiple copies of the tx, each with a different destination "rebroadcast fee" address. So certain nodes could advertise "I rebroadcast transactions up to n blocks from now with a fee of n*(fee)". Then the user creating the tx would create a new copy of the tx for each "rebroadcast node" it sends the tx to, with that specific rebroadcast node's fee address.

Maybe this has been discussed somewhere else, but just a thought.