Bitcoin Forum

Matt Corallo and I have added support for micropayment channels (https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party) 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 (https://groups.google.com/forum/#!topic/bitcoinj/H23FXOFyF4A), 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.

Thank you! This will work well for faucets that use this, and micro payments in general.

very cool

I'm super excited about contracts, and I'll be hoping to implement a lot of this in future.

Just commenting on one point.  I think bitcoin already does have a 'killer app' and that's person to person payment.

Bitcoin's short to medium future relies on scaling it to a wider audience.  New features do this too, but contracts are likely to fill a niche rather than, say, increase usage/liquidity by an order of magnitude.  But I'd LOVE to be wrong about that last statement.  KUTGW! :)

This looks great!  I'm working on a demo of my chained payment channel idea (https://bitcointalk.org/index.php?topic=152334.0), 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?

When used correctly (with a fresh ECKey for each time) it's not an issue as the scripts are run. Good question though.

Thanks, that makes sense.  I'll take a closer look at the source when I can, but this looks awesome so far.

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, 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.

Default safety margin is two hours (see CHANNEL_EXPIRE_OFFSET in StoredPaymentChannelServerStates)

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.

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.

I had a dream of creating another internet music stream, but unfortunately I currently have no time to work on it.

Payment gateways should implement micropayment channels. Are there any open source Bitcoin payment gateways?

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 :)

Great stuff.  Been interested in this personally for a while.  I know BitPay is interested too.

This is brilliant.

Until now, my working assumption for how Bitcoin will be adopted has been:

1) Disrupt an existing industry (my bet is/was international remittances) by providing an existing product/service cheaper and/or better

2) Once a foothold has been established, deliver products/services that would have been impossible with other technologies (likely building on contracts/transaction scripting or colored coins).

This announcement could well short-circuit step one.

I'm looking forward to playing with it this weekend.

This is really good!

We have to find business models that are not requiring people to rethink (as they do so very slowly), but create an offer that was not possible before.

Congratulations Matt and Mike.

Here's my "killer app" idea.

Gnu Poker

A poker client that anybody can download and install on any OS. It's decentralized, so no private company takes any rake, and no government can shut it down. Players can sit at a table with X amount of bitcoins, and the bitcoinj shuffles the balance around constantly until one of the players sits up, or when the tournament is finished.

In other words... GLOBAL    UNSTOPPABLE    RAKELESS    INSTANT PAYOUT    POKER

That's called mental poker and it's an active area of cryptographic research. It turns out to be really hard to do correctly (so nobody can cheat). Especially if you want to avoid people playing against themselves.

This is awesome -- looking forward to seeing where this could fit into my own project (micropayments to satire authors). Thanks for all the hard work!

Ahh yes, I've heard it called that before. It's nice to see you say that it's an active area of research. I can't wait until it's under development. If that app ever comes out now, there are millions of poker players worldwide who would be scrambling to get bitcoins to play.

Mike and Matt, we are all very excited for this new feature. Great job and thank you for continuing to push things forward.

Suppose the client for micropayments is written in javascript.  Somehow the javascript needs to bind to the java client, probably via applet or an installed desktop java app to communicate to the micropayment server.

I am wondering if it would be possible to port the java client code to javascript so it can talk directly to the micropayment server, perhaps with websockets.

Nice work.

So, reading https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party I don't understand what prevents double spending of the input used to fund T1.

T1 redeems an input that is sent to an output requiring both the server's and the client's signature to redeem. But what if, when the exchange is over, and I've gotten what I wanted from the server, I send out a new transaction that redeems the same input redeemed by T1, but with a higher fee to miners, that sends all coins back to myself?

In other words, what is it, in essence, that makes this any different from just showing the server a transaction that sends coins to an address that belongs to the server? And rapidly updating this transaction?

Yo that's off the chain!  :D

This has interesting, and probably negative, implications for the Color Coins project.

great work though!  -bm

The time-locking makes it possible for both parties to work trust-free.

So if the session gets initiated with one day time lock, the first transaction sending all the money to the server may not get used as the input to send it all back within this one day, but both parties sign an "all returns" transaction in the beginning. Apparently bitcoin protocol supports a "sequence number", so the highest sequence number wins and both parties are allowed to provide a higher sequence number (signed by both parties) within the time lock. Ingenious :)

(So this is not a real micro-payment in the sense of a service collecting satoshis from many clients but the service could collect *increments* of satoshis from many clients each paying some dollars in the end, which is really really great.)

Satoshi dice should use this! They would save tons of fees and reduce spam for all of us.
I'm so excited!

… maybe not possible … hmm …

Using this technique in smart meters, an electric electric company could implement realtime demand pricing and adjust the payment once per minute but only actually transfer Bitcoins on the blockchain twice per month per customer.

Pretty awesome work. Now that something is working, will this be added to the regular client at some point? Many people specifically want to do micropayments, so it would be nice if this was standalone and had some wrappers.

Now, can this be adapted to support altcoins like Litecoin and PPcoin? Then we are really onto something.

I completely agree with this. I just suggest that the code be open enough to have a plugin or extension mechanism so altcoins can be plugged into it as well. I like Bitcoin but this is too important to be Bitcoin exclusive.

Anything which benefits the cryptocurrency economy as a whole is better than just benefiting Bitcoin.

It's not bitcoin's obligation to help alt-coins to keep pace. If you are into litecoin, proof they are worth something and that they are not just some scam of some greedy people envy of the early adopters that took all the risk to push bitcoin to what it is now. If something proofs to be essential for a modern crypto currency, bitcoin will adopt it from the alt-coin or die. Not the other way round.
Edit: ooops. bad quote.

There are a couple of misunderstandings here. The first one is that T1 is broadcast at the start of the negotiation, so it gets confirmed like any normal transaction. The second is the belief that you can replace transactions by sending another one with a higher fee. That's not how Bitcoin works.

Re: alt coins. If they're similar enough to Bitcoin then the protocol and code will just work.

Re: integration into clients. It's something that you use to build other apps really. Having it directly exposed to end users in wallets doesn't make a whole lot of sense. However, wallet apps can certainly re-expose the API to other apps that don't want the hassle of actually being a wallet themselves.

SatoshiDice uses micropayments as a form of messaging. This work doesn't have any impact on that, the payment protocol is the solution to what they're doing.

Oh, I hadn't caught the first point. So does this mean that the setting up requires T1 to be in the block chain?

With regards to your second point, the answer is that miners can do this, if they want to. The protocol can't enforce this. The Satoshi client can default to ignore subsequent transactions spending the same input, but it can't be enforced in any way, and so it's not wise to build services that rely on this. If this were the case we wouldn't have to worry about double spends in the first place. But if I understand your first point correctly, this isn't what your implementation relies on anyway, so it's not relevant here.

Great job by the way! :) Both to Matt and you. This is one of the things that has so many possibilities that it's mind blowing!

We disagree. I don't see Bitcoin as a product, I see it as an algorithm and a community. The meta community is based around the shared interest in the success of cryptocurrencies, but Bitcoin is just one brand and product. The sourcecode is more important than the brand, and if you really believe in the goal of what Bitcoin sourcecode is trying to do then you'll support other algorithms which are trying to achieve the same goal.

This is the difference between how a theorist thinks and a businessman. You're thinking of Bitcoin strictly as a business while I'm thinking of it as elegant code. If Bitcoin competes with Litecoin and PPcoin for "marketshare" or = whatever to the point that the marketcap for all cryptocurrencies can't grow then in my opinion that kind of competition is bad.

Should we think of the search engine as math or as Google? I think of search as math, as code, as an algorithm to organize information which Google happened to monetize and capitalize but I don't think it's good for the community or economy or the mathematics for there to only be one algorithm, one supported design, one business model, with no variety or competition. Imagine if the US government had only one political party, what do you think could happen?

I'm familiar with this argument. I believe it's misleading for a variety of reasons, but here isn't the place to get into it. Regardless, the chain of transactions can be risk analysed as any other and if you want to wait for confirmations, the client or server can certainly do that. The example apps don't wait though.

I want to build a service that enables that. I heard you're a good UI developer ;-)

Impressive work guys!  Watching Mike's 2012 talk on youtube was what really got me excited about bitcoin again and I'm glad to see such amazing progress in making these concepts a reality.

I'd be delighted if someone could elaborate on how things change once transaction replacement is turned back on.  From what I've gleaned there's a risk of the refund transaction being modified and broadcasted but I don't understand how this could happen before the locktime and without the server resigning the inputs.  What exactly is the caveat with this implementation and transaction replacement?

Thank you very much guys! This has the potential to significantly advance how we buy and sell services and is something that was not possible before Bitcoin. Very exciting.

I am really interested to see use cases where these micropayments work in the other direction... Considering that micro-payments start with a contract between two parties (a service and a client), a service providing distributed computation could in effect pay a commission to clients that contribute processing power.

In this way the computation doesn't need to be aligned to a particular hashing algorithm or specific hardware. The computation likely isn't time sensitive so anyone could participate, and their effort wouldn't be wasted. Pricing could vary, but could be as simple as 1 satoshi per Hz per second...

It doesn't even need new infrastructure to implement. WorldCommunityGrid.org could release an updated client that sets up a Bitcoin address for payment, provides you with the private key, and on their server they run BitcoinJ to facilitate the micropayments.

Any other novel use cases where services pay clients using micropayments?

This is a brilliant idea. WRITE A WHITE PAPER.

Great ideas guys, keep them coming.

Re: renting computation power. Check out Pinnochio (from Microsoft Research) and related work to see how one might distribute a computation over untrusted nodes, with payment for their CPU time. It's not really usable yet but they're making great progress. Trusted computing is an efficient stand-in but most people don't have the right setup.


Re: differences with tx replacement enabled, check the wiki. Protocols that work with and without are described there. If we had tx replacement working again, the protocol would get more flexible - for instance the amount of money sent on a channel could go up as well as down, so you can have N-way negotiations instead of the 2-party increment-only design we have today. Unfortunately reactivating tx replacement is the sort of hard, grungy work that requires an experienced C++ programmer with time to burn and they are extremely hard to find.

Re: porting to JavaScript. You really don't want to do that. The right approach is to have wallet apps listen on a localhost socket and then export the PaymentChannelClientConnection class over RPC. A browser extension can inject a JavaScript API into the page and convert calls to it into RPCs to the wallet, whilst doing things like enforcing the same origin policy and exporting cookies to the wallet so it can re-establish client identity when the micropayment connection is established. Like I said, anyone who is serious about doing that, please do ask and I'll lay out how I'd implement it.

So... if I understand things correctly, what this announcement provides support for is the following scenario:

* We have a single consumer and a single producer of a service, neither of whom trust the other
* The service can be consumed in increments (e.g. bytes downloaded, power consumed, pints drunks) such that, at any point in the consumer/producer relationship, value has been transferred
* The requirement is to bill the consumer broadly simultaneously with that consumption: i.e. they don't pay for what they haven't yet consumed and the producer doesn't provide that for which they haven't been paid
* This is distinct to the scenario where a consumer wishes simply to make a "small" one-off payment for a product or service
* It is also distinct to the scenario where a consumer wishes to consume a service incrementally from a collection of producers
* It is also distinct to the scenario where value is only really transferred if the service is consumed in whole (e.g. download of a binary executable... 99% complete is worthless).

The system works through a two stage process:

1) The consumer publicly places some value into what amounts to escrow. In the absence of any further action, it will revert to the consumer after the expiry of some time
2) As the service is consumed, the consumer privately sends transactions to the producer, any one of which can be used by the producer to claim some portion of the locked-up value. To the extent that the consumer sends valid transactions commensurate with the value of the service they are consuming, the producer continues to provide the service and defers publication of the transaction.   At the end of the exchange, the producer publishes the highest-value transaction (from their perspective) and the remainder reverts to the consumer.


Assuming I've understood it correctly, then a particularly compelling use-case is the store-credit/stored-value scenario.  Consumers think nothing about tying up non-trivial amounts of value in store-cards, public-transit pre-pay systems or pay-as-you-go telephone cards... and so the requirement for precommittment/escrow would not be alien.

All of those areas meet the "single consumer, single producer, incrementally consumable service" requirement and so are potential areas this innovation could be applied.

The value to a consumer, of course, is that the counterparty risk (especially with store credit) is huge -- and consumers are aware of it.  There have been many high-profile cases of consumers losing money as a result of retailer bankruptcies in the UK.    This approach would overcome that.

Yep, you got it.

I think selling internet access through private wireless access points using Bitcoin micro-payment channels, as discussed by Mike in a recent talk, is a great application. A couple of days ago there was an announcement that Fon would accept Bitcoin, but that has now disappeared again. It also has overlap with Meshnet and Hocnet. Once you have a sizeable number of smartphone users with an app for this installed, and a sizeable number of homes with compatible wireless access points, additional privacy features such as those needed for Hocnet and Meshnet could be added. But getting the money to flow is probably the top priority.

This would definitely be exciting. But as far as I understand, a consumer Internet bandwidth cannot be leased out legally. The contract forbids it. But it still has a huge potential, because you could simply buy bandwidth that does allow this, and sell it at a premium, thus staying within the terms of your contract, but at the same time making a profit, and providing a valuable service to clients.

I can only imagine this working in hotels, malls or airports, where existing wifi is ridiculously overpriced.  So anyone with a mobile data plan would just sell their spare bandwidth (violating their contract, of course, but it'd be hard for the mobile provider to catch them). 

I mean, hotel/mall/airport wifi is overpriced on purpose, it's a monopoly.  They are not going to just let you walk in, set up shop, and eat their profits.

This is not going to be a public facing business in the vast majority of cases.

I can imagine it working in a lot of places. Wireless equipment isn't that expensive any more. You can get a NanoStation Loco for $50, with 10 km of range (http://www.ubnt.com/nanostationloco). I'd imagine a lot of network geeks would be interested in reselling bandwidth purchased for this purpose. It's a win-win situation. The ISPs earn extra money by selling bandwidth to individuals, who resell it to consumers, thereby taking a piece of the 3G/4G pie that telcos have.

The real disruption will come if they regulatory bodies open up more frequencies that allow wall penetration. Then hotels/airports will really have a hard time maintaining their monopoly.

In any case, airports have the right to prevent you from reselling bandwidth on their property. But they don't have the right to prevent you from sending signals that traverse their property.

I would like to take this to a ridiculous extreme for illustrative purposes. Let's say I am a writer and get paid by the word. Software could be written that reads my word total at random intervals and pays me a weekly percentage of the word total of each interval scanned for my expenses, and as an incentive to finish. This would be a way to cultivate new writers to improve their skills. As their productivity improves, their percentage could be raised and eventually bonuses earned. Maybe this isn't a good business model, but the principle applies to possibly hundreds of transactions over time with little in the way of transaction fees.

This is great news! Good job guys.

Amazing you guys have just gamefied réal life, bitcoins by achievement, incredible.

How do you avoid transaction malleability?

https://en.bitcoin.it/wiki/Transaction_Malleability

Does this not mean that even if you have a signed refund transaction, it is possible for the funding transaction to be changed, such that the refund transaction is now invalid?

Or is this just not a concern?

good point. While I'm slightly surprised to read about transaction signing not covering the whole transaction which sounds like a huge design flaw now, changing the hash sounds spooky to me, too.

*EDIT* Please ignore this. Now I get your point with the Transaction Malleability.

Bitcoin keeps adapting and growing  ;)
Thanks for all the hard work

It seems like it's something that is not likely to be a huge deal and you can only be spite exploited by it.  Say your funding transaction gets modified for some reason and that changes its hash- it's not like the server can spend it all.  It just makes your refund transaction invalid.  So the money is stuck in a joint account until a new refund is created.  The server could just laugh at you and you'd be out the money, but it doesn't seem like they get any real benefit out of it.  They could hold it hostage in a malicious case, where they refuse to sign a new transaction unless you give them half or something similar, but that would wreck their reputation and likely you would prefer to have smaller transactions to the server anyway, and if it fills up, send another one.

Malleability of transactions seems annoying to me and prevents a lot of pure trust-less applications from being rock solid. 

The poker application did sound interesting.  However, I'm not sure it's practical to do this - any time the table composition changes, you need to have some kind of new funding transaction and finalize a refund to that player.  The shared wallet would change due to different public keys, meaning you pretty much need to start from scratch every few minutes whenever someone leaves or joins (which can happen often in cash games).  I suppose you could have a system where a central server that runs the game just sets up separate channels for each player.  Whenever that person makes a bet, money is removed from the refund.  You'd also likely have a "bank" that has another input (refund transaction takes an input from the player and one from the house, and the one from the house would have to equal the amount money each player has on the table up to what the player has).  Whenever a player wins a hand, he gets money put into his account, and whenever he bets, it gets removed.  Transactions are updated, and timestamped, and when he leaves the table, the transaction is finalized.  This requires a significant amount of money for the server to put up, which seems suboptimal, but at least better than the alternative of having to keep submitting a transaction any time someone joins or leaves a table.  I'm not sure this solves a problem better than having a site that just holds money for you.  Then again, with hacking issues of some sites and seizure issues, this might be safer.

Non-canonical signatures are being rejected by the network these days, and the implementation in bitcoinj will reject any signatures that are passed over the protocol which are non canonical. So I am not sure there is a way for the server to maliciously modify the multisig contract - it would become non-canonical and fail to relay. It's not a hard forking rule (yet) so some miner could still pick up a modified form, but as you note, there isn't much incentive to do that.


Quite apart from how you manage the money, dealer-free cryptographic poker is a highly challenging problem. And even if you succeeded you have no way to prevent cheating. Centralised sites rely on lots of proprietary heuristics to try and keep cheating to a manageable level, even so, they cannot do a great job given the amounts of money at stage. But if you take away the central authority, you also take away the option to use secret rules of thumb and arbitrary eviction of players.

I admit though that I've never understood the appeal of online poker.

Seems to me "micropayment channels" is somewhat of a misnomer. I belive the whole idea behind micropayments is to allow small payments for random publishers with which you don't have or need to maintain a relationship. Think random browsing, some pages costing 5c to view. At current fee levels the bitcoin network is perfectly adequate for this, although if everybody would do it the block limit will be hit and the fee would increase.

This is a trust-free incremental settlement system and does not really solve the core micropayments problem: fast and cheap transaction to random publishers. You will tell me someone can use this system to implement micropayments that publishers can leverage, and the user needs to do a single setup transaction with that centralized system. But in that case I really don't see Bitcoin's edge. Paypal could cover that market much better since they are better positioned in terms of market and mind share. Publishers care about their 5c and will implement the system that brings home the bacon, regardless of what currency it uses in the background.

(There are of course applications for this as explained in the thread, but "micropayments" ain't it).

TLDR: Hey middle-man! If you show me that you increase the producer's balance by 1ct. referencing my transaction of 1.01ct to you, you may keep the 0.01ct for your service as with this I can request the service to unlock the paid content.

Long version:
Paypal is not trust-free. They are known to freeze your money just for you trusting them to hand it over to somebody else.
The system proposed here almost allows a middle-man to set up a gateway that is trust free although it would need some more bits:

Think paypal. How would it work with Bitcoin and trust free?
You could have one micro payment channel going from the consumer and one to the producer. These could be linked through a similar contract, so the transaction update consumer -> paypal also references another timed transaction that  gets only valid if any other paypal -> producer transaction also gets updated.

My browser would increment my payment to a gateway address only if they show me a transaction that references my unsigned transaction in increasing the earnings of the website I'm just surfing.

This way I would have two transactions – charge and finalize – per month with some middle man and the middle man would have such two transactions with producers and would never hold any party's money.

Oh, we need a standard for something like that :) I want something similar to bitcoin:.... adressses that cover this:
bitcoin:middleman=[address]&middlemanfee=50&target=[address]&targetfee=50000.

now the website would have a service running that sees the transaction from the middleman referencing the transaction that I can show them to authorize my access. I would not show the full transaction as I wouldn't want it to be published yet but that should not matter for that fact.

(I'm afraid this does not come over very clearly as it's only now forming in my head but I'm 100% sure you can extend the micro-payment channels to some two step scheme that works trust free multi point to multi point. As non-public transactions are involved you need a middle-man to keep track of these and sign them and of course such a middle man would want his share for keeping the box running but it could be standardized and made available with the standard client, so a lot of competition minimizes the profit they can aim for. Sure, producers and consumers alike would not want to use yet another such middle man but as each such middle-man relation apart from the fees they charge on top only costs 2ct for the two transactions per month, it's not much of a deal to integrate 10 of them if you want to micro-pay 10 pages that all picked distinct such services. The bigger problem would be the money that's locked up for a month like that but I guess this will all be very seamlessly handled by the clients in the future.)

The producer would in fast succession sign that each of these consumers' transactions actually increased his balance and to finalize the deal the middle man could even remove the last consumer as the producer would happily sign this finalization again. Same with the consumers, as they might not want the public to know even the last service they consumed, the middle-man could cut out this bit of info and update the transaction to a wiped version. The public would know that the middle-man got money for no apparent reason and likewise sent money to the producers for no apparent reason and apart from the middle-man (and the parties themselves) nobody knows who consumed what in which quantity.

(P.S.: Regards to all that put the TLDR in the end of their posts hoping people read their long post first. For me a TLDR is an abstract people should read to decide if they want to read the full article, not a summary to sort stuff after reading a long article.)

A problem with this scheme would be a DOS vulnerability. If the consumer negotiates the deal but denies or delays the signature, the producer would either have to build on the prior level of negotiations between the middle-man and him with the next customer (risky-ish), wait for the signature with a timeout (blocking. that's a no-go in almost all scenarios) or negotiate a new channel for as much parallelism he needs (costly-ish. has to be implemented for client and middle-man and results in multiple channels between one provider and one middle-man). The good news is that protecting against this type of DOS-attack would justify to charge a higher premium for the middle man.

Yes, that's why we call them "micropayment channels", or rather, that's why I called them that and the name has stuck. Channel is a very overloaded term in programming but it gets across the basic idea of a straight line along which things flow. With transaction replacement you can actually have more creative setups, but we'll need to do some anti-DoS heavy lifting in bitcoind for that unfortunately.

The name is misleading for another reason. There's no reason the increments have to be micro. They can be of any size.

For the case of web browsing, we already have the middlemen actually which are the ad networks. It's quite feasible to set up channels to each ad network you encounter as there aren't that many of them, and then increment a payment to them for each ad impression that you don't see. They then take care of aggregation and dispatch of the final payments. A micropayment channel to each website is also possible but more complex and isn't doable with the implementation we've released.

this  is great work!

is there a technical reason channel expiration time is always one day? monthly contracts are extremely common IRL and allowing them would allow for lot of potential use cases. plus entering passwords every day is a bit inconvinient in some cases.
btw, arent mining pools essentially getting a metered service from their miners? unfornutely this doesnt seem to work with using a single transaction to pay all miners, but it could still be a way to pay especially powerful miners without either requiring a lot of transactions or a lot of trust.

I think that is just the default.

The longer the timeout, the longer it takes to get a refund, if the service goes offline.


The pool would have to tie up lots of bitcoins.  They already effectively do it with the various payout systems.  Rather than paying out from the coinbase, they set a minimum payment and pay at once.

It would eliminate the need to trust the pool though.  OTOH, the pool would have to tie up lots of coins for each channel.

If we re-enabled tx replacement then both sides of the connection can close the channel, so you would only have to tie up money in the sense that if you want to spend the refund amount you broadcast the current best tx and then immediately respend it again to create a new channel. We need some changes in the bitcoind mining code to let it include entire chains of unconfirmed transactions simultaneously to make that work nicely, plus of course tx replacement, but it's quite feasible in theory.

What's also possible is multi-party channels. You can start with a 2-of-m multisig contract and then have multiple outputs which are incremented independently. Of course you have to trust that the other parties will not collude against you.

Yes, the one day value is just a default. It should be exposed in the API but presently isn't.

This is great!
I fully agree with the notion that bitcoin is a major improvement over legacy systems for online micropayments while it is not mature enough today to compete effectively with bank cards for macropayments.

I can envision a ADSL box establishing a micropayment channel with a laptop passing by to share the wifi bandwidth for a while.
It would only take a virtual network operator to develop and distribute the ADSL box, turning this protocol into a growth opportunity for the traditionally slow moving fixed line telcos.

The concept could be extended to mobile device, a 3G or LTE enabled smartphone temporarily sharing bandwidth with a roaming device (to cut down on  expensive data roaming costs when traveling abroad) via a bitcoin micropayment channel.

This more or less already exists for meshnet. You also need an anonymisation network to deal with liability issues.

Mike and Matt - thanks for the outstanding work, this is exactly Bitcoin needs right now.

I'm no wizard but I'm working on a bitcoinj-based GUI for building some basic m-of-n transactions right now; been wanting to do this for quite awhile. Once I get comfortable I'll spread my wings and build out from there.

again thnks for making it all possible

Awesome! Feel free to get in touch with us on the mailing list or forum. If you haven't explored JavaFX yet then I'd encourage you to do that too.

Just wanted to drop a big thanks for your work on this.

This is probably the worlds first TRUSTLESS pay-as-you-go implementation.

Thank you, I will.

Absolutely wonderful.

However, is there a chance we will be seeing this in the default client ?

Or will everybody who wants to use this channels be forced to use bitcoinj ?

Someone could reimplement it in another wallet app if they wanted to. However it's a fair chunk of code.

I don't think that's a good idea. The default client should be specialized in handling the Bitcoin protocol. It should not be "disturbed" with other features, even the coolest ones.
OTOH, a separate piece of software that interacts with the default client via its API, but has a different code base, would perhaps be interesting... (I tend to think this feature works better with lightweight clients, but anyway)

You know, the unix KISS principle.

Will we see an implementation like this in the future?

1. There are 3 parties: Customer (Carl), Merchant (Mary), and Payment processor (Peter). However, they only have minimal trust with each other

2. Carl opens a micro-payment channel with Peter by depositing some BTC in escrow, waits for 6 confirmations

3. Peter opens a micro-payment channel with Mary by depositing some BTC in escrow, waits for 6 confirmations

4. Carl wants to buy something from Mary with 1 BTC

5. Since Carl does not trust Peter for 1 BTC, he will just release 0.01 BTC to Peter through micro-payment channel

6. Peter receives 0.01 BTC from Carl, and releases 0.01 BTC to Mary through micro-payment channel

7. Goto step-5 until 1 BTC is transferred. It is automatic and should take only a few seconds

8. Mary delivers product to Carl


Advantage of this system:

1. Peter can serve as many merchants as he wants. Merchants will put Peter's logo on their windows just like Visa and AE

2. By depositing to Peter, Carl can reach every supporting merchants immediately (after initial 6 confirmation)

3. Zero-trust instant confirmation

4. Save blockchain space and mining fee

5. Peter will take minimal transaction fee


If bitcoin is going to be successful, I believe system like this must happen. At that time, people can buy bubble gum with bitcoin

Yes, a network of low trust intermediaries like that has been proposed before.

Will it be implemented? Who knows. It's a lot of work.

IMHO the next chunk of work that makes sense to do with this is bring up a real, usable demo app that lets you take out the ads on this forum. I talked to theymos and he's provisionally interested but someone would need to actually write the code so he knows how to integrate it.

Basically it means:

a) Extend the new protocol we created to support arbitrary app specific messages on the same stream as the payment traffic.

b) (Probably) extend bitcoinj to support using TLS sockets as well as raw TCP sockets.

c) Write a little GUI app that lets you send coins to it, and which sets up a connection to a micropayment server (which will run on bitcointalk.org)

d) That server needs to expose a few localhost only JSON-RPC or other kind of RPC endpoints, so when a PHP page is rendered it can ask the server "does user X have at least X coins on the channel?" and if the answer is yes, it skips rendering the ad. In the background it'd then send a message to the users GUI app saying "please send me another micropayment to pay for the next page". You want to do it async like that so page rendering is still fast. Then some code to glue it all together.

Potential user experience: you download/run the app, it has a clickable Bitcoin: URI link in the GUI, you click it and send some coins from your wallet. Then you go to your profile page on the forum, and copy/paste a blob of text from the web page to a text box in the GUI app and press "go". The blob of text contains instructions for the app on which server to connect to, a special token (i.e. copy of your auth cookie) that is sent to the server and so on. Now as long as the app is running in the background you get ad free forum pages.

Advantages of this scheme: it works with any/all browsers and operating systems, including tablet/mobile browsers as long as the app is running on some computer, somewhere. It's easily adapted to other forums and web sites.

It's also very easy to write the app. BitcoinJ provides a class called WalletAppKit that sets up everything you need to receive and send Bitcoins out of the box. Java has a nice GUI designer these days and you can run the resulting app on any desktop OS with no porting work required.

There is only one reason for this not to be implemented: Bitcoin dies before it is implemented.

Imagine in the future, all merchants in the world accepting VISA will also accept Bitcoin. It is trust-free, instant confirmation, no charge-back, very low tx fee (most fee will go to payment processor instead of miners). There will be discount for bitcoin users because of all these advantages over VISA. As user, you don't need to worry about foreign currency exchange because bitcoin is widely accepted. If there is any emergency, your family can deposit bitcoin for you to the payment processor, and it will be confirmed after 6 confirmations (I know you don't like soft-fork, but there is a soft-fork proposal to make 6 confirmations happens in 15 minutes). And of course, 1 BTC will worth at least US$10000...............

If the protocol breaks (is interrupted) after the server has signed and returned the refund transaction (T2) to the client, the server has to blacklist its input (the hash of T1) indefinitely, or am I overlooking something? Otherwise the client can replay T1 at a later time, after the locktime of T2 has passed, and refund to himself before the protocol is terminated. At least the server has to keep track of the timelock used in T2. What does the implementation do?

I don't understand you well but maybe this helps:
You secretly ask the merchant for a refund of a not yet published payment A.
The merchant secretly sends you a contract B1 "If you publish A (aka send me $100) I send you B which can be used to send $100 to you."
Now with this contract in hands you publish A.

Now you feel like you need some service from the merchant. You ask him and he offers you something for 10ct, but asks you to sign B2 "I $99.90 to you. This overrules B1"
As it's a fair deal, you sign it and send it to the merchant.
Now the merchant is compensated and grants you the 10ct. service.

Now you feel betrayed by the merchant and publish the very first full reimbursement but the merchant has time until the timeout of A expires to publish any lower reimbursement that you signed and that overrules all prior Bs.

The highest B at the end of timeout wins and becomes a blockchain transaction. This might happen before the timeout if B∞ gets published with all signatures early.

do you consider this an actual useful app or do you just propose it as good test case?

i like the idea of a "soft paywall", for example for high quality articles. but honestly, people need to see that they are paying for an actual effort that benefits them. while maintaining a large forum like this a big effort, the content is still user generated. so how do you measure the effort for the micropayments? time, clicks, ads blocked?
when you click on a news paper or blog article and a micropayment for 5 cents is executed, thats something a user can relate to. but when you stumple into a thread from some guy blabbering about anarcho-whateverilism or better yet, you answer questions in the noob forum - you really expect anyone to pay for that?

 Because bitcoin is a non refundable transaction there is still a question of trust. If there is no escrow between you and the merchant then which transaction takes place first. In your case the merchant is paid before he grants you the 10c service. Or should he grant you the service before he is paid the 10c?
 It probably won't be an issue in reality because the transactions are small and somebody will be willing to take the first step.
 
 What about a micro payment exchange?

 The low trust payment processor idea seems to me to be less useful idea than a normal payment processor because they usually have to have a higher level of trust with the merchant and the buyer than they have between themselves and often are needed to turn a non refundable transaction into a refundable transaction.
 I'm not sure if this is what is suggested.

 I like the idea of paying to not see adverts. Where will the publishers loyalties lie? Do you place really annoying adverts on your site so that everybody pays not to see them or place great adverts on your site so that you get lots of ppc or commission. Will publishers be tempted to place more and more adverts in order to win both ways? In the end the customer can choose to pay the premium fee to see no adverts or just a small fee and see the adverts that would have been shown normally before the system was introduced. :)

+1  :)

Exactly. For the 10ct. you need trust and always will need trust for things you can't pack into the blockchain.

Imagine you buy some digital good. The merchant could send you the encrypted version and forge a transaction that would only be valid if it contained the key for your copy of the digital good. You sign the transaction, granting the merchant the price. Now the merchant could either sign it, too, granting you access to the blob of data he claimed was the digital good, or not sign. At least in this scenario you are damn close to having proof that the merchant did not deliver. I doubt that it's theoretically possible to get much closer to trust-free than that.

(Well, colored bitcoins would be an example though. If there is a legally binding contract that states that this car belongs to whoever controls this satoshi, you could pass ownership of this satoshi and a payment for it in one transaction both parties sign and publish. Maybe this is still a bit esoteric.)

It's all about levels of trust. The micro payment system reduces this. It doesn't matter about legally binding contracts because people will still rip you off. Credit card companies calculate how much they will be taken from them each year by people they have entered in to legally binding contracts with and calculate their interest rates so that they still profit. Put your money in a bank account or a government bond or coloured coin guarantor that you trust and you can still lose.
 No system is perfect but reducing the level of trust required is very efficient because with trust there is also reputation and even on the Internet this can count for something, even if it's just the hassle of opening a new account with a new e-mail. So if you reduce the level of trust sufficiently it can be counter acted by the loss of reputation.
 I like the idea of micro escrow where the escrow agent only holds a small amount from each exchange participant and the exchanges happen in increments. This can be automated and the level of trust is reduced between everybody.

??

Micro-payment channels only require trust up to the value of one micro transaction that can be one Satoshi. As a micro transaction still has transactional costs of the value to calculate and send it (0.0005ct. maybe) + the two transactions back and forth you need per timout, sending 1Satoshi might still be prohibitively expensive, so as long as paying 1% transaction fees is ok, this method reduces the amount that is ok to be sent from currently $1 to $0.005 aka it is 200 times more efficient for micro transactions.

The legally binding contract thing was colored bitcoins and was in "( )" as it is just a comment where I thought up a case where there would be not only no third party risk but no risk at all, regarding the transfer of property.

The server generates a new key each you open a channel and requires it be used. So you cannot replay T1 like that. When you present it to the server in order to open up the new channel it will notice it's using the wrong key.

Mostly it'd just be a good example of how to do things, but your alternatives are:

- See the ads
- Pay to remove them
- Cheat and use an ad blocker

You don't want to do the third option, do you?  The ads/micropayments aren't paying for the content. They're paying for the overhead of the forum hosting.

Ok, so you mean the rejection of such a replay happens in step 6 of the wiki description, after the server has seen T1 completely (not only it's hash) and when the server doesn't find his freshly generated key in there?

I think you were describing why the protocol is safe for the client (buyer), while my concern was whether it is safe for the server (merchant). Anyway, Mike made this clear to me now.

Yes. See line 226 here:

https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/protocols/channels/PaymentChannelServerState.java#226

actually, i defintely want to do the third option. is there some kind of implicit contract stating i have to look at every square inch of a delivered website? i barely register advertisement anyway, it just makes my browser slower. and its not like littering my subconsciousness is earning a website any money.

One of the assumptions built into this system is getting the transactions into blocks.

Aren't these transaction non-standard?  There would be a risk that they won't be mined.

There is nothing time-critical about this scheme. Either it works or it doesn't. If it works and the timeout is approaching both parties have a chance to publish whatever they want (and have signed from the other party) and that can be days before timeout so plenty of time to find a node that mines it.

I am not sure how this step would actually work. If my timeout is one year and I constantly broadcast transactions for this, they wouldn't end up in a block unless int_max or the timeout is reached, but what would miners do with it? totally ignore it if t < timeout - 1day/hour/minute? Can they mine all of them, putting pruneable stress on the network after all? As I understand it, the last such transaction may just not have a timestamp > timeout, but that could occur even hours (?) after the timeout if the miner stretches the limits of the protocol (that allows timestamps to be non-monotonous) in order to get the fees.

Maybe that last thought is kind of a stretch but I could imagine a merchant that is programmed to finalize channels at timeout -1h and has a power outage. He would broadcast his finalization even at timeout +1h when power comes back and that would give an incentive to miners to mess with the timestamps. Imagine always somebody being late so timestamps start to diverge from real time until some non-greedy miner creates a block, but this miner would also have to mess with the time-stamp if the time-skew is already so critical that the "actual" time would look skewed to the other miners.

Just wanted to bump up and let you guys know i am very excited with this.
These advanced features are what might just prove to be the important advantage bitcoin has over other payment systems.

If I had time and the missing piece for a product I have in mind, I would be all over it. This and many more things contracts can do will help bitcoin's break through.

Has there been any implementations of these micro-payment channels in the wild?

I'm exploring the code and wonder if there are any implementations that exist yet.

I was talking to someone about this the other day and there was some use case where it made sense.  Too bad my memory is shit and I cannot even remember the application.

I was thinking about this again, and due to the lack of support from SequenceNumber and LockTime, it seems like there is an exploit.  I haven't reviewed this code ina  long time, so I could be wrong.

Scenario is as below:

A drafts 100mBTC transaction to B.  B gives refund of 100mBTC, A signs and gives to B.
A now holds a refund for 100mBTC that is payable in 24 hours.
A uses 5mBTC of services, A and B both sign the refund, making it refund 95mBTC instead.
A now holds the refund for 100mBTC and 95mBTC.  So does B.
Continue a bit more until A has run up a tab of 95mBTC.  He has all of the previous refund transactions that are timelocked, and so does B.
No one can broadcast transactions until the timelock.  Then its a mad rush to send out a refund.  A sends out the 100mBTC refund tx, and B sends out the 5mBTC refund.  B's has a higher sequence number, but it isn't supported and is ignored.  So whichever transaction gets to the miner first wins.

Am I misunderstanding how Sequence Number is not supported presently?

That's not how the protocol works. There is only one refund tx. The settlement/contract txns are sent from client to server, but the client never gets a fully signed copy.

Micropayment channels are still under development and I've been making steady progress, bugfixing, refactoring, and so on. I'm hoping to have a demo app to show soon.

Do you develop the demo app in the open? Is it in the bitcoinj repo? Starting November I will dive into bitcoinj if no great job comes along by then, which I don't push too hard for.

I'll have to look at the code again, it's been a while since I really dug into it.  My understanding was the refund is what was updated.  My apologies for not digging deeper into it before posting!

You can see the code here: https://github.com/mikehearn/PayFile

I demo'd the app at the Amsterdam conference. But it's not ready for end users yet. The current code may not even compile, I've been changing the bitcoinj side and then catching this app up later. It implements a basic file download server+GUI client in which the client pays the server for files using micropayments. One can imagine extending it later to also support uploads and many other features.

Exciting stuff Mike! Looking forward to seeing it in action.

+1

Was Circle interested in this in particular?

No. I'm not employed by circle, just to clear that up. I've joined their advisory board. The reasons they asked me are in their press release.

Yeah, well, I read the press release. It was short. So "joined their advisory board" means you don't get compensation for your advise? Compensation or not, I was interested if they were interested in transaction channels in particular which you said, "no" to. Hmm, wonder who will come out first with a working mesh-capable server (2-hop peer to peer payment just like email) or a maybe closed source centralized solution …

I'm compensated with a small quantity of stock options.

Well, I am not quite sure which specific technologies they are most interested in yet, and if I did know I couldn't tell you because it'd be commercially confidential. But if they want to talk to me me about that then of course they get first priority on my time due to this arrangement (for other topics too).

The latest status of this work is that the soon to be released bitcoinj 0.11 has a ton of major improvements and fixes in the micropayment channel implementation. In the last 6 months we took the code for major test drives and were able to find and fix a lot of the obscure issues that crop up in real apps. PayFile is nearly ready for release, though I'm not working on it at the moment. I'm hoping Simon will finish off the last remaining issues though at the moment he seems to be thinking about alt coins for Africa, so maybe I'll have to do it at some point. Anyone else who knows Java and is interested in micropayments/agents/StorJ type concepts is welcome to contact me and I'll show you what needs to be done.

At the moment the massive runup in value combined with the lack of floating fees means the min payment you can make on a micropayment channel is now quite large, at about 8 cents. That's kind of ridiculous and can't be justified by the technology, so we might have to wait until floating fees are implemented and we're able to push fees down again before micropayment channels go back to being interesting.

I should help. I definitely should as I am a Java developer and want to learn more about bitcoin and transaction channels.

This comment sounds like 8ct. per channel is bad for this technology? I read that Gavin(?) assumes the fees to go up, not down if they turn floating and long term I definitely expect them to go up. I see this as the biggest justification to add efforts on turning these channels a reality, not to put them on hold. If you and I have channels to MtGox, we can funnel payments through MtGox without having to trust MtGox (which I wouldn't at this point). The channel could have a timeout of one year so all the fees we would have to pay for maybe thousands of transactions would be 8ct + whatever MtGox charges, which could be as low as 0.0001ct.

Sure, it only matters for making micropayments for a billed service where the service is very cheap to provide - this describes most of the use cases I am currently interested in but it sounds like you have other ideas.

The only reason Gavin expects fees to go up is because his current algorithm is measuring the average fee paid with no time dimension, and some Bitcoin users that generate lots of transactions pay a lot more than the min fee, although there's little evidence this is really required. So there is an assumption that network users are economically rational and are optimising the fees they pay even though many are not.

In theory, over time if we get more and more users onto floating fees with a time preference, i.e. users state "I would like my transactions to confirm within N blocks", then the fees should start to converge on the actual level they should be given the cost of running the network, which should be much lower than they are now. It certainly doesn't cost 8 cents to verify a transaction, the only reason it's got that high is the fixed BTC numbers in the source code. But it may take some interesting efforts to get us there :-) I did some work over Christmas on writing a new estimator that measures the fees being paid by transactions that confirm within 1,2,3,etc blocks.

Anyway, this is all interesting but off topic. If you're interested in working on this, I suggest you start by reading the docs and PayFile code:

https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments
https://github.com/mikehearn/PayFile

.... that will give you a feel for the client API. Note that until I finish the HD wallets work the bitcoinj micropayment channels code reuses keys, which is a security hole, and also tx malleability can yield various obscure attacks as well. But these issues are being worked on and should go away over time, so don't let that stop you researching and prototyping.

The code itself is in the bitcoinj protocols.channels package. If you want to improve it, please go ahead and send me patches!

After reading the above then you can decide whether to help work on PayFile with Simon, which would be good if you're interested in making a P2P dropbox style file storage and serving network, or if you're more interested in other uses of payment channels, in which case you'd write your own app.

The bulk of the work on PayFile is done already. It's mostly bug fixes from here on out. And until floating fees comes along, to implement that. If you have any questions on the code, just ask.

I'm going to continue some part-time dev work on it.

Well, the basic version 1 is nearly done :) I have an entire roadmap in my head for evolving PayFile into StorJ eventually. For instance, PayFile 2 would support uploading and storage of files as well.

I have a question about this feature:

The ability to do micropayments is important, but isn't it more important the fact that this allows payments without the need to wait for ~6 blocks for confirmation?
I have seen many criticisms saying that bitcoin cannot go mainstream because it doesn't work in a supermarket, if the cashier has to wait one hour to be sure the transaction is good. But with a micropayment channel.

And, if this is the case, wouldn't it be good to change the name of the feature?

You are absolute right with the minor correction that for any reasonable transaction one confirmation (~5minutes) is almost as good as 6 confirmations but also too long for point of sales scenarios.

My vote is "payment channel" or "transaction channel".

It's not really related to that. Supermarkets can accept unconfirmed transactions with very little risk even today with a very unhealthy mining market. In future we optimistically hope the mining market will be less centralised, there will be double spend alerts etc in which case, ideally we will never hear about supermarkets being defrauded by double spending.

The code in bitcoinj already refers to the system as "payment channels" by the way, as indeed there's no reason the payments have to be micro.

The real issue with payment channels is the setup cost.

Is anyone looking into a hub system?

They could operate on a "top-up" basis. 

A 0.01BTC channel costs 0.0001, so that would be 1% for both sides, so 2% total fees. 

At $1000 per BTC, that is a $10 "fund" for 20 cents.

Duration is almost irrelevant, since it is only $10.  It could be a 60 day channel. 

Hubs could offer the option of cashing in early.  Mostly, they would do it since their reputation is on the line.

Content providers could create channels to those hubs.  Even if there were 100-1000 hubs, a content provider would only need to pay 20 cents per hub.

Probably hubs would pay for channel setup to content providers as part of their service fee.

If hubs connected to each other, then customer and provider would only need to connect to one hub each.

Hubs would probably decide if a direct channel to the content provider is cheaper or just use the provider's hub.