[ANNOUNCE] Micro-payment channels implementation now in bitcoinj

[giszmo]

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.

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.

[1714689642]

1714689642

[1714689642]

1714689642

[1714689642]

1714689642

[1714689642]

1714689642

[1714689642]

1714689642

[Mike Hearn]

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.

[fornit]

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.

[TierNolan]

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.

I think that is just the default.

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

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.

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.

[Mike Hearn]

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.

[Boussac]

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.

[mmeijeri]

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.

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

[jedunnigan]

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

[Mike Hearn]

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.

[Nagato]

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

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

[jedunnigan]

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.

Thank you, I will.

[ShadowOfHarbringer]

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

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

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 ?

[Mike Hearn]

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

[caveden]

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

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.

[jl2012]

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

[Mike Hearn]

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.

[jl2012]

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.

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

[thanke]

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?

[giszmo]

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.

[fornit]

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.

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?