6 ms·

Does everything need to devolve into sudoku-solving coins that the makers can try to profit off of? If we’re building all this tech for coins or digital stamps

by rtpg 5y ago

Does everything need to devolve into sudoku-solving coins that the makers can try to profit off of? If we’re building all this tech for coins or digital stamps, it seems like the existing system could work fine by rolling per-contact email addresses to give out. Traceability without having to kill any polar bears. Apple is already offering this through their Apple Sign-In

dotancohen 5y ago
For what it's worth I have never used any of the cryptocurrencies. It just seemed to me that this is a viable solution to a difficult problem - a way to associate a cost with a behaviour that we'd like to limit, in a way that does not prevent the poor, disadvantaged, or those who wish to remain anonymous from participating.
- xfer 5y ago
  > in a way that does not prevent the poor, disadvantaged, Yeah mining coins totally doesn't exclude poor people. If it costs less than the profit spammers make they will use it. You can't just handwave the thresold away, and pretend you are solving the problem by just asking for money(thereby excluding large swaths of people). Just use your iMessage.
  - emacsen 5y ago
    This is probably the worst part about any kind of payment based system, whether it be money or proof of work- these systems do reflect the disadvantages of the economies of the world. That said, since this problem already exists in the world, it is often overstated. If a stamp is a reasonable cost, and only a one time cost, it will be largely invisible. 25 cents (a price set by the recipient) to send a message from a stranger won't have a big impact on most people, and it's important to recognize it's only the first time. It's further important to know it would even be possible to refund the cost of the stamp back to the sender once the message is sent. The recipient could have a button that says "Return stamp" which would then let the sender re-use or in some other way organize the stamp. Now let's contrast to today... Let's say I want to send a message to a big movie star or a CEO. The chances that I will be able to get their address is relatively low. Even if I do, they likely have someone they pay to filter their messages before it gets to them.
    - xfer 5y ago
      I am sure such a scheme embedded into a protocol would work with certain group of people. Most people would just get the same amount of spam, because they can't afford to up their threshold in a way that would deter the "marketeers" to stop such activity.
      - emacsen 5y ago
        I actually think it would dramatically cut down on spam, but not hate messages.
- cabalamat 5y ago
  If the sender is on the recipient's allow-list then it goes straight through. Otherwise the recipient has to solve a captcha. This allows humans to send small numbers of emails easily, but makes it harder for spammers. Also, recipients could have deny-lists and automatically share them with others they trust. The deny-lists might be a list of senders' cryptographically generated IDs, in which case it should be reasonably hard to generate new ones (e.g. 10 minutes on an X86 cpu using an algorithm not conducive to parallelisation or special hardware).
  - denton-scratch 5y ago
    > Otherwise the recipient has to solve a captcha. No way am I going to solve captchas for incoming emails! Not any.
  - snmx999 5y ago
    Spam from hell: you don't know if the email is real and you have to solve a CAPTCHA to find out.
  - rtpg 5y ago
    Shouldn’t the sender be who needs to solve the captcha?
emacsen 5y ago
I've said this in another comment but it bears repeating, and perhaps repeating in different ways. Stamps are just tokens, as in bearer tokens. How you get stamps is a different issue. Let me give you a couple of examples how one might do stamps without cryptocurrency: 1. Alice, "I'd like 100 Bob stamps please." Bob: "Please pay me $5" 2. Alice, "I'd like 100 Bob stamps please." Bob: "Can you please do some computational work on my behalf?" 3. Alice: "I'd like 100 Bob stamps please." Bob: "How will you pay for them?" Alice: "I could trade in 30 Carol stamps, would that work?" Bob: "Yes, let's trade Carol stamps for Bob stamps." As for Apple Sign-In, I don't know what it is, so I can't speak to it.
- notriddle 5y ago
  Apple generates a random email address for each individual subscription, and forwards it to your inbox. If you cancel the subscription, then the forward is changed to a blackhole. Not only does this give you a nice way to really cancel, it also means you can track down if someone sold your address to a spam list. Or if it accidentally leaks, rotate it.
jasode 5y ago
>, it seems like the existing system could work fine by rolling per-contact email addresses to give out. The problem is you can't give out "per-contact email addresses" to future unknown people when you can't predict who will legitimately send you email that's not spam. The random-generated-rolling email addresses that hides real addresses such as systems in Apple/craigslist/ebay/domainWhoISprivacy can function because there's already a non-email type of _transaction_ or _activity_ to establish the first link for communication -- without requiring a reference to a person id. E.g. Consider that it's the _user_ that first enters the "fake" rolling email address into a shopping website. In that case, the activity is "shopping cart" and now the website can communicate back with that fake email. That doesn't work for other real-life scenarios where the sender only has the person in mind to send a message but no transaction or other triggering activity to publish/discover a random email address. For that, you need stable easy-to-type addresses such as johndoe@example.com which you can put on business cards. But the problem is that spammers also know that non-random email address. So the cpu-puzzles approach was (attempting to) solve a different problem: people can publicize their stable email addresses but spammers also knowing it doesn't matter because they don't want to spend $$$ on cpu.
- rtpg 5y ago
  This is getting a bit fanciful, but there’s a universe where you print unique addresses on business cards. Of course you can use a QR code. In the world where you can’t do this, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link. Though ultimately business cards are business cards are business cards. They’re pretty low-value and you probably want to put a less important email on there.
  - jasode 5y ago
    >, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link. Sure but as I previously mentioned, that proposal is another variation of a "solution" where you must do some non-email activity first such as ... authorize with login credentials from LinkedIn/Facebook/Google/Github/Apple/etc ... and then receive the generated rolling email address. Yes, if the solution space is opened up to include doing non-email activity as a prerequisite to later communicating via email, there are many ideas. But many SMTP email decentralized purists think having to use centralized "social proof" sites such as Facebook for single-sign-on credentials is not an acceptable solution. That's why the (failed) Hashcash idea had appeal for email enthusiasts that wanted the "proof" to reside _within_ the SMTP ecosystem. E.g. the extra Hashcash email header row would be something like "X-Hashcash: 1:20:1303030600:anni@cypherspace.org::McMybZIhxKXu57jd:ckvi" The "sudoku-solving" hashcash "proof" as one might call it... is generated by the email sender and verified by the receiver without relying on a non-email entity. The "legitimacy score" of new emails from new unknown users can be calculated and assessed within the SMTP ecosystem. ... But it's not a solution that pleases everyone because there are inevitable tradeoffs: (1) cpu heat "killing polar bears" and (2) home computers (instead of spammers' computers) inadvertently expend the cpu because of infection by malware to become part of a bot army So to go back to your idea of a non-email activity as a requirement to open up a new email communication link... this is not an unreasonable scenario as this was the way SMTP email in 1981 used to work. Before the general public accessed the internet in the 1990s, the email system didn't have a massive spam problem because the non-email activity to prevent it was being hired by University of XYZ that was part of the network linked by National Science Foundation. (That researcher had ".edu" address.) Or the person wanting to send an email was a government worker in the Department of Defense. (That government worker had a ".mil" address.) So any new email users were already vetted by the hiring procedures of universities and United States government. It's like an ancient form of "social proof" without Facebook/LinkedIn/etc. As a consequence, a researcher "bob@xyz.edu" sending a new email to "alice@darpa.mil" -- was not likely to be spam. (Similar to users noticing that their company Slack channel doesn't have spam. Yes, it's because the people talking to you on Slack had to be hired first and therefore, your coworkers are unlikely to send you spam.) But now that email is "opened up to everybody" -- including the spammers, the "hiring procedures" as the non-email activity to prevent spam doesn't scale up for a billion new users. So your proposal tries to re-create a barrier again... instead of University of Illinois vetting you before giving you an ".edu" email address, the similar idea for modern times is to have something like Facebook "vet" you with their sign-on credentials before revealing some random generated per-contact email address. To summarize the meta categories of solutions for email spam: - outside of email universe solutions: non-SMTP non-email activity prerequisite such as 3rd-party entity "social proof": e.g. 1980s old days of being hired by USA government or educational institution, or today's proposal of 3rd-party SSO credentials from centralized websites such as Facebook - inside the email universe solutions: proof-of-work, Bayesian text filtering, domain and ip reputation blacklists, etc (But domain and ip reputation blacklists solutions can arguably be categorized as "outside" of email system because it requires a big entity that can scan millions/billions of email traffic to create the blacklists. A residential SMTP server sending a new email to another residential SMTP server won't have that reputation list.)

by rtpg 5y ago

dotancohen 5y ago

For what it's worth I have never used any of the cryptocurrencies. It just seemed to me that this is a viable solution to a difficult problem - a way to associate a cost with a behaviour that we'd like to limit, in a way that does not prevent the poor, disadvantaged, or those who wish to remain anonymous from participating.

xfer 5y ago
> in a way that does not prevent the poor, disadvantaged, Yeah mining coins totally doesn't exclude poor people. If it costs less than the profit spammers make they will use it. You can't just handwave the thresold away, and pretend you are solving the problem by just asking for money(thereby excluding large swaths of people). Just use your iMessage.
- emacsen 5y ago
  This is probably the worst part about any kind of payment based system, whether it be money or proof of work- these systems do reflect the disadvantages of the economies of the world. That said, since this problem already exists in the world, it is often overstated. If a stamp is a reasonable cost, and only a one time cost, it will be largely invisible. 25 cents (a price set by the recipient) to send a message from a stranger won't have a big impact on most people, and it's important to recognize it's only the first time. It's further important to know it would even be possible to refund the cost of the stamp back to the sender once the message is sent. The recipient could have a button that says "Return stamp" which would then let the sender re-use or in some other way organize the stamp. Now let's contrast to today... Let's say I want to send a message to a big movie star or a CEO. The chances that I will be able to get their address is relatively low. Even if I do, they likely have someone they pay to filter their messages before it gets to them.
  - xfer 5y ago
    I am sure such a scheme embedded into a protocol would work with certain group of people. Most people would just get the same amount of spam, because they can't afford to up their threshold in a way that would deter the "marketeers" to stop such activity.
    - emacsen 5y ago
      I actually think it would dramatically cut down on spam, but not hate messages.
cabalamat 5y ago
If the sender is on the recipient's allow-list then it goes straight through. Otherwise the recipient has to solve a captcha. This allows humans to send small numbers of emails easily, but makes it harder for spammers. Also, recipients could have deny-lists and automatically share them with others they trust. The deny-lists might be a list of senders' cryptographically generated IDs, in which case it should be reasonably hard to generate new ones (e.g. 10 minutes on an X86 cpu using an algorithm not conducive to parallelisation or special hardware).
- denton-scratch 5y ago
  > Otherwise the recipient has to solve a captcha. No way am I going to solve captchas for incoming emails! Not any.
- snmx999 5y ago
  Spam from hell: you don't know if the email is real and you have to solve a CAPTCHA to find out.
- rtpg 5y ago
  Shouldn’t the sender be who needs to solve the captcha?

emacsen 5y ago

I've said this in another comment but it bears repeating, and perhaps repeating in different ways. Stamps are just tokens, as in bearer tokens. How you get stamps is a different issue. Let me give you a couple of examples how one might do stamps without cryptocurrency: 1. Alice, "I'd like 100 Bob stamps please." Bob: "Please pay me $5" 2. Alice, "I'd like 100 Bob stamps please." Bob: "Can you please do some computational work on my behalf?" 3. Alice: "I'd like 100 Bob stamps please." Bob: "How will you pay for them?" Alice: "I could trade in 30 Carol stamps, would that work?" Bob: "Yes, let's trade Carol stamps for Bob stamps." As for Apple Sign-In, I don't know what it is, so I can't speak to it.

notriddle 5y ago
Apple generates a random email address for each individual subscription, and forwards it to your inbox. If you cancel the subscription, then the forward is changed to a blackhole. Not only does this give you a nice way to really cancel, it also means you can track down if someone sold your address to a spam list. Or if it accidentally leaks, rotate it.

jasode 5y ago

>, it seems like the existing system could work fine by rolling per-contact email addresses to give out. The problem is you can't give out "per-contact email addresses" to future unknown people when you can't predict who will legitimately send you email that's not spam. The random-generated-rolling email addresses that hides real addresses such as systems in Apple/craigslist/ebay/domainWhoISprivacy can function because there's already a non-email type of _transaction_ or _activity_ to establish the first link for communication -- without requiring a reference to a person id. E.g. Consider that it's the _user_ that first enters the "fake" rolling email address into a shopping website. In that case, the activity is "shopping cart" and now the website can communicate back with that fake email. That doesn't work for other real-life scenarios where the sender only has the person in mind to send a message but no transaction or other triggering activity to publish/discover a random email address. For that, you need stable easy-to-type addresses such as johndoe@example.com which you can put on business cards. But the problem is that spammers also know that non-random email address. So the cpu-puzzles approach was (attempting to) solve a different problem: people can publicize their stable email addresses but spammers also knowing it doesn't matter because they don't want to spend $$$ on cpu.

rtpg 5y ago
This is getting a bit fanciful, but there’s a universe where you print unique addresses on business cards. Of course you can use a QR code. In the world where you can’t do this, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link. Though ultimately business cards are business cards are business cards. They’re pretty low-value and you probably want to put a less important email on there.
- jasode 5y ago
  >, you could have a request mechanism. It’s a link, you go there, and it requires one-time auth from _any site at all of note_. Some sort of social proof. And that gives you a link. Sure but as I previously mentioned, that proposal is another variation of a "solution" where you must do some non-email activity first such as ... authorize with login credentials from LinkedIn/Facebook/Google/Github/Apple/etc ... and then receive the generated rolling email address. Yes, if the solution space is opened up to include doing non-email activity as a prerequisite to later communicating via email, there are many ideas. But many SMTP email decentralized purists think having to use centralized "social proof" sites such as Facebook for single-sign-on credentials is not an acceptable solution. That's why the (failed) Hashcash idea had appeal for email enthusiasts that wanted the "proof" to reside _within_ the SMTP ecosystem. E.g. the extra Hashcash email header row would be something like "X-Hashcash: 1:20:1303030600:anni@cypherspace.org::McMybZIhxKXu57jd:ckvi" The "sudoku-solving" hashcash "proof" as one might call it... is generated by the email sender and verified by the receiver without relying on a non-email entity. The "legitimacy score" of new emails from new unknown users can be calculated and assessed within the SMTP ecosystem. ... But it's not a solution that pleases everyone because there are inevitable tradeoffs: (1) cpu heat "killing polar bears" and (2) home computers (instead of spammers' computers) inadvertently expend the cpu because of infection by malware to become part of a bot army So to go back to your idea of a non-email activity as a requirement to open up a new email communication link... this is not an unreasonable scenario as this was the way SMTP email in 1981 used to work. Before the general public accessed the internet in the 1990s, the email system didn't have a massive spam problem because the non-email activity to prevent it was being hired by University of XYZ that was part of the network linked by National Science Foundation. (That researcher had ".edu" address.) Or the person wanting to send an email was a government worker in the Department of Defense. (That government worker had a ".mil" address.) So any new email users were already vetted by the hiring procedures of universities and United States government. It's like an ancient form of "social proof" without Facebook/LinkedIn/etc. As a consequence, a researcher "bob@xyz.edu" sending a new email to "alice@darpa.mil" -- was not likely to be spam. (Similar to users noticing that their company Slack channel doesn't have spam. Yes, it's because the people talking to you on Slack had to be hired first and therefore, your coworkers are unlikely to send you spam.) But now that email is "opened up to everybody" -- including the spammers, the "hiring procedures" as the non-email activity to prevent spam doesn't scale up for a billion new users. So your proposal tries to re-create a barrier again... instead of University of Illinois vetting you before giving you an ".edu" email address, the similar idea for modern times is to have something like Facebook "vet" you with their sign-on credentials before revealing some random generated per-contact email address. To summarize the meta categories of solutions for email spam: - outside of email universe solutions: non-SMTP non-email activity prerequisite such as 3rd-party entity "social proof": e.g. 1980s old days of being hired by USA government or educational institution, or today's proposal of 3rd-party SSO credentials from centralized websites such as Facebook - inside the email universe solutions: proof-of-work, Bayesian text filtering, domain and ip reputation blacklists, etc (But domain and ip reputation blacklists solutions can arguably be categorized as "outside" of email system because it requires a big entity that can scan millions/billions of email traffic to create the blacklists. A residential SMTP server sending a new email to another residential SMTP server won't have that reputation list.)