Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement darkside counterpart for z_getsubtreesbyindex method #464

Closed
pacu opened this issue Nov 1, 2023 · 2 comments · Fixed by #469
Closed

Implement darkside counterpart for z_getsubtreesbyindex method #464

pacu opened this issue Nov 1, 2023 · 2 comments · Fixed by #469

Comments

@pacu
Copy link
Contributor

pacu commented Nov 1, 2023

What is your feature request?
Implement darkside z_getsubtreesbyindex method

Similarly as it is done with TreeStates we could expose some darkside RPCs that allow tests to add SubTreeRoots to a cache

How would this feature help you?
Currently, ECC SDK can't run the darksidewalletd tests because this method is missing.

-[DarksideTests.AdvancedReOrgTests testReOrgChangesInboundTxMinedHeight] : failed - Failed with error: serviceSubtreeRootsStreamFailed(ZcashLightClientKit.LightWalletServiceError.generalError(message: "there was an attempt to call an unsupported RPC: z_getsubtreesbyindex"))
@LarryRuane
Copy link
Collaborator

Which of the following two options is easier, better for you for the darkside gRPC's interface?

  • add a single subtree entry (arguments would be index, merkle root hash, end height)
  • add an entire list (array) of subtree entries, which would replace the existing array?

Or something else?

@pacu
Copy link
Contributor Author

pacu commented Nov 30, 2023

Which of the following two options is easier, better for you for the darkside gRPC's interface?

  • add a single subtree entry (arguments would be index, merkle root hash, end height)
  • add an entire list (array) of subtree entries, which would replace the existing array?

Or something else?

I think the first case will make the interface equal or similar to the TreeState one won't it? I would go for that for the sake of an uniform api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants