A receive-only online wallet server. This should have some well-known network address that can be reached by a client. There should be a spending key kept offline.
I think this is a good idea. Users will expect to be able to receive payments anytime, even if they are offline. I bet many users would be willing to trust their receive key to a wallet provider who runs a receive-only server on their behalf. And they are unlikely to go through the hassle of setting up a personal, always-on wallet server with access to their private key. Even DHT/nat tunneling doesn’t really solve this problem for users that don’t have an always-on computer.
However it looks like receive-only keys are not implemented. I see a “TODO figure out what’s needed for the bulletproof.” in design.md.
Transactions with split spend/receive keys are over my head. How is this going to work?
The only way I see this working (without just handing over your private keys to a third party that you fully trust with all received funds), is if a wallet manufacturer like Ledger produces a receive-only hardware wallet that you can setup with your existing master key (24 word list) and then hand over to a third party. Said party can now receive funds through some online webpage or API and have the wallet produce new outputs, signatures and rangeproofs, but they won’t be able to extract any private keys or spend any output.
Thanks @tromp. Interesting idea to protect the private key with special hardware.
OK so I won’t hold my breath for separate spend/receive keys.
Other ideas about wallets: the only “usually online computer” that many people have is their phone. So maybe a mobile app that accepts payments through push (and saves the private key in the OS keychain) would be a good solution for now.
no need to buy some - just join us on gitter and ask someone to send you some. You’ll need your wallet URL in the form of http://ip.of.your.walletserver:port/ .
- just join us on