Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Micropayment channel with bitUSD  (Read 922 times)

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Micropayment channel with bitUSD
« on: June 03, 2015, 04:31:58 AM »

I was looking at Streamium and thinking what is missing from our part to support the micropayment channel protocol with bitAssets.
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

It seems that we only need a new transaction field "valid_from" that prevents a transaction to be broadcasted/accepted into the blockchain before that date.

And the mechanics could be as follow.

Client: Ask the server for a pubkey.
Server: Sends pubkey

Client: Calculate a multisig deposit with both client_pubkey and server_pubkey
Client: Send and unsigned tx to server that returns 100% of the funds he is willing to use to his self with a valid_from field set to Now+2hours and expiration set to Now+2hours+1day.
Server: Sings transaction and send back to client

Server: Create unsigned transaction that allocates 99% to the client 1% to the server
Client: Validates/sign the transaction and send back to server

Some minutes/seconds pass ...

Server: Create unsigned transaction that allocates 98% to the client 2% to the server
Client: Validates/sign the transaction and send back to server

Some minutes/seconds pass ...

Server: Create unsigned transaction that allocates 97% to the client 3% to the server
Client: Validates/sign the transaction and send back to server

And so on and so forth... until the channel is closed and the server broadcast the transaction to get his money and send the rest to the client.
If the server hangs the client has the first transaction signed by the server that can broadcast after the specified date in "valid_from".

I think micropayments in bitUSD has a lot of potential in a lot of audiences/industries.
games, video streaming, torrent seeds, adult entertainment, etc, etc, etc.

Questions:

What is the impact to add that field to the transaction?
Is a hard fork required?

Code: [Select]
struct transaction
   {
      fc::time_point_sec    expiration;
      optional<fc::time_point_sec>    valid_from;
      optional<uint64_t>    reserved;
      vector<operation>     operations
    ....

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11904
    • View Profile
    • BitShares.Europe
  • BTS: xeroc
  • GitHub: xeroc
Re: Micropayment channel with bitUSD
« Reply #1 on: June 03, 2015, 06:51:33 AM »
I like that idea ...
but I am not sure it's easily implemented .. devs may require an additional database to store valid but not-yet-executed transactions with their valid_from field ..


paging @bytemaster @vikram
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu


Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #3 on: June 03, 2015, 09:50:45 AM »
Xeroc, there is no need to store the transaction. The node can validate it (in the transaction validation state) and reject it if the condition is not met without storing anything.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #4 on: June 03, 2015, 09:53:37 AM »
would this work for recurring payments too?
Favdesu, I can't see it working for recurring payments.
This is to handle very small payments (sometimes smaller that the fee) that are the result of a continuous provided service.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11904
    • View Profile
    • BitShares.Europe
  • BTS: xeroc
  • GitHub: xeroc
Re: Micropayment channel with bitUSD
« Reply #5 on: June 03, 2015, 09:57:47 AM »
Xeroc, there is no need to store the transaction. The node can validate it (in the transaction validation state) and reject it if the condition is not met without storing anything.
That would allow spamming/ddosing of the network, wouldn’t it?
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #6 on: June 03, 2015, 10:35:14 AM »
Xeroc, there is no need to store the transaction. The node can validate it (in the transaction validation state) and reject it if the condition is not met without storing anything.
That would allow spamming/ddosing of the network, wouldn’t it?
Same situation that we already have with the expired field treatment in the evaluation state.

https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/transaction_evaluation_state.cpp

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 936
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #7 on: June 03, 2015, 12:42:03 PM »
I agree this is a great idea.  People can always spam the network with invalid transactions with or without this, but they shouldn't be propagated, and the sender should be disconnected when this happens.

I don't think we need "valid_from" for this, just transaction expiration.  After funding the multisig, the parties just need to keep updating signed settling transactions shared between them.  If the previous settling transaction is about to expire and you don't have a new one yet, broadcast the last one.

Micropayment channels like this are also perfect for mesh networking. 

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #8 on: June 03, 2015, 01:46:45 PM »
I agree this is a great idea.  People can always spam the network with invalid transactions with or without this, but they shouldn't be propagated, and the sender should be disconnected when this happens.

I don't think we need "valid_from" for this, just transaction expiration.  After funding the multisig, the parties just need to keep updating signed settling transactions shared between them.  If the previous settling transaction is about to expire and you don't have a new one yet, broadcast the last one.

Micropayment channels like this are also perfect for mesh networking. 

The client will fund a multisig balance, so if the server disappears that money will stay in limbo.
To prevent this the server needs to sign a transaction that sends 100% of the funds back to the client.

Suppose that the valid_from field is not in the transaction.
Then the client will always have a signed transaction from the server that refunds 100% to him.

If i were the client, i will use the service sending signed transactions when the server requires me and after some time i will broadcast the first transaction letting the server with 0 and me with 100%.

This behavior is the one that is prevented by the "valid_from" field.

How will you handle this case without "valid_from"?

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 936
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #9 on: June 03, 2015, 02:14:22 PM »
I agree this is a great idea.  People can always spam the network with invalid transactions with or without this, but they shouldn't be propagated, and the sender should be disconnected when this happens.

I don't think we need "valid_from" for this, just transaction expiration.  After funding the multisig, the parties just need to keep updating signed settling transactions shared between them.  If the previous settling transaction is about to expire and you don't have a new one yet, broadcast the last one.

Micropayment channels like this are also perfect for mesh networking. 

The client will fund a multisig balance, so if the server disappears that money will stay in limbo.
To prevent this the server needs to sign a transaction that sends 100% of the funds back to the client.

Suppose that the valid_from field is not in the transaction.
Then the client will always have a signed transaction from the server that refunds 100% to him.

If i were the client, i will use the service sending signed transactions when the server requires me and after some time i will broadcast the first transaction letting the server with 0 and me with 100%.

This behavior is the one that is prevented by the "valid_from" field.

How will you handle this case without "valid_from"?
With transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig.  After 30 seconds (and every minute thereafter), the settling transaction is updated.  If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.

The update frequency can increase and decrease depending on value of payments and trust between parties.  The initial settling transaction could also include a connect fee to the server to prevent theft of the first 30 seconds service.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #10 on: June 03, 2015, 02:29:34 PM »
Quote
With transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig.  After 30 seconds (and every minute thereafter), the settling transaction is updated.  If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.

The update frequency can increase and decrease depending on value of payments and trust between parties.  The initial settling transaction could also include a connect fee to the server to prevent theft of the first 30 seconds service.

That could work and was also my first approach but has some risks.

If for whatever reason the client lost connectivity or the participation rate is low then there is a chance that the refund transaction wont make it to the blockchain and after that the transaction is expired.

So, even if it could work, you will be relaying on connectivity and participation rate.
On the other hand if i have (client) a refund transaction that has a valid_from in the future and a big expiration delta i can use the service with the confidence that in case of problems i will get my money back.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 936
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #11 on: June 03, 2015, 02:46:23 PM »
Quote
With transaction expiration. Ideally, both parties should first sign a transaction distributing the funds back to the client expiring in say a minute, then with that in hand, the client funds the multisig.  After 30 seconds (and every minute thereafter), the settling transaction is updated.  If one party fails to update, the other settles by broadcasting the last settling transaction before it expires.

The update frequency can increase and decrease depending on value of payments and trust between parties.  The initial settling transaction could also include a connect fee to the server to prevent theft of the first 30 seconds service.

That could work and was also my first approach but has some risks.

If for whatever reason the client lost connectivity or the participation rate is low then there is a chance that the refund transaction wont make it to the blockchain and after that the transaction is expired.

So, even if it could work, you will be relaying on connectivity and participation rate.
On the other hand if i have (client) a refund transaction that has a valid_from in the future and a big expiration delta i can use the service with the confidence that in case of problems i will get my money back.
I don't think low delegate participation is a serious risk factor in this, and it could be managed by decreasing the update frequency a bit.

If the client loses connectivity, the server will still want to be paid, and should therefore settle using the last transaction. Thus connectivity loss is only an issue if both lose connectivity, or if the remaining connected party refuses to settle. This risk can be mitigated by periodic settling when the stakes reach uncomfortable levels.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #12 on: June 03, 2015, 03:15:42 PM »
Quote
I don't think low delegate participation is a serious risk factor in this, and it could be managed by decreasing the update frequency a bit.

If the client loses connectivity, the server will still want to be paid, and should therefore settle using the last transaction. Thus connectivity loss is only an issue if both lose connectivity, or if the remaining connected party refuses to settle. This risk can be mitigated by periodic settling when the stakes reach uncomfortable levels.

I agree with you that the scenario in which both fail to broadcast the transaction is the real issue.
But is kind of a big issue since if that happens the server gets nothing and the client has all his funds locked in the multisig and that should be addressed in the protocol keeping more states in server side.

Don't blame me if I'm being over simplistic here.

But, wouldn't that change (the optional valid_from field) will have a low impact and won't require a hard fork, and will require only a new check in the transaction_evaluation_state::evaluate function?
« Last Edit: June 03, 2015, 05:44:37 PM by ElMato »

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 936
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #13 on: June 04, 2015, 02:20:01 AM »
Quote
I don't think low delegate participation is a serious risk factor in this, and it could be managed by decreasing the update frequency a bit.

If the client loses connectivity, the server will still want to be paid, and should therefore settle using the last transaction. Thus connectivity loss is only an issue if both lose connectivity, or if the remaining connected party refuses to settle. This risk can be mitigated by periodic settling when the stakes reach uncomfortable levels.

I agree with you that the scenario in which both fail to broadcast the transaction is the real issue.
But is kind of a big issue since if that happens the server gets nothing and the client has all his funds locked in the multisig and that should be addressed in the protocol keeping more states in server side.

Don't blame me if I'm being over simplistic here.

But, wouldn't that change (the optional valid_from field) will have a low impact and won't require a hard fork, and will require only a new check in the transaction_evaluation_state::evaluate function?

I think the risk is pretty low without "valid_from", and as I said periodic settling keeps it low.  Even with "valid_from", you're giving one party disproportional leverage over the other for settling, not actually solving the problem.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 269
    • View Profile
Re: Micropayment channel with bitUSD
« Reply #14 on: June 06, 2015, 12:17:47 AM »
Quote
I think the risk is pretty low without "valid_from", and as I said periodic settling keeps it low.  Even with "valid_from", you're giving one party disproportional leverage over the other for settling, not actually solving the problem.

Even if you do periodic settling the protocol must be extended to support "sessions", otherwise the client will never get its money back and the server will not get paid for the consumed service in case both missed the opportunity to publish their respective transactions.

Also forcing periodic settling has other implications in economics terms since, depending on the settlement frequency, the fees will quickly add up making the service more expensive or not viable at all.

Without forced settlement the server can charge a one time fee (equals to the network fee to publish the transaction) in the first transaction.

I cant see why one party has advantage over the other by using the "valid_form" field.

Every transaction that the client signs could have BTS_BLOCKCHAIN_MAX_TRANSACTION_EXPIRATION_SEC expiration given the server enough time to publish it. And the first transaction that the server gives to the client can have also expiration at MAX ...



It seems that we already have a sort of "valid_from" field already implemented....
Looking at the code in
https://github.com/BitShares/bitshares/blob/master/libraries/blockchain/transaction_evaluation_state.cpp#L145

If we set the expiration of the transaction to T0+3days => valid_from = T0+1days, giving us

valid_from = expiration - 2days

So it seems that we have everything in place to construct micropayments channels with bitAssets!!!!

 

Google+