4 ms·

Why would transacting lottery tickets be cheaper than transacting money? EDIT: Who pays for the lottery ticket transactions that the bank is saving?

jaywalk 5y ago
Because the bank only has to process/pay out the winning tickets instead of every single micropayment.
- thinkloop 5y ago
  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 5y ago
    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 5y ago
    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 5y ago
      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 5y ago
        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.

jaywalk 5y ago

Because the bank only has to process/pay out the winning tickets instead of every single micropayment.

thinkloop 5y ago
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 5y ago
  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 5y ago
  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 5y ago
    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 5y ago
      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.