Jack Grigg
Jack Grigg
I'm not keen on a biflag approach, because: - it attempts to subdivide a space that was not designed to be subdivided; - it is still susceptible to forks accidentally...
For future reference: I encountered this error while trying to query Zallet for a coinbase transaction. The wallet in question was recovered from seed and had only 2 transactions without...
We unblocked #1625 by adding parallel build methods instead of refactoring the existing one.
Here is AFAICT the flow graph for how both `transactions.block` and `transactions.mined_height` are set. - The dotted lines are when `transactions.block` is only set if a corresponding scanned block exists...
Attempted sketch of an event sequence that could give rise to this error condition. ⚠️ indicates inconsistencies with the error conditino (invalidating the event sequence). - The Swift SDK's `UTXOFetcher`...
> `expired_unmined` is set in the view like so: > > https://github.com/zcash/librustzcash/blob/a26e7aefebb55fcdbea6a7328e5dfff60b3a733a/zcash_client_sqlite/src/wallet/db.rs#L957-L960 > > The issue for these transactions is presumably then that `blocks.height` is incorrectly set to null, and...
In a meeting today, @daira @nuttycom and I discussed how wallet apps should identify accounts. We discussed several options, including deriving a persistent account-level identifier from the seed phrase, or...
> This doesn't need to be something that's exposed at the `zcash_client_backend` level Not having encoding functions at the `WalletRead` level makes for potentially inconsistent UX (hard to tell given...
> While the value can be opaque, it _should_ be serializable. I already said this above: > - Augment `AccountId` with the ability to encode to, and parse from, opaque...
#1631 implements the UUID-per-account approach.