 Show Posts
|
|
Pages: [1] 2 3 »
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Streamium added. First implementation of a pay-per-time payment channel. Looks good  Source code is github linked too.
|
|
|
|
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? |
|
|
|
Some older conceptual/blue-sky work that I rediscovered Amiko pay - on a slow development cycle but worth a mention. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
Sounds interesting, keep us posted.
|
|
|
|
The reason I don't have a makefile is because it's not a trivial thing to compile and I'm not good with makefiles. A makefile would be nice be it's not something I want to produce right now. Anyone is highly welcome to create a makefile however. I do ask that the tree structure of the source and header files remains intact, so you'd need some sort of bash code to work through that (One thing that made me use python instead).
Still, it would be great if we could compile your library with a classic "./configure && make" I'm not good enough a GNU programmer, but if someone here is, please help. Meanwhile, I'll read the automake manual and I'll see what I can do. Anyway your project really seem like an awesome step towards a GNU version of bitcoin (C language + GNU license). Please keep up. 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. |
|
|
|
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) |
|
|
|
Well, my next task is to re-write the high-level API from chaiscript / java into C++. Afterwards, I'll start work on the QT simple GUI.
da2ce7 Coding machine <o> ... 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? |
|
|
|
|
