Staking Claims with Scheduled Tweets | Hacker News Reader

Staking Claims with Scheduled Tweets

shkspr.mobi

36 pointsedent30 comments

An old trick to make predictions without influencing the outcome:

E.g. https://twitter.com/gwern/status/1017575588641505280?s=20

https://en.wikipedia.org/wiki/Anagram#Establishment_of_prior...

Very cool old-school way. I also like the attempts at reverse engineering that led to the wrong interpretations but which were true results!

Why do you need the date in the reply tweet?

As I understand it, the premise of the method is that, at day D, you already have written the contents of tweet Tr (to be posted as a reply to T) and so you can already compute its hash and tweet the hash as part of T on day D. Then on day D+N, you tweet Tr, which hashes correctly to what you said it would, and thus is extremely unlikely to have been tampered with.

Where does the date string contained in Tr come into play?

Human readability. You are correct that the existence of the hash shows when the original message was written. But for human readability and understanding, I thought it was useful to have.

Niantic (The Company behind Pokemon Go and Ingress) would do something similar for events in Ingress: They had a "measurement window", in which they would look at the state of the gameboard in a certain city and count stats (details irrelevant for the story here). The measurement window was 10 minutes long, but they would look randomly at one specific second and count the state at that second. Before each measurement window they would post a SHA hash on their twitter account, and release the string that lead to it afterwards (which was a bunch of garbage and a time like this: "52o5dfeis(})5eidfjsdkdbn 10:03:20 huner54652&e") Worked great for that proof :)

This sounds very interesting but I'm a little confused by the problem they were trying to solve -- what were they trying to prove knowledge of?

patio11 wrote about “dropping hashes” here: https://www.kalzumeus.com/essays/dropping-hashes/

>Modern hashes like SHA256 are probably resistant to collisions in Twitter’s limited message space.

Actually, no. 140 characters alphanumeric translates to 833 bits of entropy. This is significantly more than the 256 bits in SHA256, and due to the pigeonhole principle, collisions are guaranteed. That said, it's still nontrivial to bruteforce the hash, because searching thorough 256 bits is hard, but that's unrelated to the "limited message space".

Collisions are guaranteed, yes, but, you also have to keep in mind that the only collisions that matter are the interesting ones. That is, collisions between two different messages written in different languages, and where both messages make some sort of sense. Although I don't have a mathematical proof of it, I'd have to wager that those types of collisions are exceedingly rare.

Edit: At least "exceedingly rare within the space of plain-text messages smaller than N characters," for some reasonable value of N.

Yeah the key point is:

‘ And, of course, a person can post two hashes – for contradictory messages – and only publish replies one of them. ‘

Perhaps also state when the reply is coming in the initial tweet so if you don't meet your deadline, people can assume you decided to hide it.

Someone can also decide to simply delete their tweet. Unless you were closely monitoring the account, you wouldn't know.

I made something that does this some time back: https://tweetencryptor.netlify.app/

Smart,

what about using words (like a password phrase) instead of a hash? You can schedule title of the upcoming tweet, so people can like it and "subscribe" to notifications

I'm not sure of any hashing algorithms which use words as their output. Or have I misunderstood your comment?

It's just a byte string converted to a hex string commonly. Chunk it into quads of hex and you can index into a 65k dictionary (the OED has more than twice that).

even better than a dictionary: use dicewords, which have already mapped numbers to a canonical list of words.

My critique of this blogpost will have the sha-256 hash:2738490299aeefee10202fa46283bc856

I’ll post in 25 years in the future once I brute force this hash.

There's actually an unlimited number of messages that will result in that hash. For all we know, that sha will also result from the hashing of "I'm a giant idiot" repeated an enormous number of times. I'd hazard a guess that there is probability 1 that this is the case.

Unless it is super long, I guess chance of not getting the original message by brute force is super super low

Not even in 1000 years, it is 33 digits :)

A company which specializes on message integrity... surety.com

Why would you use twitter for something like this when you could simply create a blockchain DAPP that runs on Ethereum? All you'd need to do is learn the Solidity language, compile it with Mist and purchase some initial startup gas to pay for the executions. Then, the integrity of your predictions would be guaranteed by a globally distributed network of several mining organizations, rather than dependent on one politically-suspect US tech company.

This seems like an ideal use-case for verifiable blockchain-backed applications.

> Why would you use twitter for something like this when you could simply

Ok, go on

> create a blockchain DAPP that runs on Ethereum? All you'd need to do is learn the Solidity language, compile it with Mist and purchase some initial startup gas to pay for the executions.

So much simpler than tweeting!

> globally distributed network of several mining organizations, rather than dependent on one politically-suspect US tech company.

Yup, those reliable and impartial miners that noone really knows who they are, but we’re 200% sure they’re not mostly in China and could absolutely never be influenced by Chinese authorities?

I'm pretty sure the parent poster's tongue was cutting a hole through their cheek when writing the post.

you laugh but I have periodically thought about making a prediction service and considered that blockchain of course would be a good verification - however after playing with it in my head I can never figure out a way to monetize it adequately to pay back the effort required, as the only people I can think would actually want to use the service are paranoid know-it-all jerks like me who want to show everyone how right they are - and I know for a fact I'm too cheap to pay for that service.

I‘m working for a blockchain-backed secure timestamping service

https://documents.originstamp.com/

Also wrote a CLI:

https://github.com/dennis-tra/originstamp-cli

Reply on news.ycombinator.com