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_partyIt 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?
struct transaction
{
fc::time_point_sec expiration;
optional<fc::time_point_sec> valid_from;
optional<uint64_t> reserved;
vector<operation> operations
....