This is a really interesting idea, and also stimulates some broader thoughts about our payment channel(s) and fee structure. I’ve argued previously that compensating Ursulas (= workers, stakers, nodes, proxies) based on only one of a. policy duration or b. re-encryption requests, leads to various problems – see https://github.com/nucypher/mint-paper/issues/7. In short, there is a risk of abuse if Alice and Bob are separate end-users with distinct, discretionary economic motives, and there isn’t a prevailing application layer channeling funds between users. Moreover:
- If Ursula is only paid when re-encrypting (or some % of them), but Bob issues very few or no requests over the course of the policy duration, then they will spend resources (the vast majority of overheads, in fact) maintaining an available policy/state, but receive little or no compensation.
- If Ursula is only paid for holding a policy, then this doesn’t help address the uptime problem. The infrequency with which an Alice would pay for a 3 or 6 or 12 month policy also makes probabilistic micropayments unnecessary and unsuitable.
Therefore a hybrid approach, where Alice pays once for the persistence of the policy, and Bob probabilistically pays for each re-encryption, might be a happy medium.
In this flow, Ursula accepts an Arrangement based on the (standardised) cost of being online for the policy’s duration, which is entirely covered by Alice’s deposit up front.
Later, Bob pings Ursula. Ursula checks he has sufficient funds (see verification point below), then commits to some random numbers. The rest of the process mirrors jMyles’s proposal above. This disentangles Bob from Alice, where he is no longer restricted by the ‘punch’ bestowed to him, and can request re-encryptions as many times as he is willing to pay for (and collateralise).
Some general points about probabilistic micropayments applied to the NuCypher network, regardless of the viability of this counter-proposal:
- Ursula needs the ability to verify that the payer (whether its Alice or Bob) has enough funds to cover the situation in which ALL of the winning tickets are redeemed – i.e. for all their current policies or requests, and for all n Ursulas with whom there is presently a commercial relationship.
- The risk remains of Ursula receiving the capsule and random numbers, withholding the CFrag, and proceeding to claim payouts. I have some thoughts on this, will summarise in another post.
- In terms of sourcing randomness, why not use something akin to LivePeer’s approach:
Winning tickets are selected based a random value produced by hashing the payer’s random number with the payee’s secret random number.