Today @insider and I had some discussion about how to deal with NanoPay with multiple receivers.
Basically we came up with 2 ways:
- let channel id = hash(channel nonce, all participants) such that the participants of a channel are immutable. Adding or removing receiver(s) leads to a new channel. Each new state update must have equal or higher amount for every receiver in the previous state.
- let channel id = (sender, channel nonce), and allow adding new receivers to a channel. Each new state update will be valid as long as at least one receiver has equal or higher amount than previous state.
Proposal 1 is easier, but the disadvantages are: 1. sender needs to know all receivers at the time of channel creation; 2. if sender accidentally add more receivers while keeping the amount not changed, these amount will be double paid to existing receivers.
Proposal 2 is more flexible, but the disadvantages are: 1. it may encourage sender to use a single channel for everything, and eventually has huge channel that is always being used and never expires; 2. it may encourage sender to use the same channel in parallel for different services, and if they happen to have the same receiver, may cause race condition.
In general, we should discourage same channel to be used in parallel as a channel is intrinsically sequential, so using it in parallel needs to be very careful and if not handled properly, will cause race condition that causes someone to lose token.
At the end, we agree that this is not something we need in the near term and decided to delay the final design and implementation to prevent premature optimization.