Pages:
Author

Topic: Send bitcoins into the future! (LBAAT.net) - page 2. (Read 9167 times)

donator
Activity: 2772
Merit: 1019
December 07, 2012, 02:32:21 AM
#26
There is a bot grabbing secrets every hour, on the hour. We feel proud someone took the time to actually do it Smiley

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.

you might want to parse that a little more robustly.
sr. member
Activity: 364
Merit: 250
December 07, 2012, 02:04:32 AM
#25
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..
legendary
Activity: 1540
Merit: 1002
December 06, 2012, 05:30:03 AM
#24
td;du

(too dumb; didnt understand)


Which means the message is not of importance to you Smiley 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.
legendary
Activity: 2072
Merit: 1006
this space intentionally left blank
December 06, 2012, 05:23:26 AM
#23
td;du

(too dumb; didnt understand)
legendary
Activity: 1540
Merit: 1002
December 06, 2012, 05:02:22 AM
#22
There is a bot grabbing secrets every hour, on the hour. We feel proud someone took the time to actually do it Smiley

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.
legendary
Activity: 1540
Merit: 1002
December 04, 2012, 04:21:19 AM
#21
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.
donator
Activity: 2772
Merit: 1019
December 04, 2012, 02:29:36 AM
#20
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?
legendary
Activity: 1540
Merit: 1002
December 03, 2012, 05:35:42 PM
#19
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.
legendary
Activity: 1988
Merit: 1012
Beyond Imagination
December 03, 2012, 05:20:21 PM
#18
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
donator
Activity: 2772
Merit: 1019
December 03, 2012, 04:50:10 PM
#17
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?
legendary
Activity: 2940
Merit: 1333
December 03, 2012, 04:43:10 PM
#16
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://bitcointalksearch.org/topic/explain-lock-time-replacing-transactions-23501
donator
Activity: 2772
Merit: 1019
December 03, 2012, 04:40:51 PM
#15
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
legendary
Activity: 1137
Merit: 1001
December 03, 2012, 04:32:05 PM
#14
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.
sr. member
Activity: 364
Merit: 250
December 03, 2012, 04:14:42 PM
#13
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...
donator
Activity: 2772
Merit: 1019
December 03, 2012, 04:14:08 PM
#12
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?
donator
Activity: 2772
Merit: 1019
December 03, 2012, 04:08:21 PM
#11
Quote
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"?
legendary
Activity: 1137
Merit: 1001
December 03, 2012, 02:59:27 PM
#10
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.





full member
Activity: 174
Merit: 100
December 02, 2012, 10:54:49 PM
#9
Looks like a brilliant idea.
You will be very successful with this novelty business.
hero member
Activity: 931
Merit: 500
December 02, 2012, 10:47:24 PM
#8
I need time (no pun intended) to digest this.

Watching.
legendary
Activity: 1137
Merit: 1001
December 01, 2012, 11:09:34 AM
#7
Quote
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:

Quote
All requests can be done use GET or POST methods

Can be done using?

nice catch. Fixing..
Pages:
Jump to: