Send bitcoins into the future! (LBAAT.net) - page 2.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: nelisky on December 06, 2012, 05:02:22 AM

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.

you might want to parse that a little more robustly.

BitCoiner2012

sr. member

Activity: 364

Merit: 250

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

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: 2weiX on December 06, 2012, 05:23:26 AM

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.

2weiX

legendary

Activity: 2058

Merit: 1005

this space intentionally left blank

td;du

(too dumb; didnt understand)

nelisky

legendary

Activity: 1540

Merit: 1002

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.

nelisky

legendary

Activity: 1540

Merit: 1002

Quote from: molecular on December 04, 2012, 02:29:36 AM

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.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: nelisky on December 03, 2012, 05:35:42 PM

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?

nelisky

legendary

Activity: 1540

Merit: 1002

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.

johnyj

legendary

Activity: 1988

Merit: 1012

Beyond Imagination

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

molecular

donator

Activity: 2772

Merit: 1019

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?

dooglus

legendary

Activity: 2940

Merit: 1333

Quote from: TTBit on December 03, 2012, 04:32:05 PM

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

molecular

donator

Activity: 2772

Merit: 1019

Quote from: TTBit on December 03, 2012, 04:32:05 PM

Quote from: molecular on December 03, 2012, 04:14:08 PM

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

TTBit

legendary

Activity: 1136

Merit: 1001

Quote from: molecular on December 03, 2012, 04:14:08 PM

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.

BitCoiner2012

sr. member

Activity: 364

Merit: 250

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

molecular

donator

Activity: 2772

Merit: 1019

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?

molecular

donator

Activity: 2772

Merit: 1019

Quote from: TTBit on December 01, 2012, 11:09:34 AM

Quote from: dooglus on November 30, 2012, 11:27:50 PM

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

TTBit

legendary

Activity: 1136

Merit: 1001

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.

Jessica

full member

Activity: 174

Merit: 100

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

beckspace

hero member

Activity: 931

Merit: 500

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

Watching.

TTBit

legendary

Activity: 1136

Merit: 1001

Quote from: dooglus on November 30, 2012, 11:27:50 PM

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.

Quote from: dooglus on November 30, 2012, 11:33:09 PM

Also:

Quote

All requests can be done use GET or POST methods

Can be done using?

nice catch. Fixing..

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