Author Topic: Micropayment channel with bitUSD  (Read 5342 times)

0 Members and 1 Guest are viewing this topic.

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
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.

 +5% +5%
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

TravelsAsia

  • Guest
Are you still looking into this approach?

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
You need the withdraw conditions on the blockchain to have a timestamp condition built into them to "lock up the funds" and the structure of these transactions is not compatible with what we have planned for Monday.

That said, the value of this kind of micropayment channel is not lost on me and we are looking into options.

Thanks Dan.


At the risk of being a repetitive-dumb i would like to write this example.
Will it work with what is planed for Monday?


Service: Voip provider
Cost: 0.2 USD  per minute
Network fee: 0.01 USD
Client wants to talk at most 25 minutes. (5 USD)

Client: Connects to server, send client pubkey for the session, ask for server public key.
Server: Calculate multisig balance, send pubkey for the session.
Client: calculate multisig balance = F(server_pubkey, client_pubkey)
Client: Build a tx with expiration = NOW + 3 Days withdrawing 5 USD from the multisig balance to himself and send to server for signing
           (This tx can be broadcasted from NOW + 1 Day)
Server: Signs the tx and send back to client.
Client: transfer from his account 5 USD to the multisig balance.
Server: Detect transfer to multisig balance.
Server: Build tx with expiration in NOW + 2 Days with:

            network fee + 0.20 USD => Server
             4.79                                 => Client

Client: signs tx and send back to server.

-------
voip client start
-------

1 minute pass

Server: Build tx with expiration in NOW + 2 Days with:

            network fee + 0.40 USD => Server
             4.79                                 => Client

Client: signs tx and send back to server.

1 minute pass
 
Server: Build tx with expiration in NOW + 2 Days with:

            network fee + 0.60 USD => Server
             4.79                                 => Client

Client: signs tx and send back to server.

some seconds pass
 
-----
Voip client hangs
-----

Server: Broadcast last transaction because he wants to get paid for the 3 minutes of service.
[multisig]
     |----------> 0.60 to Server
     |----------> 4.39 to Client
     |----------> (0.01 network Fee)


In case the server hangs .. the client has 2 days since T0+1Day to claim his 5 USD.


Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • View Profile
You need the withdraw conditions on the blockchain to have a timestamp condition built into them to "lock up the funds" and the structure of these transactions is not compatible with what we have planned for Monday.

That said, the value of this kind of micropayment channel is not lost on me and we are looking into options.
Kinda like nLockTime? Is there an checklockverifytime equivalent?
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline bytemaster

You need the withdraw conditions on the blockchain to have a timestamp condition built into them to "lock up the funds" and the structure of these transactions is not compatible with what we have planned for Monday.

That said, the value of this kind of micropayment channel is not lost on me and we are looking into options.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
Quote
Without the "valid_from" system, after a session has been broken and all settling transactions expired, the two parties are forced to come to a mutually acceptable agreement, or neither gets anything.
Using the "valid_from" field, once the "valid_from" date passes, the client can claim the entire pot, or whatever percentage was pre-arranged before the session took place.

True, but this can only happen if the transactions the client signs have short expiration.

But since this transactions are generated by the server, the server can say "hey .. sign me this tx that expires in 2 days to continue using the service for X seconds".

And if the channel goes down, the server has plenty of time to publish the last transaction signed by the client.
   

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
This approach will not work with BTS.

Bytemaster, which part will not work?
I can't see why not  ???


Offline bytemaster

This approach will not work with BTS.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
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!!!!

Without the "valid_from" system, after a session has been broken and all settling transactions expired, the two parties are forced to come to a mutually acceptable agreement, or neither gets anything.  Using the "valid_from" field, once the "valid_from" date passes, the client can claim the entire pot, or whatever percentage was pre-arranged before the session took place.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
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!!!!

Offline Troglodactyl

  • Hero Member
  • *****
  • Posts: 960
    • View Profile
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: 288
    • View Profile
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: 960
    • View Profile
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: 288
    • View Profile
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: 960
    • View Profile
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.