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

If I had time and the missing piece for a product I have in mind, I would be all over it. This and many more things contracts can do will help bitcoin's break through.

Just wanted to bump up and let you guys know i am very excited with this.
These advanced features are what might just prove to be the important advantage bitcoin has over other payment systems.

There is nothing time-critical about this scheme. Either it works or it doesn't. If it works and the timeout is approaching both parties have a chance to publish whatever they want (and have signed from the other party) and that can be days before timeout so plenty of time to find a node that mines it.

I am not sure how this step would actually work. If my timeout is one year and I constantly broadcast transactions for this, they wouldn't end up in a block unless int_max or the timeout is reached, but what would miners do with it? totally ignore it if t < timeout - 1day/hour/minute? Can they mine all of them, putting pruneable stress on the network after all? As I understand it, the last such transaction may just not have a timestamp > timeout, but that could occur even hours (?) after the timeout if the miner stretches the limits of the protocol (that allows timestamps to be non-monotonous) in order to get the fees.

Maybe that last thought is kind of a stretch but I could imagine a merchant that is programmed to finalize channels at timeout -1h and has a power outage. He would broadcast his finalization even at timeout +1h when power comes back and that would give an incentive to miners to mess with the timestamps. Imagine always somebody being late so timestamps start to diverge from real time until some non-greedy miner creates a block, but this miner would also have to mess with the time-stamp if the time-skew is already so critical that the "actual" time would look skewed to the other miners.

One of the assumptions built into this system is getting the transactions into blocks.

Aren't these transaction non-standard?  There would be a risk that they won't be mined.

actually, i defintely want to do the third option. is there some kind of implicit contract stating i have to look at every square inch of a delivered website? i barely register advertisement anyway, it just makes my browser slower. and its not like littering my subconsciousness is earning a website any money.

Yes. See line 226 here:

https://code.google.com/p/bitcoinj/source/browse/core/src/main/java/com/google/bitcoin/protocols/channels/PaymentChannelServerState.java#226

I think you were describing why the protocol is safe for the client (buyer), while my concern was whether it is safe for the server (merchant). Anyway, Mike made this clear to me now.

Ok, so you mean the rejection of such a replay happens in step 6 of the wiki description, after the server has seen T1 completely (not only it's hash) and when the server doesn't find his freshly generated key in there?

Mostly it'd just be a good example of how to do things, but your alternatives are:

- See the ads
- Pay to remove them
- Cheat and use an ad blocker

You don't want to do the third option, do you?  The ads/micropayments aren't paying for the content. They're paying for the overhead of the forum hosting.

The server generates a new key each you open a channel and requires it be used. So you cannot replay T1 like that. When you present it to the server in order to open up the new channel it will notice it's using the wrong key.

??

Micro-payment channels only require trust up to the value of one micro transaction that can be one Satoshi. As a micro transaction still has transactional costs of the value to calculate and send it (0.0005ct. maybe) + the two transactions back and forth you need per timout, sending 1Satoshi might still be prohibitively expensive, so as long as paying 1% transaction fees is ok, this method reduces the amount that is ok to be sent from currently $1 to $0.005 aka it is 200 times more efficient for micro transactions.

The legally binding contract thing was colored bitcoins and was in "( )" as it is just a comment where I thought up a case where there would be not only no third party risk but no risk at all, regarding the transfer of property.

It's all about levels of trust. The micro payment system reduces this. It doesn't matter about legally binding contracts because people will still rip you off. Credit card companies calculate how much they will be taken from them each year by people they have entered in to legally binding contracts with and calculate their interest rates so that they still profit. Put your money in a bank account or a government bond or coloured coin guarantor that you trust and you can still lose.
 No system is perfect but reducing the level of trust required is very efficient because with trust there is also reputation and even on the Internet this can count for something, even if it's just the hassle of opening a new account with a new e-mail. So if you reduce the level of trust sufficiently it can be counter acted by the loss of reputation.
 I like the idea of micro escrow where the escrow agent only holds a small amount from each exchange participant and the exchanges happen in increments. This can be automated and the level of trust is reduced between everybody.

Exactly. For the 10ct. you need trust and always will need trust for things you can't pack into the blockchain.

Imagine you buy some digital good. The merchant could send you the encrypted version and forge a transaction that would only be valid if it contained the key for your copy of the digital good. You sign the transaction, granting the merchant the price. Now the merchant could either sign it, too, granting you access to the blob of data he claimed was the digital good, or not sign. At least in this scenario you are damn close to having proof that the merchant did not deliver. I doubt that it's theoretically possible to get much closer to trust-free than that.

(Well, colored bitcoins would be an example though. If there is a legally binding contract that states that this car belongs to whoever controls this satoshi, you could pass ownership of this satoshi and a payment for it in one transaction both parties sign and publish. Maybe this is still a bit esoteric.)

+1 

 Because bitcoin is a non refundable transaction there is still a question of trust. If there is no escrow between you and the merchant then which transaction takes place first. In your case the merchant is paid before he grants you the 10c service. Or should he grant you the service before he is paid the 10c?
 It probably won't be an issue in reality because the transactions are small and somebody will be willing to take the first step.
 
 What about a micro payment exchange?

 The low trust payment processor idea seems to me to be less useful idea than a normal payment processor because they usually have to have a higher level of trust with the merchant and the buyer than they have between themselves and often are needed to turn a non refundable transaction into a refundable transaction.
 I'm not sure if this is what is suggested.

 I like the idea of paying to not see adverts. Where will the publishers loyalties lie? Do you place really annoying adverts on your site so that everybody pays not to see them or place great adverts on your site so that you get lots of ppc or commission. Will publishers be tempted to place more and more adverts in order to win both ways? In the end the customer can choose to pay the premium fee to see no adverts or just a small fee and see the adverts that would have been shown normally before the system was introduced.

do you consider this an actual useful app or do you just propose it as good test case?

i like the idea of a "soft paywall", for example for high quality articles. but honestly, people need to see that they are paying for an actual effort that benefits them. while maintaining a large forum like this a big effort, the content is still user generated. so how do you measure the effort for the micropayments? time, clicks, ads blocked?
when you click on a news paper or blog article and a micropayment for 5 cents is executed, thats something a user can relate to. but when you stumple into a thread from some guy blabbering about anarcho-whateverilism or better yet, you answer questions in the noob forum - you really expect anyone to pay for that?

I don't understand you well but maybe this helps:
You secretly ask the merchant for a refund of a not yet published payment A.
The merchant secretly sends you a contract B1 "If you publish A (aka send me $100) I send you B which can be used to send $100 to you."
Now with this contract in hands you publish A.

Now you feel like you need some service from the merchant. You ask him and he offers you something for 10ct, but asks you to sign B2 "I $99.90 to you. This overrules B1"
As it's a fair deal, you sign it and send it to the merchant.
Now the merchant is compensated and grants you the 10ct. service.

Now you feel betrayed by the merchant and publish the very first full reimbursement but the merchant has time until the timeout of A expires to publish any lower reimbursement that you signed and that overrules all prior Bs.

The highest B at the end of timeout wins and becomes a blockchain transaction. This might happen before the timeout if B∞ gets published with all signatures early.

If the protocol breaks (is interrupted) after the server has signed and returned the refund transaction (T2) to the client, the server has to blacklist its input (the hash of T1) indefinitely, or am I overlooking something? Otherwise the client can replay T1 at a later time, after the locktime of T2 has passed, and refund to himself before the protocol is terminated. At least the server has to keep track of the timelock used in T2. What does the implementation do?

There is only one reason for this not to be implemented: Bitcoin dies before it is implemented.

Imagine in the future, all merchants in the world accepting VISA will also accept Bitcoin. It is trust-free, instant confirmation, no charge-back, very low tx fee (most fee will go to payment processor instead of miners). There will be discount for bitcoin users because of all these advantages over VISA. As user, you don't need to worry about foreign currency exchange because bitcoin is widely accepted. If there is any emergency, your family can deposit bitcoin for you to the payment processor, and it will be confirmed after 6 confirmations (I know you don't like soft-fork, but there is a soft-fork proposal to make 6 confirmations happens in 15 minutes). And of course, 1 BTC will worth at least US$10000...............

Yes, a network of low trust intermediaries like that has been proposed before.

Will it be implemented? Who knows. It's a lot of work.

IMHO the next chunk of work that makes sense to do with this is bring up a real, usable demo app that lets you take out the ads on this forum. I talked to theymos and he's provisionally interested but someone would need to actually write the code so he knows how to integrate it.

Basically it means:

a) Extend the new protocol we created to support arbitrary app specific messages on the same stream as the payment traffic.

b) (Probably) extend bitcoinj to support using TLS sockets as well as raw TCP sockets.

c) Write a little GUI app that lets you send coins to it, and which sets up a connection to a micropayment server (which will run on bitcointalk.org)

d) That server needs to expose a few localhost only JSON-RPC or other kind of RPC endpoints, so when a PHP page is rendered it can ask the server "does user X have at least X coins on the channel?" and if the answer is yes, it skips rendering the ad. In the background it'd then send a message to the users GUI app saying "please send me another micropayment to pay for the next page". You want to do it async like that so page rendering is still fast. Then some code to glue it all together.

Potential user experience: you download/run the app, it has a clickable Bitcoin: URI link in the GUI, you click it and send some coins from your wallet. Then you go to your profile page on the forum, and copy/paste a blob of text from the web page to a text box in the GUI app and press "go". The blob of text contains instructions for the app on which server to connect to, a special token (i.e. copy of your auth cookie) that is sent to the server and so on. Now as long as the app is running in the background you get ad free forum pages.

Advantages of this scheme: it works with any/all browsers and operating systems, including tablet/mobile browsers as long as the app is running on some computer, somewhere. It's easily adapted to other forums and web sites.

It's also very easy to write the app. BitcoinJ provides a class called WalletAppKit that sets up everything you need to receive and send Bitcoins out of the box. Java has a nice GUI designer these days and you can run the resulting app on any desktop OS with no porting work required.