Has there been any consideration to a payments channel protocol - something like BIP70, but designed to signal and negotiate a new payment channel rather than single transactions?
Payment channels seem like a killer app for bitcoin - something that just hasn't been possible before a decentralised trustless currency existed. Most people on the forum probably understand the basic mechanics of setting up a payment channel (see Mike Hearn's original description at
https://bitcoin.org/en/developer-guide#micropayment-channel or
https://en.bitcoin.it/wiki/Contract#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party if you're not familiar with the concept). There's really interesting work going on in payment channels, for example
https://streamium.io/ and
https://www.bitmesh.network/ , but as far as I can tell, there isn't a standard way for a service provider to signal to a client that they want to set up a payment channel and exchange the information required for that channel to be set up (eg bitcoin addresses, bond amount, nLockTime, payment frequency, payment amount). Would a standardised way to signal this be helpful for getting payment channel projects off the ground? Would it help streamium, for example, if wallets could natively understand payment channels and pay for streams?
I've been really interested in payment channels for a while, but this is my first post to bitcointalk. Apologies if this has already been covered before - I've had a search through the forums but couldn't find anyone else suggesting this as a way forward for payment channels. I've already spent a lot of time thinking about what a protocol should look like and will be happy to flesh out the details in the comments below, but wanted to gauge interest before writing everything up.