Many very light wallets

Question

Hello,

  We have talked about this in other question, but to organize better the questions I have decided to open a new question.

  We need to deal with many user accounts (tens of thousands or even hundreds) , but we want this users have the lightest wallet possible in an Android device.

  We have think about three possibilities:

1.- One wallet for all of them with wallet address (getnewaddress). But in this case we think that we must isolate the rpcport from public, with a proxy that ensures that a user cannot send funds of other.

2.- One wallet for all of them but only with watch-only addresses. We have generated the address and private with Bitcoin compatible addresses, but deal with raw transactions and sign externally the transactions is not so easy.

3.- An SPV client in every android device, but this is not so light as we want, and the development effort is high.

Our questions are:

Do you have any experience or recommendation over theses approaches?

There is another solution we have not think about?

How is the scalability of the wallet on one Multichain node for approaches 1 and 2 ? How many address do you think is reasonable to have in one wallet. For example for users doing 5 transactions over assets in a week (in mean).

In case 2, related with watch-only addresses, can the wallet do combineunspent for those watch-only addresses? If not, can be this a performance problem?

Thanks,

   Fernando

Answer 1

You should definitely not expose the MultiChain RPC API of a node directly to thousands of end users, even if you use watch-only addresses. There are too many API calls that affect the node's processing (e.g. pause) to let users access it directly.

So either use SPV wallets for each Android user, or else introduce some kind of internal API which bridges the Android user to your server, and then your server communicates with MultiChain. You can still use watch-only addresses and mobile transaction signing in this case, and it's the safest option, though you have to think about what happens if users lose their device/keys.