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

*EDIT* Please ignore this. Now I get your point with the Transaction Malleability.

good point. While I'm slightly surprised to read about transaction signing not covering the whole transaction which sounds like a huge design flaw now, changing the hash sounds spooky to me, too.

How do you avoid transaction malleability?

https://en.bitcoin.it/wiki/Transaction_Malleability

Does this not mean that even if you have a signed refund transaction, it is possible for the funding transaction to be changed, such that the refund transaction is now invalid?

Or is this just not a concern?

Amazing you guys have just gamefied réal life, bitcoins by achievement, incredible.

This is great news! Good job guys.

I would like to take this to a ridiculous extreme for illustrative purposes. Let's say I am a writer and get paid by the word. Software could be written that reads my word total at random intervals and pays me a weekly percentage of the word total of each interval scanned for my expenses, and as an incentive to finish. This would be a way to cultivate new writers to improve their skills. As their productivity improves, their percentage could be raised and eventually bonuses earned. Maybe this isn't a good business model, but the principle applies to possibly hundreds of transactions over time with little in the way of transaction fees.

I can imagine it working in a lot of places. Wireless equipment isn't that expensive any more. You can get a NanoStation Loco for $50, with 10 km of range (http://www.ubnt.com/nanostationloco). I'd imagine a lot of network geeks would be interested in reselling bandwidth purchased for this purpose. It's a win-win situation. The ISPs earn extra money by selling bandwidth to individuals, who resell it to consumers, thereby taking a piece of the 3G/4G pie that telcos have.

The real disruption will come if they regulatory bodies open up more frequencies that allow wall penetration. Then hotels/airports will really have a hard time maintaining their monopoly.

In any case, airports have the right to prevent you from reselling bandwidth on their property. But they don't have the right to prevent you from sending signals that traverse their property.

I can only imagine this working in hotels, malls or airports, where existing wifi is ridiculously overpriced.  So anyone with a mobile data plan would just sell their spare bandwidth (violating their contract, of course, but it'd be hard for the mobile provider to catch them). 

I mean, hotel/mall/airport wifi is overpriced on purpose, it's a monopoly.  They are not going to just let you walk in, set up shop, and eat their profits.

This is not going to be a public facing business in the vast majority of cases.

This would definitely be exciting. But as far as I understand, a consumer Internet bandwidth cannot be leased out legally. The contract forbids it. But it still has a huge potential, because you could simply buy bandwidth that does allow this, and sell it at a premium, thus staying within the terms of your contract, but at the same time making a profit, and providing a valuable service to clients.

I think selling internet access through private wireless access points using Bitcoin micro-payment channels, as discussed by Mike in a recent talk, is a great application. A couple of days ago there was an announcement that Fon would accept Bitcoin, but that has now disappeared again. It also has overlap with Meshnet and Hocnet. Once you have a sizeable number of smartphone users with an app for this installed, and a sizeable number of homes with compatible wireless access points, additional privacy features such as those needed for Hocnet and Meshnet could be added. But getting the money to flow is probably the top priority.

Yep, you got it.

So... if I understand things correctly, what this announcement provides support for is the following scenario:

* We have a single consumer and a single producer of a service, neither of whom trust the other
* The service can be consumed in increments (e.g. bytes downloaded, power consumed, pints drunks) such that, at any point in the consumer/producer relationship, value has been transferred
* The requirement is to bill the consumer broadly simultaneously with that consumption: i.e. they don't pay for what they haven't yet consumed and the producer doesn't provide that for which they haven't been paid
* This is distinct to the scenario where a consumer wishes simply to make a "small" one-off payment for a product or service
* It is also distinct to the scenario where a consumer wishes to consume a service incrementally from a collection of producers
* It is also distinct to the scenario where value is only really transferred if the service is consumed in whole (e.g. download of a binary executable... 99% complete is worthless).

The system works through a two stage process:

1) The consumer publicly places some value into what amounts to escrow. In the absence of any further action, it will revert to the consumer after the expiry of some time
2) As the service is consumed, the consumer privately sends transactions to the producer, any one of which can be used by the producer to claim some portion of the locked-up value. To the extent that the consumer sends valid transactions commensurate with the value of the service they are consuming, the producer continues to provide the service and defers publication of the transaction.   At the end of the exchange, the producer publishes the highest-value transaction (from their perspective) and the remainder reverts to the consumer.


Assuming I've understood it correctly, then a particularly compelling use-case is the store-credit/stored-value scenario.  Consumers think nothing about tying up non-trivial amounts of value in store-cards, public-transit pre-pay systems or pay-as-you-go telephone cards... and so the requirement for precommittment/escrow would not be alien.

All of those areas meet the "single consumer, single producer, incrementally consumable service" requirement and so are potential areas this innovation could be applied.

The value to a consumer, of course, is that the counterparty risk (especially with store credit) is huge -- and consumers are aware of it.  There have been many high-profile cases of consumers losing money as a result of retailer bankruptcies in the UK.    This approach would overcome that.

Great ideas guys, keep them coming.

Re: renting computation power. Check out Pinnochio (from Microsoft Research) and related work to see how one might distribute a computation over untrusted nodes, with payment for their CPU time. It's not really usable yet but they're making great progress. Trusted computing is an efficient stand-in but most people don't have the right setup.


Re: differences with tx replacement enabled, check the wiki. Protocols that work with and without are described there. If we had tx replacement working again, the protocol would get more flexible - for instance the amount of money sent on a channel could go up as well as down, so you can have N-way negotiations instead of the 2-party increment-only design we have today. Unfortunately reactivating tx replacement is the sort of hard, grungy work that requires an experienced C++ programmer with time to burn and they are extremely hard to find.

Re: porting to JavaScript. You really don't want to do that. The right approach is to have wallet apps listen on a localhost socket and then export the PaymentChannelClientConnection class over RPC. A browser extension can inject a JavaScript API into the page and convert calls to it into RPCs to the wallet, whilst doing things like enforcing the same origin policy and exporting cookies to the wallet so it can re-establish client identity when the micropayment connection is established. Like I said, anyone who is serious about doing that, please do ask and I'll lay out how I'd implement it.

This is a brilliant idea. WRITE A WHITE PAPER.

I am really interested to see use cases where these micropayments work in the other direction... Considering that micro-payments start with a contract between two parties (a service and a client), a service providing distributed computation could in effect pay a commission to clients that contribute processing power.

In this way the computation doesn't need to be aligned to a particular hashing algorithm or specific hardware. The computation likely isn't time sensitive so anyone could participate, and their effort wouldn't be wasted. Pricing could vary, but could be as simple as 1 satoshi per Hz per second...

It doesn't even need new infrastructure to implement. WorldCommunityGrid.org could release an updated client that sets up a Bitcoin address for payment, provides you with the private key, and on their server they run BitcoinJ to facilitate the micropayments.

Any other novel use cases where services pay clients using micropayments?

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.

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?

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

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.

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?