Conversation
instagibbs
force-pushed
the
decodeblock
branch
from
febd003 to
1aecb69
Compare
Note to reviewers: This pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
From a performance perspective using RPC for utility-only functions that could be performed locally, especially something that requires pumping over megabytes of data, is a bad idea. I can imagine this is useful as a quick hack but it's not something to encourage. |
| Needs rebase |
|
What about expanding / renaming |
|
@Sjors please no overloading, especially when the purposes are different. |
| AssertLockHeld(cs_main); | ||
| UniValue result(UniValue::VOBJ); | ||
| result.pushKV("hash", blockindex->GetBlockHash().GetHex()); | ||
| result.pushKV("hash", block.GetHash().GetHex()); |
There was a problem hiding this comment.
There is a performance penalty in not using blockindex->GetBlockHash(). Suggestion:
result.pushKV("hash", blockindex ? blockindex->GetBlockHash().GetHex() : block.GetHash().GetHex());| } | ||
|
|
||
| return blockToJSON(block, nullptr, verbosity >= 2); | ||
|
|
| + HelpExampleRpc("decodeblock", "\"<block hex>\"") | ||
| ); | ||
|
|
||
| LOCK(cs_main); |
There was a problem hiding this comment.
Could lock after DecodeHexBlk below.
Disagree, if we end up adding this, then adding it as a separate "pure utility" (as in "this function could run without node") RPC call with disparate functionality is best. I think coaxing it into an existing server function unnecessarily complicates the interface. |
|
I'm a -0; I agree with the sentiment that this should be done in a standalone tool rather than part of bitcoind. |
7 participants
I find this useful for looking at not-PoW-valid blocks rather than using an external parser.