[ANNOUNCE] Micro-payment channels implementation now in bitcoinj

[Daily Anarchist]

That's called mental poker and it's an active area of cryptographic research. It turns out to be really hard to do correctly (so nobody can cheat). Especially if you want to avoid people playing against themselves.

Ahh yes, I've heard it called that before. It's nice to see you say that it's an active area of research. I can't wait until it's under development. If that app ever comes out now, there are millions of poker players worldwide who would be scrambling to get bitcoins to play.

[1714670169]

1714670169

[1714670169]

1714670169

[1714670169]

1714670169

[1714670169]

1714670169

[conv3rsion]

Mike and Matt, we are all very excited for this new feature. Great job and thank you for continuing to push things forward.

[jimbobway]

The coolest next step would be a binding to the web, so any website can take advantage of micropayments triggered by JavaScript. This is a project of medium complexity, it's essentially a plumbing and UI job. It's doable in spare time but it'd have to be your main project to design, build, document and support it. I can lay out how it's done if you are serious about implementing it.

Suppose the client for micropayments is written in javascript.  Somehow the javascript needs to bind to the java client, probably via applet or an installed desktop java app to communicate to the micropayment server.

I am wondering if it would be possible to port the java client code to javascript so it can talk directly to the micropayment server, perhaps with websockets.

Nice work.

[runeks]

So, reading https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party I don't understand what prevents double spending of the input used to fund T1.

T1 redeems an input that is sent to an output requiring both the server's and the client's signature to redeem. But what if, when the exchange is over, and I've gotten what I wanted from the server, I send out a new transaction that redeems the same input redeemed by T1, but with a higher fee to miners, that sends all coins back to myself?

In other words, what is it, in essence, that makes this any different from just showing the server a transaction that sends coins to an address that belongs to the server? And rapidly updating this transaction?

[barfor]

Yo that's off the chain! 

[bluemeanie1]

This has interesting, and probably negative, implications for the Color Coins project.

great work though!  -bm

[giszmo]

So, reading https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party I don't understand what prevents double spending of the input used to fund T1.

T1 redeems an input that is sent to an output requiring both the server's and the client's signature to redeem. But what if, when the exchange is over, and I've gotten what I wanted from the server, I send out a new transaction that redeems the same input redeemed by T1, but with a higher fee to miners, that sends all coins back to myself?

In other words, what is it, in essence, that makes this any different from just showing the server a transaction that sends coins to an address that belongs to the server? And rapidly updating this transaction?

The time-locking makes it possible for both parties to work trust-free.

So if the session gets initiated with one day time lock, the first transaction sending all the money to the server may not get used as the input to send it all back within this one day, but both parties sign an "all returns" transaction in the beginning. Apparently bitcoin protocol supports a "sequence number", so the highest sequence number wins and both parties are allowed to provide a higher sequence number (signed by both parties) within the time lock. Ingenious

(So this is not a real micro-payment in the sense of a service collecting satoshis from many clients but the service could collect *increments* of satoshis from many clients each paying some dollars in the end, which is really really great.)

[giszmo]

Satoshi dice should use this! They would save tons of fees and reduce spam for all of us.
I'm so excited!

… maybe not possible … hmm …

[justusranvier]

Using this technique in smart meters, an electric electric company could implement realtime demand pricing and adjust the payment once per minute but only actually transfer Bitcoins on the blockchain twice per month per customer.

[super3]

Pretty awesome work. Now that something is working, will this be added to the regular client at some point? Many people specifically want to do micropayments, so it would be nice if this was standalone and had some wrappers.

[Luckybit]

If anyone intends to build a music streaming service contact me.

I had a dream of creating another internet music stream, but unfortunately I currently have no time to work on it.

And of course basically any service that is billed per minute via phone today, x-rated or otherwise, would be an ideal fit.  Technical support, legal advice, astrological readings, etc.  It enables all those industries to ditch the phone carriers as the billing mechanism and move to Internet-only delivery and payment.  I'd be curious to know what percentages the phone companies skim off the top on their per-minute numbers, if it's a large amount, then this technology becomes a compelling alternative and some bright enterpreneur could probably get funded and build a business disrupting that market.

Payment gateways should implement micropayment channels. Are there any open source Bitcoin payment gateways?

Now, can this be adapted to support altcoins like Litecoin and PPcoin? Then we are really onto something.

[Luckybit]

OK, so where can we go from here? If anyone has some serious time they can dedicate to one of these projects, let me know.

The coolest next step would be a binding to the web, so any website can take advantage of micropayments triggered by JavaScript. This is a project of medium complexity, it's essentially a plumbing and UI job. It's doable in spare time but it'd have to be your main project to design, build, document and support it. I can lay out how it's done if you are serious about implementing it.

As a more experimental, easier step, you could implement a music or video streaming service as a standalone desktop Java app. I know you think they're ugly, but if you grab the JavaFX demos you'll see you can create some truly beautiful UIs using the new toolkit. It's come a long way since the Swing days.

http://www.oracle.com/technetwork/java/javafx/samples/index.html

JavaFX has widgets for playing video and audio streams out of the box, as well as an embedded WebKit, and you can then bundle up the resulting program into standalone packages for each OS (Mac users get a draggable app folder, etc). The UIs are themed using CSS and you can also use JavaScript, so it's not totally alien to web developers. All the kinds of animations you'd expect from a Mac or iPhone UI are present and easily usable, and there's a slick UI builder app too. So it's pretty nice. I wish I had more time to play with it.

Anyway, the point is that it's very easy to build a basic wallet app with bitcoinj, just instantiate WalletAppKit and off you go, so then the model is you'd send some Bitcoins to your movie player app or whatever and tell it which movie to play. Then you can pay-per-second, for instance. As an experiment I think you could get this working over a weekend. Not including the time taken to find some videos of course

I completely agree with this. I just suggest that the code be open enough to have a plugin or extension mechanism so altcoins can be plugged into it as well. I like Bitcoin but this is too important to be Bitcoin exclusive.

Anything which benefits the cryptocurrency economy as a whole is better than just benefiting Bitcoin.

[giszmo]

OK, so where can we go from here? If anyone has some serious time they can dedicate to one of these projects, let me know.

The coolest next step would be a binding to the web, so any website can take advantage of micropayments triggered by JavaScript. This is a project of medium complexity, it's essentially a plumbing and UI job. It's doable in spare time but it'd have to be your main project to design, build, document and support it. I can lay out how it's done if you are serious about implementing it.

As a more experimental, easier step, you could implement a music or video streaming service as a standalone desktop Java app. I know you think they're ugly, but if you grab the JavaFX demos you'll see you can create some truly beautiful UIs using the new toolkit. It's come a long way since the Swing days.

http://www.oracle.com/technetwork/java/javafx/samples/index.html

JavaFX has widgets for playing video and audio streams out of the box, as well as an embedded WebKit, and you can then bundle up the resulting program into standalone packages for each OS (Mac users get a draggable app folder, etc). The UIs are themed using CSS and you can also use JavaScript, so it's not totally alien to web developers. All the kinds of animations you'd expect from a Mac or iPhone UI are present and easily usable, and there's a slick UI builder app too. So it's pretty nice. I wish I had more time to play with it.

Anyway, the point is that it's very easy to build a basic wallet app with bitcoinj, just instantiate WalletAppKit and off you go, so then the model is you'd send some Bitcoins to your movie player app or whatever and tell it which movie to play. Then you can pay-per-second, for instance. As an experiment I think you could get this working over a weekend. Not including the time taken to find some videos of course

I completely agree with this. I just suggest that the code be open enough to have a plugin or extension mechanism so altcoins can be plugged into it as well. I like Bitcoin but this is too important to be Bitcoin exclusive.

Anything which benefits the cryptocurrency economy as a whole is better than just benefiting Bitcoin.

It's not bitcoin's obligation to help alt-coins to keep pace. If you are into litecoin, proof they are worth something and that they are not just some scam of some greedy people envy of the early adopters that took all the risk to push bitcoin to what it is now. If something proofs to be essential for a modern crypto currency, bitcoin will adopt it from the alt-coin or die. Not the other way round.
Edit: ooops. bad quote.

[Mike Hearn]

T1 redeems an input that is sent to an output requiring both the server's and the client's signature to redeem. But what if, when the exchange is over, and I've gotten what I wanted from the server, I send out a new transaction that redeems the same input redeemed by T1, but with a higher fee to miners, that sends all coins back to myself?

There are a couple of misunderstandings here. The first one is that T1 is broadcast at the start of the negotiation, so it gets confirmed like any normal transaction. The second is the belief that you can replace transactions by sending another one with a higher fee. That's not how Bitcoin works.

Re: alt coins. If they're similar enough to Bitcoin then the protocol and code will just work.

Re: integration into clients. It's something that you use to build other apps really. Having it directly exposed to end users in wallets doesn't make a whole lot of sense. However, wallet apps can certainly re-expose the API to other apps that don't want the hassle of actually being a wallet themselves.

SatoshiDice uses micropayments as a form of messaging. This work doesn't have any impact on that, the payment protocol is the solution to what they're doing.

[runeks]

T1 redeems an input that is sent to an output requiring both the server's and the client's signature to redeem. But what if, when the exchange is over, and I've gotten what I wanted from the server, I send out a new transaction that redeems the same input redeemed by T1, but with a higher fee to miners, that sends all coins back to myself?

There are a couple of misunderstandings here. The first one is that T1 is broadcast at the start of the negotiation, so it gets confirmed like any normal transaction. The second is the belief that you can replace transactions by sending another one with a higher fee. That's not how Bitcoin works.

Oh, I hadn't caught the first point. So does this mean that the setting up requires T1 to be in the block chain?

With regards to your second point, the answer is that miners can do this, if they want to. The protocol can't enforce this. The Satoshi client can default to ignore subsequent transactions spending the same input, but it can't be enforced in any way, and so it's not wise to build services that rely on this. If this were the case we wouldn't have to worry about double spends in the first place. But if I understand your first point correctly, this isn't what your implementation relies on anyway, so it's not relevant here.

Great job by the way! Both to Matt and you. This is one of the things that has so many possibilities that it's mind blowing!

[Luckybit]

It's not bitcoin's obligation to help alt-coins to keep pace. If you are into litecoin, proof they are worth something and that they are not just some scam of some greedy people envy of the early adopters that took all the risk to push bitcoin to what it is now. If something proofs to be essential for a modern crypto currency, bitcoin will adopt it from the alt-coin or die. Not the other way round.
Edit: ooops. bad quote.

We disagree. I don't see Bitcoin as a product, I see it as an algorithm and a community. The meta community is based around the shared interest in the success of cryptocurrencies, but Bitcoin is just one brand and product. The sourcecode is more important than the brand, and if you really believe in the goal of what Bitcoin sourcecode is trying to do then you'll support other algorithms which are trying to achieve the same goal.

This is the difference between how a theorist thinks and a businessman. You're thinking of Bitcoin strictly as a business while I'm thinking of it as elegant code. If Bitcoin competes with Litecoin and PPcoin for "marketshare" or = whatever to the point that the marketcap for all cryptocurrencies can't grow then in my opinion that kind of competition is bad.

Should we think of the search engine as math or as Google? I think of search as math, as code, as an algorithm to organize information which Google happened to monetize and capitalize but I don't think it's good for the community or economy or the mathematics for there to only be one algorithm, one supported design, one business model, with no variety or competition. Imagine if the US government had only one political party, what do you think could happen?

[Mike Hearn]

With regards to your second point, the answer is that miners can do this, if they want to. The protocol can't enforce this.

I'm familiar with this argument. I believe it's misleading for a variety of reasons, but here isn't the place to get into it. Regardless, the chain of transactions can be risk analysed as any other and if you want to wait for confirmations, the client or server can certainly do that. The example apps don't wait though.

[aantonop]

Geez. This is exciting! Excellent work.

So who wants to create a pay as much as you use music streaming service? Micropayments for each second of listening. Goes straight to artist.

I want to build a service that enables that. I heard you're a good UI developer ;-)

[loudog40]

Impressive work guys!  Watching Mike's 2012 talk on youtube was what really got me excited about bitcoin again and I'm glad to see such amazing progress in making these concepts a reality.

I'd be delighted if someone could elaborate on how things change once transaction replacement is turned back on.  From what I've gleaned there's a risk of the refund transaction being modified and broadcasted but I don't understand how this could happen before the locktime and without the server resigning the inputs.  What exactly is the caveat with this implementation and transaction replacement?

[amincd]

Thank you very much guys! This has the potential to significantly advance how we buy and sell services and is something that was not possible before Bitcoin. Very exciting.