Notes

- How to recieve funds with static string? LN-URL compatibility?
- Can wallets use HD-wallet like technique to deterministically derive state?
Each provider would have to provide some seed input, for checking state on
that provider. If you could derive a token, you could blind it and ask the
provider if it was valid. However you wouldn't know the amount, which might
be necessary to derive full token.
- Do it in rust, so it's fast, secure, and can be used by mobile wallets
- abstract over providers with API (can move from custodial to non custodial
and back easily)
- AMP so you can keep funds with multiple providers
- Can leave provider easily by just draining wallet to another provider
- Can use Chaumian cash system that hides: user account balances from provider,
don't know which user is doing which transaction
- By separating frontend from backend, anyone can run a custodial wallet
backend (for friends, etc)
- Liquid integration for lower fees
- Client side wallet
- Everything over tor
- Transfer between providers
- Use multiple providers
- Why not hosted channels?
- transition from self-hosting
- accept reality that many will use custodial. give them smooth transition to non-custodial
- competitive landscape and interoperability of email is its killer feature
- self-custody of on-chain funds, custodial lightning wallet
- why self-custody of lighting is hard: channels close randomly, lose funds due to fees, bad behavior in high fee environments (pay high fees at best, lose funds at worst)
- for privacy, only thing that you can do with on-chain funds is open channel and loop out?
- Can you deposit with on-chain funds to provider A, then move to another provider?
- liquid interop?
- exchanges can implement the protocol to give customers wallet.
- get users by offering free transfer to/from exchanges
- charge small fee on transactions
- proof of reserves
- open source the wallet (desktop, ios, android, web)
- web version how?
- state backup how? encrypted backup with provider(s)?
- no selective censorship. must censor all users or no users.
- could support non-bitcoin cryptocurrencies. However, would greatly complicate wallet, and make it harder to support bitcoin well. Writing as if I weren't a bitcoin maximalist. Different coins have different technical properties, which make it challenging to support them all well. RBF, script types, etc.
- AMP to make amounts smaller and more uniform
- internal transfers?
- POP3/IMAP API is very important
- bitcoin wallet protocol
- application layer internet standard protocol
- providing this service increases own anonymity set. You can run your own backend, and encourage others to use it
- Makes lightning network surveillance very hard, since single channel is shared by many users
- future of lightning is mostly custodial, this is okay, similar to email. Not as good as all self custody sovereign individuals aiming down their up-pulled bootstraps with their 3d printed guns, but still good. Diversity of software, balance is portable, no lock-in, much competition, can always transition to self-custody seamlessly, businesses can self custody when it makes sense.
- unrealistic for normies to understand balance decrementing due to channel close/open fees, balance unavailable due to channel open/close, concept of inbound liquidity, need to stay online/trust watchtowers
- service provider going out of business notice
- white label wallet just binds to particular service provider
- Nice wallet architecture / protocol / client