search

lukechampine / walrus

A wallet server for Sia
https://lukechampine.com/docs/walrus
MIT License
12 stars 0 forks source link

Proposal: Remove hot wallet server #3

Closed lukechampine closed 5 years ago

lukechampine commented 5 years ago

Currently, walrus can be used as either a "hot" wallet (allowing it to sign transactions for you) or as a "cold" watch-only wallet, where the server does not store your seed or keys and only you can sign transactions.

Hot wallets are convenient, but less secure; I certainly can't recommend that anyone use the hot wallet server today, since the API is completely unauthenticated. Even if I did add authentication, I don't like the idea of an always-on server that keeps your seed in memory. Instead, all walrus servers should be watch-only servers, and seed management + signing should be delegated to the client. This significantly simplifies the implementation and documentation of walrus. It also removes a possible point of confusion around narwal (which only provides a watch-only walrus instance, not a hot wallet).

In tandem with this change, I will replace the hot wallet client of us with a watch-only client that also stores the seed, allowing it to implement the proto.Wallet interface. The user can then be prompted to enter their seed whenever they need to sign a transaction or generate a new address, e.g. when forming a file contract. This will make it possible to use programs like user with a narwal instance, such that a person possessing only some SC on an exchange can start uploading and downloading immediately, never downloading the blockchain. They could even do so with a hardware wallet -- except that, unfortunately, the Ledger Nano S app does not support file contract transactions. So I would need to either add support for those, or the user could accept the reduced security of signing an opaque hash.

Relatedly, I would like to move the /seedindex routes to the watch-only wallet. Originally, I intended for the watch-only wallet to be highly generic, i.e. it would allow you to associate arbitrary metadata with arbitrary addresses. But my thinking has changed, and now I believe that it's best to assume that all addresses are seed-based addresses (with an associated index), and that watch-only wallets should only watch addresses for which they possess the unlock conditions. True watch-only wallets are niche enough that custom support can be added later if there is sufficient demand.

lukechampine commented 5 years ago

A consequence of this is that the wallet server can no longer automatically increment its seedindex in response to seeing a wallet-owned address appear on-chain. This is unfortunate, but honestly not a huge loss. Such functionality is mainly useful when using the same wallet across multiple devices without a coordinating server, and when rescanning the chain from scratch. Both usecases can be addressed explicitly, via rescanning code and a special non-server "shared" hot wallet.