Use of Hashes in BlogNomic

Essay by Kevan

BlogNomic dynasties sometimes use hashes to store information. Here's a simplified, game-specific overview of what hashes are and what you need to know about them.

How hashes work

A hashing process takes a piece of text and converts it into a short, garbled string of letters and numbers. That output string is known as a hash. You can try this out for yourself at https://www.md5hashgenerator.com

For example, the input string The Ruleset and Gamestate can only be altered in manners specified by the Ruleset. produces the hash 8d788fec20e1c0815096ecbf6fb6d84a

Hashing is a one-way process: it's not possible to reverse the hash to get the original string back. All input strings always reduce to a 32 character hash, so a single hash will theoretically correspond to multiple potential input strings. And if you hashed the full text of a novel down to 32 characters, it would obviously be impossible to reverse that to get the entire novel back: no compression method could be that good.

All you can do is repeat the original string to confirm that it matches the hash.

Why this is useful for BlogNomic

Hashes allow players to publicly commit to a decision without revealing the details of that decision, in a way that they can confirm later on. It also doesn't require a third party to keep track of that data: although it works to have the Emperor receive and then publish such secret decisions, hashes don't require players to wait for the Emperor, and will survive the rare (but not unknown) situation where the Emperor disappears from the game mid-dynasty taking secret information with them.

An example game rule might be that players use hashes to announce their moves, and when everyone has announced, players reveal the actual moves, which get processed simultaneously:

Player 1, 9:30am: My moves are 3a20a09c9c8ecb4d1935f180a39c4f0b

Player 2, 9:45am: And mine are 2df028843fbc3b43957c626bbb111f9f

[other players pass]

Player 2, 2pm: Okay, my moves were I walk north, lock the front door, then move east to the drawing room.

Player 1, 2:10pm: Oh no! Mine were I search the garden twice, then move in through the front door. I'm locked out!

Having revealed their original inputs, each player is now able to confirm that when their opponent posted a hash earlier in the day, that hash corresponded to the input. A player can't change their mind and try to claim a different move instead, as that wouldn't match the earlier hash.

Remember your original strings!

The most important thing when using hashes in BlogNomic is to keep an accurate copy of the original strings. If you can't reproduce your original input exactly, you won't be able to prove that your hash is valid.

In the earlier example, if Player 1 could remember that 2df028843fbc3b43957c626bbb111f9f was the hash for locking the front door and moving to the drawing room, that in itself is not enough to confirm their move. They need to be able to quote the original string exactly to confirm to other players that this was their actual order.

Dynastic rules will usually be written in such a way that a player who forgets a string is no different from a player who failed to submit one at all: that their secret orders or information will be considered blank.

It's worth keeping a notes document, draft email or similar record for the duration of the dynasty, where you can store copies of the strings that you're hashing.

Implementation

Using salts

If the original string is very short or commonplace, such as a single dictionary word, the internet might already know about it. For example, the hash of the single word tangelo comes out as e1723c6ace5b7108c93c49d4dcda9ea5, and if you search online for that output hash, the internet will indeed tell you that this is the hash of "tangelo".

If the original string follows a predictable format, players might be able to guess each other's strings, and confirm their suspicions straight away. For example, if all orders in a game were being written in the form of I move my army from [place] to [place]. and one player suspects that another might be moving from Rome to Venice this turn, they could check the shared hash to see if it matched that, before submitting their own orders. With a little more effort, a player might write a script to generate hashes for all possible sentences in that format, allowing them to read everyone's orders just from the hashes.

The way to get around both of these issues is to add a salt to the input string: a handful of unpredictable extra words or characters, added by the writer. These can just be stuck on the end of the input (I move my army from Rome to Venice. paradiddle hypoxia terrarium magnetite), or players can be encouraged to write their orders in any language they wish so long as the core instruction is unambiguous (Leaving our garrison at Rome, my general leads his troops on the long march north to Venice). Both of these would be realistically unguessable.

Cases to handle

When writing a rule using hashes, it shouldn't take for granted that a player will always be able and willing to confirm a hash after the event. They may forget the original string or note it down incorrectly, making it impossible to prove their hash; they may also tactically decline to reveal the input string if they realise that doing so would harm their position. Hash rules are generally written as a player optionally proving a hash if they wish perform some game action, where if they fail or decline to do so, it's the same as if they'd never posted a hash in the first place.

Any hash rule should consider whether players duplicating each other's hashes is an exploit. If it's a dynasty where players are playing rock-paper-scissors using salted hashes, a player would be able respond to an opponent's move by just repeating that opponent's hash verbatim to force a tie, without having to know the input string.

Hash rules should also consider the fact that players can privately prove hashes to one another. In regular Werewolf-type games, you generally aren't allowed to just show your card to someone to 100% confirm your identity; and in a Werewolf-type BlogNomic dynasty run by an Emperor, you can't informally prove your identity to someone because the Emperor is tracking it. With hashes, though, a player has the option to share the input string of their public hash with another player, or even the whole group, if challenged.

Examples of usage

• The Tenth Dynasty of Josh used hashes in its Denizens rule: anonymous GNDT Hacker accounts could post a hash of "a grammatical English sentence of no more than 20 words which includes the Hacker’s own Corp Name and no other Corp Names" to record who controlled them, which the controlling player would have to confirm at a later date if they wanted to claim credit for the Hacker's actions.
• The Sixteenth Dynasty of Kevan used hashes in its Confessions rule, for resolving Prisoners' Dilemmas. Two players would post comments as hashes, and then reveal the strings. The rule simply required strings to contain the word "defect" to be a defection, with all other outcomes (including the player failing to prove their hash) being taken as cooperation. Example post: The Vienna Opera Heist
• The Twenty-Third Dynasty of Kevan used hashes in its Loyalty and Reports rules. In the first, each player's first action had to be joining a secret faction by publicly posting a hash of such a statement; this could then be confirmed at the end of the game, for scoring. In the second, any player could submit a prediction by posting the hash of it; at the end of the game those predictions would be revealed and scored.
• The Fourteenth Dynasty of Josh used hashes in the Ethics of the Nobility, allowing the Emperor to note the true identity of an anonymous message sender in a way that could only be verified at the end of the game.
• The First Dynasty of Habanero used hashes in its Secrets and Tells rule: when players found items in a search, they could privately decide what those items were, locking it in by posting a hash to their gamestate. If they wanted to reveal and use the item, they had to prove that their hash matched it.

Further reading

• Cryptographic hash function, at Wikipedia