[ANNOUNCE] Micro-payment channels implementation now in bitcoinj

[Mike Hearn]

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.

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.

[1714676620]

1714676620

[1714676620]

1714676620

[simondlr]

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

[hivewallet]

Yo that's off the chain! 

+1

[giszmo]

Was Circle interested in this in particular?

[Mike Hearn]

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.

[giszmo]

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 …

[Mike Hearn]

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.

[giszmo]

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.

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

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.

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.

[Mike Hearn]

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.

[simondlr]

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.

[Mike Hearn]

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.

[fremen]

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?

[giszmo]

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.

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.

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

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

[Mike Hearn]

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.

[TierNolan]

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.