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.

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.

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?

 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.

Sounds interesting, keep us posted.

I already offered to do this (would take about a day) but he wants to keep the existing directory layout which would be PITA for any automake set-up ... so probably have to stick to his python hack make until he can change that.

What did you have in mind in particular ... there is a lot of sample user data data out there demonstrating server contracts, asset contracts, mulitple Nym wallets, basket currency contracts and etc ...

E.g.
https://github.com/FellowTraveler/Open-Transactions/tree/846a9398ea5326df9eaa2c162d3dcc8a0934e184/sample-data

Meaty stuff isis .... gonna take some ruminating.

As a first blush .... so it is going to piggy-back onto bitcoin network to broadcast "OPEN" tx requests that then get transformed into bitcoin Tx's by the targetted node that has the required keys to sign the bitcoin tx .. and then rebroadcast on bitcoin network proper?

Just a guess here, but I think mainline will resist this ... but should be enough incentive here for many users to adopt it regardless ( I wonder about how many "OPEN" enabled nodes you are going to need for security considerations)

da2ce7 Coding machine ... I can probably do the port/build on linux OS's, (maybe some docs and integration stuff install scripts, etc if needed.)

- What financial functions are we going to give Granny's GUI?

- How shall we split the loot up?