[HN Gopher] Electronic lottery tickets as micropayments (1997)
___________________________________________________________________
Electronic lottery tickets as micropayments (1997)
Author : mrleinad
Score : 54 points
Date : 2021-06-29 18:45 UTC (4 hours ago)
(HTM) web link (fermatslibrary.com)
(TXT) w3m dump (fermatslibrary.com)
| thinkloop wrote:
| Why would transacting lottery tickets be cheaper than transacting
| money?
|
| EDIT: Who pays for the lottery ticket transactions that the bank
| is saving?
| jaywalk wrote:
| Because the bank only has to process/pay out the winning
| tickets instead of every single micropayment.
| thinkloop wrote:
| Yes, I understand that, but that is only for the bank,
| society still has to pay for the 999 of 1000 transactions
| that the bank saved. Who pays for those, why would they be
| cheaper given that they are essentially money again.
| londons_explore wrote:
| The whole aim of this scheme is to try to allow
| micropayments in a world where banks want to take a $0.20
| fee on each transaction.
|
| If you could persuade all banks to make all fees be
| percentage based or nill, such a scheme would be
| unnecessary.
| saurik wrote:
| Everyone pays them, but only probabilistically: the cost of
| a single commit gets spread out over the cost of all 1000
| of those transactions (in the same way that costs of doing
| business that you can't track to a single customer still
| get paid by all customers simply inflating your price just
| a bit). As an example, if the cost of your product is $0.01
| and the cost of a bank transfer is $0.25, and you receive
| tickets at 1/2500 probability, then you tack on to
| everyone's receipt "their share" of that fee, charging them
| $0.0101 instead of $0.01, for a claim value per ticket of
| $25.25 (as $25.25*1/2500==$0.0101), which you can see
| includes the $25 for the 2500 products people bought and
| the extra $0.25 to pay the banking fee. So: the recipient
| paid that fee, but passed it on to the sender, who
| ultimately paid that fee... but a much much lower fee
| ($0.0001 instead of $0.25).
| thinkloop wrote:
| I understand the bit about doing less payments is cheaper
| than doing more payments. The part that everyone is
| glossing over is:
|
| "and you receive tickets at 1/2500 probability"
|
| How do you receive these tickets? How can they be
| trusted? How can you guarantee they are honored? If we
| can receive lottery tickets in a cheap, trusted, secure
| manner why don't we just use the same system for the
| money itself?
| saurik wrote:
| FWIW, this is not skimmed over in any of the papers ;P.
|
| The only real mechanism you need is a shared random
| number generator? Here is the simple one most people use:
| you make a random number, hash it, and send me the hash.
| I make a second random number, and then sign the number
| and the hash. You then determine if you won by hashing
| your number with mine, and if the hash type cast to a
| number is less than 1/2500 times the maximum such number,
| then you won, and can reveal your original number to the
| bank--which has to be willing to honor the weird
| instructions I scrawled on my check involving "only
| accept this check if the following math holds based on
| the public key of my bank account" to verify these hashes
| and signatures... here is where turing complete
| blockchains come in :D--as proof. Neither of us can now
| control whether the ticket wins.
|
| The thing you seem to be missing though honestly isn't
| that? You are conflating the ability to create a
| "trusted" mechanism with a "cheap" one: in a world where
| it costs $0.25 to move the money, the issue is how to
| mitigate that cost without losing trust in the process.
| This is a transform on an existing trusted system that is
| "too expensive" to make it cheaper. If you had a cheap
| way of doing it, you wouldn't need this transform... but
| you don't have a cheap way of doing it: you only have an
| expensive way... so we agree to share the cost of using
| that expensive way across numerous parties.
|
| Really, I think the right question here is "but this
| can't come for free: what is the cost?" and the key
| tradeoff is that now all transfers are some horribly
| confusing probabilistic space of variance over possible
| payouts... you go to buy a stick of gum and end up
| "losing" four days in a row and have now spent over $100
| on four sticks of gum, which _in the limit_ should
| eventually work out, but even then there will be some
| binomial distribution where different people got lucky
| throughout their lives and others didn 't; and, I think
| worse, users can run into "cash flow" problems during
| losing streaks as they have a budget based on their non-
| probabilistic income that is now being used on
| probabilistic expenditures... the whole thing is a mess
| if you apply it indiscriminately :(.
|
| This scheme is thereby simply "different": it results in
| a primitive that only makes sense for very large numbers
| of very tiny transactions, which the original trusted
| system likely wasn't capable of, as it wanted to make it
| not only cost effective but "reasonable" to spend $5...
| by which I mean that, after I give you the money, I know
| what I gave you and you know what you got and the amount
| of money left in my account is in a knowable state and so
| no one is "gambling" hoping to get lucky enough to make
| it through this month without "actually" spending money
| on their gum habit--or, alternatively, getting _massively
| overpaid_ for gum ;P--so they can pay their respective
| rents), something this system is (maybe almost
| "hilariously") incapable of.
|
| Put elsewise: I do not know of any current way to
| _deterministically_ accept very small quantities of
| money, at scale; but, given a way to deterministically
| accept large quantities of money (at high cost) with some
| attached instructions (such as you theoretically could do
| with a simple check if the bank tellers were still people
| and had advanced math degrees ;P), I am able to convert
| that into a way to accept small quantities of money (at
| low cost)... except now it is stochastic (probabilistic)
| instead of deterministic :(. If, thereby, you had a way
| to _deterministically_ accept small quantities of money,
| then I have a way to (now stochastically : /...) accept
| _even smaller_ quantities of money (which deceases your
| variance and increases your efficiency); and, in fact, I
| am always excited by the release of higher-efficiency
| blockchains (such as Avalanche) for this reason.
| thinkloop wrote:
| Thank you for that response, I didn't realize the lottery
| was happening at the moment of payment. I thought tickets
| were given out then the draw happens at a later date and
| the tickets are redeemed then. This makes sense! Thanks
| for clarifying.
| petermcneeley wrote:
| How is double spend avoided? EDIT: My bad I thought this was a
| currency.
| nightpool wrote:
| I don't understand the question. Each lottery ticket is made
| out to a single "recipient"--in what situation do you imagine a
| double spend?
| alisonkisk wrote:
| it's not (self-protecting) transferable / decentralized
| currency.
|
| It's same as a paper lottery ticket.
| saurik wrote:
| Your question is not without merit, as these lottery tickets
| end up feeling a bit like "checks" (the paper kind you give
| someone as an IOU against your bank account), which makes it
| subject to the same general "kiting" attack of writing multiple
| checks that would all have to pay off at the same time in order
| to not overdraw your account.
|
| In case this isn't obvious how it applies to this case--as the
| probabilities might be obfuscating things somewhat, and I have
| now seen multiple replies to you make it sound like your
| question is invalid, despite being the key question for how to
| use this technology (as someone who works with it daily and has
| for years)--imagine if you send four people 50% tickets for
| your entire balance.
|
| In this scenario, you would expect two of them would win; let's
| just assume this is the actual concrete result. Even if you
| decide that people who receive a winning ticket will commit
| their ticket before accepting it, two of these people got
| losing tickets and a third will succeed in claiming their
| winner... you just managed to get 1.5x the value of your
| account, by handing out more (probabilistic) checks than you
| can (probabilistically) pay.
|
| The only protection from it not being a true 2x overdraft was
| that two of the participants had a naive way to verify they got
| paid... but really, participants in this system _usually_
| accept money from low-probability _losing_ tickets; this then
| becomes a form of off-chain settlement that is subject to
| scenarios where people can "double-spend" some of their money
| if you aren't paying attention, in a way that is actually very
| analogous to blockchains (such as Bitcoin and Ethereum) that
| experience routine chain reorganization: you need to have some
| kind of scheme in place to not only decide a single valid
| result but also a scheme to feel comfortable with the
| "finality" of that result (the whole "wait for six
| confirmations" jazz).
|
| The usual solution to this is to have the spender put money
| down into an on-chain contractual "escrow" that gets "burned"
| (destroyed) as part of any overdraft, to make it so you
| hopefully lose more money than you are capable of overspending
| in any reasonable period of time (which I would argue has at
| least some parallels to mechanisms in proof of stake
| blockchains, with the understanding that every single lottery
| payment account is effectively its own blockchain at this
| point).
|
| Honestly, I find much more inspiration in this much later
| paper, which extends this scheme to zero-knowledge coins and
| does some of the math required to understand the bounds on the
| escrow required to manage this risk.
|
| https://eprint.iacr.org/2016/1033.pdf
| Robotbeat wrote:
| That's basically what cryptocurrency Mining is. You get paid for
| mining with a digital lottery.
| sidpatil wrote:
| A similar interest payment structure exists for conventional
| savings accounts as well:
| https://en.m.wikipedia.org/wiki/Prize-linked_savings_account
| saurik wrote:
| Prior discussion of this same link can be found at this other
| thread (which I had in my list of links below but it felt useful
| to surface it).
|
| https://news.ycombinator.com/item?id=15700718
|
| So, something maybe-fascinating to people is that Rivest--who
| designed this scheme--helped start a company to use it on the web
| to pay for things like news articles and generally replace ads.
| It was called Peppercoin, and was sufficiently before its time
| that not only did it fail (well, in the usual YC-sense: it got
| acquired by something boring and failed to change the world) but
| a lot of the people working on this technology today have never
| heard of it ;P.
|
| Here are a million references I have in a note I was collecting
| back in December on the rise and fall of Peppercoin (which I
| intended to show to my team at Orchid--where we are trying to
| apply this technology to a decentralized market for bandwidth and
| other Internet services: see orchid.com--and then honestly never
| have as I have been busy; and I considered that, maybe even "best
| case", this was likely to be a distraction to them as much as it
| was to me ;P).
|
| background
|
| https://news.ycombinator.com/item?id=989020
|
| https://news.ycombinator.com/item?id=15272944
|
| https://news.ycombinator.com/item?id=9837380
|
| https://news.ycombinator.com/item?id=17533350
|
| papers
|
| https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.44...
|
| https://people.csail.mit.edu/rivest/pubs/Riv97b.pdf
|
| http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.5.1...
|
| https://people.csail.mit.edu/rivest/pubs/Riv04c.slides.slide...
|
| wikis
|
| https://en.m.wikipedia.org/wiki/Peppercoin
|
| https://en.bitcoinwiki.org/wiki/Peppercoin
|
| https://ebrary.net/88179/business_finance/micropayments
|
| funding
|
| http://web.archive.org/web/20031002123349/http://www.paidcon...
|
| https://www.buyoutsinsider.com/peppercoin-banks-on-4-3m-in-c...
|
| http://www.econtentmag.com/Articles/News/News-Item/Peppercoi...
|
| https://www.wsj.com/articles/SB112430543406915783
|
| launch
|
| https://bizwest.com/2003/10/31/peppercoin-solves-download-pa...
|
| https://www.technologyreview.com/2003/12/01/233570/the-webs-...
|
| https://www.nytimes.com/2004/01/07/technology/circuits/a-vir...
|
| https://nextbillion.net/cashless-transactions-at-the-bop-pep...
|
| "2.0"
|
| https://www.finextra.com/pressarticle/1492/peppercoin-releas...
|
| 2004-2005
|
| https://www.digitaltransactions.net/peppercoin-scores-anothe...
|
| https://www.digitaltransactions.net/moneris-signs-up-pepperc...
|
| https://www.bizjournals.com/boston/blog/mass-high-tech/2005/...
|
| https://thepaypers.com/payments-general/peppercoin-small-pay...
|
| banking
|
| https://www.businesswire.com/news/home/20050112005057/en/Pep...
|
| https://thepaypers.com/payments-general/chase-merchant-servi...
|
| mastercard
|
| https://www.finextra.com/newsarticle/14621/peppercoin-and-ma...
|
| https://www.cbronline.com/news/mastercard_and_peppercoin_to_...
|
| https://www.insidearm.com/news/00025887-mastercard-supports-...
|
| https://www.networkworld.com/article/2316448/mastercard-team...
|
| https://www.pressreader.com/usa/san-francisco-chronicle/2005...
|
| "3.0"
|
| https://www.digitaltransactions.net/is-peppercoin-eyeing-opp...
|
| https://www.digitaltransactions.net/peppercoin-3-0-debuts-wi...
|
| operations
|
| https://www.digitalcommerce360.com/2006/04/24/charles-casert...
|
| https://www.securetechalliance.org/secure/events/20061003/T0...
|
| 2006-2007
|
| https://www.bizjournals.com/boston/stories/2006/07/24/story1...
|
| https://www.insidearm.com/news/00015050-suntrust-merchant-se...
|
| https://www.allwirelessnews.com/features/heartland-payment-s...
|
| acquirement
|
| https://www.americanbanker.com/news/peppercoin-sold-to-orego...
|
| https://www.businesswire.com/news/home/20070416005392/en/Cho...
|
| https://mashable.com/2007/04/17/peppercoin/
|
| postmortem
|
| https://www.techdirt.com/articles/20070417/012124.shtml
| satya71 wrote:
| I'd take this over BAT.
| saurik wrote:
| We are using a scheme based on this premise as part of Orchid, a
| decentralized market for Internet resources such as bandwidth.
|
| https://github.com/OrchidTechnologies/orchid
|
| In the current end-user client--which you can currently download
| from the iOS/Android/Mac application stores--we use this to pay
| for VPN service "as you go" in rather small units (the size of
| these chunks in our case feels limited by bandwidth overhead of
| sending signatures and CPU usage for signing tickets, as opposed
| to by the reasonable size of a transfer).
|
| https://www.orchid.com/download
| thinkloop wrote:
| Where do the savings come in? If you know how to securely send
| lottery tickets why can't you use the same system to send the
| money instead?
| saurik wrote:
| See my response to your other question here:
| https://news.ycombinator.com/item?id=27681781 (but like, the
| idea is that you can spread the cost of an underlying
| transfer--which costs money to perform and potentially
| _permanently_ store on the underlying blockchain--across all
| of the people making probabilistic payments, which you can
| make very small if the people involved are willing to
| tolerate the variance on a resulting purchase and have a high
| enough principal to still have a reasonably high efficiency
| after paying for the amortized fees).
| yboris wrote:
| "In 1997, Ron Rivest (one of the inventors of Public-key
| cryptography) proposed the use of digital lottery tickets for
| online micropayments.
|
| In this scheme, a lottery ticket for a $10 prize with a 1/1000
| chance of winning could be used to pay for 1 cent"
|
| https://twitter.com/fermatslibrary/status/140994550447414067...
| ezconnect wrote:
| PDF link https://people.csail.mit.edu/rivest/pubs/Riv97b.pdf
___________________________________________________________________
(page generated 2021-06-29 23:01 UTC)