The whole blocker to micro payments were banks and credit card companies (same reason ACH is so archaic even though other companies have much better systems--they decided it's not in their interest to improve it). Credit cards have a flat fee, plus a percentage. That's why small businesses have a minimum purchase price (even though it's against their merchant agreement).

When it first started I figured PayPal would have enabled microtransactions, but I gave up on that years ago. Venmo could, but it doesn't seem like that's the market they're focused on. Bitcoin would fill that niche, but it has a few other barriers.

It is more recently called “probabilistic payments” and that search phrase will get you some results of such constructions in bitcoin among other things.

How hard do you think this would be to implement on top of the Venmo or stripe API?

I don't know but I'm working on an Ethereum implementation right now, and it's pretty easy.

I don't know anything about this, but how do you make randomness in Ethereum? I assume it has to replicable across any computer and therefore would be pseudo-random and predictable. Do you use something like the NIST randomness beacon at a specified future time?

Google "provably fair bitcoin lottery". They typically are based on a future block's hash value combined with a published random seed.

Here's an example: https://github.com/hmel/bitcoin-raffle

In theory, a miner could try to manipulate the hash of the future block to change the outcome. It is much more difficult with Bitcoin, where valid blocks are more rare and produce a high income, but with Ethereum blocks are so frequent that it might be possible to collude with the mining pools is done on a large scale.

Additionally, how does this deal with Proof-of-Stake algorithms? Ethereum is heading there, and as far as I am aware the blocks would no longer publish hashes.

A sybill attack would greatly increase the probability. And has cheatingly other gains.

No need for a future block. Recipient commits to the hash of a value. Payer signs a value. Hash the preimage (revealed in claim) and the signed value together. If less than a threshold, pass.

As long as neither party has any way to manipulate the hash. Should probably add a 0th step where the payer commits to use a specific signature.

The signature doesn't matter. Allowing the payer to change it only increases (potentially) the odds of them having to pay, which they won't do. In some constructions--in others it has no effect.

Ok it looks better after looking at it again. Thanks.