Bitcoin Forum

Introducing a way to send bitcoins to yourself or someone else in the future. LBAAT.net (http://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 (http://bitaddress.org). All calculations are done on the client side, no information is sent. Armory (bitcoinarmory.com (http://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

https://dl.dropbox.com/u/12679676/Explained.png

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

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

This sounds really cool. :)

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

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".

Also:


Can be done using?

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.


nice catch. Fixing..

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

Watching.

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

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.


https://dl.dropbox.com/u/12679676/pichost/agfyJJG3118.jpg

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

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 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...

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

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

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?

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

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.

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?

It would work assuming other time keeping services existed, sure. Assuming the encryption step itself was done offline to keep things safe, that  would be a good solution although there's an extra step that happens behind the scenes at lbaat, and that is timestamping and checksumming (sort of) the plain message before encrypting, to prevent attacks where someone provides garbled text stating it is an lbaat encrypted message, or simply provide the wrong timestamp for decryption. With your multiple services approach that part is lost, though it might not be important for whatever use case you are considering, of course.

There is a bot grabbing secrets every hour, on the hour. We feel proud someone took the time to actually do it :)

Now, just a small detail about how the timepoints are created; the hour part needs to have 2 digits, so have a 0 (zero) prepended if < 10. Meaning '20121206:9' needs to become '20121206:09'. Added some text to "how to use" to make it clear.

td;du

(too dumb; didnt understand)

Which means the message is not of importance to you :) But in case you are planning on making use of the JSON API all I meant was someone has a script that grabs secrets as they become available, using a call like https://lbaat.net/getSecret.json?timepoint=20121206:9 and if you try that you'll see the response does not have any real data. To get the data from that timepoint you need to prepend a zero to the hour part (digits after colon) to make it 2 digit long, so https://lbaat.net/getSecret.json?timepoint=20121206:09 will work as expected.

I still don't understand this gmae...  but how long will TAABL be down? I seriously miss it - any eta? Wish I knew how to place tehe bitcoin future game..

you might want to parse that a little more robustly.

I can, and I would but this is always a question of code complexity vs security&performance. It is much easier to introduce an exploitable bug when we start catering for special cases in public APIs, but you know that for sure.

Of course this is a simple example, but I try to keep that as a rule of thumb for all machine interfaces. Humans tend to guess and be inventive, machines just do what they're told to do.

This (LBAAT) is not a game, rather a service. As for TAABL (and DiceOnCrack, and LBAAT) being down, I woke to find it not running due to improper startup after the server got rebooted. I'm finding out why the server got rebooted and also why the services didn't all come up correctly after the system was back up, but for now all is running again!

Just for your reference, TAABL.net does not and has not worked since I posted my last post in this thread. Even now.

What are you getting? It was down before, but it has been working fine for me since I started things properly, and it is most certainly working for me now.

lbaat.net works for me

Wouldn't work for about 6 hours solid past when I posted that from any computer here, but works now. Apologies, still don't know the "why" of it.


How is Bitcoin in to the future a service?

If it happens again, feel free to PM me which will send an email.

As for LBAAT, it is not a game as I stated although TTBit did advertise a game using the service.

What you can do with it is create a bitcoin address that you'll only be able to get coins from in the future. Say you want to send coins to your brother for his next anniversary, and lets pretend that's next November. You can send the coins to him right now by using a private/public key pair that you know and a timepoint in November.

- Using the timepoint and the public key you create a bitcoin address on lbaat.net, and fund that address with as many coins as you wish to give you brother.
- You give the address, the timepoint and your private key to your brother. He can see the address but can't yet get to the coins.
- Come November your brother uses the private key and the timepoint secret (which is only disclosed after timepoint is reached) to calculate the address private key and get the coins.

The game TTBit created here (https://bitcointalk.org/index.php?topic=128608.msg1370628#msg1370628) lets you have the private key and timepoint for a bunch of future addresses, first one to get the timepoint secret and calculate the private key can redeem the coins.

Can anyone think of a process in nature that is regular with time but somehow predictable to achieve something like this?

So... n-lock is no good for this, but couldn't a script be set up that requires part of the hash of a valid future block to redeem an input? I mean theoretically, that sort of non-standard ability is off for virtually all miners right no I'm pretty sure.

edit: I'm not actually very familiar with this, can you reference data from a (future in particular) block in a script?

Astronomic phenomena mostly. Star and satellite rises and sets, eclipses, stuff like that.

This is such an awesome idea!! Seriously it is really, really, really cool very nice work and much respect ;D

I want to turn all my money into bitcoins and send them to my future self. While I'm broke, I'll take comfort in the fact that I won't be in the future!

Feature request: Could you please implement sending Euros into the past?

Oops, off by one (<9 instead of <=9 to append the 0).  If anyone is interested here is the code, it just grabs the latest secret as needed and calculates others.

Thanks for posting!

bitaddress.org now offers EC Multiplication so it can be used with LBAAT to create and redeem future addresses. It is found on the vanity tab, and you have to select "Multiply". Thank you pointbiz.

Note that while you're suggesting interesting EC math to make new addresses, you can also use these secrets in multi-signature transactions. For example, you can do automated escrow similar to the old ClearCoin service, where a Buyer pays money in escrow to the Seller, and then either Buyer and Seller agree on who gets the funds or the Buyer can take them back after a year. The Buyer makes 2 keys, and the Seller 1, they tell the public keys to each other, and then they make a requires-3-signatures-of-4 escrow address with the 2 Buyer public keys, the 1 Seller public key, and the LBAAT timepoint public key a year out. The Buyer sends the funds to that escrow address, and then either the Buyer and Seller together can sign a transaction to send the escrowed funds to the party they agree on, or after a year the Buyer can take the funds back all by himself using his two keys and the released LBAAT private key.

Using multisig in Bitcoin-QT requires using the command line or debug console and knowing a lot of technical details, but the functionality is all there if somebody wanted to make a nice GUI for it. I don't know if some of the other clients do a better job presenting how to make this work.

This service is awesome, I was dreaming of something like this!

There's one thing in the FAQ I need to better understand...
- If the site ever disappears, what happens?

- If the site disappears AND for some reason you can't publish the secrets, does everyone lose their coins?

Thank you for the review and input. We have always had a design from the start to address this, but it wasn't implemented because it was a lot of work and the site may not be used. We are currently working on it, but it has been slow. With your post we may kick it up a notch.

A cynical person would worry we could hold coins hostage. This would be especially easy if you let LBAAT discover the address for a given public key, rather than the other way around. We would never do that of course, but it is something for users to keep in mind for our service or a competing service.

Hello Ttbit. Hope the years have been kind to you! Since lbaat.net site has been down I saw in one of your older post you would release the seeding hash if that happens. Could you provide me with that information or anything related to it. Loooong shot I know.

Thank you! Peace and love