Bounding the recipient set and payment rates

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.

No implementation files, tests, or entry points are mentioned. Start by turning the proposed recipient-set Merkle sum tree and payment-rate bounds into an agreed protocol design, then define the escrow and authentication behavior that would demonstrate the design is complete.

Written by the indexing model from the issue text.