[ANNOUNCE] Micro-payment channels implementation now in bitcoinj

[poiuytr4]

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.

 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.

[1714686657]

1714686657

[1714686657]

1714686657

[1714686657]

1714686657

[1714686657]

1714686657

[1714686657]

1714686657

[1714686657]

1714686657

[paraipan]

very cool

+1 

[giszmo]

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.

 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.

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

[poiuytr4]

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.

 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.

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

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.

[giszmo]

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.

 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.

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

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.

??

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.

[Mike Hearn]

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?

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.

[Mike Hearn]

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?

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.

[thanke]

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?

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.

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?

[thanke]

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?

[..]

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.

[..]

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.

[Mike Hearn]

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?

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

[fornit]

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.

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.

[TierNolan]

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.

[giszmo]

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.

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.

[yona]

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.

[giszmo]

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.

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.

[simondlr]

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.

[alp]

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.

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?

[Mike Hearn]

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.

[giszmo]

I'm hoping to have a demo app to show soon.

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.

[alp]

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'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!