very cool idea, haven't seen anyone think about this yet. generally, unidirectional channels make everything a lot easier.
here is how it might work with the current protocol:
- user A wants to open a channel to tollgate B with 1000 sats capacity
- user A obtains B's public key
- user A mints a 1000 sat coin with 2-of-2 multisig and SIG_ALL signature flag that requires signatures from and B also on the outputs
- outputs are the BlindedMessage's that are created when this coin (input) is swapped with the mint
- thus, the outputs determine the channel state (distribution of funds), so to make payments, we need to update the outputs and sign them again
- to open the channel, the initial state is A=1000 and B=0 (sats), A signs both, the input (the coin itself) and two outputs (the enforced distribution) and sends all this to B.
- B signs the input+outputs as well. now B could close the channel.
- to make a 10 sat payment, A creates new outputs A=990 and B=10 and signs them, sends them over to B. now B can enforce the new state.
- when they're both done with the channel, B can close the channel with the latest state (the one where she gets most).
some notes:
- after closing the channel, B should be nice enough send A her remaining channel balance after /v1/swap'ing them and receiving new BlindSignature's. B can't use these BlindSignature, only A can unblind them. if she isn't nice, A would have to /v1/restore the BlindSignature's.
- B should never send back her signatures to A, otherwise A might close the channel with an earlier state.
- to allow A to close the channel uncooperatively (in case B stops operating for example), the initial coin can have a second "refund" spend path with a time lock which also determine the channel's maximum lifetime.
I just sketched this out after reading your post, so there might issues or better ways of doing this. you can checkout spillman channels, they are much simpler than the lightning channels we're using today. but I think the idea above here is pretty close to how they work.
