Topic: [ANNOUNCE] Micro-payment channels implementation now in bitcoinj (Read 29464 times)

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.

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.

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

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?

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.

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.

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.

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.

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.

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 …

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.

Was Circle interested in this in particular?

+1

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

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.

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!

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.

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.

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?

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.