Send bitcoins into the future! (LBAAT.net)

[TTBit]

Introducing a way to send bitcoins to yourself or someone else in the future. LBAAT.net (short for "little bit at a time") has developed the tools necessary to create a future bitcoin address with no known private key. This address can be funded immediately. However, coins can not be redeemed until the selected time, and only by the intended recipient. It is 100% secure in that at no point in time does LBAAT have the ability to create the private key.

Why would you wish to send coins into the future?
* Forced savings. You suspect bitcoins may go to $1000 each, but don't want to find yourself 2 years from now having sold them all at $12.
* Monthly/weekly payments. You send coins to addresses that can not be redeemed by your service provider until the payment is due.
* Leave coins to your children and grandchildren for after your death.
* Give the gift of delayed bitcoins. A 1 BTC gift that can not be redeemed until next Christmas / Birthday.
* Authentication. Force users to send coins to themselves in the future in order to use your web services. For example, force a user to send 1 BTC to themselves tomorrow in order to sign your guest book.

Delayed Messages
Using AES encryption, LBAAT.net makes it possible to post messages that can only be revealed at a specifc time in the future.
* Increased auction formats. Have everyone display their bids which can only be revealed at a certain time. Now host a blind auction, vickrey auction, and all-pay auction on the forums.
* Prove you know something now, but don't want to reveal until later. All messages are timestamped.

To redeem future bitcoins, you will need the aid of an EC calculator. LBAAT has javascript calculator that does the necessary calculations for you. This page was on the wonderful work of bitaddress.org. The EC calculator in Armory works great as well.

How does it work?
Delayed, connected secrets make it possible to send bitcoins securely into the future. LBAAT.net releases a 32 byte secret every hour on the hour. We call these "timepoint secrets." All timepoint secrets are connected - the current 32 byte timepoint secret is the hash of the unknown timepoint secret one hour from now. If you have the current timepoint secret, all prior timepoint secrets can be generated, but not the next one.

What if the system is compromised?
Because all timepoint secrets are connected, a compromised future secret will compromise all further secrets from that point. This is an incentive for LBAAT to secure its data. It will be easy to tell if the site has been compromised, as future addresses will be redeemed early. Even though a compromised future secret would lead to early redemption of coins, note that LBAAT never has access to any balance.

Generating a future address:
By submitting a bitcoin public key, LBAAT.net will multiply that public key by the timepoint secret using EC math, which will result in another public key, and a bitcoin address is obtained. If you own the private key it is possible to verify the address by requesting the public part to the timepoint secret, and multiply this by your own private key using an EC calculator, as found in Armory.

Revealing the private key:
When the timepoint secret has been revealed, multiply this secret by your private key to reveal the private key to the bitcoin address in question. LBAAT has created an on off-line javascript calculator created with the code from bitaddress.org. All calculations are done on the client side, no information is sent. Armory (bitcoinarmory.com) is also capable of performing the calculatioins off-line.

What happens if you disappear?
If the site is closed, we are prepared to provide the seed hash. With this seed, all secrets can be obtained. We also have prepared a 6 of 10 shared secret of this seed. 10 trusted members of the bitcoin community will have a code. If we disappear, the community can still revive the seed hash (details to follow).

I sent coins to a future address that I want now. Can I have the secret?
No. Once a future secret is revealed, the system is compromised.

Do you have an API?
Yes. Check out the How to Use page for documentation

[TTBit]

As an example, here are bitcoins sent into the future. I have sent 0.20 bitcoins into the future address: 1NQwkuQZQ1EEb52hECUeCLH4WueKRZg3zC

These can not be redeemed until November 30 2012 at 23:00 UTC.

I selected 2012 11 30 and 23:00, and input my public key of an address I created at bitaddress.org
The public key I used was:
04657418339EFBEDB43BF546E44D891814BD7D921159FC49A0328947652AF0BB0
D459AA2A1170B6F5F2F6E42E5D4E895EA128DCF272F860963477594DAF55A89CB


In order to redeem (pretend only you know this information)
The private key to this public key:
WIF: 5JgQuqD9z3XV14kXQK4nrnA8mNQXAuoiSLFcNDV1Un9xNKatbhy
RAW: 71D16DF050DB60E2AEAC376A625D6244D41857BBDDA60FA3722751D9F3B97E55

Despite the timestamp of this post and when the coins were deposited, no one will be able to redeem these until 23:00 UTC

[TTBit]

Coins were redeemed at 23:16. Congrats to whoever got them

[elux]

This sounds really cool.

(Assuming it works as stated, haven't tried it.)

[dooglus]

a compromised future secret will compromise all further secrets from that point.

That's confusing to me.  It only makes sense if going back in time is going further.  I think it would be clearer if you said "all previous secrets from that point" or, better, "all secrets before that point".

[dooglus]

Also:

All requests can be done use GET or POST methods

Can be done using?

[TTBit]

a compromised future secret will compromise all further secrets from that point.

That's confusing to me.  It only makes sense if going back in time is going further.  I think it would be clearer if you said "all previous secrets from that point" or, better, "all secrets before that point".

Will edit, thank you. Hard to get the tense correct when describing a past point in the future that is still a future point from now.

Also:

All requests can be done use GET or POST methods

Can be done using?

nice catch. Fixing..

[beckspace]

I need time (no pun intended) to digest this.

Watching.

[Jessica]

Looks like a brilliant idea.
You will be very successful with this novelty business.

[TTBit]

Thanks for the kind words!

Here is what the nieces and nephews are getting for Christmas 2012: Bitcoins for 2013

The private key needed to combine with the timepoint is under the scratch off. The public key:

041C7196A7374892E239F58972EB821847058AD653CF1E5AD67092A73DC601866
4920E69322CAB67F5B87DC04FBAE5801B14BAF09AF3F827429FF31A9D2B90D746

Instructions on how to redeem are on the reverse. Blank cards were printed up at kinkos on cardstock. Later filled in at home with QR code and private key.

[molecular]

a compromised future secret will compromise all further secrets from that point.

That's confusing to me.  It only makes sense if going back in time is going further.  I think it would be clearer if you said "all previous secrets from that point" or, better, "all secrets before that point".

Will edit, thank you. Hard to get the tense correct when describing a past point in the future that is still a future point from now.

how about "all earlier secrets" or "all younger secrets"?

[molecular]

This is really cool. I've thought about the need for such and/or similar service but couldn't come up with that secret(t) = sha256(secret(t+1)) idea. Pretty awesome!

First I thought "sending coins to the future" could be accomplished using a tx with "lock time". However reading how that works revealed that such a transaction could be replaced, so the recipient of the gift can't be certain to be able to access the money at time x, because the sender could've replace the transaction. Correct?

One question: what's the time of the first (or should I say: last) secret?

[BitCoiner2012]

I really want to try this because I love all your games at TAABL.net, but the first postI didn't really understand, these new updated information should help a lot. Going to review this and try to play...

[TTBit]

This is really cool. I've thought about the need for such and/or similar service but couldn't come up with that secret(t) = sha256(secret(t+1)) idea. Pretty awesome!

First I thought "sending coins to the future" could be accomplished using a tx with "lock time". However reading how that works revealed that such a transaction could be replaced, so the recipient of the gift can't be certain to be able to access the money at time x, because the sender could've replace the transaction. Correct?

One question: what's the time of the first (or should I say: last) secret?

I am not familiar with "lock time". Hope we didn't re-invent the wheel. I want to look into that.

The secrets go for a bit more than 200 years.

[molecular]

This is really cool. I've thought about the need for such and/or similar service but couldn't come up with that secret(t) = sha256(secret(t+1)) idea. Pretty awesome!

First I thought "sending coins to the future" could be accomplished using a tx with "lock time". However reading how that works revealed that such a transaction could be replaced, so the recipient of the gift can't be certain to be able to access the money at time x, because the sender could've replace the transaction. Correct?

One question: what's the time of the first (or should I say: last) secret?

I am not familiar with "lock time". Hope we didn't re-invent the wheel. I want to look into that.

The secrets go for a bit more than 200 years.

found some info about "lock time" here: https://en.bitcoin.it/wiki/Contracts

[dooglus]

I am not familiar with "lock time". Hope we didn't re-invent the wheel. I want to look into that.

See discussion here: https://bitcointalk.org/index.php?topic=23501.0

[molecular]

Been thinking: Something a little different would be to send a public message to the future, not coins. Is that possible? Of course noone should be able to read it before the time has come.

Of course the main problem is that LBAAT.net could easily read the message because it knows the future secret.

The only solution I can think of would be to use multiple "time secret services" and combine their secrets (for the same future timepoint) to encrypt the message. They would have to collaborate in order to read my message before the given time.

Ideas?

[johnyj]

An interesting idea, but I think it is still not feel like real future since the future secret is already known. It will feel more like a magic that the key is available through a future event which is no way to produce today

Like a safe with a built in time lock which only opens the safe when a certain time reached, the timer itself should be locked in the safe

[nelisky]

It is quite different for private keys and for messages. The former is just a contract in the form of lbaat holding a secret (that it knows ahead of time) but not disclosing it before the agreed time. Knowing the secret gives no advantage to lbaat, and the only "attack" possible would be not disclosing the secret at all, making the address unusable and any coins sent there lost. This particular issue will be addressed shortly.

The latter usage with the messages is trickier, because the message is disclosed plainly to lbaat at encryption time. One option would be to provide the user with tools to do asymmetric encryption with a public key, the result of which would then be encrypted by lbaat. Once decrypted when the secret is revealed the user would then use his private key to retrieve the plain message, but this presents a usability challenge; making this easy to do for unskilled users is a problem, and making sure said users keep the private key safe is another.

Maybe the ability to use some password to encrypt the text prior to sending it to lbaat? It could be a simple, not all that safe password, but it would add a layer that would make it harder for lbaat to misbehave and read the secret messages.

[molecular]

The latter usage with the messages is trickier, because the message is disclosed plainly to lbaat at encryption time. One option would be to provide the user with tools to do asymmetric encryption with a public key, the result of which would then be encrypted by lbaat. Once decrypted when the secret is revealed the user would then use his private key to retrieve the plain message, but this presents a usability challenge; making this easy to do for unskilled users is a problem, and making sure said users keep the private key safe is another.

This wont work, because I want the message to be made public even without the user having to be able to produce the key (assume he has died, for example).

Would my above-proposed method of using multiple LBAAT-like services work (encrypt the message using the "product" (?) of n public keys from n independant services and then everyone would be able to decrypt it once the n secret keys are revealed) or am I misunderstanding something?