feature: add InstantLock and ChainLock data buffers in Core RPC #6391
Assignees
Milestone
Comments
|
Proposals related to and motivated by this issue: https://www.dashcentral.org/p/DCD_RPC-Web-Proxy-Explorer_2024-Q4-fixed https://www.dashcentral.org/p/Dev_Web_SDK-Platform_Id_with_Explorer https://www.dashcentral.org/p/Dev_P2P_and_ZMQ_Explorers Having IS/CL data in the Core RPC would likely improve certain use cases, but being able to work around this with separate services is a reasonable trade off until addressed more thoroughly. |
|
I expect this to be implemented in the next week or two. It'll then be included in latest nightlies, and released in v22.1; thanks for the good request, and clear issue! |
5 tasks
PastaPastaPasta
added a commit
that referenced
this issue
Jan 18, 2025
…RPC getbestchainlock 82c0cf2 docs: release notes for new RPC getislocks and for RPC getbestchainlock changes (Konstantin Akimov) c1a861e feat: implement new rpc getislock (Konstantin Akimov) 53a5707 feat: add new field hex to RPC getbestchainlock (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented #6391 > To register an identity in the DashPlatform network, there is a required field of InstantLock or ChainLock buffer in IdentityCreateTransition. You first create and broadcast Core transaction, then wait for InstantLock or ChainLock, and then create and broadcast transaction in the Platform chain with that data. ## What was done? To retrieve information about ChainLocks has been implemented new field `hex` for RPC getbestchainlock which return information in zmq-compatible hex-encoded binary format. To retrieve information about InstantSend Lock has been implemented a new RPC `getislocks` that return information for list of txids in human-friendly JSON format and binary hex-encoded zmq-compatible format. ## How Has This Been Tested? See new checks in functional test `interface_zmq_dash.py` ## Breaking Changes N/A ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone ACKs for top commit: PastaPastaPasta: utACK 82c0cf2 Tree-SHA512: 175af621bcea3d2896d629dad080bdcde3ee471be6a849fb5a21bfcf1e580926e26b42906cf636f245529a79af9acac757487c47ad3584afd879057633bef6c2
|
Will be released in v22.1, to be released soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
To register an identity in the DashPlatform network, there is a required field of InstantLock or ChainLock buffer in IdentityCreateTransition. You first create and broadcast Core transaction, then wait for InstantLock or ChainLock, and then create and broadcast transaction in the Platform chain with that data.
The problem is in obtaining these lock signatures, because it is only available in the ZMQ, but its not so easy to use on the client, as it is requires a TCP connection and adds a lot of complexity in the client code, making it almost impossible in the web without self-written WebSocket gateways.
Core RPC also misses such information right now, however query methods like
verifychainlockandverifyislockare presented (that accepts the same buffer). GetTransaction and GetBlock Core RPC queries already has a boolean field, it would be nice to see an actual buffer there too.Describe the solution you'd like
It would be really great to see instantlock and chainlock buffers in the
gettransactionandgetblockRPC responses, but separate query would work as wellAdditional context
pshenmic/platform-cli#13 (comment)
The text was updated successfully, but these errors were encountered: