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

0 Members and 1 Guest are viewing this topic.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • 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"?

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. 

Offline ElMato

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

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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?

Offline ElMato

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

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

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
would this work for recurring payments too?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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

Offline ElMato

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