probabilistic payment

[zack-bitcoin]

https://www.orchid.com/assets/whitepaper/whitepaper.pdf

This paper talks about probabilistic payments to do some very cool stuff. In some cases, they are better for micropayments instead of channels.

I am thinking of doing a hard update for a new kind of spend transaction that has this probabilistic feature.

Probabilistic payments seem ideal for a lot of website sybil defense applications. Because you don't have to wait for a tx to confirm to buy credits, and you don't have to make a channel. it would be a great upgrade to the encrypted messenger system. This could be the solution to the sharing blocks altruism problem. If we use probabilistic payments to pay the servers who send us blocks, this will make the full nodes completely resistant to sybil spam.

[zack-bitcoin]

Example. Bob wants to pay Alice.

1) Alice generates a secret, and commit_alice = hash(secret). she sends the commit to Bob. 2) Bob chooses a random number. He includes the random number and commit_alice into a payment. He decides how much value to send. He signs the payment and sends it back to Alice. 3) Alice verifies that the payment is signed and contains commit_alice. There is a small probability that her secret makes the payment valid, if it does, then she puts the payment and her secret together into a tx that will spend Bob's money to her. She signs this and publishes it on-chain.

[zack-bitcoin]

I guess this doesn't work, because Bob will want to take his money back. He will be willing to pay an even higher fee to prevent his money from getting spent.

[zack-bitcoin]

It seems like solving the double-spend problem for probabilistic payments requires making an on-chain safety deposit, and specifying the only account that the money can get spent to. But if you add that feature, then it is equivalent to a payment channel.

[zack-bitcoin]

If we add these 3 tx types, it looks like we can do probabilistic payments: 1) moves some money into a new probabilistic-payment-account. 2) makes a probabilistic payment from your pp-account. 3) wait a delay after (2) before you can make this tx. This unlocks the money from the probabilistic payment. You can only make this tx if there has been exactly 1 (2) for this pp-account. 1/5th of the veo goes back to the person who created the pp-account, and 4/5ths goes to the person receiving the payment.

if multiple (2) get published for the same pp-account, then 9/10ths of the money from that account is deleted, and 1/10th goes to the miners, and the tx fees for all the (2)'s after the first get deleted. The miner fee for (2) needs to be less than 1/10th of how much money is in the pp-account.

[zack-bitcoin]

Probabilistic payments could be useful for efficiently re-filling a channel, so you can start accepting more channel payments.

[zack-bitcoin]

For an example, lets say the tx fee on a blockchain is $1, that you have $100 in your pp-account, and you want to make a payment for $2.

There is only a 2% chance that the tx will be included on-chain, so on average you only have to pay 2% of a tx fee per payment. So the tx fee for a $2 payment would be only $0.02.

If you had $1000 in the pp-account instead of $100, then the average fee would be only $0.002.

[jtremback]

It seems like solving the double-spend problem for probabilistic payments requires making an on-chain safety deposit, and specifying the only account that the money can get spent to. But if you add that feature, then it is equivalent to a payment channel.

I wasn't aware of this, can you explain more?

[zack-bitcoin]

I was wrong about that. Which is why I reopened the issue and described a mechanism that overcomes that limitation.

[zack-bitcoin]

If a group of ppl set up a probabilistic payment network, will it helps?

so, like, I would send 0.1% chance to get $1000 to you, and you would send a 4.9% chance to get $20 to the coffee shop, And you keep the extra 0.1% chance of $20 as a fee. since the probabilistic payment is based on hashlocking, it is easy to connect them together like this. It is a good idea. Maybe it makes more sense to make a probabilistic payment to someone who has a channel with the coffee shop already. And they can use the channel to pay the coffee shop immediately. connecting a channel payment to a probabilistic payment should be easy. since they are both based on the same hashlocking protocol. it is like a lightning payment. What if there are 2 tiny lightning networks, and we use probabilistic payments to settle things between the channel networks. Say I want to buy a coffee. I would make a lightning payment to my channel operator, who uses a probabilistic payment to forward the lightning to the coffee shop's channel operator. where it turns back into a normal channel payment to pay the coffee shop.

[jtremback]

What's the benefit of this combo?

[zack-bitcoin]

This combo means each consumer can think of money normally, they don't have to risk $1000 to buy coffee, like they would have to in a purely probabilistic payment version. Also the vendor can think of money normally. If they sell $1 of coffee, then their account increases by $1.

The problems with current pure-channels version of lightning are: the massive amounts of liquidity in all the channel hubs to connect everyone in the world, the trouble of routing payments, trying to efficiently agree on the correct fee for each step of the lightning payment, closing/reopening channels when they run out of liquidity.

If we use probabilistic payments, then every lightning payment has exactly 3 steps. 1) consumer to their hub as a channel payment. 2) hub to hub as probabilistic payment. 3) and then hub to vendor as a channel payment.

So there is a lower amount of liquidity that needs to be locked in channels for everyone to be connected, it only grows linearly with the number of users.

Any 2 hubs can connect with probabilistic payments. so it is a big salability improvement.

[zack-bitcoin]

If each channel hub has N channels with users, and is connected to M other channel hubs, and P is the number of customers, then I think the number of channels with a pure-channel lightning network is P(1+(M/(2N))) And the number of hops for a lightning payment is logM(P/N) The number of fees paid per lightning payment is logM(P/N) - 1.

With the combo, the number of channels is just P, there are 3 hops per payment, and only 2 fees paid per payment.

With pure probabilistic payments, the number of channels is 0, there is 1 hop per payment, and ~0 fees per payment, but each user is taking huge risk in an unacceptable way.

[zack-bitcoin]

With pure lightning, every channel operator is always watching the balances of their channels to try and stay useful so they can get fees. It is computationally expensive. They have to charge fees to cover the computation cost. Sometimes there is a scarcity of veo available for certain lightning paths. This scarcity can drive up the cost of making payments.

With the combo, none of the operators every have to care about channel balances. They can instantly make payments to any other operator. There is never a scarcity of veo in certain places causing higher fees.

Each customer has to think about their channel balance, and that's it.

[zack-bitcoin]

It looks like we can't route a lightning derivative contract through a probabilistic payment. That would put too much risk on the channel hubs.

We can use probabilistic payments as part of a lightning network doing continuous rainbow net work derivatives that dont use an Oracle.

[zack-bitcoin]

Probabilistic payments are an ideal tool for refilling a channel without having to write anything on-chain. So they will make normal derivatives in channels more useful indirectly, by making it cheaper to maintain a channel.

[zack-bitcoin]

How about mining pools use probabilistic payments to pay the workers. Then each worker could have constant cryptographic guarantees about the rate at which value is going to them.

it is nice not to have to run a full node. And small miners can set their payout to much less than a block reward. it's guaranteed fairness, yes big miners are already being paid like 1 block reward or more per payout. So it isn't about variance for them, it is the convenience of not having to run a full node. I think they would appreciate the proof of how much you are being paid, because then you could immediately know the relative expected profit of different mining pools. you don't have to wait a month and take an average.

[zack-bitcoin]

https://github.com/zack-bitcoin/amoveo/commit/67437d9774f3be564b2c628e5d231f4aa21c76b2

Here you can see I started writing the tx types for probabilistic payments.

[zack-bitcoin]

If many different probabilistic payments use a common source or randomness, then it is possible for the payment hubs to completely hedge their risks in processing probabilistic payments. Probabilistic payments make the lightning network work.

[zack-bitcoin]

For example. if you have a probabilistic account with $1000 locked in it. You could choose a source of entropy 2 months in the future. Every time you make a payment, you use the same entropy to spend a different part of the money. At the end, when there is only 1 day left, you have $300 left in the probabilistic account. That means there is a 30% chance that you have $1000, and a 70% chance that you have nothing. To get rid of this risk, you can send the $300 into your own channels. So now your probabilistic account is left with a 100% of $0. which is 0 risk.

[zack-bitcoin]

we are going with the sortition chain plan for this.