First, thank you to the poster for posting this - I haven't laughed this hard in a while.
Second - thank you to the person who actually made this. This is incredibly hilarious (just based on the project I'm gonna go ahead an assume they have an account here :) )
Lastly - I know that this is a joke project, but one thing I'm not understanding: how does the system read the current state of the chess board? The, er, Bluetooth/WiFi 'output' of the system is clear enough, but I'm not clear on how the current chess board is input into the system so that Stockfish can actually compute the next move.
(This is a semi-serious question - if you know I'd be curious to find out, but I'm not gonna lose sleep over this and I don't expect anyone else to waste time on it either :) )
> Second - thank you to the person who actually made this. This is incredibly hilarious
Hey there, thank you, I'm the creator of this.
> I'm gonna go ahead an assume they have an account here
I have an account here, but I don't use ycombinator this much. Just got notified by someone that a thread about my project is getting some attention here
> Lastly - I know that this is a joke project, but one thing I'm not understanding: how does the system read the current state of the chess board?
It gets the state of the board though a manually inputted FEN code. Unless the user of this would hook it up with a camera and scan the board in real time, it's assumed that whoever is using this has someone helping them. So the helper would operate the backend, input the board, and send it to the end-user
The actual implementation just takes them from the console.
If you were actually going to use this to cheat in professional tournaments, I imagine you'd just use the API of a chess website that is broadcasting the game live. Lichess has a free, documented, API for instance.
15 minute delay doesn’t seem sufficient in a classical game. Spending 15 minutes on one crucial move is common and wouldn’t raise suspicion.
Give a little squeeze at the start of your turn, to indicate that you wish to request the next engine move, then sit there for 15 minutes appearing deep in thought until the answer is beamed to your behind.
Alternatively the device could stream all the moves with the move number encoded, so it could be entirely unidirectional and you wouldn’t need an input method. Just wait 15 minutes for the next move.
There are many legal reasons that they could not perform a body search for anal cheating devices, butt more importantly: human perseverance has shown that some communication devices will always be able to stay hidden...no matter how invasive the search.
It would complicate the buttocol a bit but one could imagine having the engine predict the opponent next moves and propose different responses to them: if e5f4, then e3f4 – if c7c5 then ...
Or like with thumpers used in practice - you'd have an accomplice in the audience handling any required interaction. This is often used for "blind" magic tricks with audience.
In the proposed cheating scheme, you have an accomplice who reads the moves of the game as they're broadcast over the internet and then transmits the next move to you.
Maybe if there's a model with sensor data, they can implement two way communication through clenches? Just need to make sure to avoid having gassy food for lunch or else you might end up miscommunicating a bit.
Morse code for the classical chess notation is actually pretty inefficient (12ish bits of data). Often times the actual viable moves are vastly reduced. With your own custom entropy code and custom symbol table, you could massively reduce the transmission time.
E.g.
- 1-4 bits for the piece class to move.
- 3 bits for the column of the destination
- 1-3 bits left over for disambiguation. E.g. Column
That's perhaps a bit too much optimization for a troll project. But fun nonetheless.
Possibly! For instance, when I built the twitterdildonics project back in 2007 (changed tweet character values to vibration speeds, using an extremely early precursor to buttplug.io), a lot of people were saying I should transmit using morse code, but instead I took UTF-8 and poorly translated it back to 0-255 range, which accidentally ended up with super interesting results:
Though, perhaps improving the encoding density might improve the experience during transmission. As will all things UX, you won't likely get the real answer without usability testing.
> That's perhaps a bit too much optimization for a troll project. But fun nonetheless.
I've used Morse code because the original theories of how this was done was that Hans used Morse, so I used it as well. - to stay as close as possible to the actual leading theory and not invent my own method.
I considered abstracting the decoder, so it's not a hard-coded `MorseEncoder()` but just an IMoveEncoder interface where you can inject any encoder that takes a move as input and returns a pattern output
I also thought - Morse is a "common standard" - it would possibly be easier to learn and remember than a custom made encoding scheme
The interesting thing I learned about this is that the big names in chess all agree that they don't need to be told what move to make. In a recent interview Magnus Carlsen said:
> The people who get caught are those who cheat in a really obvious and stupid manner. The problem was that he [i.e., a player caught in 2016] was not good enough to see what would’ve made sense.
> Had I started cheating in a clever manner, I am convinced no one would notice. I would’ve just needed to cheat one or two times during the match, and I would not even need to be given moves, just the answer on which move was way better. Or, here there is a possibility of winning, and here you need to be more careful. That is all I would need in order to be almost invincible, which does frighten me.
So all you need is a buzz or maybe two - "caution" and "opportunity," "defense" and "offense" or whatever.
The difficult part is getting the game state to the device. In streamed games this can be done with a medium amount of trouble but in non-streamed OTB games you'd need the player or a confederate to be silently inputting moves for the engine to respond to. Not impossible but... difficult. Nevertheless, when the prizes are in the hundreds of thousands, people may try to find a way.
The Fritz chess engine program has a feature where when playing against the engine, and there’s a winning move in the position, an indicator light will come on.
These hints are helpful at all levels, because if you’re playing fritz and a move says there’s a strongly winning move, you’re going to look more at bold moves that involve things like sacrifices that lead to a scary attack, any move that takes a piece, any move that gives a check, and less at passive moves like moving your king around. You can ignore variations that obviously lead to no change in the status quo. Often it will be the case that only one move COULD be the winning move because only one move causes any meaningful effect on the position so the fact the tactics light is flashing means you can just play it without further calculation. Computer hints allow the human brain to basically filter for better candidate moves far more efficiently.
What if moving your king is the winning move. Plus, what’s stopping a good “AI” from incorporating this meta game into it’s calculations for showing the indicator?
Hikaru analyzed some of Niemann’s games and at certain points he was very surprised by the move, but said that if he was told that there was a strong winning move in that position he would have found the move easily.
Kind of similar to what Magnus said that he wouldn’t even need the move, just a hint like “strong winning move on the board” would be enough for him to find the winning line because he wouldn’t have to look at defensive or passive moves.
A king move can be the one strong move in a position, but let me be more clear. Early into the game your king is usually pretty far away from the action, so even if it is the best move, moving it usually doesn't affect things in a direct enough way so as to have a massively positive effect on the position. It's possible, it's just not very likely. It's only in positions where the king is really getting into fights with the other pieces where it becomes likely a king move is the one strong move.
These kinds of heuristics doesn't need to be perfect to give you an edge.
> I would not even need to be given moves, just the answer on which move was way better
I feel like people keep looking past this line, and suggesting that the device transmit things like "caution" or whatever. In another thread, someone suggested it could warn you if the most tempting line was a bad one.
These all rely on the idea that Stockfish can think like a human and say "Carlsen will be thinking of X, I'll warn him that's a bad idea."
I've never seen any indication that Stockfish can know what a human is thinking, novice or grandmaster.
Instead Carlsen suggested something else: he asks about two moves, and Stockfish tells him which is rated higher.
That's totally doable by stockfish, but means all these suggestions require an input, such as a butt-squeeze detector.
Stockfish rates moves by chasing them down a game tree and evaluating positions. I can imagine several heuristics for a "non-obvious move here" buzzer based on that architecture:
- Hidden gem: The best move has similar value to others if exploring a few moves, but becomes clearly better at depth [n].
- Trap: There is a move that has similar value to others on shallow exploration, but offers opponent a checkmate at depth [n]
- Material exchange: The best move involves a major material loss in the first few moves.
I would love to see these tested in practice, but it seems very plausible to me that some combination of them could make a very useful one-bit (erm, one-butt?) signal.
> I've never seen any indication that Stockfish can know what a human is thinking, novice or grandmaster.
But it's incredibly easy to train ML models to predict what a human thinks is a good move. Then you just send a signal when "most probable move" is different than "chess engine strongest move".
I have worked on this problem. I would not say incredibly easy. Maia chess (linked in other reply) is pretty good but only has an accuracy of around 55% iirc, and that’s with enough data to train on. Grandmaster level games are rarer and have less data.
Most popular chess tournaments have a live audience. So that would be another vector.
Any delay would have to be significant like 30min to avoid players just waiting for the broadcast to match the board state during a critical move where they wanted to cheat.
And then if you see the players exit the playing hall while the board is 30min behind, do you just fast forward broadcast the remaining moves? That kind of takes the drama out of the most interesting part of the game. Or do you just keep the feed on delay and ask the players not to indicate if they won/lost yet? I’m sure their body language would be obvious.
For any tournament where it matters, they're being paid as a form of entertainer/athlete. It's not ideal, but it's also not unreasonable to put restrictions like that on them. It's already reasonably common to have things like interviews afterwards.
> It seems not too crazy to have a morse code format to input moves too, right?
At 3 minutes per move for the standard format, it's totally reasonable. It might be a bit less feasible during speed chess (which is used as a tie breaker).
Overtime you can learn to isolate pelvic floor muscles and anal sphincter, so a cockring and buttplug, or vag-toy and buttplug, could enable rapid input, and greater bandwidth using cords.
Yes. But you need to tell the AI the current board state anyway (ie via transmitting what moves have been made). So adding some more input is not necessarily that much harder.
The benefit of getting the AI pick a move from the top two you are considering is that play looks more convincingly human.
Exactly this. Many top games have one or two critical moments where a player makes a blunder or even just a small mistake. Often this is not picked up on, but if a top player is made aware this has happened, they can quickly find it and punish it.
To complete the memetic conjunction, HN will surely be abuzz at the fact that the underlying buttplug library is, in fact, written in Rust. For when memory safety really matters: https://github.com/buttplugio/buttplug
The underlying library being written in Rust is something of a relief (if you'll pardon the expression) as I am nervous about anything to do with my butt being written in something called C Sharp.
I get the joke but it's worth pointing out C# is actually memory safe and more flexible than Rust in that regard (with the downside of less control on GC).
A question about delivery channel;I don't like receiving chess moves in my butt. If I wanted to get my chess moves in my penis would buttplug's device support include a viable alternative?
Also, I might be interested in parallel chess cheating. If DP is on the table would multi-match support be viable through the API?! I might have to break my no-pegging rule.. But in the name of increased chess move bandwidth it might be on the table.
Yup! The library is named Buttplug just because I like making large media publications say "Buttplug". I even made a whole video about it: https://www.youtube.com/watch?v=c6bghuCy6d8
Buttplug.io actually works with 100s of different toys. There's a full list at iostindex:
In terms of multi-match API support, we're... getting there. One of the dreams after the next big feature (MOBILE APPS! Thank god for flutter and flutter-rust-bridge) is getting WebRTC connections going, which should make situations like this easier to support.
You could probably enhance it for 2 way communication if you had something that could sense anal sphincter pressure. Then you could encode your opponent’s move via contractions, and then have it transmit the best move to you.
You would basically have a chess computer that you communicated with entirely through your butt.
This would work, even if you played in a Faraday cage since the communication and computation is all internal.
Ok, so, sort of NSFW links ahead, but there's actually an open source project that does this.
The Nogasm is a pleasure denial project that uses pelvic floor contraction frequency, as sensed by pressure output in an air filled cavity, to prolong play.
Output from either of these devices could be used for that, though discerning between voluntary versus involuntary muscle contraction would be challenging.
Seems like it would be pretty easy. Send a "dot" for three contractions each one second apart. Send a "dash" for three contractions each three seconds apart. It would be pretty slow, but it doesn't need to be fast.
It can't be too slow, if it takes too long to input moves, you can't input in realtime, or you have to slow down your play and that can look suspicious.
I was going to comment that this is only 1 way, whereas the sockfish project was 2 way, if I remember correctly. This would only work if the accomplice has a visual of the game.
Your solution would probably work, I guess. I sadly don't know anything about measuring sphincter pressure.
You could also have a pressure sensor in a shoe or something that interfaces with the buttplug via bluetooth, or even a small wire. Though, I could imagine competition security looking at feet but drawing the line before checking butts. So, the chances of getting caught could be higher with my approach.
If the player was male, could the prostate gland be leveraged somehow? Personally, I think it'd be easier to make one's prostate twitch or "pulse" than to consciously control the pressure of their anal sphincter in a high-stress situation.
So buttplug.io as a library is made for supporting communication with toys from a host, but itself is not made to be a peripheral protocol. It's verbose af because of some of the early decisions I made that we are now very very stuck with.
That said, on the firmware side, I'm pushing for tcode, which is a sort of gcode variant for sex toy firmware. There's documentation for it in STPIHKAL (sex toy protocols i have known and loved), our protocol aggregation repo:
A couple years ago, a discussion over the cyberdeck trend and how people intentionally make them anti-ergonomic, led me to I run 'sed s/deck/plug/g' on the text of the Sprawl Trilogy as a joke.
You might be on to something. Detectors would probably be more efficient although telling everyone to leave their cellphones outside is usually not kosher.
I bet if you wear this overnight while you sleep, and setup stockfish to play itself, you will subconsciously learn a muscle memory of the AI strategy.
We actually just got sensor support in the latest major version of Buttplug, so reading input from pressure sensors, kegelcizers, etc is now a possibility!
I want to build an automated cat feeder. Personally speaking, in terms of systems design where a bug could result in an extreme breakdown of diplomatic relations, it is of equivalent gravitas to building a reliable nuke silo.
Is this the project where I finally pick up Rust, or should I continue with the usual Python mitigations (reach-this-target-state instead of do-this-thing, tiny stable wrapper around heavy Python logic, no fonts.com online dependency, restart foodd every minute, etc.)
Reminds me of this other "covert information receiving technique for individuals being closely watched", but in this case used for cheating on a proctored exam: https://news.ycombinator.com/item?id=30675666
In the hands (ass?) of a top chess player presumably one could just send a binary signal as to whether a chess engine thinks there is a big move available ahead (i.e. take risks now).
I don't think this needs to be a programming problem. If you have a team of coconspirators watching the game live from another location you can manually turn the vibrator on and off remotely. It's not like Sockfish where the player had to relay game state before getting the next move. You don't even need to use Stockfish, you could use any game engine.
I do love how chess continues to make Mornington Crescent less satirical. And why all of it sounds like a jazz band has already composed the soundtrack.
You’re playing with the ButtFish? I see you and raise the bongcloud. The double bongcloud? Aw man, I told the Manchurian candidate I’d need a favour but not for this.
I really love this, only missing a few style points because you were honest that it didn't get a full-fledged test. I'm sure someone is in-progress right now though.
Can't wait for Tour De France competitors to put lithium batteries and hydraulic agregates in their bodies to drive the pedals along with their muscles.
Second - thank you to the person who actually made this. This is incredibly hilarious (just based on the project I'm gonna go ahead an assume they have an account here :) )
Lastly - I know that this is a joke project, but one thing I'm not understanding: how does the system read the current state of the chess board? The, er, Bluetooth/WiFi 'output' of the system is clear enough, but I'm not clear on how the current chess board is input into the system so that Stockfish can actually compute the next move.
(This is a semi-serious question - if you know I'd be curious to find out, but I'm not gonna lose sleep over this and I don't expect anyone else to waste time on it either :) )