Currently, the Android wallet can already be used as a cold wallet:
- Use a fresh (factory reset) Android device and don't set up any Wifi connections
- Use flight mode and don't insert a SIM card
- Install the Android app by sideload
- generate your wallet
- Done - you have a cold wallet
This works, but the experience is subpar because the app tries to connect to the network and shows zero balance. The UI could be improved: There could be a setting that switches to "Cold wallet" mode. In this mode, there is no attempt to retrieve information and the wallet list will not show any balances any more. Additionally, in this mode, a big warning can be shown when a network connection is detected.
These UI improvements can be done without problems, however, as soon as you want to access your funds, you need to connect and the wallet goes from cold to hot. In theorey, that is not necessary: A second - connected - device with only the public address could prepare the unsigned transaction, this transaction can be transferred to the cold wallet device by QR code, the transaction is then signed and transferred back by QR code and the cold wallet never needs to connect to the internet.
Discussion with @aslesarenko : https://discord.com/channels/668903786361651200/669207683869573142/869136961904996382
A POC should be implemented to see if this is viable to add to the app and have a ledger alternative for people owning a second, not needed Android device.
In most of the cases full context data is not required, but in any case each input box requires proof (aka signature) to be generated, which is done by this method https://github.com/ScorexFoundation/sigmastate-interpreter/blob/de6220fefd5738ea7984ebb18e088d0da9f58f3c/sigmastate/src/main/scala/sigmastate/interpreter/ProverInterpreter.scala#L117
It is possible to implement optimised serialization/deserialization of the Context data storing only necessary data. Each ErgoTree can be analysed on which context data is actually used in the contract and only those data need to be serialized and passed to the Cold Wallet.
In most of the cases the context data set is actually small, so the implementation can be generic (but may be quite involved).
The first PoC version can support P2PK addresses only, in which case context data in not needed, and some dummy Context can be created in Cold Wallet App, to be passed in prove method above.
Open questions:
- Inboxes need to be serialized, sent to the cold wallet, and validated to show the user what is withdrawn
- How to determine which key is needed to sign? Easy for p2pk addresses, but for general scripts it is not apparent
enhancement