[HN Gopher] Show HN: Futuure - hash-certified public prediction ...
___________________________________________________________________
Show HN: Futuure - hash-certified public prediction store
Author : ssimono
Score : 85 points
Date : 2021-03-12 08:59 UTC (14 hours ago)
(HTM) web link (futuu.re)
(TXT) w3m dump (futuu.re)
| harveytoro wrote:
| Nice. I did something similar a couple of months ago that posts
| to Twitter: https://predictionelect.com
| DJBunnies wrote:
| It seems like a centralized approach for this topic is not a good
| one.
| dedoussis wrote:
| Great idea! Just submitted my first pok.
|
| Feature request: User groups and pok access levels. Restrict pok
| access down to a given set of users. I imagine that a large share
| of the pok volume does not (and should not) concern the wider
| public. For example, I could have a group with my buddies, and
| register a pok wrt my best friend breaking up with their partner.
|
| This group concept could be exploited in the form of a plugin
| that can be hooked on Slack rooms or WhatsApp groups. Every time
| a pok is unsealed the Futuure bot could notify the room, letting
| others congratulate you upon a successful prediction (or the
| inverse).
| ssimono wrote:
| Very good point! We thought about it and should implement it
| rather soon
| neolog wrote:
| Why allow hiding predictions? That means I can make a bunch of
| predictions and only reveal the ones that were right.
| zitterbewegung wrote:
| Also why not use Twitter and or Pastebin?
| iNic wrote:
| They would need to implement a feature where others can see
| that someone has made a prediction, and a maximum time for how
| long the prediction can stay hidden.
|
| EDIT: That is exactly how it works. They write " There is no
| way to edit or delete a pok after you save it".
| cmeacham98 wrote:
| As far as I can tell the website provides no way to revoke or
| otherwise hide a prediction once you make it - it will always
| be revealed at the specified date.
|
| Additionally, the creation screen proclaims:
|
| > There is no way to edit or delete a pok after you save it
| elevaet wrote:
| Could hack this system by holding two accounts, each one
| making predictions in opposite directions, then burn the one
| that was wrong. This would work for the first prediction, but
| becomes geometrically more difficult to manage fabricating a
| history of correct predictions.
| chalcolithic wrote:
| Congrats on releasing it! The same idea was on my todo list for
| almost a decade:)
|
| Have you figured out how to promote it (that's what stopped me
| from implementing the thing)?
| alentodorov wrote:
| If you're excited about something there's a good chance other
| fellow HNers will find it interesting. Just pot it here for
| starters.
| ssimono wrote:
| Thanks. Some people sometimes post hash of a prediction on
| Twitter https://twitter.com/patio11/status/1241551327743770624.
| If some "influencers" can start using Futuure that can be a
| good driver
| renewiltord wrote:
| Cool stuff. Automates the process we do on Twitter where we post
| the hash and then a scheduled tweet revealing.
|
| Sadly, a list of hashes isn't that interesting. So it's not that
| interesting to read current list.
| ErikBjare wrote:
| Might be more interesting to read once some predictions get
| unsealed.
| jpdaigle wrote:
| The one time I've tried doing this sort of "publish hash first,
| plaintext later" scheme, verification was hard because the
| hashing is vulnerable to whether or not the reader adds a
| newline after the text, a CR vs a CRLF, etc.
| renewiltord wrote:
| I think the best way is to post the command. So what I do is
| post printf "Hello World" | sha256sum
| ketamine__ wrote:
| Like when Patrick McKenzie (@patio11) posted a hash about some
| Covid nonsense he wanted to be right about?
| klingon78 wrote:
| 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 third-party breaking if
| its like a contract. While they could act as a law office or
| official records office that keeps the contract, deed, or
| certificate on-file, I'd not keep the only copy of something
| important with a startup that could go out of business and
| has no requirement to keep my data or secure its future, so
| I'd hope there's something for that.
| Moodles wrote:
| 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.
| monkeydust wrote:
| Ha, I was literally thinking the same thing. This
| bizarrely might be something suitable for a public
| blockchain and its not using it.
| Moodles wrote:
| Keybase does something similar by sticking the Merkle
| tree root of hashes of signatures in the bitcoin
| blockchain: https://book.keybase.io/docs/crypto
| jimmySixDOF wrote:
| Not sure if anyone is doing that as a service now but the
| old methods like post it to yourself in a sealed envelope
| or email are just as legally binding (ie not binding at all
| in any way) as the most sophisticated hashed blockchain you
| can throw at the problem today. There's a reason lawyers
| use signatures on paper over registered mail. We are
| talking about a part of the law where the last technical
| advance was to accept Fax Machines.
| fluxinflex wrote:
| 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.
| ssimono wrote:
| Hey, I am the main dev behind this. The poks are currently not
| encrypted because there is no way to fundamentally allow a
| decryption later without someone having the key the whole time,
| which defeats the purpose. But we're looking into potential
| with applications stored in Ethereum or something! In the
| meantime we are committed to not use, and not even look at the
| content before their release
| fluxinflex wrote:
| 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 before
| their due dates.
| jojo_was_a_man wrote:
| But there are other crypto mechanism for that purpose...
| see - Verifiable Delay Functions
|
| https://eprint.iacr.org/2018/601.pdf
| fogof wrote:
| VDFs are designed to take a long time to compute. To use
| them here, it would require someone to be computing the
| solution continuously between the time the prediction is
| made and the time it is revealed - that's too inefficient
| for this purpose.
| jpalomaki wrote:
| It would be cool if there was a relatively reliable way of
| creating cryptographic "time capsules" that can be only opened
| at certain date in future.
|
| 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.
| Moodles wrote:
| There's this
| http://people.csail.mit.edu/rivest/RivestShamirWagner-
| timelo... which uses repeated squaring as a kind of
| unparallelizable searching function to force a set period of
| time until a solution is found.
|
| I wonder if you could perhaps do a kind of Shamir secret
| sharing scheme where as long as most of the participants are
| honest, they all agree to piece together their shares of the
| secret at the specified time.
| smilliken wrote:
| Maybe someone else can find it, but scottaaronson.com has an
| article that describes a scheme where there's a cheap
| computation that has to be done serially, so anyone can open
| if it they crunch cheap hashes for the requisit amount of
| time. The cleverness in the construction is that the creator
| gets to skip this work.
| space_rock wrote:
| 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
| pablovidal85 wrote:
| It could commit the hashes via https://opentimestamps.org/ to
| the bitcoin blockchain for example.
| space_rock wrote:
| Yes. Nice link. This is the project that I had in mind
| OJFord wrote:
| There is (was?) a relatively popular Ethereum one isn't
| (wasn't) there?
|
| Adding in the 'contracts' nature of it to commit to a wager on
| the prediction.
| atleta wrote:
| Indeed, there was a service I used back in around 2008 that did
| just this. It wasn't about predictions per se, but timestamping
| content. They were called GuardTime. The company still exists,
| but the service does not seem to, anymore.
|
| 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.
| viraptor wrote:
| What feature would a blockchain give them that they can't have
| now in a simpler way?
| space_rock wrote:
| It's a tamper-proof prediction to the world that cannot be
| altered by any party
| kngl wrote:
| A proof that the pok and its hash hasn't been altered since
| its creation.
| smt88 wrote:
| 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.
| space_rock wrote:
| So these hashes are distributed. How do we know they
| haven't been altered since future reveal? How does one
| find the "true" dataset? Trust random people on the
| internet?
| dnautics wrote:
| no, since it's public, if you care so much about it, you
| keep a periodic snapshot of the hashes. So you're
| trusting _yourself_ (and math). What 's missing to be a
| "blockchain" in (what should be) the generally accepted
| definition is byzantine fault tolerance.
| [deleted]
| ginger_beer_m wrote:
| Once you're done building a working system to do the
| above, you'd have basically built a blockchain.
| smt88 wrote:
| Using a very loose definition of blockchain, sure. For
| anything post-Satoshi, no.
|
| The extra governance layer that makes it a blockchain is
| also not trivial.
| bsenftner wrote:
| Okay, I'll bite. What's the point? My thinking here is "....and?
| that's it? why bother?"
| smt88 wrote:
| Trustworthy digital bookie, I guess?
| SamBam wrote:
| But why not make the prediction public? That' the part I
| don't understand. (I came to ask the same question as GP.)
|
| It seems that it's used on Twitter to prove that you were
| right about something, and so people should trust your
| foresight ability. E.g., this tweet here: [1]
|
| How does keeping it secret change things? If it's about
| something that _is_ secret that you know about, well then
| having foreknowledge is not that surprising. Is it so other
| people can 't steal your prediction and also be right, so
| you're not as special?
|
| Indeed, as far as I can tell, that tweet was a prediction
| about global consequences of the Coronavirus. How does
| keeping that secret help anyone at all, besides saying "ha
| ha, I was secretly right all along!"
|
| I guess I can also think of some very specialized cases, like
| getting a hash of a patent you're submitting to prove
| invention date. But I think I'm being dumb not coming up with
| more obvious reasons that must make this desirable to lots of
| people..
|
| 1. https://twitter.com/patio11/status/1241551327743770624
| scubbo wrote:
| Because making a prediction publically can affect the event
| itself. Either in a positive feedback loop (Elon Musk
| tweets "Gamestonk" => Gamestop stock goes up) or negatively
| (in any hypothetical situation where an adversary wants to
| frustrate you, allowing them to know your prediction also
| allows them to work against you).
| jmcqk6 wrote:
| Having secret predictions are also problematic.
|
| Imma going to go and make a whole bunch of predictions,
| wait a year, and then only reveal the ones that actually
| came true.
|
| Now I'm a genius, right?
|
| This is basically similar to an old common scam, where
| you would mail 100 people, and 50 would say 'buy this
| stock it's awesome', and another 50 would say 'sell this
| stock, it stinks', and to 50 of those people, you're
| going to look like a genius, and to the others, you're
| just another scrub.
|
| Now I could go and make several predictions for the top
| 100 stocks, planning for every possible move, and then as
| they come true, start to reveal those predictions and
| BAM, I'm a fucking genius, give me all your money, and
| I'll invest it for you.
| SamBam wrote:
| I think these always depend on generating the hash and
| publicizing it ahead of time. Otherwise yes, it's
| worthless. But I think most people realize that.
| orblivion wrote:
| I see that futuure is a tag. What I would do is predict that
| futuure will still be around in 5 years, and seal it for that
| long. I might look really smart with no potential downside!
| Diederich wrote:
| Ah cool, back in 2012 I was going to build something like this
| and registered hashservice.com...but I never got around to it.
|
| Though that domain name still has some interesting potential!
| [deleted]
| se4u wrote:
| One alternative implementation of this which is very simple is as
| follows.
|
| 1. User makes a public declaration to always make a prediction
| using some platform. Like they release a tweet saying all future
| predictions will happen on futuu.re (or on a Blockchain)
|
| 2. They only release the sha hashes of their prediction to
| futuu.re, along with a date for that prediction, and users keep
| the true prediction with themselves. At any time before deadline
| they must reveal the content to the world and tell futuu.re about
| it. Futuu.re verifies that the sha matches the prediction and
| keeps an easy record. All predictions must start with a preamble.
|
| 3. futuu.re maintains three counters for a use, one showing the
| number of predictions made till that time, second showing
| predictions that should be revealed till that time, third showing
| the number of predictions that have been revealed . This
| establishes the long time accuracy of the user.
|
| This way when someone reveals their pok then the public will know
| whether they tried to fool people because the users trust ratio
| will go down if they make a lot of predictions without revealing
| them. This is also more secure since the actual content is never
| stored on the server.
|
| The only thing that needs to be done is to use a content
| formatter/validator at the time of hash creation for stylstic
| reasons and to make it convenient for public to verify the
| accuracy of the user.
| rkangel wrote:
| You would need some concept of published identity, otherwise
| they could just create their predictions against multiple
| different identities each with e.g. 10 predictions.
| se4u wrote:
| So actually this wont be a problem. Basically if they do this
| then each account that they create will only have very few
| published predictions. So it will be like a coin which comes
| up head twice after two tosses. The public will not trust
| such accounts with low number of correct predictions.
|
| To build trust you'd need to have a high count of revealed
| predictions in any given account.
|
| That said people can try to game the system by uploading a
| very large number of predictions programmatically, so I think
| a rate throttling will have to be enforced. Any account can't
| make more than one prediction a day or something like that.
|
| Also note that the issue you raised will also affect OP's
| implementation.
| Wronnay wrote:
| I don't wanna be a "Korinthenkacker", but "Build in Berlin" means
| to me the builder has to obey the Law and add an Imprint and
| Privacy Policy to his site...
| Cu3PO42 wrote:
| Privacy policy is definitely required. You could maybe get past
| the requirement of an imprint by arguing this isn't
| "geschaftsmassig" (lacks a proper translation; superset of
| commercial), but I think that would be a hard sell.
___________________________________________________________________
(page generated 2021-03-12 23:02 UTC)