proposal: points promises

[jeffkaufman]

Being able to credibly promise points would make the game more interesting. Here's a sketch of how we could do this:

• All files below have contents -1 and so (a) don't affect how many points you have since #33 gives you a point for having PRs merged, and (b) don't need review.

• I check in a PR that creates a file players/jeffkaufman/bonuses/points_promise_3_795902ce393e. This represents a promise to transfer 3 points to anyone who can figure out what string 795902ce393e is the first 12 hex digits truncated sha256 hash (hash) of.

• Somehow, someone figures out what this hash represents, and wants to redeem the points.

• They create a PR that creates players/example/bonuses/points_redemption_795902ce393e_39dad4ebe765 where 795902ce393e is the initial promise hash and 39dad4ebe765 is the hash of the concatenation of the target string plus a salt they've chosen.

• They create a third PR that creates players/example/bonuses/points_reveal_39dad4ebe765_<salt> where <salt> is the short string they chose above.

Once the third PR is in, it can be verified that the player really did identify the original string, get_user_points counts example at +10 and jeffkaufman at -10.

Now imagine another player tries to snipe the redemption. If we simply allowed this and figured it would be rare and difficult we could do away with the points reveal PR and the salt and just have the points redemption PR check in the secret directly. (And maybe that's ok?) But if we want to be robust to this we can say that if there are multiple valid claims on the same points promise then the points go to the person whose points redemption PR was merged first. So as long as you don't create the reveal PR until the redemption PR has been merged then you're safe from sniping (or, if you are sniped, you can take the points back right away as soon as your reveal PR goes in).

[jeffkaufman]

The actual code for this would be:

• Documentation on how to hash things. Something like:

    echo text | shasum -a 256 | sed 's/\(^.............\).*/\1/'
  

• Code that get_user_points calls that looks for and processes points promise / redemption / reveal files.

[jeffkaufman]

@csvoss @pavellishin @tnelling looking for design review

[jeffkaufman]

This design is wrong: the points reveal PR isn't enough to assign points from. It also needs to include the secret plaintext.

I'm thinking now that the complicated workaround to avoid sniping isn't worth it. While it's neat, sniping is very hard to do in practice. So I think we could just have the first PR merged that reveals the secret get the points.

[tnelling]

Isn't a PR a credible promise of points (provided it contains the right files)? Is the goal here to be able to make the promise to an unspecified other party in exchange for something? I'm not sure I understand the use case for that exactly.

[jeffkaufman]

The idea is, you're promising points to the first person to claim them, by identifying their key.

If you just make a PR then nothing keeps the recipient from approving it and taking the points even if they don't know the key.

[tnelling]

I don't think that answers my question. What is the use case for promising points using this method? Presumably you're going to send someone the key, but in exchange for what?

[jeffkaufman]

@tnelling I'm not sure what this would be useful for yet. Maybe some sort of game? Being able to transfer points with a key instead of a PR just sounds like it would be a useful building block.

[pavellishin]

This feels like a lot of moving parts. I'm intrigued by the idea of secret points, but I have some questions, and also the concern that nobody's going to bother doing a two-PR dance for anything but a substantial number of points.

Questions:

• why are we reading the point amount out of the filename?
• what happens if I don't have enough points at time of redemption?

Also, maybe we can reduce the number of PRs required by redeeming point promises via issues. To redeem a point, you open an issue, labeled with (e.g.) #pointredemption. Travis would check the issues to redeem points, similarly to the PR-point calculation, before running all the points-related checks (e.g., the random-winner check.)

If we query by date, we can solve the problem of sniping - the earliest issue opened "wins". I don't

There are two problems with my approach:

1. This would increase the number of requests required, buuut if we can query by label, and the response includes the issue title, it would likely only add the overhead of one request per Travis run until a lot of redemptions have taken place. (We can also clean up old redemptions when we restart the game.

2. Malicious players can't delete issues, but they can remove labels; once enough points to win have been redeemed by some number of players, a malicious player could mass-remove their labels, open their own tickets with the answers, label them all, and re-trigger the master job (potentially by having an innocuous and ready-to-merge PR all ready to go at 4am.)

[pavellishin]

also i swear to god, if we end up re-inventing bitcoin, I'm going to find a way to burn this game to the ground.