@The00Dustin
Well, now I see that nLockTime is pretty useless for my aim.
@CIYAM
You made a great system. I will check it out when some coin integrates it.
@Flashman
I will be glad to see an example of delayed (time-lock) transaction. Unfortunately, I haven't found anything about it on the XCP wiki.
Topic: Time-based crypto container on Bitcoin blockchain? (Read 1651 times)
For the encryption part I don't think that Ethereum can actually help, however, there is a new "proof" that I have been developing (can't go into details as I am getting a math guy to evaluate it for any unforeseen attack vectors and to provide it with a more formal analysis before creating a white paper) that when combined with Shamir's Secret Sharing could go a long way towards providing *exactly* what you are after.
It would not be a "trustless" solution, however, it would only require trusting say X out of Y parties (not sure what the limits of X and Y are with Shamir's offhand) such that X do not conspire together (to break the time-lock) or Y - X do not stop creating new blocks (making the time-lock locked forever).
The "time" would not be exact but would likely occur within a pretty reasonable tolerance.
It would not be a "trustless" solution, however, it would only require trusting say X out of Y parties (not sure what the limits of X and Y are with Shamir's offhand) such that X do not conspire together (to break the time-lock) or Y - X do not stop creating new blocks (making the time-lock locked forever).
The "time" would not be exact but would likely occur within a pretty reasonable tolerance.
Counterparty just ported the entire Ethereum command language to Bitcoin, so whatever that could do, now bitcoin can.
There is a system (which I created some time back) that could easily be able to do part of what the OP is wanting to do (still not encrypting - but proper time locking).
It's called AT (http://ciyam.org/at) and in particular read the "Dormant Funds Transfer" use case (http://ciyam.org/at/at_dormant.html).
Unfortunately although I created a 20 BTC "bounty" to implement AT on a Bitcoin clone (https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263) there hasn't been much interest from devs so far (it is being currently implemented for Qora which is a separate blockchain altogether).
I am not sure whether Ethereum can do this (although presumably it could) so you might also want to look into that (as it is now being used by Counterparty which does actually sit on top of Bitcoin).
It's called AT (http://ciyam.org/at) and in particular read the "Dormant Funds Transfer" use case (http://ciyam.org/at/at_dormant.html).
Unfortunately although I created a 20 BTC "bounty" to implement AT on a Bitcoin clone (https://bitcointalksearch.org/topic/20-btc-bounty-for-first-at-atomic-cross-chain-transfer-with-script-clone-826263) there hasn't been much interest from devs so far (it is being currently implemented for Qora which is a separate blockchain altogether).
I am not sure whether Ethereum can do this (although presumably it could) so you might also want to look into that (as it is now being used by Counterparty which does actually sit on top of Bitcoin).
@The00Dustin
Yup - I think you have understood it correctly - so it doesn't really "lock funds" at all - but instead can "unlock them" assuming they weren't spent in the meantime.
Yup - I think you have understood it correctly - so it doesn't really "lock funds" at all - but instead can "unlock them" assuming they weren't spent in the meantime.
@Elwar @CIYAM
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
While I haven't done any investigation, I am assuming that it is possible to export a signed raw transaction with the nLockTime setting encoded in it. I am also assuming that the signature covers nLockTime so that it cannot be manipulated. Otherwise, this wouldn't make sense:I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
Specifically because of this:You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
In other words, assuming I'm right, once you generate and export a signed nLockTime transaction, it can be distributed to multiple parties, any one of whom can execute it after the time has expired. However, in the meantime, the funds would not really be locked. That is to say that if you wanted to cancel the scheduled transaction, you would only need to make a new transaction right now to move coins from the input that is scheduled to be used, however, it also means that if your private keys were hacked/stolen, the funds could still be stolen (ETA: immediately).ETA: I know this still isn't what you want, but it isn't what you want because you want to lock yourself out, while you indicated it wasn't what you wanted because the transaction could be lost (presumably by the software closing).
As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped.
I think you'll find it's actually worse than that (from what I recall reading it won't be included in the mempool of peers at all unless you are running "testnet").
@Elwar @CIYAM
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
@Vessko
Thanks for the link. I will look into it.
I found nLockTime interesting but it has some issues. As far as I understand a tx with nLockTime may be lost (it's stored in mempool and not included in the blockchain) if mempools of nodes, my client broadcasted to, were wiped. So such method can't be used for long-term savings (I want to keep myself from spending some BTC for a long time).
@Vessko
Thanks for the link. I will look into it.
@Elwar
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
Yes, that is what I was talking about. This would actually make a pretty good Bitcoin service.
Time-lock encryption is a fiendishly difficult problem but there are various possible solutions. For a short overview, see, for instance, Time-lock encryption.
@Elwar
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
@OP - this of course has nothing to do with encryption (as Bitcoin doesn't encrypt anything).
You are probably referring to nLockTime and yes the issue is that nLockTime txs whose time (or block) is in the future are not accepted by peers (so your client would have to re-broadcast the tx after that point in time).
It still has some value in that the tx could be manually sent to another person (thus acting like a last will) provided that they eventually broadcast in order to make sure the transfer actually happens.
@OP - this of course has nothing to do with encryption (as Bitcoin doesn't encrypt anything).
There are ways to add time delays to a transaction but from everything I have seen you have to run the client the whole time.
I checked into it a while ago, basically you can add code to a transaction but the code lives on your wallet and executes only if that wallet is running (there is more to it but that was the high level impression I got out of it).
I checked into it a while ago, basically you can add code to a transaction but the code lives on your wallet and executes only if that wallet is running (there is more to it but that was the high level impression I got out of it).
I wonder if it's possible to make some kind of crypto container using blockchain technology which I can only decrypt after sometime (eg. 1 year). I know there are some methods depending on Moore's law and weak cryptography but this is not what I need. In brief, I'd like to have a time capsule.
Jump to: