-
Notifications
You must be signed in to change notification settings - Fork 92
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
[WIP][RPC] RingCT output overhaul #688
base: master
Are you sure you want to change the base?
Conversation
This debug information was only temporarily added to check out some stuff.
Cleaner to add in an overload method than to pass in anything empty. Lots of duplicate code so this absolutely can be improved greater than this. The reason for this is that veil-tx and some test files will fail to build if `GetTxRingCtInputs`is there.
This should be faster to do it like this. I'm not sure why the other class was considered.
We need the RPC to be able to display the key images for RingCT. This allows us to extend Veil more beyond just Veil Core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 0eac106
A few trivial changes and noted todos.
Copyrights added to changed flies and commented line removed as per review request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 3abedee
The count up from 0 is too much and the map itself should've been sequential. Erasing the map and putting it all together as an array makes a lot more sense.
`data_hex` in this context is infact the ephemeral public key. Best to name it as such. Also, the `objKeyImage` is in fact `arrKeyImage`. Missed that on my go through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 9cd1242
Once these changes are final we should rebase to one commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK - Definitely rebase when merging so this can be cherry picked more easily
Visually, it didn't look great at all to lump all the commitment, inputs, and key_images together when they are related to one another in groups. This is meant to visually represent that accurately. This should make it easier to turn the Json into objects from other clients and make representation in explorers better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK f6ea7a1
rebase would be the only other item.
UniValue o(UniValue::VOBJ); | ||
ScriptPubKeyToUniv(s->scriptPubKey, o, true); | ||
entry.pushKV("scriptPubKey", o); | ||
entry.pushKV("data_hex", HexStr(s->vData.begin(), s->vData.end())); | ||
entry.pushKV("valueCommitment", HexStr(&s->commitment.data[0], &s->commitment.data[0]+33)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will want to make 33 at const as some point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a const for 33 is added as part of #696
src/core_write.cpp
Outdated
const std::vector<uint8_t> vKeyImages = txin.scriptData.stack[0]; | ||
UniValue arrKeyImage(UniValue::VARR); | ||
for (unsigned int k = 0; k < nSigInputs; k++) { | ||
arrKeyImage.push_back(HexStr(&vKeyImages[k*33], &vKeyImages[(k*33)+33])); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will want to make 33 at const as some point?
I'll get this rebased once I wake up. This has to make it into the 2.0 branch as it will break RPC backwards compatibility. |
In that case we should create a 2.0 branch and revise the PR to be a merge request into the 2.0 branch; so it doesn't accidentally get pushed into master. Probably a good thing to do in conjunction with the rebase and conflict resolution. |
I have been going through again trying to find where this won't be compatible with the current chain, but I can't pinpoint exactly. We will need to tie that portion to the hardfork marker; since I believe the intention is to hardfork via rejecting old protocols a certain amount of time after release, to allow for enough 2.0 nodes to be upgraded. e.g. |
We talked about this, it isn't about chain incompatibility. The software implements the Veil protocol which has it's own versioning (protocol version). We can have a hard fork and the software wouldn't go up a major version as its own RPC API is still backwards compatible. This is a major change to the RPC API to provide more for external software that needs to build independent RingCT transactions. Thus, breaking compatibility for current users of our RPC API for that method. |
This is going back to WIP until I can fix it up and change somethings post Veil RingCT Staking. |
@Zannick This should have been committed a long time ago. Can you please review this in the light of your RingCT PR, and we'll see if we can test both PRs together? |
Problem
RPC needs to be expanded to allow for key images to be revealed. This PR is meant to give the RPC the necessary outputs in the proper locations to allow us to extend the RingCT protocol of Veil outside of Veil Core. This is required for future Veil prospects such as Veil "Link" server and client as it needs to be able to get the key_images.
Root Cause
It never has been included in the RPC before, even with the inherited code.
Solution
Adding it to the method that allows us to serialise our transactional data to JSON.
Testing Results
Following RPC commands were update:
getrawtransaction
decoderawtransaction
getblock
This builds upon #686 by @codeofalltrades.
Example output:
Additional
The code that is in the
debug
section of the JSON output ofgettransaction
was deleted to conform with standard Bitcoin RPC protocol.