31–40 of 62 posts
Earlier quoted context omitted.
A proof that the pok and its hash hasn't been altered since its creation.
You can accomplish this with plain old cryptography. No blockchain needed. There are lots of ways to do it. One of them would be for Fuuture to publish the hash to literally anywhere. Public + cryptographically verifiable + distributed + append-only still does not equal blockchain, as long as we're defining blockchain as something that was not invented before 2009.
Earlier quoted context omitted.
Like when Patrick McKenzie (@patio11) posted a hash about some Covid nonsense he wanted to be right about?
If it’s about releasing information on schedule that’s verifiably created with a datetime stamp and maybe also by user, then it’s not really about predictions, it’s more than that. It could be used for any info, and then verification is available for the who and when. The thing though that would make this worthwhile would be if it were decentralized, because you want universal verification and independence of some th…
Earlier quoted context omitted.
A proof that the pok and its hash hasn't been altered since its creation.
You can accomplish this with plain old cryptography. No blockchain needed. There are lots of ways to do it. One of them would be for Fuuture to publish the hash to literally anywhere. Public + cryptographically verifiable + distributed + append-only still does not equal blockchain, as long as we're defining blockchain as something that was not invented before 2009.
I wonder whether predictions (aka "poks") are stored in encrypted form in their database? Knowing what people think will happen in the future is obviously rather useful information.
So something like, I encrypt message with a certain public key. The private key is guaranteed to only become available on 1st of January 2030.
Blockchain is overhypered nonsense 99.9999% of the time. But seriously this is the one in a billion projects where you should use the Bitcoin blockchain as much as I hate to say it
It wasn't based on a public, distributed block chain, but it was a kind of a block chain (without PoW, PoS etc. - which you don't need if it's run by a single actor). The way they built trust was that they did publish their hash (tip of the block chain) I think in the (printed) Financial Times periodically. That made it impossible even for them to forge the chain.
Earlier quoted context omitted.
True, it's not the same as hashing a password and comparing hashes - you need to decrypt your data. Encryption adds one layer of obfuscation for a bad actor that might steal the database but does not get their hands on the key. Plus access to the key can be managed differently than access to the database. Either way, it comes down to sensitivity of the predictions made and how users would react should they be exposed…
But there are other crypto mechanism for that purpose... see - Verifiable Delay Functions https://eprint.iacr.org/2018/601.pdf
Earlier quoted context omitted.
If it’s about releasing information on schedule that’s verifiably created with a datetime stamp and maybe also by user, then it’s not really about predictions, it’s more than that. It could be used for any info, and then verification is available for the who and when. The thing though that would make this worthwhile would be if it were decentralized, because you want universal verification and independence of some th…
Honestly (and I hate saying this) but you could stick the hashes in a public blockchain and get clients to verify. But of course this would cost money and any Merkle tree would do, but I can’t believe I just non-ironically suggested a blockchain for something.
Though that domain name still has some interesting potential!