Electronic lottery tickets as micropayments (1997)

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.