Looking at ther verbosity flag I’m thinking that the abilty for someone to download the actual proof (hexdata) is a bit overly expensive as you put that in the verbosity=2.
Maybe the hex is what you want to return when verbosity is zero. And you never return the hex for higher verbosity, just the interpreted version. This seems more consistent with other bitcoind RPC calls.
@tom - Ok, verbosity flag is changed as per your suggestion. For getdsproof verbosity=false does what you expect, and dumps hex data (same as getblock false).
Note that the getdsprooflist command’s verbosity=false defaults to just a list of dspids. You need to do verbosity=1 to get the hex data in this “listing” mode (this is a command designed for polling… that’s why).
This now works more like getblock. Thanks for the suggestion!
FYI – Merge request for BCHN for this lives here now: RPC methods for the DSProof subsystem (!1026) · Merge Requests · Bitcoin Cash Node / Bitcoin Cash Node · GitLab
@tom The ancestors are relayed to the peer in addition to being added to the filter, sorry if this wasn’t obvious.
Its not a bad idea, but its not the best solution I’d work on today. Imagine your wallet is on mobile and the transaction is 500 deep.
@tom How can an electrum client validate the double-spend of one of those 500 ancestors without receiving them? Does the server say “trust me, this is one of your unconfirmed ancestors, and it has been double-spent”?
This is an excellent question.
As the current level of the stack people are working on is full node (and thus the input to electrumx protocol servers) it is likely that the next step is to talk about the protocol to talk between the electrumx server and its clients.
Everyone that has good ideas about how to do this in a smart way while still making it fast is needed to solve this in the best way possible.
Notifying of an additional RPC call that has been merged into BCHN’s master branch.
https://docs.bitcoincashnode.org/doc/json-rpc/getdsproofscore.html
Whether to release in current form is something that @cculianu has been thinking about, and I would invite others to give feedback on the call.