Description
Slatepack currently always uses address index 0. RFC 0015 suggests using a fresh address for each transaction while keeping index 0 as a stable public address.
Address rotation needs a broader design for index allocation, Tor listeners and recovery after restoring a wallet from seed. Without storing the derivation path in the Slatepack, restored wallets would have to search through derived keys to find the correct one.
This should therefore not be implemented as part of the contracts work. Contracts will continue to use address index 0 until Slatepack address rotation is handled consistently across the wallet.
One option would be to allocate and store an address index atomically for each transaction. If the wallet is later recreated from the seed, its stored indices are lost. How does it find Slatepacks encrypted for previously used addresses, and how does it choose the next index without reusing an old address?
Related
RFC 0015: Slatepack
grin-rfcs#55
grin-wallet#456
grin#3769
Description
Slatepack currently always uses address index 0. RFC 0015 suggests using a fresh address for each transaction while keeping index 0 as a stable public address.
Address rotation needs a broader design for index allocation, Tor listeners and recovery after restoring a wallet from seed. Without storing the derivation path in the Slatepack, restored wallets would have to search through derived keys to find the correct one.
This should therefore not be implemented as part of the contracts work. Contracts will continue to use address index 0 until Slatepack address rotation is handled consistently across the wallet.
One option would be to allocate and store an address index atomically for each transaction. If the wallet is later recreated from the seed, its stored indices are lost. How does it find Slatepacks encrypted for previously used addresses, and how does it choose the next index without reusing an old address?
Related
RFC 0015: Slatepack
grin-rfcs#55
grin-wallet#456
grin#3769