Conversation
Sosthene00
commented
Dec 17, 2025
Sosthene00
commented
- Give user a date for birthday on seed screen
- Ask user for a birthday on recover
- We're using the blockheight the wallet was created in and take the day that block was mined at 12am as an easy to remember proxy for the user. At worst we will scan a whole day worth of data for nothing.
Sosthene00
force-pushed
the
birthday
branch
3 times, most recently
from
574a00c to
a6ab3fe
Compare
|
Lots of improvements to handle offline wallet creation, I think that's an interesting feature to have, and no matter what it's also useful if services like mempool or blindbit or nameserver are temporarily down. Basically the idea is that user can create a new wallet while having 0 network, but will get stuck at the dana address register step with an offline screen that just let him share payment code with a qr code and copy paste it so that it can still be paid on the spot. As soon as network's back normal flow resume. |
Sosthene00
force-pushed
the
birthday
branch
3 times, most recently
from
530885f to
88a7535
Compare
This was residue from back when we used to store the json-serialized SpWallet struct in the flutter secure storage directly. Having this makes #243 more difficult, so we remove it here.
This was residue from back when we used to store the json-serialized SpWallet struct in the flutter secure storage directly. Having this makes #243 more difficult, so we remove it here.
This was residue from back when we used to store the json-serialized SpWallet struct in the flutter secure storage directly. Having this makes #243 more difficult, so we remove it here.
Sosthene00
force-pushed
the
birthday
branch
5 times, most recently
from
7ddaa33 to
d91fb3d
Compare
|
Two general comments:
const String _keyBirthdayLegacy = "birthday";
const String _keyBirthdayTimestamp = "birthdaytimestamp";
I will try to work on these points tomorrow |
It may be a bit more readable now though.
As for the other comments I agree with it and will make the necessary changes. |
|
Addressed your comments, except for having a separate key in storage and a separate getter for legacy birthday stored as block height, it was easier for me to keep things as they are now. What I do is that I still convert a block height into a DateTime, obviously a block height will give a Date long in the past, close to beginning of epoch time. If that date is before defaultBirthday, then it is interpreted as a block height. |
Hardcode a default `DateTime` for all network, 1st June of 2025 for now.
* `getBlockForHash`: needed to retrieve the timestamp of a block * `getBlockHashForHeight`: retrieve the block hash from its height * `getBlockFromTimestamp`: used to get the height of the closest block from a timestamp
Add `toSeconds()` method to `DateTime` and a `toDate()` method to `int`
Birthday becomes a DateTime (stored as unix timestamp) instead of a block height integer. Includes migration logic for existing wallets that still have a block height stored.
* add a ticker box on Seed Phrase Recovery screen * if ticked open birthday picker * if user does'nt provice a birthday set network default
Minimum allowed birthday can be used for two purposes: - In date picker screen, to set a sensible minimum - During wallet recovery, we parse Datetimes before this timestamp as a legacy birthday (block height)
|
2c55de4: ACK, if I really wanted to nit I'd say why not choose Dana creation as minimum birthday too, but nevermind |
Thinking about this some more, I propose that we actually do allow birthday to be |
Let's keep it simple and move on, that's a very limited edge case and fixable if user can change birthday. |
Make birthday variable in WalletState non-nullable. In case we can't get the birthday variable, use a default birthday. This only happens when wallets upgrade from legacy birthday format (using block height) and there's a connection error.
When creating a new wallet, set lastScan to current block height. Before, this would be lazily initialized by the chain synchronization service, but I think setting it immediately on wallet creation is preferable.
This was residue from back when we used to store the json-serialized SpWallet struct in the flutter secure storage directly. Having this makes #243 more difficult, so we remove it here.
2 participants
