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