|
Title: Delayed transactions (using nTimeLock) Post by: halftimepad on December 18, 2012, 05:15:26 PM Hello all. I'm new in the Bitcoin community and I have a particular interest in contracts, Script and all the new possibilities that usual currencies don't have.
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. https://en.bitcoin.it/wiki/Protocol_specification#tx (https://en.bitcoin.it/wiki/Protocol_specification#tx) There are some interesting uses in contracts in transaction replacement, but this ability seems to be disabled at the moment http://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported (http://bitcoin.stackexchange.com/questions/861/why-isnt-transaction-replacement-supported). I have made a small block explorer based on bitcointools (https://github.com/gavinandresen/bitcointools (https://github.com/gavinandresen/bitcointools)) to find transactions with a lock_time value different from 0 and have found five transactions that do have a wait time. They are in blocks: 000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c 000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05 00000000000005f229df518de50c53616f4f2f895deca078dce1d74d5b79e39c 000000000000026e8536f6ffe741feeb30d7123e6435b3ad7db141833969b5bf 00000000000001d985839442aac0179713fc7f6e5b109d524a272d3d55600d7a The transactions are: Code:
It seems none of them will be able to be redeemed for a long time. I have a few questions: - This ability looks like a feature to me, but it seems clients shouldn't allow this kind of transaction and some people treat this as a bug: http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime/5833#5833 (http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime/5833#5833) https://github.com/bitcoin/bitcoin/issues/1820 (https://github.com/bitcoin/bitcoin/issues/1820) Are locked transactions supposed to be supported or not? - If not, what will happen to the already existing locked transactions? - Can you easily introduce a locked transaction using the standard client? If not, how? Thanks! Title: Re: Delayed transactions (using nTimeLock) Post by: theymos on January 03, 2013, 08:30:58 PM Quote It seems none of them will be able to be redeemed for a long time. That's not how lockTime works. lockTime prevents a transaction from getting into blocks. Once it's in a block, it can be spent. These transactions were always final because all of their inputs have sequence numbers of UINT_MAX: 000000000000036a546044e094db778e1c146f051cd5d0e52fb0e6c43e63ea8c 000000000000049bd7c8aebf91efc907c880a35c05b7861b4eab3fc09655bb05 The other transactions all became final two blocks before the blocks that they were added to. Title: Re: Delayed transactions (using nTimeLock) Post by: Gavin Andresen on January 03, 2013, 09:21:28 PM theymos is correct; if all the inputs have a UINT_MAX sequence number then lockTime is ignored.
Quote Are locked transactions supposed to be supported or not? Yes, they're supported by the network. Quote - Can you easily introduce a locked transaction using the standard client? If not, how? No, there is no easy way to create such a transaction using the reference code. * Super-duper-bitcoin-ninjas like gmaxwell who edit raw transaction hex to set lock times / sequence numbers don't count. Title: Re: Delayed transactions (using nTimeLock) Post by: Mike Hearn on January 03, 2013, 09:24:52 PM You could try writing a bitcoinj app if you want to play with these features. It's an API designed to make doing that kind of thing easy.
Title: Re: Delayed transactions (using nTimeLock) Post by: etotheipi on January 04, 2013, 06:32:32 AM One thing that wasn't mentioned yet was that there's not currently a mechanism for replacement. Locked transactions can be "introduced" into the blockchain fairly easily, and nodes will accept them and hold them in their memory pool (and thus drop conflicting transactions), but they won't forward otherwise-valid replacements, and only miners with custom rules will mine them for you. If you want to replace a time-locked transaction, you're going to have to mine it yourself, or go find a miner to agree to help you. Once a replacement is mined (or even just a regular transaction spending one of the inputs), all nodes holding the time-locked tx will see the conflict and drop the one in their memory pool.
So, if you can create the tx, you can get the "time-delay" aspect out of the network right now, but you have to work pretty hard if you use the "replacement" aspect of it. P.S. - Congrats on being the most well-spoken, research-driven, single-post Newbie I've seen on these forums :) Title: Re: Delayed transactions (using nTimeLock) Post by: gmaxwell on January 04, 2013, 03:47:00 PM - Can you easily introduce a locked transaction using the standard client? If not, how? I thought everyone else had good answeres to your other questions... but you can create locked transactions using createraw transaction and then just manually editing the hex transaction. You'll need to consult the bitcoin wiki on the layout but it's quite easy to adjust the locktime and sequence by hand and decoderawtransaction will show you your success.Title: Re: Delayed transactions (using nTimeLock) Post by: halftimepad on January 05, 2013, 11:55:09 PM Thank you all for the explanations!
I have already been playing with raw transactions in the testnet with bitcoind. After a few false starts (I still have some trouble with the change and I forgot about the sequence number) I think I have managed to send some transactions with a lock time. I'm still a bit confused, because right after sending them, I could spend the coins in another transaction. Here is an example transaction: Code: {The sequence number is a bit strange because I just replaced an f by a 0 in the hex transaction, but I think it is OK. I will continue playing and post the results. I might be doing something else wrong. Title: Re: Delayed transactions (using nTimeLock) Post by: Peter Todd on January 06, 2013, 01:15:49 AM I'm still a bit confused, because right after sending them, I could spend the coins in another transaction. Here is an example transaction: Code: "locktime" : 3, The reason why you were able to spend that tx is because of this. What you've done is made a transaction that can't be spent in any block before block #3, which was over four years ago. What did you expect to happen? Title: Re: Delayed transactions (using nTimeLock) Post by: jl2012 on January 06, 2013, 08:06:11 AM Quote It seems none of them will be able to be redeemed for a long time. Quote "locktime" : 3, obviously you misunderstand the meaning of nlocktime. The value refers to the absolute block height, not a relative one. Your example means "locked after block height = 3", not "locked 3 blocks later" Title: Re: Delayed transactions (using nTimeLock) Post by: halftimepad on January 06, 2013, 11:56:32 AM Quote The reason why you were able to spend that tx is because of this. What you've done is made a transaction that can't be spent in any block before block #3, which was over four years ago. What did you expect to happen? Quote obviously you misunderstand the meaning of nlocktime. The value refers to the absolute block height, a relative one. Your example means "locked after block height = 3", not "locked 3 blocks later" Ouch! How embarrassing! Thank you, that's it! Title: Re: Delayed transactions (using nTimeLock) Post by: Peter Todd on January 06, 2013, 01:36:43 PM Speaking of, here is an exercise for you: why must the locktime be an absolute number? Why can't it be a relative number?
Title: Re: Delayed transactions (using nTimeLock) Post by: halftimepad on January 06, 2013, 09:58:37 PM Speaking of, here is an exercise for you: why must the locktime be an absolute number? Why can't it be a relative number? Uhm... I would think it is because you can never be sure which block will carry your transaction. I guess an absolute number gives you an approximate date. Roughly, you can imagine a block will appear each ten minutes and the transaction will be accepted around the time you include in the timestamp. Title: Re: Delayed transactions (using nTimeLock) Post by: halftimepad on January 06, 2013, 11:29:54 PM I finally did it!
Testnet3 transaction: 33924d240e571f633ee2ea64ffd917d0c6a9a995b670740e54c5bc954f6f33bd Thank you all for the help. The standard client shows it alright and works as expected. Title: Re: Delayed transactions (using nTimeLock) Post by: Peter Todd on January 06, 2013, 11:36:54 PM Speaking of, here is an exercise for you: why must the locktime be an absolute number? Why can't it be a relative number? Uhm... I would think it is because you can never be sure which block will carry your transaction. I guess an absolute number gives you an approximate date. Roughly, you can imagine a block will appear each ten minutes and the transaction will be accepted around the time you include in the timestamp. That's exactly it. You might fight this post by satoshi on that subject interesting: https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119 (https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119) Congrats on your tx! Title: Re: Delayed transactions (using nTimeLock) Post by: phelix on March 29, 2013, 09:23:15 AM Can nLockTime TX be used to flood Mempools?
http://bitcoin.stackexchange.com/questions/8408/can-nlocktime-tx-be-used-to-flood-mempools Quote from: danny If the transactions are properly linked to previous valid transactions they eventually get into the blockchain (and out of the mempool) regardless of the nLockTime lockTime prevents a transaction from getting into blocks. Once it's in a block, it can be spent. From what I see in the source I think danny is wrong and theymos is right: All tx in a block need to be "final" and a tx is only final if we passed it's nLockTime (blockheight or unixtime). Can somebody confirm this? Title: Re: Delayed transactions (using nTimeLock) Post by: theymos on March 29, 2013, 12:20:18 PM All tx in a block need to be "final" Right. a tx is only final if we passed it's nLockTime (blockheight or unixtime). A transaction is also final if its sequence number is equal to UINT_MAX, regardless of nLockTime. Title: Re: Delayed transactions (using nTimeLock) Post by: phelix on March 29, 2013, 04:04:23 PM All tx in a block need to be "final" Right. a tx is only final if we passed it's nLockTime (blockheight or unixtime). A transaction is also final if its sequence number is equal to UINT_MAX, regardless of nLockTime. Thanks for explaining. Now I need to think about it some more. ::) Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on April 24, 2013, 01:38:20 AM It seems like there are three ways someone may want to use transactions/locktime
1. Send a transaction with locktime and revoke or change it before the lock time 2. Send a transaction with locktime and be unable to change it, yet the party receiving the transaction can still not spend it until locktime 3. Send a transaction and shortcut the locktime (basically a normal transaction, described below with uint_max) So reading this thread I understand transactions aren't in blocks until they are final / locktime expires (unless unit_max), but I'm thinking more theoretically for a second on how it should/could work. So usecase #1 seems covered today, I'm told you can resend transactions without the lock time or with a new version and other miners will confirm this (correct me if I'm wrong) And usecase #3 is basically a normal transaction without locktime. The interesting usecase is #2 I think. Here are a few problems I see... Right now nodes probably wont relay transactions with a future locktime of n days out, forcing the party creating the transaction to resend the transaction closer to the locktime or give the transaction to the receiving party to retransmit. Possible solution to this problem is include the transaction in the blockchain, it would be not be able to be changed but that is the purposes of usecase #2. Because the transaction is not confirmed until the future locktime, the sending party can create another transaction and mine a block their-selves (or ask someone else to) and reverse a transaction with a future locktime. The only way around this I see is to add future transactions to the blockchain. So if you did add the transaction to the blockchain then your problem is how do you prevent the receiving party of the transaction from spending the coins before locktime. Though this seems like a easier problem than trying to solve the above two problems. Is it not possible to check the parent transaction of a newly created transaction to make sure it is valid at the time of the new transaction? Again I (think I) realize how it works today, but I dont think this usecase #2 is covered today (please correct me if i'm wrong). Assuming #2 isn't covered today, would adding future transactions to the blockchain, and verifying the parent transaction's locktime be possible? Or does that break all kinds of other things I'm not thinking about. Thanks Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on May 17, 2013, 07:33:47 PM Shamelessly bumping for comments on bitcoin supporting three different types of transactions based on locktime (discussed above).
Thoughts? Title: Re: Delayed transactions (using nTimeLock) Post by: Mike Hearn on May 17, 2013, 09:49:10 PM 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.
Title: Re: Delayed transactions (using nTimeLock) Post by: kfreds on May 18, 2013, 12:05:04 AM 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 Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on May 20, 2013, 03:11:19 PM Thanks for the input, I have a few questions. Hopefully you can clarify a few things for me.
...indeed the risk is that somebody finney attacks you. You can reduce the risk by requiring both parties to sign for the output 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. 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. 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. 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 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 Title: Re: Delayed transactions (using nTimeLock) Post by: coastermonger on May 20, 2013, 04:36:49 PM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on May 20, 2013, 05:26:12 PM 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. 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. Title: Re: Delayed transactions (using nTimeLock) Post by: coastermonger on May 20, 2013, 07:31:05 PM Thanks for the comments scrubadub,
This post is basically a snippet of a larger discussion that is happening here: https://bitcointalk.org/index.php?topic=209409.msg2213559#msg2213559 Quote though it somewhat goes against the idea that once bitcoins are sent they are gone. 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. Title: Re: Delayed transactions (using nTimeLock) Post by: n4ru on October 25, 2013, 06:33:48 AM 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? Title: Re: Delayed transactions (using nTimeLock) Post by: Gavin Andresen on October 27, 2013, 11:44:02 PM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: chsados on November 11, 2013, 02:54:22 AM 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. 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? Title: Re: Delayed transactions (using nTimeLock) Post by: Peter Todd on November 12, 2013, 03:33:00 AM 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? 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. Title: Re: Delayed transactions (using nTimeLock) Post by: Mike Hearn on November 12, 2013, 12:10:13 PM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: gmaxwell on November 12, 2013, 04:42:40 PM 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 (https://bitcointalk.org/index.php?topic=327767.0), 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. Title: Re: Delayed transactions (using nTimeLock) Post by: fortunative on December 14, 2013, 11:14:53 AM One thing that wasn't mentioned yet was that there's not currently a mechanism for replacement. Locked transactions can be "introduced" into the blockchain fairly easily, and nodes will accept them and hold them in their memory pool (and thus drop conflicting transactions), but they won't forward otherwise-valid replacements, and only miners with custom rules will mine them for you. If you want to replace a time-locked transaction, you're going to have to mine it yourself, or go find a miner to agree to help you. Once a replacement is mined (or even just a regular transaction spending one of the inputs), all nodes holding the time-locked tx will see the conflict and drop the one in their memory pool. So, if you can create the tx, you can get the "time-delay" aspect out of the network right now, but you have to work pretty hard if you use the "replacement" aspect of it. P.S. - Congrats on being the most well-spoken, research-driven, single-post Newbie I've seen on these forums :) 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 (https://en.bitcoin.it/wiki/Dominant_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? Title: Re: Delayed transactions (using nTimeLock) Post by: Technomage on December 23, 2013, 11:41:30 PM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: kuverty on December 25, 2013, 03:03:22 AM 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. 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! Title: Re: Delayed transactions (using nTimeLock) Post by: porqupine on March 03, 2014, 04:47:13 AM What's the current status on major mining pools accepting Lock_time transactions / higher sequence number replacements?
Title: Re: Delayed transactions (using nTimeLock) Post by: kjj on March 03, 2014, 01:09:18 PM What's the current status on major mining pools accepting Lock_time transactions / higher sequence number replacements? They don't. No one will accept your transaction until it is final (nLocktime in the past and/or nSequence at maximum). Title: Re: Delayed transactions (using nTimeLock) Post by: porqupine on March 03, 2014, 02:01:58 PM What's the current status on major mining pools accepting Lock_time transactions / higher sequence number replacements? They don't. No one will accept your transaction until it is final (nLocktime in the past and/or nSequence at maximum). 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? Title: Re: Delayed transactions (using nTimeLock) Post by: silversurfer1958 on May 13, 2014, 04:29:27 PM 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 Title: Re: Delayed transactions (using nTimeLock) Post by: DeathAndTaxes on May 13, 2014, 04:41:14 PM 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? 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. Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on June 16, 2014, 05:43:51 PM What's the current status on major mining pools accepting Lock_time transactions / higher sequence number replacements? They don't.No one will accept your transaction until it is final (nLocktime in the past and/or nSequence at maximum). 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. Title: Re: Delayed transactions (using nTimeLock) Post by: DeathAndTaxes on June 16, 2014, 06:29:15 PM 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). Title: Re: Delayed transactions (using nTimeLock) Post by: tryexcept on June 16, 2014, 06:42:18 PM I like how you are thinking. try greenaddress.com ::)
Title: Re: Delayed transactions (using nTimeLock) Post by: Peter R on June 16, 2014, 07:56:07 PM 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? Title: Re: Delayed transactions (using nTimeLock) Post by: DeathAndTaxes on June 16, 2014, 08:09:33 PM 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. 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. Quote 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? 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. Title: Re: Delayed transactions (using nTimeLock) Post by: tryexcept on June 16, 2014, 08:27:54 PM Quote 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. 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 Title: Re: Delayed transactions (using nTimeLock) Post by: scrubadub on June 26, 2014, 02:34:07 AM There are two issues with a system like that a) ...the miner including it in a block could simply take credit b) ...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. 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 (https://bitcointalk.org/index.php?topic=131443.msg1926206#msg1926206). 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. Title: Re: Delayed transactions (using nTimeLock) Post by: DeathAndTaxes on June 26, 2014, 02:47:45 AM 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 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. Title: Re: Delayed transactions (using nTimeLock) Post by: silversurfer1958 on July 05, 2014, 06:16:35 PM 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 :) Title: Re: Delayed transactions (using nTimeLock) Post by: Joe_Bauers on July 10, 2014, 06:29:24 PM 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 :) There is so much potential here, it should at least be attempted! Title: Re: Delayed transactions (using nTimeLock) Post by: kolinko on July 11, 2014, 09:07:45 AM Quote I wonder if some sort of side chain mechanism could do this, or maybe a new coin could handle this. 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. Quote timelocked in a transaction might also be a way of passing on an inheritence to your children 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 Title: Re: Delayed transactions (using nTimeLock) Post by: Jellp on July 12, 2014, 01:13:01 PM 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 Title: Re: Delayed transactions (using nTimeLock) Post by: No_2 on March 17, 2015, 11:43:41 AM ... Note that nLockTime'd transactions are only non-standard until the locktime expires, at which point they can be broadcast and mined normally. ... I've just found a few posts saying nLockTime is not supported dated for around 2013 (here is one example (http://bitcoin.stackexchange.com/questions/7788/what-format-is-the-time-of-a-bitcoin-transaction-stored-in)), but according to this thread the above is true. Can I confirm that this is still the case? Title: Re: Delayed transactions (using nTimeLock) Post by: DeathAndTaxes on March 17, 2015, 02:50:43 PM 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.
Title: Re: Delayed transactions (using nTimeLock) Post by: No_2 on March 17, 2015, 04:15:28 PM 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. Great. That's what I thought but was getting worried something I could not see may have changed. Thanks again DeathAndTaxes. Title: Re: Delayed transactions (using nTimeLock) Post by: Cryddit on March 20, 2015, 09:56:14 PM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: StephenMorse on March 24, 2015, 03:41:34 AM 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. 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 Title: Re: Delayed transactions (using nTimeLock) Post by: Cryddit on March 25, 2015, 02:44:05 AM 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. 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. 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 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. Title: Re: Delayed transactions (using nTimeLock) Post by: silversurfer1958 on July 15, 2016, 12:23:33 AM 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. Title: Re: Delayed transactions (using nTimeLock) Post by: cr1776 on July 15, 2016, 01:02:34 AM 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. Take a look at BIP65, perhaps that would be useful. |