Topic: Make a transaction that cannot be spent in X years (Read 1839 times)
I mean I guess you could put the coins away like the Winklevoss twins do and save the codes in the safety deposit box or something. I'm not sure if they can keep the said owner of the box out until the time you stipulate. It is a rather interesting question to me and I'll follow along to see if there is a current solution or what people think could work.
After some research, I've found out that it can be done; it is not the easiest thing to do and it's not 100% safe:
First way:
1) I sign a transaction that transfers the amount to a multi-sig address, redeemable by me and by another private key owned by the recipient;
2) I sign an incomplete transaction with the desired lock time that transfers the amount from the multi-sig address to the sole address owned by the recipient (or another). The recipient completes the transaction by signing it but does not broadcast it.
3) when the time has come the transaction is broadcasted by the recipient. The broadcast cannot be done before otherwise nodes may drop it because is too far in the future.
This schema also works if the money is needed before (e.g. health issue). I and the recipient would just have to sign a new transaction that moves the bitcoins somewhere.
There is the problem though, also pointed out by a previous poster, that the transaction format must not change meanwhile...
Second way:
Using an oracle.
sources: https://en.bitcoin.it/wiki/Contracts (Example 4).
Best regards,
ilpirata79
First way:
1) I sign a transaction that transfers the amount to a multi-sig address, redeemable by me and by another private key owned by the recipient;
2) I sign an incomplete transaction with the desired lock time that transfers the amount from the multi-sig address to the sole address owned by the recipient (or another). The recipient completes the transaction by signing it but does not broadcast it.
3) when the time has come the transaction is broadcasted by the recipient. The broadcast cannot be done before otherwise nodes may drop it because is too far in the future.
This schema also works if the money is needed before (e.g. health issue). I and the recipient would just have to sign a new transaction that moves the bitcoins somewhere.
There is the problem though, also pointed out by a previous poster, that the transaction format must not change meanwhile...
Second way:
Using an oracle.
sources: https://en.bitcoin.it/wiki/Contracts (Example 4).
Best regards,
ilpirata79
I'm not sure if it is possible within the current implementation of Bitcoin, but one suggestion might be a safe deposit box - although that would then be within the realms of a bank. Perhaps some other location within your security just in case of emergency.
There is a mechanism in the protocol that blocks a transaction until a certain time or block.
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
That has the problem that I can revoke the transaction when I want, by broadcasting a different transaction that has not the lock.
What I want is for the money to be not spendable until the time has come...
like I transfer the amount to a public key (the transaction gets into the block) whose script does not allow to spend the amount until a certain date has come.
Best regards,
ilpirata79
2. Save the signed transaction and delete your private key to adress A. Give the private key to adress B to the recipient.
3. Hope that the protocol doesn't change so that your transaction is still valid when the lock time ends.
There is a mechanism in the protocol that blocks a transaction until a certain time or block.
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
That has the problem that I can revoke the transaction when I want, by broadcasting a different transaction that has not the lock.
1. Send the money to an intermediate address.
2. Create a time-locked transaction sending from the intermediate address.
3. Destroy the private key for the intermediate address.
What about giving them the private key of the address but encrypted? You can set a date for them to receive an email containing the key for the encryption at a later date with a tool like http://www.lettermelater.com/
What happens if the service goes offline?
How about this:
Make a split key (2 of 3 to send) with a tool such as bitaddress.org and give the person one of the keys, then keep the other yourself and give one to a trusted relative or your attorney with instructions to give it to the person at the future date. This way you could also make exceptions for medical emergencies or other dire situations.
Send the bitcoins to an address, then let in escrow the private key of that address?
There is a mechanism in the protocol that blocks a transaction until a certain time or block.
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
That has the problem that I can revoke the transaction when I want, by broadcasting a different transaction that has not the lock.
What I want is for the money to be not spendable until the time has come...
like I transfer the amount to a public key (the transaction gets into the block) whose script does not allow to spend the amount until a certain date has come.
Best regards,
ilpirata79
Interesting idea.
How about opening an email account and setting it to send the details at a certain date, then disposing of the email password.
Of course you do have to rely on the service to still be running x years down the line and that your friend still has the same email address.
How about opening an email account and setting it to send the details at a certain date, then disposing of the email password.
Of course you do have to rely on the service to still be running x years down the line and that your friend still has the same email address.
not possible, it takes 2 private keys to decode
ok i just noticed its an offline generator, that does not grab the users public key for you to abuse later. if you highlight at the top of your page that its a browser based generator that can be used offline, your service could have more advantage. i will edit my last post to emphasise it.
What would the purpose of this type of time delay be?
A will? An inheritance? These are the only that come to mind at the moment.
It does seem like it would be better to handle the delivery of the funds yourself. Rather than keeping the funds locked up, they are in your possession until they need to be sent. If some unforeseen event happens, the funds can be accessed.
A will? An inheritance? These are the only that come to mind at the moment.
It does seem like it would be better to handle the delivery of the funds yourself. Rather than keeping the funds locked up, they are in your possession until they need to be sent. If some unforeseen event happens, the funds can be accessed.
I helped create LBAAT along with nelisky.
One use I envisioned was similar to captcha. You provably send bitcoins to YOURSELF as a way to prevent spamming a site. The site can verify that you sent $5 worth of bitcoins to an address that can not be redeemed for X days. Once the private key was released, you sweep the coins back into your wallet.
lbaat.net releases a private key every hour, called a "timepoint secret". The timepoint secret keys are connected - the hash of next hour's private key is this hour's private key. By requesting a public key in the future, you can combine it with your own private key to create an address with no known private key. When lbaat releases the timepoint, it can be combined with your personal private key to release the coins.
lbaat has no way of stealing the coins.
...and its my site
lbaat has no way of stealing the coins.
...and its my site
This sounds like a clever idea, still I don't see the need for it.
Rather OP should invest some money in self-control classes :p
What about giving them the private key of the address but encrypted? You can set a date for them to receive an email containing the key for the encryption at a later date with a tool like http://www.lettermelater.com/
You could do something like this with multisig I would think. It wouldn't be an automatic thing unless you wrote a script to do it after x amount of time, but yeah.
There is a mechanism in the protocol that blocks a transaction until a certain time or block.
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
Please read these:
https://en.bitcoin.it/wiki/Protocol_specification#tx
https://bitcointalksearch.org/topic/delayed-transactions-using-ntimelock-131443
What would the purpose of this type of time delay be?
A will? An inheritance? These are the only that come to mind at the moment.
It does seem like it would be better to handle the delivery of the funds yourself. Rather than keeping the funds locked up, they are in your possession until they need to be sent. If some unforeseen event happens, the funds can be accessed.
A will? An inheritance? These are the only that come to mind at the moment.
It does seem like it would be better to handle the delivery of the funds yourself. Rather than keeping the funds locked up, they are in your possession until they need to be sent. If some unforeseen event happens, the funds can be accessed.
I think this is interesting. Being able to set aside transactions to be scheduled into the future is kind of like scheduling to pay a bill through a credit card company. They make you click on a real date and input the amount. Once you do that the funds are "withdrawn" from your account and put into a "holding section" until said time has arrived then those funds are applied. You should also be able to cancel any funds that are in the "holding section" just like you would be able to with a bank/credit card payment online. This already exists in banking, no reason why it couldn't be incorporated into a program for btc.
lbaat.net releases a private key every hour, called a "timepoint secret". The timepoint secret keys are connected - the hash of next hour's private key is this hour's private key. By requesting a public key in the future, you can combine it with your own private key to create an address with no known private key. When lbaat releases the timepoint, it can be combined with your personal private key to release the coins.
lbaat has no way of stealing the coins.
...and its my site
lbaat has no way of stealing the coins.
...and its my site
How can you know the public key associated with a private key that is unknown until a certain time in the future?
Best regards,
ilpirata79
lbaat will give the public key upon request. You combine this with your private key to get a 3rd public key (private key is unknown).
lbaat.net releases a private key every hour, called a "timepoint secret". The timepoint secret keys are connected - the hash of next hour's private key is this hour's private key. By requesting a public key in the future, you can combine it with your own private key to create an address with no known private key. When lbaat releases the timepoint, it can be combined with your personal private key to release the coins.
lbaat has no way of stealing the coins.
...and its my site
lbaat has no way of stealing the coins.
...and its my site
ha ha ha, yea we know the USER wont have the private key until X date, but your code knows the seed that creates these hourly keys meaning you can sweep the addresses as you like when you like even years before you say it meant to be active..
OP do not trust third party services with 'dad man switches' as they prey on people to not check it regular...... and then its too late
not possible, it takes 2 private keys to decode
lbaat.net releases a private key every hour, called a "timepoint secret". The timepoint secret keys are connected - the hash of next hour's private key is this hour's private key. By requesting a public key in the future, you can combine it with your own private key to create an address with no known private key. When lbaat releases the timepoint, it can be combined with your personal private key to release the coins.
lbaat has no way of stealing the coins.
...and its my site
lbaat has no way of stealing the coins.
...and its my site
How can you know the public key associated with a private key that is unknown until a certain time in the future?
Best regards,
ilpirata79
Jump to: