Bounding the recipient set and payment rates

[yondonfu]

Within the Livepeer network, we already have a bound on N because the number of registered orchestrators on the network is always known.

We can bound W by having a recipient i define a time window with an associated max payment rate w_i. During each time window, the recipient is only willing to accept tickets from a particular sender until it receives w_i macropayments from the sender. If a sender hits this limit, the recipient stops accepting tickets until the next time window. The declared w_i might reflect a recipient's willingness to take on risk.

Chiesa et. al present an interesting idea in the form of recipient address set Merkle tree for each penalty escrow

• When a sender creates a penalty escrow it also submits a commitment to the recipient set that the sender intends to work with. When a sender interacts with recipient, the sender first proves that the recipient is included in the recipient set commitment for the sender's penalty escrow and that the value of the penalty escrow is at least the total sum of all max payment rates of the recipient set.
• The commitment is constructed as the root of a Merkle sum tree over the recipient set. The leaves of the tree contain the address of the recipient and also the recipient's max payment rate. Each node in the tree stores the sum of the max payment rates stored in its children such that the root of the tree stores the sum of the max payment rates of all leaves in the tree.
• When a sender connects with a recipient, the sender provides the Merkle authentication path for the recipient's address and the recipient checks if the max payment rate stored in the leaf corresponds to the recipient's actual declared max payment rate. Once this proof is verified, if we assume that all other recipients only work with a sender if provided a valid authentication path for this root, then the recipient knows if the sender works with n recipients then there are n valid authentication paths and the root contains at least the sum of the max payment rates for the n recipients. The recipient can verify that the sender's penalty escrow is >= the value in the root. A sender could try to to make the value in the root smaller by making one of the max payment rates in the leaves smaller than the actual declared value. If we assume that the recipient for that leaf will refuse to work with the sender since the max payment rate in the leaf is wrong then it is fine that the value in the root is inaccurate because the value transacted with this particular recipient will just be 0.

[eladmallel]

Very interesting approach with the Merkle tree commitment. Do I understand correctly that such an approach poses a limitation on how often O can update w_i for a specific B? - since every such update would require communication with B and for B to update the commitment tree on-chain?

[yondonfu]

Yeah you could allow O to update w_i on-chain once at the beginning of each round which would allow B to update its receiver set commitment once per round. This is pretty restrictive though so I'm interested in alternatives such as O enforced pre-pay policies (B has to send some number tickets up front before receiving any transcoded results) which are relaxed over time if some amount of value is transacted by B as a complement to the use of a penalty escrow.

[eladmallel]

How does pre-pay help bound W? - I don't see how it mitigates risk, unless coupled with frequent ticket redemptions.

Can you elaborate on how pre-pay mitigates W without assuming frequent ticket redemptions?

[yondonfu]

Pre-pay doesn't help bound W. But perhaps in the absence of a bound on W (because it might result in very high penalty escrow requirements if B wants to work with many O), this could complement the existence of a penalty escrow as it does increase the the risk for B for the following reasons:

• O can drop out and B doesn't receive any transcoded results
• More tickets that are sent out can reduce the time it takes for a winning ticket to be sent and in the case of double spends this would decrease the time it takes to detect a double spend

A B might face a stricter pre-pay policy if it has transacted zero value with O. As the amount of value transacted with O increases, the pre-pay policy could be relaxed. So, if a malicious B wants to improve its ability to double spend it would first have to transact some amount of value with a set of Os before it can effectively double spend with that set of Os. If a malicious B double spends at this point and has its penalty escrow slashed then all Os would ban the offending address which means the malicious entity would have to start fresh with a new account in order to start double spending again which also means it faces stricter pre-pay policies again. The goal here is to add another cost to double spending because you have to re-build reputation once you get caught double spending once.

This assumes ticket redemption either immediately upon receiving a winning ticket or at least within some bounded time after receiving a winning ticket which is enforced by a ticket expiration time. I think this assumption is fine for an initial version.