Topic: [ANNOUNCE] Micro-payment channels implementation now in bitcoinj - page 3. (Read 29559 times)

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

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.

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

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 ?

Thank you, I will.

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

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

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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.

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.

Bitcoin keeps adapting and growing 
Thanks for all the hard work