Topic: Payment Channel Protocol (Read 658 times)

I think that already exists, but only implemented in bitcoinj so far. This is one area for which Mike Hearn really deserves credit, as he developed it all at his own initiative. I seem to remember Gavin Andresen was very enthusiastic about it at the time.

Hi domob.

The lightning network is definitely a very cool idea and I'm really excited about watching it develop. On the other hand, reading the white paper makes my brain hurt. It's a very complex system and seems like overkill for a bunch of applications where a simple unidirectional payment channel would suffice.

At the moment payment channels seem more theoretical than practical. There are a few applications being built, but my feeling is that widespread adoption would be helped along by having a standard way to negotiate and open channels. Creating a very lightweight protocol with that goal - and only that goal - could be a step towards proving out payment channels (before lightning comes along and solves all our problems )

Take a look at the "Lightning Network" - http://lightning.network/.

Payment channels were sold as "trustless".

I still want to see an implementation that people can test and pick apart to see if it breaks the "trustless" claim.

otherwise it is all talk.

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.