Topic: [ANN] Bitcoin Payment Channels - community reference repository (Read 3023 times)

Added Hashplex python implementation for Lightning Network routing, still needs HTLC and revocation https://github.com/utxo/wheels/wiki

Looks like payment channel development is increasing rapidly now.

Thunder Network - java implementation hub-spoke 'lightningesque' network (building on bitcoinJ's payment channel implementation?)

Thunder Network website

matsjj github code

Blockstream - Rusty Russell's strawman protocol implementation for lightning network development added.

https://github.com/utxo/wheels/wiki

New white paper added http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
"A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels"
Christian Decker   Roger Wattenhofer

https://lists.blockstream.io/listinfo/lightning-dev Blockstream lightning development mailing list added.

Not really. Payment channels give unique advantages that cannot be replicated without leveraging the multi-sig and nlocktime features of the bitcoin protocol. Your whole spiel here reeks of pushing an external agenda on a thread that has nothing to do with the discussion you provided. It is not welcome.

Facebook in 2004 didn't have the ability to handle the amount of load it gets today.

Back in 2004, Facebook's software didn't need the scale, so their software couldn't handle it.

The came condition occurs now with bitcoin micro-transactions.

The network can't handle large amounts of them, because no one has yet found an application that needs large scale bitcoin micro-transactions.

In my opinion, every single one of these "payment channels" projects are approaching the problem from the wrong perspective.

Lightning Network and Strawpay and the like are putting the cart before the horse. Even if the lightning network were to actually get built, it would just site there unused much like straw pay is just sitting there, unused today.

My attempt to bring micro-transactions to bitcoin is called autotip. Its a chrome extension that sends bitcoin to a participating website. Its kind of like a "reverse adblock" if you will. As of right now, 5 people have it installed, despite my every effort to get people to use it. Only 5 people felt it was something they'd be interested in. Part of the reason why Autotip works now is because not many people use it. If its usage were to explode, it would need to change the way it works under the hood.

Autotip takes a "usage first" approach rather than a "technical solution approach first". Its true that once Autotip gets a lot of traffic (if ever), then it will probably have to switch to using some other approach. I feel like Autotip is a square peg, and "payment channels" are all turning out to be round holes. Autotip will probably never implement payment channels.

The only project that I know of that uses payment channels is streamium. But anyone could build a live streaming site like streamium without payment channels and it would work just as well as streamium. A future version of Autotip will have a Video API (much like the current Audio API) so you can monetize videos, much like how streamium monetizes live video.

Yeah, I might be able to run some tests ... not that keen on binaries though.

I did have a question why you used 4-of-6 multi-sig escrow though: if the sender has 3 keys the arbitrator 2 keys and the receiver 1 key a valid transaction needs the sender and either of the other two to sign. Can't this also be achieved with 3-of-4 multi-sig where the sender has 2 keys and the arbitrator and receiver 1 key each?

edit: scratch that last question, I read the paper in some more depth.

Almost trustless. -Almost- The whole process breaks down trades into a series of micro-trades which means that even without any kind of dispute system - the maximum financial inconvenience is very, very, small so you can precisely reason about the worse-case scenarios for these kind of transfers (which is still magnitudes better than security outcomes for traditional systems.) But then you add in a dispute system on top of that in such a way that contracts can become reliable without becoming less secure and you have the first p2p cryptocurrency exchange that is actually practical (and not based on a huge amount of flawed trust.) There's a lot more to it than that, but that's the basic idea.

As for the release: give me some more time to hook the UI up to the exchange stuff. I already have a working prototype I just want to release something that doesn't require 100 command line switches to work.

Actually, let me know if you're interested in helping test this and I can PM you a link to a binary when its ready. (I've barely done any promotion for this project so I'm going to need testers sooner or later :p)

Streamium added. First implementation of a pay-per-time payment channel. Looks good  Source code is github linked too.

Thanks, added. Looks interesting and useful for low trust (trustless?) transfers. When do you think you might have an implementation available for testing?

You can add my paper if you like. It's a design for a peer-to-peer cryptocurrency exchange that uses micro-payment channels to transfer coins between blockchains.

Edit: wasn't aware of most of the innovations in this thread. Lightning Network looks extremely interesting.

 RustyRussell review of the Lightning network paper in 5 parts incl. summary ... exciting that multihop off-chain tx routing appears theoretically possible and scalability maybe solved by a trustless layer-2 cryptofinancial p2p protocol.

Coindesk article

Some older conceptual/blue-sky work that I rediscovered Amiko pay - on a slow development cycle but worth a mention.

Bitcoin Lightning Network - White paper

Some quite exciting claims being made in here about possibilities for secure off-chain transaction routing via multi-hop payment channels using contract-hash and nTimelock.

Edit: https://www.youtube.com/watch?v=8zVzw912wPo youtube of presentation.

Strawpay added.

Appears to be a hub model, with an implementation in the Multibit client (java, based on bitcoinJ), as per this article http://bravenewcoin.com/news/strawpay-tackles-bitcoin-transaction-woes/.

Anyone who has more info, would be appreciated.

Reserved for OP.

Hi,

I've been following developments in the area of bitcoin (micro)-payment channels about ever since the concept was first put out there. At present, the work is dispersed and there doesn't seem to be a collated repository of everything that is happening in this important development area. So I've started one.

https://github.com/utxo/wheels/wiki

To get started I've put a cache of links I've been accumulating in the wiki and will keep adding to it. It is probably not comprehensive so please submit github PR or links in this thread if you know of a payment channel project. We are now seeing enough activity that extra benefits for all can be had by having a reference repository, imo. As a nod to the hub-spoke model for payment channels it is called "wheels".

Longer term if there is development for pay-chan standards protocols or reference implementations it might make sense to host them as open source in this repo and I am happy to contribute in whatever way towards achieving that as the need arises. Also am open to any other sensible suggestions as to what a community reference repository for payment channels might be used for, protocol spec. development, security review, testing tool development, etc.

Looking forward to comments/feedback.