Great stuff. Been interested in this personally for a while. I know BitPay is interested too.
Topic: [ANNOUNCE] Micro-payment channels implementation now in bitcoinj - page 6. (Read 29527 times)
OK, so where can we go from here? If anyone has some serious time they can dedicate to one of these projects, let me know.
The coolest next step would be a binding to the web, so any website can take advantage of micropayments triggered by JavaScript. This is a project of medium complexity, it's essentially a plumbing and UI job. It's doable in spare time but it'd have to be your main project to design, build, document and support it. I can lay out how it's done if you are serious about implementing it.
As a more experimental, easier step, you could implement a music or video streaming service as a standalone desktop Java app. I know you think they're ugly, but if you grab the JavaFX demos you'll see you can create some truly beautiful UIs using the new toolkit. It's come a long way since the Swing days.
http://www.oracle.com/technetwork/java/javafx/samples/index.html
JavaFX has widgets for playing video and audio streams out of the box, as well as an embedded WebKit, and you can then bundle up the resulting program into standalone packages for each OS (Mac users get a draggable app folder, etc). The UIs are themed using CSS and you can also use JavaScript, so it's not totally alien to web developers. All the kinds of animations you'd expect from a Mac or iPhone UI are present and easily usable, and there's a slick UI builder app too. So it's pretty nice. I wish I had more time to play with it.
Anyway, the point is that it's very easy to build a basic wallet app with bitcoinj, just instantiate WalletAppKit and off you go, so then the model is you'd send some Bitcoins to your movie player app or whatever and tell it which movie to play. Then you can pay-per-second, for instance. As an experiment I think you could get this working over a weekend. Not including the time taken to find some videos of course
The coolest next step would be a binding to the web, so any website can take advantage of micropayments triggered by JavaScript. This is a project of medium complexity, it's essentially a plumbing and UI job. It's doable in spare time but it'd have to be your main project to design, build, document and support it. I can lay out how it's done if you are serious about implementing it.
As a more experimental, easier step, you could implement a music or video streaming service as a standalone desktop Java app. I know you think they're ugly, but if you grab the JavaFX demos you'll see you can create some truly beautiful UIs using the new toolkit. It's come a long way since the Swing days.
http://www.oracle.com/technetwork/java/javafx/samples/index.html
JavaFX has widgets for playing video and audio streams out of the box, as well as an embedded WebKit, and you can then bundle up the resulting program into standalone packages for each OS (Mac users get a draggable app folder, etc). The UIs are themed using CSS and you can also use JavaScript, so it's not totally alien to web developers. All the kinds of animations you'd expect from a Mac or iPhone UI are present and easily usable, and there's a slick UI builder app too. So it's pretty nice. I wish I had more time to play with it.
Anyway, the point is that it's very easy to build a basic wallet app with bitcoinj, just instantiate WalletAppKit and off you go, so then the model is you'd send some Bitcoins to your movie player app or whatever and tell it which movie to play. Then you can pay-per-second, for instance. As an experiment I think you could get this working over a weekend. Not including the time taken to find some videos of course
If anyone intends to build a music streaming service contact me.
I had a dream of creating another internet music stream, but unfortunately I currently have no time to work on it.And of course basically any service that is billed per minute via phone today, x-rated or otherwise, would be an ideal fit. Technical support, legal advice, astrological readings, etc. It enables all those industries to ditch the phone carriers as the billing mechanism and move to Internet-only delivery and payment. I'd be curious to know what percentages the phone companies skim off the top on their per-minute numbers, if it's a large amount, then this technology becomes a compelling alternative and some bright enterpreneur could probably get funded and build a business disrupting that market.
Payment gateways should implement micropayment channels. Are there any open source Bitcoin payment gateways? 
Anyway, sounds cool. What exact use case are you thinking of? Something like video streaming where you pay a small amount every 20-30 seconds?
Not too hard to imagine the porn industry producing the first apps built on this mechanism.
And of course basically any service that is billed per minute via phone today, x-rated or otherwise, would be an ideal fit. Technical support, legal advice, astrological readings, etc. It enables all those industries to ditch the phone carriers as the billing mechanism and move to Internet-only delivery and payment. I'd be curious to know what percentages the phone companies skim off the top on their per-minute numbers, if it's a large amount, then this technology becomes a compelling alternative and some bright enterpreneur could probably get funded and build a business disrupting that market.
Geez. This is exciting! Excellent work.
So who wants to create a pay as much as you use music streaming service? Micropayments for each second of listening. Goes straight to artist.
So who wants to create a pay as much as you use music streaming service? Micropayments for each second of listening. Goes straight to artist.
What about pay per view Tube sites? What about the ability to charge for the amount of time spent on the site? This could end the ad based model.
If anyone intends to build a music streaming service contact me.
Default safety margin is two hours (see CHANNEL_EXPIRE_OFFSET in StoredPaymentChannelServerStates)
So, at any time, the server has
- fully signed multi-sig transaction (value of A + B)
- refund transaction that pays A to the client and B to the server
The client has
- fully signed multi-sig transaction
- refund transaction that pays the entire multi-sig back to the client (time locked though)
As long as the server broadcasts its 2 transactions with sufficient time before the locktime, it is guaranteed to get B coins.
The client can pay more by sending a new refund transactions with lower A and higher B.
What is the default safety margin? With a 24 hour channel, is it 12 hours "active" and then 24 hours of lock time?
Anyway, sounds cool. What exact use case are you thinking of? Something like video streaming where you pay a small amount every 20-30 seconds?
Micropayments would be cool for "like" type situations, where you can setup your browser to pay to a link. However, that wouldn't be supported by this, unless you do a two level system. Your brower connects to your micropayment service and it handles the actual transfer to the web site.
- fully signed multi-sig transaction (value of A + B)
- refund transaction that pays A to the client and B to the server
The client has
- fully signed multi-sig transaction
- refund transaction that pays the entire multi-sig back to the client (time locked though)
As long as the server broadcasts its 2 transactions with sufficient time before the locktime, it is guaranteed to get B coins.
The client can pay more by sending a new refund transactions with lower A and higher B.
What is the default safety margin? With a 24 hour channel, is it 12 hours "active" and then 24 hours of lock time?
Anyway, sounds cool. What exact use case are you thinking of? Something like video streaming where you pay a small amount every 20-30 seconds?
Micropayments would be cool for "like" type situations, where you can setup your browser to pay to a link. However, that wouldn't be supported by this, unless you do a two level system. Your brower connects to your micropayment service and it handles the actual transfer to the web site.
Geez. This is exciting! Excellent work.
So who wants to create a pay as much as you use music streaming service? Micropayments for each second of listening. Goes straight to artist.
So who wants to create a pay as much as you use music streaming service? Micropayments for each second of listening. Goes straight to artist.
Thanks, that makes sense. I'll take a closer look at the source when I can, but this looks awesome so far.
When used correctly (with a fresh ECKey for each time) it's not an issue as the scripts are run. Good question though.
This looks great! I'm working on a demo of my chained payment channel idea, based on BitcoinJ for a number of reasons. Unfortunately, it has some critical differences from your protocol which means I can't use your code. Still, after my demo is working, I'll refactor it to have a similar API to yours after I'm done with the demo (my code is very, very ugly).
I do have a possibly stupid question. Are you doing any checks to see if the input to the refund transaction is an output the server already owns, to make sure that it isn't sending its own money back in the refund transaction? Or are you getting around that some other way?
I do have a possibly stupid question. Are you doing any checks to see if the input to the refund transaction is an output the server already owns, to make sure that it isn't sending its own money back in the refund transaction? Or are you getting around that some other way?
very cool
Thank you! This will work well for faucets that use this, and micro payments in general.
Matt Corallo and I have added support for micropayment channels to bitcoinj. Micropayment channels allow you to send, after an initial setup process, very tiny payments to a chosen third party in a trust-free manner without broadcasting all the payments onto the block chain. This lets you avoid the fees and anti-flooding protections that would otherwise cause problems. The cost is a single ECDSA signature on the client side, and a single verify on the server side.
Please see the announcement, or the code here:
https://code.google.com/p/bitcoinj/source/detail?r=4908c241f7161bc5facfb85b466feba2929f2567
or the documentation here:
https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments
The documentation explains how the protocol works, the API design and takes you through the included example client/server apps line by line. As you can see it is very easy to use.
Matt did 90% of the work and deserves most of the credit, but I'd also like to give a shout out to Jeremy Spilman and of course Satoshi for their contributions to the design.
Now for some personal commentary. I'm excited by this work for a couple of reasons.
One is that I strongly believe that Bitcoin's short to medium term future lies in finding an advanced "killer app" rather than trying to compete head on with VISA or MasterCard. Whilst Bitcoin has many advantages over credit card payments, for most people the barriers to entry are high enough to keep them on their existing payment solutions. If we create a new market or application that is highly compelling and requires Bitcoin, then we give people a stronger incentive to acquire some. And once they've made the decision to get some coins for that killer app, why not get a little bit more than needed and also use it to buy other things later? To make a killer app we need things Bitcoin can do that other systems can't. Micropayments is an obvious example.
The second reason this work is important is that our community hasn't been making good use of the contracts features Satoshi left for us. Despite that many designs were documented years ago (by me on the Contracts page), there haven't really been any apps that use them. "Where are the contract apps?" is a question that came up a lot when I was in California for the conference. The cause seems to be that it's hard to understand how to turn the high level descriptions on the wiki into working code. The micropayment channels code in bitcoinj now gives us a worked example from beginning to end - you can read the theory, read the protocol description and then see it how to translate it into a real, working system that manages all the fiddly details. Now we have an complete demonstration of how to turn a contract design into reality, I hope we've cut a road through the jungle that others can follow.
If you're interested in building a contract app, please do consider building on bitcoinj and feel free to ask us any questions on the mailing list. We're happy to help.
Please see the announcement, or the code here:
https://code.google.com/p/bitcoinj/source/detail?r=4908c241f7161bc5facfb85b466feba2929f2567
or the documentation here:
https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments
The documentation explains how the protocol works, the API design and takes you through the included example client/server apps line by line. As you can see it is very easy to use.
Matt did 90% of the work and deserves most of the credit, but I'd also like to give a shout out to Jeremy Spilman and of course Satoshi for their contributions to the design.
Now for some personal commentary. I'm excited by this work for a couple of reasons.
One is that I strongly believe that Bitcoin's short to medium term future lies in finding an advanced "killer app" rather than trying to compete head on with VISA or MasterCard. Whilst Bitcoin has many advantages over credit card payments, for most people the barriers to entry are high enough to keep them on their existing payment solutions. If we create a new market or application that is highly compelling and requires Bitcoin, then we give people a stronger incentive to acquire some. And once they've made the decision to get some coins for that killer app, why not get a little bit more than needed and also use it to buy other things later? To make a killer app we need things Bitcoin can do that other systems can't. Micropayments is an obvious example.
The second reason this work is important is that our community hasn't been making good use of the contracts features Satoshi left for us. Despite that many designs were documented years ago (by me on the Contracts page), there haven't really been any apps that use them. "Where are the contract apps?" is a question that came up a lot when I was in California for the conference. The cause seems to be that it's hard to understand how to turn the high level descriptions on the wiki into working code. The micropayment channels code in bitcoinj now gives us a worked example from beginning to end - you can read the theory, read the protocol description and then see it how to translate it into a real, working system that manages all the fiddly details. Now we have an complete demonstration of how to turn a contract design into reality, I hope we've cut a road through the jungle that others can follow.
If you're interested in building a contract app, please do consider building on bitcoinj and feel free to ask us any questions on the mailing list. We're happy to help.
Jump to: