Add command to allow service provider claiming funds from channel

[vsbogd]

At the moment channel claiming is implemented within snet-daemon through snet-daemon claim interface. This command should be moved into the snet-cli tool.

Possible way to implement it is to add additional gRPC interface to the daemon to:

• claim payments
• list payments in progress
• list channels

This interface will be implemented by separate daemon instance: treasurer server.

Use this interface to implement snet-cli claim command.

See https://github.com/singnet/snet-cli/issues/134#issuecomment-443182697 for more detailed description

[astroseger]

There is a problem.

Which ethereum identity will be used? snet-cli identity or identity of this instance of the daemon?

1. I propose to agree in terminology. I propose to call "the treasurer server" the system which actually sign transaction on behalf of service provider.

Now I can ask the main question. Who will be the treasurer server (who will sign the transactions): snet-cli or the instance of the daemon?

Because if it will be the daemon, then it kind of break all logic of snet-cli as owner of identity.

[astroseger]

I would argue that in the beta, it would be better to make snet-cli the treasurer server (only snet-cli will actually send transactions). It will allow as to solve the following issues in one place:

• https://github.com/singnet/snet-cli/issues/111 (poor usability on the slow main net)
• https://github.com/singnet/snet-cli/issues/67 (algorithm of sending transaction which will actually work on the main net)

Because if we send transaction in snet-cli and in the daemon we need to solve these issue in two places.

[vsbogd]

1. It will be code duplication: to write this server properly in snet-cli you will need to reproduce the code which is already implemented in daemon.
2. Also supporting this infrastructure in daemon code base is simpler, because you have all things which plays with internal storage in one place.
3. Anyway one need clear interface for claiming and daemon already has it, the only work which should be done is to provide snet-cli access to this API.

https://github.com/singnet/snet-cli/issues/111 and https://github.com/singnet/snet-cli/issues/67 can be solved in daemon code base as well.

[vsbogd]

Results of offline discussion with @astroseger:

• snet-daemon already has an API to work with payments (see godoc) such as:
  • StartClaim()
  • Claim.Finish()
  • Claim.Payment()
  • ListClaims()
• make gRPC API using API above to manage claims in snet-daemon
• use this API in snet-cli to implement claim command
• snet-cli can manage Ethereum transactions internally like it does it now for Registry or MPE contracts
• snet-cli interface for Ethereum transaction management could be improved further; in general it could be aligned with common approach used in existing Ethereum based DApps
• it is not very natural to implement adaptive algorithm described in https://github.com/singnet/snet-cli/issues/67 in snet-cli, more natural is to use separate service like treasurer to control transactions automatically and make snet-cli to be console to this service.

[astroseger]

@raamb So the questions is: who will do it in the daemon?

[raamb]

@astroseger the Bangalore team will pick this up.

[raamb]

Discussed with @astroseger about this. We have a functional way of claiming funds for now, we will evaluate if this is absolutely required for Beta or not. As Sergey pointed out if Daemon is unable to support hardware wallets etc we will have to get this done. Initial estimates indicate that it would be 2-3 man days worth of work.

[pennachin]

This is required for the beta, of course. Unless I'm missing something, there is no reason the daemon should even know about hardware wallets, etc. The daemon is a server-side deployment component, it should not be the component signing these mainnet transactions. The cli is a "service owner admin" component, it makes far more sense for any signing of "real money" transactions to be done there.

One of the reasons for the Arbiter contract design was to prevent having to give the daemon private keys to a meaningfully funded wallet. That's still a requirement.

[vsbogd]

The way it is implemented right now means that daemon doesn't need access to the private key to collect and validate the payments. But to implement collecting payments as soon as possible we have implemented separate console tool which reuses daemon code to claim the payments. This tool can be used separately from daemon and its configuration. I agree that it makes sense to move payment management cli into snet-cli tool, but it requires additional development.

[astroseger]

@pennachin

In the current implementation "snet-daemon" has two completely separated components "the daemon" and "the treasurer server".

• Daemons do not have any Ethereum identity.
• "the treasurer server" has separate config and he has the Ethereum identity.

But in the current implementation "the treasurer server" is very "thin". It is actually a command line tool.

It makes a lot of sense to move "the treasurer server" functionality to snet-cli. It will make snet-cli only one owner of Ethereum identity. And, as I understand, it is very easy to do (see description from @vsbogd ).

And in the future I would suggest to build the real " treasurer server" around snet-cli, in order to have single Ethereum identity manager.

[pennachin]

@astroseger this makes a lot of sense to me.

[vforvalerio87]

@astroseger agreed; much more elegant

[raamb]

I guess my comment "Daemon is unable to support hardware wallets etc" was the cause of some confusion, my apologies. I was referring to the treasurer component of the daemon by this statement not the Daemon itself.

[astroseger]

was closed with #162