randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
February 04, 2015, 03:33:51 AM |
|
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/wikiTo 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.
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
February 04, 2015, 03:42:19 AM |
|
Reserved for OP.
|
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
March 01, 2015, 06:43:52 AM Last edit: March 06, 2015, 08:52:49 AM by randy-waterhouse |
|
Bitcoin Lightning Network - White paperSome 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.
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
March 09, 2015, 08:29:30 AM |
|
Some older conceptual/blue-sky work that I rediscovered Amiko pay - on a slow development cycle but worth a mention.
|
|
|
|
|
Uptrenda
Member
Offline
Activity: 114
Merit: 16
|
|
April 09, 2015, 01:13:36 AM |
|
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.
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
May 28, 2015, 08:03:05 AM |
|
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. Thanks, added. Looks interesting and useful for low trust (trustless?) transfers. When do you think you might have an implementation available for testing?
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
May 28, 2015, 10:21:44 PM |
|
Streamium added. First implementation of a pay-per-time payment channel. Looks good Source code is github linked too.
|
|
|
|
Uptrenda
Member
Offline
Activity: 114
Merit: 16
|
|
May 29, 2015, 02:55:22 AM |
|
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. Thanks, added. Looks interesting and useful for low trust (trustless?) transfers. When do you think you might have an implementation available for testing? 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)
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
June 02, 2015, 11:11:02 PM Last edit: June 03, 2015, 12:19:44 AM by randy-waterhouse |
|
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. Thanks, added. Looks interesting and useful for low trust (trustless?) transfers. When do you think you might have an implementation available for testing? 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) 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.
|
|
|
|
priestc
Jr. Member
Offline
Activity: 34
Merit: 1
|
|
June 03, 2015, 05:02:12 PM |
|
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.
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
June 07, 2015, 08:03:39 AM |
|
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. 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.
|
|
|
|
|
|
|
|
randy-waterhouse (OP)
Newbie
Offline
Activity: 41
Merit: 0
|
|
August 13, 2015, 01:08:26 AM |
|
Added Hashplex python implementation for Lightning Network routing, still needs HTLC and revocation https://github.com/utxo/wheels/wikiLooks like payment channel development is increasing rapidly now.
|
|
|
|
|