[ANNOUNCE] Micro-payment channels implementation now in bitcoinj

[1base58]

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?

[Luckybit]

I am really interest 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.

This is a brilliant idea. WRITE A WHITE PAPER.

[Mike Hearn]

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.

[gendal]

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.

[Mike Hearn]

Yep, you got it.

[mmeijeri]

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.

[runeks]

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.

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.

[jmw74]

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.

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.

[runeks]

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.

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.

[cbeast]

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.

[kwukduck]

This is great news! Good job guys.

[Prophet]

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

[tomcollins]

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?

[giszmo]

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.

[nomailing]

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

[freedomno1]

Bitcoin keeps adapting and growing 
Thanks for all the hard work

[tomcollins]

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.

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.

[Mike Hearn]

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

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.

The poker application did sound interesting.  However, I'm not sure it's practical to do this...

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.

[cryptopunk]

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

[giszmo]

This is a trust-free incremental settlement 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.

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