[#1411] Refactor AccountBalance to use Balance for transparent funds #1570
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1570 +/- ##
==========================================
+ Coverage 56.30% 56.67% +0.36%
==========================================
Files 148 148
Lines 19062 19137 +75
==========================================
+ Hits 10733 10845 +112
+ Misses 8329 8292 -37 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Changes required.
Note that tests passed despite the bug of not checking the overflow invariant in AccountBalance::add_unshielded_value. The suggested replacement code obviously does maintain the invariant because it only uses other public methods, but still we might want more test coverage here.
|
Thank you for the thorough review! I'll be addressing these comments shortly. |
pacu
force-pushed
the
feature/transparent-balance
branch
from
3734cda
to
68b9725
Compare
pacu
force-pushed
the
feature/transparent-balance
branch
from
d49ebd3
to
f706b33
Compare
pacu
force-pushed
the
feature/transparent-balance
branch
from
f706b33
to
da30040
Compare
There was a problem hiding this comment.
The changes to (This was fixed.)AccountBalance should be documented in the CHANGELOG for zcash_client_backend, not zcash_primitives.
Also, the fix to (This was also fixed.)zcash_client_sqlite's implementation of get_wallet_summary, along with its remaining limitations, should be documented in the CHANGELOG for zcash_client_sqlite:
### Fixed
- `zcash_client_sqlite::WalletDb`'s implementation of
`zcash_client_backend::data_api::WalletRead::get_wallet_summary` has been
fixed to take account of `min_confirmations` for transparent balances.
Note that this implementation treats `min_confirmations == 0` the same
as `min_confirmations == 1` for both shielded and transparent TXOs.
It also does not currently distinguish between pending change and
non-change; the pending value is all counted as non-change (issue
[#1592](https://github.com/zcash/librustzcash/issues/1592)).
pacu
force-pushed
the
feature/transparent-balance
branch
3 times, most recently
from
4be5ae8
to
b291e3d
Compare
| WHERE ( | ||
| t.mined_height < :mempool_height -- tx is mined | ||
| AND :mempool_height - t.mined_height >= :min_confirmations -- has at least min_confirmations |
There was a problem hiding this comment.
This looks wrong to me. mempool_height is typically chain_tip_height + 1. mined_height is at most the chain tip height, or null, so changing the query in this fashion is introducing a footgun for zero-conf shielding.
Also, :mempool_height - t.mined_height will be NULL when mined_height IS NULL, which then will always cause this condition to fail.
Instead of using :mempool_height directly, compute a balance_height outside of the query from the mempool height and min_confirmations, and then query against that height here, accounting for mined_height being allowed to be null in the case that min_confirmations == 0.
There was a problem hiding this comment.
This looks wrong to me.
mempool_heightis typicallychain_tip_height + 1.mined_heightis at most the chain tip height, or null, so changing the query in this fashion is introducing a footgun for zero-conf shielding.
Is Zero-conf shielding something that should be address here? I understood it was not.
Also,
:mempool_height - t.mined_heightwill beNULLwhenmined_height IS NULL, which then will always cause this condition to fail.
In this particular query a pre-condition is that the TX is mined so I guess desirable that the condition is evaluated to FALSE.
Instead of using
:mempool_heightdirectly, compute abalance_heightoutside of the query from the mempool height andmin_confirmations, and then query against that height here, accounting formined_heightbeing allowed to be null in the case thatmin_confirmations == 0.
This sounds like a good idea.
There was a problem hiding this comment.
Is Zero-conf shielding something that should be address here? I understood it was not.
No, we'll need another PR for that. The current code appears to work as documented: min_confirmations == 0 behaves the same as min_confirmations == 1. I don't think we should complicate this PR to make zero-conf shielding work; it's obvious that this code will need to change to support that, and there's no regression for any case as of this PR.
There was a problem hiding this comment.
Btw @nuttycom did you see this? #1413 (comment)
…unds closes zcash#1411 - Adds min_confirmations to transparent account balances - Adds a new `transparent_balance_spendability` test to verify transparent funds spendability. - cargo clippy + cargo fmt Refactor: Extract Method on lambda `check_balance`
properly verify `min_confirmations` assumptions
pacu
force-pushed
the
feature/transparent-balance
branch
from
78a5927
to
f96f045
Compare
|
I think I chewed a doc commit with this rebase from main and fix. I'll review all the changes and then ask for review |
fixes #1411