Yeah, it is like hashing a phone number to protect its owner's identity. With a small domain known by the attacker hashing isn't really one-directional.
There's nothing wrong with only wanting to reveal a crush if it's somewhat returned. If it isn't, you're just putting them in an uncomfortable position for no good reason.
Tinder goes in two directions. This would go in 4 directions. Swipe up to send them to your friends, down to your enemies, left to the void, right to you.
You start with 2048 single people, and have to act as matchmaker to pair them off into married couples who each produce at least one child. A generation later, you take the 1024 first-borns of each couple and have to pair them off too, into 512 new pairings.
Repeat that long process until there is just one couple left, whose first-born you then propose to. Having lived long and healthily enough to complete this game, you must have some very desirable genes and/or wealth, and you'll be good friends with basically all this person's ancestors, so there's a strong chance they'll say yes, despite the age difference.
You'd want to use asymmetric public key cryptography so that Bob could hash his message with Alice's public key, and it could only be decrypted with Alice's private key.
Yup, everyone publishes their public keys. No one’s private keys gets published (fake crush created).
I’m not sure if zero-knowledge proofs exist for love outside of action - repeated acts of commitment over time (to reduces the confidence that someone doesn’t love you).
Seems to me such a system must make it expensive to claim to have a crush on someone. Otherwise Bob can just claim to have a crush on everyone and will find out who crushes on him.
That lets Bob confess semi-deniably to Alice (if Alice is willing to share her private key, she can still show Bob's confession to Carroll and prove that it's authentic). But it still doesn't do any matching; Alice will know about Bob's feelings whether she returns then or not.
> Those games only make at least a bit of sense when everybody enters their crush and only when matching both get notified.
Even then, among heterosexuals they will suffer from the same problem as basically every software platform for romance among straight people: the massive asymmetry in interest between men and women. Men would copy and paste virtually every woman they know into the system as a "crush," so they can find which if any of their female acquaintances might be interested, and then they would decide who to pursue.
> Men would copy and paste virtually every woman they know into the system as a "crush," so they can find which if any of their female acquaintances might be interested, and then they would decide who to pursue.
Smart men would, who know their place in the world. Any of them are good enough for you, really. Take the one that you like the most out of the ones who like you. Is this a problem? If it weren't asymmetric, it would be hopeless. Instead, most men get the choice between one or more interested women, and most women get a response from one or more of the men they were interested in.
It's better if one side isn't as picky as the other. The other options are that only a couple of people match up at all, or everyone getting a response from everyone i.e. no signal at all.
I don't follow this, either logically or in practice.
Granted I've never dated as a gay man or as a lesbian, but from what I've observed it seems to me a much smoother and more mutual process than straight dating. I've even heard from bi men about how much easier and less stressful it is to date men than women. AFAICT when both parties are on a level playing field, and there's not a massive asymmetry in power, interest, and investment, there's a lot less grief overall.
> edit: I mean, isn't that Bumble?
Bumble is a valiant attempt to fix this issue but it seems to mostly be a failure. An average man may occasionally get a message (which will usually just say "hi"), but the asymmetry in interest is still there, and it's still mostly men's responsibility to do the real initiating.
And when everyone is an actual adult, not a manchild or other people without a fully formed prefrontal cortex and thus prone to making ugly, life-changing decisions - for themselves and others - on a dime.
That's most of the demographic for this product. The number of over-25 people, not in a committed relationship, who still haven't figured out how to ask people out, is pretty small.
I dunno. I'm reasonably well adjusted and apparently even decently attractive, and I still have a super hard time with the whole asking people out thing. I've been lucky enough to have people ask me out but otherwise I'm not sure I'd have had much luck dating at all.
This tool doesn't do what I'd want, but a tool that did would be kinda neat :)
that's because it's not zero knowledge, it's password hashing.
a zero knowledge proof would do something like prove a valid attestation of love, but reveal nothing about who (other than maybe membership in some large enough set).
Yeah zero-knowledge is supposed to give you no usable information, but brute-forcing aside, the fact anyone can learn they are not the target is knowledge, right?
I believe "zero knowledge" refers to the third party here. That is, you give it A => B, and it tells you if B => A was given previously, without it knowing the actual values of A or B. While you might be able to brute force the system by trying every name you know, the third party can't unless you give the third party a registry of names to try.
Related is the humorous paper "Solving the Dating Problem with the SENPAI Protocol" [1], though the solution in that paper does not rely on a third party.
Quite simple: you don't deal at all. That's zero assumptions about the name. Let them eat cake and enter whatever they want. The user should know their sweetie well enough to guess what they will enter as own name. This is an assumption about their level of mutual knowledge, true, but not one about the naming scheme.
This is a design decision that will very likely lead to missed matches, bold of you to assume it's desirable but even that doesn't answer the entire ordeal. How are they going to enter the name, have you read 11?
On the contrary, there is a very strong and completely invalid assumption: that Alice will type her name in exactly the way Bob typed her name, and vice versa, that neither will misspell it, that either both will use the official name or both will use the same nickname.
> 12. People’s names are case sensitive. 13. People’s names are case insensitive.
You can store this as an attribute
> 14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those.
This can be other fields if you're trying to structure the data, or you can simply store the entire name as a contiguous field.
> 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
Don't string compare names as a test for equality.
The obvious response to this is: that's too hard (/impossible to do). But that's just the reality of the situation. These issues are not necessarily possible to solve. #21 in particular makes this application very broken even with very plain vanilla western names.
I mean, you would want to handle this correctly for a "real" thing, but this is just a cute demo and that's gonna be a close enough approximation to work for this I think.
"The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information."
"In cloud computing, the term zero-knowledge (or occasionally no-knowledge or zero access) refers to software services that store, transfer or manipulate data such that it is only accessible to its owner, not to the service provider."
Your quote heavily misspells "bullshit marketing" ;)
For marketing reasons, people try give things fancy names, even if those names are misused and are completely wrong. This is exactly what happened with all those "zero-knowledge encrypted cloud storages" and so on.
My problem is that they started doing this my using "zero knowledge" as a term from cryptography. The trend had started in early 2010s or so, as cryptocurrencies and all things crypto became popular, people realized they could use that vibe for profit.
So cloud storage providers in particular had realized "zero knowledge" sounds cool and fancy and started using it in their marketing despite stealthily assigning it entirely different meaning from where they took it from (well, some had their cryptographic designs all backwards recognizably even to my uneducated brain - false promises when most customers don't have sufficient knowledge and awareness, business as usual). They were critiqued for it, and they just shrugged it off because who gives a fuck about some angry nerds insisting on some correct word usage. And so this shit caught on, and yes, now we have two meanings.
I suppose I got to let it go, but I feel upset about the outcome.
As far as I understand it (and I'm not a cryptographer!), it is not zero knowledge.
Zero knowledge means you can prove you know something without disclosing any additional information about it, at all - that's why it's called "zero". And here, a hash of crush name is exposed, so it's not.
But why impossible? Take this example: https://en.wikipedia.org/wiki/Zero-knowledge_proof#Discrete_... - all parties exchange are essentially random numbers (which doesn't count as "additional information"), yet they establish the fact that Peggy knows x. There's that footnote about how r must be truly random, of course, but as long as everything's done right there is no additional information there whatsoever, only random noise.
Side note: one thing I certainly don't understand are NI-ZK - while I think I have some rough understanding of how interactive ZK proofs work - well, I mean, I've read Quisquater et al.'s "How to explain zero-knowledge protocols to your children" - but I'm pretty clueless how they manage to make such things non-interactive.
Oh, I think I see your point now. But I think it's a weird argument, to be honest.
I suppose the fact that it's Peggy and Victor who are running that protocol is simply irrelevant. They're talking about that value of x after all, and nothing related to that topic is revealed beyond the proof of the fact that Peggy knows it. If she'd appear in person, wherever she wears a red shirt or a white one would be might be considered "information" but it would be completely out of scope.
Fun concept, but quite easy to use with a malicious intent. It would be better if only people who have a crush on you could use the link (meaning the confession would work both ways)
Instead of getting your SO's name tattooed on your body that you'll regret in a few years, you'll instead get your names added to the blockchain...that you'll regret in a few years.
Blake2b + Hybrid PoW chain with LOW TRANSACTION FEES and 4 TX/S THROUGHPUT now CONFIRMING COMMITTED RELATIONSHIPS with blockchain technology! Your relationship isn't valid until there are AT LEAST 36 CONFIRMATIONS on $LOVE chain!!1
Also now supporting ON-CHAIN unique NFTs for couples for low fees!!
Similar to how blockchains killer app is delivering pizza.
You deliver the pizza as normal then do something something blockchain and now it is
blockchain.
To stop my friends from using this to guess who my crush is, a fun iteration could be instead of entering the person’s name, you enter the last text you sent, place you met, etc. Something only the two of you would know … and maybe even something romantic :)
What does this achieve that posting "text me and I'll tell you if I have a crush on you" doesn't?
Or texting your crush directly?
I suppose it's a useful commitment mechanism for proving you aren't telling everyone they're your only crush, but that seems a bit of a niche use case.
1. Since it's an external web site with a little bit of tech behind it that presumably others are using, it might seem less desperate or strange than the post you suggest.
2. The potential crushee can do the check without notifying you they're doing so. They might be too embarrassed/intimidated to actually tell you they're interested in whether you have a crush.
Small idea, no idea how useful if at all but maybe it could be a simple page with a list of reasons why the sender likes the recipient, and/or a YouTube playlist of songs that remind them of the recipient etc
Well... hactually... This is kind like the opposite of zero-knowledge, where everyone can know your crush just by entering all suspecting names in the link.
I remember reading a joke research paper about something like this. It explored all currently known methods of confessing your love, their pros and cons, and had a funny acronym for each. It then proposed a newer, secure algorithm for confessing to your crush if the feeling was mutual, and without leaking information to 3rd parties. I'm trying to find it, but I don't have it saved and I haven't found it on Google yet.
I'm really impressed with how readable and how funny that is, but I'm sure I'm missing at least one of the jokes contained within. In particular, they suggest an extension to their protocol called "SENPAI-MTT (More Than Two)", which I'm sure must be a cleverly chosen backronym, but I can't work out why (or if) it is funny.
My initial thought was that it could be a reference to the Japanese verb meaning "to look"[0], such as mite ita ("was looking") but represented in vowelless chatspeak[1]. More logical, though, would be the verb meaning "to notice"[2], but the imperative would be kizuite kudasai ("please notice!")[2], and that doesn't match "MTT" at all.
The paper does discuss such relationships, but "SENPAI-MTT (More Than Two)" is an extension to the protocol to allow a participant to choose from more than two (i.e. Crush / No Crush) possible opinions about someone.
It's in the section titled "Ternary Responses", and covers the use case of a participant wanting to express "Maybe" as an opinion.
Oh, actually, I might have worked it out. It could be that "More Than Two" is designed to be somehow the reverse of "Less Than Three", which represents a heart.
It's fascinating to see how far people are willing to go to avoid the awkward feeling of potential rejection.
I mean I have been there.
But as I am older this just feels funny. If you like someone just tell them. Rejection is part of the fun.
Right? I embraced rejection therapy and the results were scary good. A whole new world opened up, not only in romance, but sales, financing, recruitment, etc.
204 comments
[ 2.7 ms ] story [ 248 ms ] threadIf Bob publishes his link, and I want to know who his crush is, I can simply try all our classmates' names and quickly find out that it's Alice.
Those games only make at least a bit of sense when everybody enters their crush and only when matching both get notified.
Also brute-forceable, but at least it's quadratic (if you suspect nothing about crushes, which is unrealistic in itself).
I remember those reallllly early games like MASH or even early "compatibility" apps. Very coy.
"Find out if your crush fancies you, just choose them from your contacts:"
...
"Message 'hey there, I like you' sent"
Repeat that long process until there is just one couple left, whose first-born you then propose to. Having lived long and healthily enough to complete this game, you must have some very desirable genes and/or wealth, and you'll be good friends with basically all this person's ancestors, so there's a strong chance they'll say yes, despite the age difference.
https://www.pinecone.io/learn/locality-sensitive-hashing/
I’m not sure if zero-knowledge proofs exist for love outside of action - repeated acts of commitment over time (to reduces the confidence that someone doesn’t love you).
I don't see a clear way of mapping the concept of a zero knowledge proof to the crush problem.
But the best I can come up with is:
1) No one learns that Alice (claims to) have a crush on Bob
2) Unless Bob also claims to have a crush on Alice, in which case.
3) Only Bob learns that Alice has a crush on him.
4) If Bob learns that Alice has a crush on him, Alice learns that Bob has a crush on her.
5) All the above guarantees are symmetric if you swap Bob and Alice.
Maybe the second half of the class could be about designing a more secure system. Or use this dilemma to explain public-private key encryption.
Even then, among heterosexuals they will suffer from the same problem as basically every software platform for romance among straight people: the massive asymmetry in interest between men and women. Men would copy and paste virtually every woman they know into the system as a "crush," so they can find which if any of their female acquaintances might be interested, and then they would decide who to pursue.
Smart men would, who know their place in the world. Any of them are good enough for you, really. Take the one that you like the most out of the ones who like you. Is this a problem? If it weren't asymmetric, it would be hopeless. Instead, most men get the choice between one or more interested women, and most women get a response from one or more of the men they were interested in.
It's better if one side isn't as picky as the other. The other options are that only a couple of people match up at all, or everyone getting a response from everyone i.e. no signal at all.
edit: I mean, isn't that Bumble?
Granted I've never dated as a gay man or as a lesbian, but from what I've observed it seems to me a much smoother and more mutual process than straight dating. I've even heard from bi men about how much easier and less stressful it is to date men than women. AFAICT when both parties are on a level playing field, and there's not a massive asymmetry in power, interest, and investment, there's a lot less grief overall.
> edit: I mean, isn't that Bumble?
Bumble is a valiant attempt to fix this issue but it seems to mostly be a failure. An average man may occasionally get a message (which will usually just say "hi"), but the asymmetry in interest is still there, and it's still mostly men's responsibility to do the real initiating.
That's most of the demographic for this product. The number of over-25 people, not in a committed relationship, who still haven't figured out how to ask people out, is pretty small.
This tool doesn't do what I'd want, but a tool that did would be kinda neat :)
a zero knowledge proof would do something like prove a valid attestation of love, but reveal nothing about who (other than maybe membership in some large enough set).
I never had a thing for good spellers.
To a point, however, you've also described a Bloom filter reasonably well. That is it would show whether their hash is not in the set.
Related is the humorous paper "Solving the Dating Problem with the SENPAI Protocol" [1], though the solution in that paper does not rely on a third party.
[1]: http://sigtbd.csail.mit.edu/pubs/2016/paper10.pdf
Seems like someone hasn't read the famous "Falsehoods Programmers Believe about Names"[0]
[0] https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-...
The relationship between person and name is one-to-many
> 11. People’s names are all mapped in Unicode code points.
You can implement custom characters, i.e. https://en.wikipedia.org/wiki/Private_Use_Areas or have a process for exceptions
> 12. People’s names are case sensitive. 13. People’s names are case insensitive.
You can store this as an attribute
> 14. People’s names sometimes have prefixes or suffixes, but you can safely ignore those.
This can be other fields if you're trying to structure the data, or you can simply store the entire name as a contiguous field.
> 18. People’s names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
Don't string compare names as a test for equality.
The obvious response to this is: that's too hard (/impossible to do). But that's just the reality of the situation. These issues are not necessarily possible to solve. #21 in particular makes this application very broken even with very plain vanilla western names.
"The essence of zero-knowledge proofs is that it is trivial to prove that one possesses knowledge of certain information by simply revealing it; the challenge is to prove such possession without revealing the information itself or any additional information."
Your quote heavily misspells "bullshit marketing" ;)
For marketing reasons, people try give things fancy names, even if those names are misused and are completely wrong. This is exactly what happened with all those "zero-knowledge encrypted cloud storages" and so on.
Clearly there are two big clusters of meaning for “zero-knowledge” and they seem distinct enough to not overlap. Seems fine to me.
My problem is that they started doing this my using "zero knowledge" as a term from cryptography. The trend had started in early 2010s or so, as cryptocurrencies and all things crypto became popular, people realized they could use that vibe for profit.
So cloud storage providers in particular had realized "zero knowledge" sounds cool and fancy and started using it in their marketing despite stealthily assigning it entirely different meaning from where they took it from (well, some had their cryptographic designs all backwards recognizably even to my uneducated brain - false promises when most customers don't have sufficient knowledge and awareness, business as usual). They were critiqued for it, and they just shrugged it off because who gives a fuck about some angry nerds insisting on some correct word usage. And so this shit caught on, and yes, now we have two meanings.
I suppose I got to let it go, but I feel upset about the outcome.
Zero knowledge means you can prove you know something without disclosing any additional information about it, at all - that's why it's called "zero". And here, a hash of crush name is exposed, so it's not.
Check this out for a much better explanation: https://crypto.stackexchange.com/questions/70877/is-a-hash-a...
This is physically impossible and definitely not what ZK means.
But why impossible? Take this example: https://en.wikipedia.org/wiki/Zero-knowledge_proof#Discrete_... - all parties exchange are essentially random numbers (which doesn't count as "additional information"), yet they establish the fact that Peggy knows x. There's that footnote about how r must be truly random, of course, but as long as everything's done right there is no additional information there whatsoever, only random noise.
Side note: one thing I certainly don't understand are NI-ZK - while I think I have some rough understanding of how interactive ZK proofs work - well, I mean, I've read Quisquater et al.'s "How to explain zero-knowledge protocols to your children" - but I'm pretty clueless how they manage to make such things non-interactive.
I suppose the fact that it's Peggy and Victor who are running that protocol is simply irrelevant. They're talking about that value of x after all, and nothing related to that topic is revealed beyond the proof of the fact that Peggy knows it. If she'd appear in person, wherever she wears a red shirt or a white one would be might be considered "information" but it would be completely out of scope.
Blake2b + Hybrid PoW chain with LOW TRANSACTION FEES and 4 TX/S THROUGHPUT now CONFIRMING COMMITTED RELATIONSHIPS with blockchain technology! Your relationship isn't valid until there are AT LEAST 36 CONFIRMATIONS on $LOVE chain!!1
Also now supporting ON-CHAIN unique NFTs for couples for low fees!!
Sep 23, 2014
https://bitcoinmagazine.com/press-releases/couple-get-marrie...
Or texting your crush directly?
I suppose it's a useful commitment mechanism for proving you aren't telling everyone they're your only crush, but that seems a bit of a niche use case.
2. The potential crushee can do the check without notifying you they're doing so. They might be too embarrassed/intimidated to actually tell you they're interested in whether you have a crush.
It could be done better with public/private key cryptography, but then your audience has to be able to deal with that.
Oh well, it's on my backlog down in the "I'll never actually get there" section.
My initial thought was that it could be a reference to the Japanese verb meaning "to look"[0], such as mite ita ("was looking") but represented in vowelless chatspeak[1]. More logical, though, would be the verb meaning "to notice"[2], but the imperative would be kizuite kudasai ("please notice!")[2], and that doesn't match "MTT" at all.
[0] http://www.japaneseverbconjugator.com/VerbDetails.asp?txtVer...
[1] https://old.reddit.com/r/LearnJapanese/comments/bupbs9/about...
[2] http://www.japaneseverbconjugator.com/VerbDetails.asp?txtVer...
It's in the section titled "Ternary Responses", and covers the use case of a participant wanting to express "Maybe" as an opinion.
Oh, actually, I might have worked it out. It could be that "More Than Two" is designed to be somehow the reverse of "Less Than Three", which represents a heart.