Implement tracking of ZIP 48 transparent multisig accounts#2144
Implement tracking of ZIP 48 transparent multisig accounts#2144nullcopy wants to merge 6 commits intozcash:mainfrom
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2144 +/- ##
==========================================
- Coverage 73.86% 73.29% -0.57%
==========================================
Files 227 229 +2
Lines 37518 37838 +320
==========================================
+ Hits 27712 27735 +23
- Misses 9806 10103 +297 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
nullcopy
force-pushed
the
feat/COR-132/1361-full-transparent-coin-tracking
branch
from
c360cd5 to
fd60c3e
Compare
|
Just discovered #1153 which should be part of this discussion, as the root cause of most challenges in this PR is the requirement for a UA to contain a shielded receiver. |
nullcopy
force-pushed
the
feat/COR-132/1361-full-transparent-coin-tracking
branch
4 times, most recently
from
e764821 to
7495f1f
Compare
|
Force pushed to fix test build errors |
nuttycom
left a comment
nuttycom
left a comment
There was a problem hiding this comment.
Flushing a few comments from review.
| AND hd_seed_fingerprint IS NULL | ||
| AND hd_account_index IS NULL |
There was a problem hiding this comment.
This makes me think that the hd seed fingerprint and hd account index should potentially no longer be part of the account table; instead, maybe they should be stored in something like an account_derivation table that foreign keys to this one? This relates to my comment about AccountPurpose.
nullcopy
force-pushed
the
feat/COR-132/1361-full-transparent-coin-tracking
branch
from
3fd60d3 to
e787251
Compare
|
Force pushed to rebase onto main and address PR feedback |
nullcopy
force-pushed
the
feat/COR-132/1361-full-transparent-coin-tracking
branch
2 times, most recently
from
5cc8405 to
bdab817
Compare
|
Sorry... had to force-push again to resolve conflicts with the merge base and trigger CI Also fixed a bug in the ZIP 48 multipath descriptor tests |
This commit adds a ZIP 48 account type and the methods necessary to create/import such an account, to the backend interface.
This commit adds changes the database schema and implements the backend API necessary for view-only support of ZIP 48 multisig accounts.
This commit adds methods to get addresses for a ZIP 48 account.
This commit implements the ZIP 48 address retrieval methods: * get_next_zip48_multisig_address() * get_zip48_multisig_address_for_intex()
This commit implements `PartialOrd` and `Ord` on `AccountPubkey`. Then sort `key_info` so that ZIP 48 multipath descriptor will have a canonical encoding.
nullcopy
force-pushed
the
feat/COR-132/1361-full-transparent-coin-tracking
branch
from
dc51ecd to
c509e83
Compare
|
Force pushed to rebase and drop the |
Before this, clippy complained that `insert_zip48_multisig_address()` required too many arguments. This commit bundles related arguments into a tuple, to cleanly address the issue.
| FROM addresses | ||
| WHERE account_id = :account_id | ||
| AND key_scope = :key_scope | ||
| AND redeem_script IS NOT NULL", |
There was a problem hiding this comment.
I think we should take the "diversifiability" of an address from information at the account level; this query seems fragile to me in the presence of adding other types of redeem scripts.
3 participants
This PR implements support for balance tracking of ZIP 48 transparent multisig accounts. This is a first step towards general P2SH account tracking.
I wanted to get feedback on this, before deciding how to approach general P2SH account support.
resolves #2197
resolves COR-1068