2012-08-21 08:21:33 +02:00
// Copyright (c) 2010 Satoshi Nakamoto
2023-04-25 13:51:26 +02:00
// Copyright (c) 2009-2020 The Bitcoin Core developers
2023-12-31 01:00:00 +01:00
// Copyright (c) 2014-2024 The Dash Core developers
2014-11-20 03:19:29 +01:00
// Distributed under the MIT software license, see the accompanying
2012-08-21 08:21:33 +02:00
// file COPYING or http://www.opensource.org/licenses/mit-license.php.
2020-03-19 23:46:56 +01:00
# include <amount.h>
# include <chain.h>
# include <chainparams.h>
# include <consensus/consensus.h>
# include <consensus/params.h>
# include <consensus/validation.h>
# include <core_io.h>
2021-07-01 19:15:03 +02:00
# include <deploymentinfo.h>
# include <deploymentstatus.h>
Merge #11372: Address encoding cleanup
92f1f8b31 Split off key_io_tests from base58_tests (Pieter Wuille)
119b0f85e Split key_io (address/key encodings) off from base58 (Pieter Wuille)
ebfe217b1 Stop using CBase58Data for ext keys (Pieter Wuille)
32e69fa0d Replace CBitcoinSecret with {Encode,Decode}Secret (Pieter Wuille)
Pull request description:
This PR contains some of the changes left as TODO in #11167 (and built on top of that PR). They are not intended for backporting.
This removes the `CBase58`, `CBitcoinSecret`, `CBitcoinExtKey`, and `CBitcoinExtPubKey` classes, in favor of simple `Encode`/`Decode` functions. Furthermore, all Bitcoin-specific logic (addresses, WIF, BIP32) is moved to `key_io.{h,cpp}`, leaving `base58.{h,cpp}` as a pure utility that implements the base58 encoding/decoding logic.
Tree-SHA512: a5962c0ed27ad53cbe00f22af432cf11aa530e3efc9798e25c004bc9ed1b5673db5df3956e398ee2c085e3a136ac8da69fe7a7d97a05fb2eb3be0b60d0479655
Make linter happy
Dashify
2018-03-07 00:04:56 +01:00
# include <key_io.h>
2022-09-22 13:14:48 +02:00
# include <llmq/blockprocessor.h>
2022-11-07 19:09:44 +01:00
# include <llmq/context.h>
2022-09-22 13:14:48 +02:00
# include <llmq/chainlocks.h>
# include <llmq/instantsend.h>
refactor: remove the g_evoDb global; use NodeContext and locals (#5058)
<!--
*** Please remove the following help text before submitting: ***
Provide a general summary of your changes in the Title above
Pull requests without a rationale and clear improvement may be closed
immediately.
Please provide clear motivation for your patch and explain how it
improves
Dash Core user experience or Dash Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
consider building the system outside of Dash Core, if possible.
-->
## Issue being fixed or feature implemented
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
globals should be avoided to avoid annoying lifetime / nullptr /
initialization issues
## What was done?
<!--- Describe your changes in detail -->
removed a global, g_evoDB
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
make check
## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->
none
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have performed a self-review of my own code
- [x] 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
**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2022-12-10 18:58:17 +01:00
# include <evo/evodb.h>
2020-03-19 23:46:56 +01:00
# include <miner.h>
# include <net.h>
2022-04-05 11:09:41 +02:00
# include <node/context.h>
2020-03-19 23:46:56 +01:00
# include <policy/fees.h>
# include <pow.h>
# include <rpc/blockchain.h>
2023-04-16 21:53:03 +02:00
# include <rpc/mining.h>
2020-03-19 23:46:56 +01:00
# include <rpc/server.h>
2018-11-13 18:34:43 +01:00
# include <rpc/util.h>
2022-03-25 01:19:33 +01:00
# include <script/descriptor.h>
2019-04-14 06:08:47 +02:00
# include <script/script.h>
2022-03-25 01:19:33 +01:00
# include <script/sign.h>
2021-06-21 00:49:59 +02:00
# include <shutdown.h>
2022-08-26 23:52:53 +02:00
# include <spork.h>
2020-03-19 23:46:56 +01:00
# include <txmempool.h>
2019-04-14 06:08:47 +02:00
# include <univalue.h>
2021-06-25 08:07:28 +02:00
# include <util/fees.h>
2021-06-27 08:33:13 +02:00
# include <util/strencodings.h>
2023-01-02 08:21:01 +01:00
# include <util/string.h>
2021-06-25 08:07:28 +02:00
# include <util/system.h>
2020-06-10 15:50:50 +02:00
# include <util/translation.h>
2021-06-25 08:07:28 +02:00
# include <validation.h>
2020-03-19 23:46:56 +01:00
# include <validationinterface.h>
# include <warnings.h>
2014-05-10 14:54:20 +02:00
2021-10-01 21:19:08 +02:00
# include <governance/classes.h>
2021-04-23 00:32:03 +02:00
# include <governance/governance.h>
2021-10-01 21:19:08 +02:00
# include <masternode/sync.h>
2017-12-01 06:14:57 +01:00
2016-10-18 21:11:22 +02:00
# include <memory>
2013-04-13 07:13:08 +02:00
# include <stdint.h>
2014-11-20 03:19:29 +01:00
/**
* Return average network hashes per second based on the last ' lookup ' blocks ,
* or from the last difficulty change if ' lookup ' is nonpositive .
* If ' height ' is nonnegative , compute the estimate at the time when a given block was found .
*/
2023-07-27 21:02:24 +02:00
static UniValue GetNetworkHashPS ( int lookup , int height , const CChain & active_chain ) {
const CBlockIndex * pb = active_chain . Tip ( ) ;
2013-12-29 12:14:06 +01:00
2023-07-27 21:02:24 +02:00
if ( height > = 0 & & height < active_chain . Height ( ) ) {
pb = active_chain [ height ] ;
}
2013-05-17 12:57:05 +02:00
2019-08-06 05:08:33 +02:00
if ( pb = = nullptr | | ! pb - > nHeight )
2013-05-17 12:57:05 +02:00
return 0 ;
// If lookup is -1, then use blocks since last difficulty change.
if ( lookup < = 0 )
2015-04-10 18:35:09 +02:00
lookup = pb - > nHeight % Params ( ) . GetConsensus ( ) . DifficultyAdjustmentInterval ( ) + 1 ;
2013-05-17 12:57:05 +02:00
// If lookup is larger than chain, then set it to chain length.
if ( lookup > pb - > nHeight )
lookup = pb - > nHeight ;
2023-07-27 21:02:24 +02:00
const CBlockIndex * pb0 = pb ;
2013-04-13 07:13:08 +02:00
int64_t minTime = pb0 - > GetBlockTime ( ) ;
int64_t maxTime = minTime ;
2013-05-17 12:57:05 +02:00
for ( int i = 0 ; i < lookup ; i + + ) {
pb0 = pb0 - > pprev ;
2013-04-13 07:13:08 +02:00
int64_t time = pb0 - > GetBlockTime ( ) ;
2013-05-17 12:57:05 +02:00
minTime = std : : min ( time , minTime ) ;
maxTime = std : : max ( time , maxTime ) ;
}
// In case there's a situation where minTime == maxTime, we don't want a divide by zero exception.
if ( minTime = = maxTime )
return 0 ;
2014-12-16 15:43:03 +01:00
arith_uint256 workDiff = pb - > nChainWork - pb0 - > nChainWork ;
2013-04-13 07:13:08 +02:00
int64_t timeDiff = maxTime - minTime ;
2013-05-17 12:57:05 +02:00
2016-02-08 16:49:27 +01:00
return workDiff . getdouble ( ) / timeDiff ;
2013-05-17 12:57:05 +02:00
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan getnetworkhashps ( )
2013-05-17 12:57:05 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " getnetworkhashps " ,
2022-05-12 22:29:17 +02:00
" \n Returns the estimated network hashes per second based on the last n blocks. \n "
" Pass in [blocks] to override # of blocks, -1 specifies since last difficulty change. \n "
" Pass in [height] to estimate the network speed at the time when a certain block was found. \n " ,
{
{ " nblocks " , RPCArg : : Type : : NUM , /* default */ " 120 " , " The number of blocks, or -1 for blocks since last difficulty change. " } ,
{ " height " , RPCArg : : Type : : NUM , /* default */ " -1 " , " To estimate at the time of the given height. " } ,
} ,
RPCResult {
RPCResult : : Type : : NUM , " " , " Hashes per second estimated " } ,
RPCExamples {
HelpExampleCli ( " getnetworkhashps " , " " )
+ HelpExampleRpc ( " getnetworkhashps " , " " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2013-05-17 12:57:05 +02:00
2023-07-27 21:02:24 +02:00
ChainstateManager & chainman = EnsureAnyChainman ( request . context ) ;
2014-10-19 10:46:17 +02:00
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
return GetNetworkHashPS ( ! request . params [ 0 ] . isNull ( ) ? request . params [ 0 ] . get_int ( ) : 120 , ! request . params [ 1 ] . isNull ( ) ? request . params [ 1 ] . get_int ( ) : - 1 , chainman . ActiveChain ( ) ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2013-05-17 12:57:05 +02:00
}
2019-03-19 08:43:37 +01:00
# if ENABLE_MINER
2022-05-05 20:07:00 +02:00
static bool GenerateBlock ( ChainstateManager & chainman , CBlock & block , uint64_t & max_tries , unsigned int & extra_nonce , uint256 & block_hash )
2022-03-25 01:30:06 +01:00
{
block_hash . SetNull ( ) ;
{
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
CHECK_NONFATAL ( std : : addressof ( : : ChainActive ( ) ) = = std : : addressof ( chainman . ActiveChain ( ) ) ) ;
IncrementExtraNonce ( & block , chainman . ActiveChain ( ) . Tip ( ) , extra_nonce ) ;
2022-03-25 01:30:06 +01:00
}
CChainParams chainparams ( Params ( ) ) ;
while ( max_tries > 0 & & block . nNonce < std : : numeric_limits < uint32_t > : : max ( ) & & ! CheckProofOfWork ( block . GetHash ( ) , block . nBits , chainparams . GetConsensus ( ) ) & & ! ShutdownRequested ( ) ) {
+ + block . nNonce ;
- - max_tries ;
}
if ( max_tries = = 0 | | ShutdownRequested ( ) ) {
return false ;
}
if ( block . nNonce = = std : : numeric_limits < uint32_t > : : max ( ) ) {
return true ;
}
std : : shared_ptr < const CBlock > shared_pblock = std : : make_shared < const CBlock > ( block ) ;
2022-05-05 20:07:00 +02:00
if ( ! chainman . ProcessNewBlock ( chainparams , shared_pblock , true , nullptr ) ) {
2022-03-25 01:30:06 +01:00
throw JSONRPCError ( RPC_INTERNAL_ERROR , " ProcessNewBlock, block not accepted " ) ;
2022-05-05 20:07:00 +02:00
}
2022-03-25 01:30:06 +01:00
block_hash = block . GetHash ( ) ;
return true ;
}
2024-03-02 22:26:00 +01:00
static UniValue generateBlocks ( ChainstateManager & chainman , const NodeContext & node , const CTxMemPool & mempool , const CScript & coinbase_script ,
int nGenerate , uint64_t nMaxTries )
2015-04-01 05:28:28 +02:00
{
2024-03-02 22:26:00 +01:00
EnsureLLMQContext ( node ) ;
2015-04-01 05:28:28 +02:00
int nHeightEnd = 0 ;
int nHeight = 0 ;
{ // Don't keep cs_main locked
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
CHECK_NONFATAL ( std : : addressof ( : : ChainActive ( ) ) = = std : : addressof ( chainman . ActiveChain ( ) ) ) ;
nHeight = chainman . ActiveChain ( ) . Height ( ) ;
2017-06-09 21:58:02 +02:00
nHeightEnd = nHeight + nGenerate ;
2015-04-01 05:28:28 +02:00
}
2015-04-10 07:33:06 +02:00
unsigned int nExtraNonce = 0 ;
2015-05-10 14:48:35 +02:00
UniValue blockHashes ( UniValue : : VARR ) ;
2018-04-23 17:52:26 +02:00
while ( nHeight < nHeightEnd & & ! ShutdownRequested ( ) )
2015-04-10 07:33:06 +02:00
{
2024-03-02 22:26:00 +01:00
std : : unique_ptr < CBlockTemplate > pblocktemplate ( BlockAssembler ( chainman . ActiveChainstate ( ) , node , mempool , Params ( ) ) . CreateNewBlock ( coinbase_script ) ) ;
2015-04-10 07:33:06 +02:00
if ( ! pblocktemplate . get ( ) )
2015-04-10 12:49:01 +02:00
throw JSONRPCError ( RPC_INTERNAL_ERROR , " Couldn't create new block " ) ;
2015-04-10 07:33:06 +02:00
CBlock * pblock = & pblocktemplate - > block ;
2022-03-25 01:30:06 +01:00
uint256 block_hash ;
2022-05-05 20:07:00 +02:00
if ( ! GenerateBlock ( chainman , * pblock , nMaxTries , nExtraNonce , block_hash ) ) {
2016-03-14 11:35:55 +01:00
break ;
}
2022-03-25 01:30:06 +01:00
if ( ! block_hash . IsNull ( ) ) {
+ + nHeight ;
blockHashes . push_back ( block_hash . GetHex ( ) ) ;
2015-04-10 07:33:06 +02:00
}
2015-04-01 05:28:28 +02:00
}
return blockHashes ;
}
2012-08-21 08:21:33 +02:00
2022-03-25 01:30:06 +01:00
static bool getScriptFromDescriptor ( const std : : string & descriptor , CScript & script , std : : string & error )
{
FlatSigningProvider key_provider ;
const auto desc = Parse ( descriptor , key_provider , error , /* require_checksum = */ false ) ;
if ( desc ) {
if ( desc - > IsRange ( ) ) {
throw JSONRPCError ( RPC_INVALID_PARAMETER , " Ranged descriptor not accepted. Maybe pass through deriveaddresses first? " ) ;
}
FlatSigningProvider provider ;
std : : vector < CScript > scripts ;
if ( ! desc - > Expand ( 0 , key_provider , scripts , provider ) ) {
throw JSONRPCError ( RPC_INVALID_ADDRESS_OR_KEY , strprintf ( " Cannot derive script without private keys " ) ) ;
}
2022-04-25 21:13:24 +02:00
// Combo descriptors can have 2 or 4 scripts, so we can't just check scripts.size() == 1
2022-03-25 01:30:06 +01:00
CHECK_NONFATAL ( scripts . size ( ) > 0 & & scripts . size ( ) < = 4 ) ;
if ( scripts . size ( ) = = 1 ) {
script = scripts . at ( 0 ) ;
} else if ( scripts . size ( ) = = 4 ) {
// For uncompressed keys, take the 3rd script, since it is p2wpkh
script = scripts . at ( 2 ) ;
} else {
// Else take the 2nd script, since it is p2pkh
script = scripts . at ( 1 ) ;
}
return true ;
} else {
return false ;
}
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan generatetodescriptor ( )
2022-03-25 01:19:33 +01:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan {
2022-03-25 01:19:33 +01:00
" generatetodescriptor " ,
" \n Mine blocks immediately to a specified descriptor (before the RPC call returns) \n " ,
{
{ " num_blocks " , RPCArg : : Type : : NUM , RPCArg : : Optional : : NO , " How many blocks are generated immediately. " } ,
2023-11-03 15:06:02 +01:00
{ " descriptor " , RPCArg : : Type : : STR , RPCArg : : Optional : : NO , " The descriptor to send the newly generated coins to. " } ,
2023-04-16 21:53:03 +02:00
{ " maxtries " , RPCArg : : Type : : NUM , /* default */ ToString ( DEFAULT_MAX_TRIES ) , " How many iterations to try. " } ,
2022-03-25 01:19:33 +01:00
} ,
RPCResult {
2022-05-12 22:29:17 +02:00
RPCResult : : Type : : ARR , " " , " " ,
{
{ RPCResult : : Type : : STR_HEX , " blockhashes " , " hashes of blocks generated " } ,
}
} ,
2022-03-25 01:19:33 +01:00
RPCExamples {
" \n Generate 11 blocks to mydesc \n " + HelpExampleCli ( " generatetodescriptor " , " 11 \" mydesc \" " ) } ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2022-03-25 01:19:33 +01:00
const int num_blocks { request . params [ 0 ] . get_int ( ) } ;
2023-04-16 21:53:03 +02:00
const uint64_t max_tries { request . params [ 2 ] . isNull ( ) ? DEFAULT_MAX_TRIES : request . params [ 2 ] . get_int ( ) } ;
2022-03-25 01:19:33 +01:00
2022-03-25 01:30:06 +01:00
CScript coinbase_script ;
2022-03-25 01:19:33 +01:00
std : : string error ;
2022-03-25 01:30:06 +01:00
if ( ! getScriptFromDescriptor ( request . params [ 1 ] . get_str ( ) , coinbase_script , error ) ) {
2022-03-25 01:19:33 +01:00
throw JSONRPCError ( RPC_INVALID_ADDRESS_OR_KEY , error ) ;
}
2023-07-27 21:02:24 +02:00
const NodeContext & node = EnsureAnyNodeContext ( request . context ) ;
const CTxMemPool & mempool = EnsureMemPool ( node ) ;
ChainstateManager & chainman = EnsureChainman ( node ) ;
2019-07-03 15:46:43 +02:00
2024-03-02 22:26:00 +01:00
return generateBlocks ( chainman , node , mempool , coinbase_script , num_blocks , max_tries ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2022-03-25 01:19:33 +01:00
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan generatetoaddress ( )
2016-03-23 13:24:34 +01:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " generatetoaddress " ,
2022-05-12 22:29:17 +02:00
" \n Mine blocks immediately to a specified address (before the RPC call returns) \n " ,
{
{ " nblocks " , RPCArg : : Type : : NUM , RPCArg : : Optional : : NO , " How many blocks are generated immediately. " } ,
2023-11-03 15:06:02 +01:00
{ " address " , RPCArg : : Type : : STR , RPCArg : : Optional : : NO , " The address to send the newly generated coins to. " } ,
2023-04-16 21:53:03 +02:00
{ " maxtries " , RPCArg : : Type : : NUM , /* default */ ToString ( DEFAULT_MAX_TRIES ) , " How many iterations to try. " } ,
2022-05-12 22:29:17 +02:00
} ,
RPCResult {
RPCResult : : Type : : ARR , " " , " hashes of blocks generated " ,
{
{ RPCResult : : Type : : STR_HEX , " " , " blockhash " } ,
} } ,
RPCExamples {
" \n Generate 11 blocks to myaddress \n "
+ HelpExampleCli ( " generatetoaddress " , " 11 \" myaddress \" " )
2020-06-15 12:14:31 +02:00
+ " If you are using the " PACKAGE_NAME " wallet, you can get a new address to send the newly generated coins to with: \n "
2022-05-12 22:29:17 +02:00
+ HelpExampleCli ( " getnewaddress " , " " ) } ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2023-04-16 21:53:03 +02:00
const int num_blocks { request . params [ 0 ] . get_int ( ) } ;
const uint64_t max_tries { request . params [ 2 ] . isNull ( ) ? DEFAULT_MAX_TRIES : request . params [ 2 ] . get_int ( ) } ;
2016-03-23 13:24:34 +01:00
Merge #11117: Prepare for non-Base58 addresses (#3294)
* Merge #11117: Prepare for non-Base58 addresses
864cd2787 Move CBitcoinAddress to base58.cpp (Pieter Wuille)
5c8ff0d44 Introduce wrappers around CBitcoinAddress (Pieter Wuille)
Pull request description:
This patch removes the need for the intermediary Base58 type `CBitcoinAddress`, by providing {`Encode`,`Decode`,`IsValid`}`Destination` functions that directly operate on the conversion between `std::string`s and `CTxDestination`.
As a side, it also fixes a number of indentation issues, and removes probably several unnecessary implicit `CTxDestination`<->`CBitcoinAddress` conversions.
This change is far from complete. In follow-ups I'd like to:
* Split off the specific address and key encoding logic from base58.h, and move it to a address.h or so.
* Replace `CTxDestination` with a non-`boost::variant` version (which can be more efficient as `boost::variant` allocates everything on the heap, and remove the need for `boost::get<...>` and `IsValidDestination` calls everywhere).
* Do the same for `CBitcoinSecret`, `CBitcoinExtKey`, and `CBitcoinExtPubKey`.
However, I've tried to keep this patch to be minimally invasive, but still enough to support non-Base58 addresses. Perhaps a smaller patch is possible to hack Bech32 support into `CBitcoinAddress`, but I would consider that a move in the wrong direction.
Tree-SHA512: c2c77ffb57caeadf2429b1c2562ce60e8c7be8aa9f8e51b591f354b6b441162625b2efe14c023a1ae485cf2ed417263afa35c892891dfaa7844e7fbabccab85e
* CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* fix CBitcoinAddress GetKeyID check
Signed-off-by: Pasta <pasta@dashboost.org>
* fix providertx.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* hopefully fix governance-classes.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-validators.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-classes.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* fix governance-classes.h
Signed-off-by: Pasta <pasta@dashboost.org>
* DecodeTransaction -> DecodeDestination, fix governance-validators.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* More fixes for 3294
* Move GetIndexKey into rpc/misc.cpp near getAddressesFromParams
No need to have it in base58.cpp anymore as this is only used in getAddressesFromParams
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Alexander Block <ablock84@gmail.com>
2020-01-22 11:35:04 +01:00
CTxDestination destination = DecodeDestination ( request . params [ 1 ] . get_str ( ) ) ;
if ( ! IsValidDestination ( destination ) ) {
2016-03-23 13:24:34 +01:00
throw JSONRPCError ( RPC_INVALID_ADDRESS_OR_KEY , " Error: Invalid address " ) ;
Merge #11117: Prepare for non-Base58 addresses (#3294)
* Merge #11117: Prepare for non-Base58 addresses
864cd2787 Move CBitcoinAddress to base58.cpp (Pieter Wuille)
5c8ff0d44 Introduce wrappers around CBitcoinAddress (Pieter Wuille)
Pull request description:
This patch removes the need for the intermediary Base58 type `CBitcoinAddress`, by providing {`Encode`,`Decode`,`IsValid`}`Destination` functions that directly operate on the conversion between `std::string`s and `CTxDestination`.
As a side, it also fixes a number of indentation issues, and removes probably several unnecessary implicit `CTxDestination`<->`CBitcoinAddress` conversions.
This change is far from complete. In follow-ups I'd like to:
* Split off the specific address and key encoding logic from base58.h, and move it to a address.h or so.
* Replace `CTxDestination` with a non-`boost::variant` version (which can be more efficient as `boost::variant` allocates everything on the heap, and remove the need for `boost::get<...>` and `IsValidDestination` calls everywhere).
* Do the same for `CBitcoinSecret`, `CBitcoinExtKey`, and `CBitcoinExtPubKey`.
However, I've tried to keep this patch to be minimally invasive, but still enough to support non-Base58 addresses. Perhaps a smaller patch is possible to hack Bech32 support into `CBitcoinAddress`, but I would consider that a move in the wrong direction.
Tree-SHA512: c2c77ffb57caeadf2429b1c2562ce60e8c7be8aa9f8e51b591f354b6b441162625b2efe14c023a1ae485cf2ed417263afa35c892891dfaa7844e7fbabccab85e
* CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* fix CBitcoinAddress GetKeyID check
Signed-off-by: Pasta <pasta@dashboost.org>
* fix providertx.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* hopefully fix governance-classes.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-validators.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-classes.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* fix governance-classes.h
Signed-off-by: Pasta <pasta@dashboost.org>
* DecodeTransaction -> DecodeDestination, fix governance-validators.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* More fixes for 3294
* Move GetIndexKey into rpc/misc.cpp near getAddressesFromParams
No need to have it in base58.cpp anymore as this is only used in getAddressesFromParams
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Alexander Block <ablock84@gmail.com>
2020-01-22 11:35:04 +01:00
}
2017-03-09 08:14:27 +01:00
2023-07-27 21:02:24 +02:00
const NodeContext & node = EnsureAnyNodeContext ( request . context ) ;
const CTxMemPool & mempool = EnsureMemPool ( node ) ;
ChainstateManager & chainman = EnsureChainman ( node ) ;
2019-07-03 15:46:43 +02:00
2019-04-14 06:08:47 +02:00
CScript coinbase_script = GetScriptForDestination ( destination ) ;
2016-03-23 13:24:34 +01:00
2024-03-02 22:26:00 +01:00
return generateBlocks ( chainman , node , mempool , coinbase_script , num_blocks , max_tries ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2016-03-23 13:24:34 +01:00
}
2022-03-25 01:30:06 +01:00
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan generateblock ( )
2022-03-25 01:30:06 +01:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " generateblock " ,
2022-03-25 01:30:06 +01:00
" \n Mine a block with a set of ordered transactions immediately to a specified address or descriptor (before the RPC call returns) \n " ,
{
2024-02-25 19:19:02 +01:00
{ " output " , RPCArg : : Type : : STR , RPCArg : : Optional : : NO , " The address or descriptor to send the newly generated coins to. " } ,
2022-03-25 01:30:06 +01:00
{ " transactions " , RPCArg : : Type : : ARR , RPCArg : : Optional : : NO , " An array of hex strings which are either txids or raw transactions. \n "
" Txids must reference transactions currently in the mempool. \n "
" All transactions must be valid and in valid order, otherwise the block will be rejected. " ,
{
{ " rawtx/txid " , RPCArg : : Type : : STR_HEX , RPCArg : : Optional : : OMITTED , " " } ,
} ,
2024-02-25 19:19:02 +01:00
} ,
2022-03-25 01:30:06 +01:00
} ,
RPCResult {
RPCResult : : Type : : OBJ , " " , " " ,
{
2024-02-25 19:19:02 +01:00
{ RPCResult : : Type : : STR_HEX , " hash " , " hash of generated block " } ,
2022-03-25 01:30:06 +01:00
}
} ,
RPCExamples {
" \n Generate a block to myaddress, with txs rawtx and mempool_txid \n "
+ HelpExampleCli ( " generateblock " , R " ( " myaddress " '[ " rawtx " , " mempool_txid " ]') " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2022-03-25 01:30:06 +01:00
const auto address_or_descriptor = request . params [ 0 ] . get_str ( ) ;
CScript coinbase_script ;
std : : string error ;
if ( ! getScriptFromDescriptor ( address_or_descriptor , coinbase_script , error ) ) {
const auto destination = DecodeDestination ( address_or_descriptor ) ;
if ( ! IsValidDestination ( destination ) ) {
throw JSONRPCError ( RPC_INVALID_ADDRESS_OR_KEY , " Error: Invalid address or descriptor " ) ;
}
coinbase_script = GetScriptForDestination ( destination ) ;
}
2023-07-27 21:02:24 +02:00
const NodeContext & node = EnsureAnyNodeContext ( request . context ) ;
const CTxMemPool & mempool = EnsureMemPool ( node ) ;
2022-03-25 01:30:06 +01:00
std : : vector < CTransactionRef > txs ;
const auto raw_txs_or_txids = request . params [ 1 ] . get_array ( ) ;
for ( size_t i = 0 ; i < raw_txs_or_txids . size ( ) ; i + + ) {
const auto str ( raw_txs_or_txids [ i ] . get_str ( ) ) ;
uint256 hash ;
CMutableTransaction mtx ;
if ( ParseHashStr ( str , hash ) ) {
const auto tx = mempool . get ( hash ) ;
if ( ! tx ) {
throw JSONRPCError ( RPC_INVALID_ADDRESS_OR_KEY , strprintf ( " Transaction %s not in mempool. " , str ) ) ;
}
txs . emplace_back ( tx ) ;
} else if ( DecodeHexTx ( mtx , str ) ) {
txs . push_back ( MakeTransactionRef ( std : : move ( mtx ) ) ) ;
} else {
2020-10-16 05:31:12 +02:00
throw JSONRPCError ( RPC_DESERIALIZATION_ERROR , strprintf ( " Transaction decode failed for %s. Make sure the tx has at least one input. " , str ) ) ;
2022-03-25 01:30:06 +01:00
}
}
CChainParams chainparams ( Params ( ) ) ;
2023-07-27 21:02:24 +02:00
LLMQContext & llmq_ctx = EnsureLLMQContext ( node ) ;
2022-03-25 01:30:06 +01:00
2023-07-27 21:02:24 +02:00
ChainstateManager & chainman = EnsureChainman ( node ) ;
CChainState & active_chainstate = chainman . ActiveChainstate ( ) ;
2024-03-14 04:29:04 +01:00
CBlock block ;
2022-03-25 01:30:06 +01:00
{
LOCK ( cs_main ) ;
CTxMemPool empty_mempool ;
2024-03-02 22:26:00 +01:00
std : : unique_ptr < CBlockTemplate > blocktemplate ( BlockAssembler ( active_chainstate , node , empty_mempool , chainparams ) . CreateNewBlock ( coinbase_script ) ) ;
2022-03-25 01:30:06 +01:00
if ( ! blocktemplate ) {
throw JSONRPCError ( RPC_INTERNAL_ERROR , " Couldn't create new block " ) ;
}
block = blocktemplate - > block ;
}
2023-05-20 16:24:32 +02:00
// 1 coinbase + could have a few quorum commitments
CHECK_NONFATAL ( block . vtx . size ( ) > = 1 ) ;
2022-03-25 01:30:06 +01:00
// Add transactions
block . vtx . insert ( block . vtx . end ( ) , txs . begin ( ) , txs . end ( ) ) ;
{
LOCK ( cs_main ) ;
2019-10-30 15:27:22 +01:00
BlockValidationState state ;
2023-07-27 21:02:24 +02:00
if ( ! TestBlockValidity ( state , * llmq_ctx . clhandler , * node . evodb , chainparams , active_chainstate , block , chainman . m_blockman . LookupBlockIndex ( block . hashPrevBlock ) , false , false ) ) {
2022-03-25 01:30:06 +01:00
throw JSONRPCError ( RPC_VERIFY_ERROR , strprintf ( " TestBlockValidity failed: %s " , state . GetRejectReason ( ) ) ) ;
}
}
uint256 block_hash ;
2023-04-16 21:53:03 +02:00
uint64_t max_tries { DEFAULT_MAX_TRIES } ;
2022-03-25 01:30:06 +01:00
unsigned int extra_nonce { 0 } ;
2023-07-27 21:02:24 +02:00
if ( ! GenerateBlock ( chainman , block , max_tries , extra_nonce , block_hash ) | | block_hash . IsNull ( ) ) {
2022-03-25 01:30:06 +01:00
throw JSONRPCError ( RPC_MISC_ERROR , " Failed to make block. " ) ;
}
UniValue obj ( UniValue : : VOBJ ) ;
obj . pushKV ( " hash " , block_hash . GetHex ( ) ) ;
return obj ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2022-03-25 01:30:06 +01:00
}
2021-01-11 04:30:24 +01:00
# else
2018-05-04 22:42:39 +02:00
static UniValue generatetoaddress ( const JSONRPCRequest & request )
2021-01-11 04:30:24 +01:00
{
throw JSONRPCError ( RPC_METHOD_NOT_FOUND , " This call is not available because RPC miner isn't compiled " ) ;
}
2022-03-25 01:19:33 +01:00
static UniValue generatetodescriptor ( const JSONRPCRequest & request )
{
throw JSONRPCError ( RPC_METHOD_NOT_FOUND , " This call is not available because RPC miner isn't compiled " ) ;
}
2022-03-25 01:30:06 +01:00
static UniValue generateblock ( const JSONRPCRequest & request )
{
throw JSONRPCError ( RPC_METHOD_NOT_FOUND , " This call is not available because RPC miner isn't compiled " ) ;
}
2019-03-19 08:43:37 +01:00
# endif // ENABLE_MINER
2016-03-23 13:24:34 +01:00
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan generate ( )
2020-08-14 11:03:36 +02:00
{
return RPCHelpMan { " generate " , " has been replaced by the -generate cli option. Refer to -help for more information. " , { } , { } , RPCExamples { " " } , [ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue {
if ( request . fHelp ) {
throw std : : runtime_error ( self . ToString ( ) ) ;
} else {
throw JSONRPCError ( RPC_METHOD_NOT_FOUND , self . ToString ( ) ) ;
}
} } ;
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan getmininginfo ( )
2012-08-21 08:21:33 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " getmininginfo " ,
2019-01-29 15:55:37 +01:00
" \n Returns a json object containing mining-related information. " ,
{ } ,
RPCResult {
2022-05-12 22:29:17 +02:00
RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : NUM , " blocks " , " The current block " } ,
{ RPCResult : : Type : : NUM , " currentblocksize " , /* optional */ true , " The block size of the last assembled block (only present if a block was ever assembled) " } ,
{ RPCResult : : Type : : NUM , " currentblocktx " , /* optional */ true , " The number of block transactions of the last assembled block (only present if a block was ever assembled) " } ,
{ RPCResult : : Type : : NUM , " difficulty " , " The current difficulty " } ,
{ RPCResult : : Type : : NUM , " networkhashps " , " The network hashes per second " } ,
{ RPCResult : : Type : : NUM , " pooledtx " , " The size of the mempool " } ,
{ RPCResult : : Type : : STR , " chain " , " current network name (main, test, regtest) " } ,
{ RPCResult : : Type : : STR , " warnings " , " any network and blockchain warnings " } ,
} } ,
2019-01-29 15:55:37 +01:00
RPCExamples {
HelpExampleCli ( " getmininginfo " , " " )
2013-10-29 12:29:44 +01:00
+ HelpExampleRpc ( " getmininginfo " , " " )
2019-01-29 15:55:37 +01:00
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2014-10-19 10:46:17 +02:00
2023-07-27 21:02:24 +02:00
const NodeContext & node = EnsureAnyNodeContext ( request . context ) ;
ChainstateManager & chainman = EnsureChainman ( node ) ;
2014-10-19 10:46:17 +02:00
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
const CTxMemPool & mempool = EnsureMemPool ( node ) ;
const CChain & active_chain = chainman . ActiveChain ( ) ;
2014-10-19 10:46:17 +02:00
2015-05-10 14:48:35 +02:00
UniValue obj ( UniValue : : VOBJ ) ;
2023-07-27 21:02:24 +02:00
obj . pushKV ( " blocks " , active_chain . Height ( ) ) ;
2019-02-15 14:56:43 +01:00
if ( BlockAssembler : : m_last_block_size ) obj . pushKV ( " currentblocksize " , * BlockAssembler : : m_last_block_size ) ;
if ( BlockAssembler : : m_last_block_num_txs ) obj . pushKV ( " currentblocktx " , * BlockAssembler : : m_last_block_num_txs ) ;
2023-07-27 21:02:24 +02:00
obj . pushKV ( " difficulty " , ( double ) GetDifficulty ( active_chain . Tip ( ) ) ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
obj . pushKV ( " networkhashps " , getnetworkhashps ( ) . HandleRequest ( request ) ) ;
2020-06-18 11:17:23 +02:00
obj . pushKV ( " pooledtx " , ( uint64_t ) mempool . size ( ) ) ;
obj . pushKV ( " chain " , Params ( ) . NetworkIDString ( ) ) ;
2020-06-10 15:50:50 +02:00
obj . pushKV ( " warnings " , GetWarnings ( false ) . original ) ;
2012-08-21 08:21:33 +02:00
return obj ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2012-08-21 08:21:33 +02:00
}
2014-12-01 13:51:45 +01:00
// NOTE: Unlike wallet RPC (which use BTC values), mining RPCs follow GBT (BIP 22) in using satoshi amounts
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan prioritisetransaction ( )
2012-08-21 08:21:33 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " prioritisetransaction " ,
2022-05-12 22:29:17 +02:00
" Accepts the transaction into mined blocks at a higher (or lower) priority \n " ,
{
{ " txid " , RPCArg : : Type : : STR_HEX , RPCArg : : Optional : : NO , " The transaction id. " } ,
{ " fee_delta " , RPCArg : : Type : : NUM , RPCArg : : Optional : : NO , " The fee value (in duffs) to add (or subtract, if negative). \n "
" Note, that this value is not a fee rate. It is a value to modify absolute fee of the TX. \n "
" The fee is not actually paid, only the algorithm for selecting transactions into a block \n "
" considers the transaction as it would have paid a higher (or lower) fee. " } ,
} ,
RPCResult {
RPCResult : : Type : : BOOL , " " , " Returns true " } ,
RPCExamples {
HelpExampleCli ( " prioritisetransaction " , " \" txid \" 10000 " )
+ HelpExampleRpc ( " prioritisetransaction " , " \" txid \" , 10000 " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
2012-08-21 08:21:33 +02:00
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
{
2014-10-19 10:46:17 +02:00
LOCK ( cs_main ) ;
2012-08-21 08:21:33 +02:00
2018-09-24 20:54:10 +02:00
uint256 hash ( ParseHashV ( request . params [ 0 ] . get_str ( ) , " txid " ) ) ;
2019-03-14 15:44:42 +01:00
CAmount nAmount = request . params [ 1 ] . get_int64 ( ) ;
2016-10-19 15:01:33 +02:00
2023-07-27 21:02:24 +02:00
EnsureAnyMemPool ( request . context ) . PrioritiseTransaction ( hash , nAmount ) ;
2012-07-11 20:52:41 +02:00
return true ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2012-07-11 20:52:41 +02:00
}
2012-08-21 08:21:33 +02:00
2014-10-30 03:56:33 +01:00
// NOTE: Assumes a conclusive result; if result is inconclusive, it must be handled by caller
2019-10-30 15:27:22 +01:00
static UniValue BIP22ValidationResult ( const BlockValidationState & state )
2014-10-30 03:56:33 +01:00
{
if ( state . IsValid ( ) )
2015-05-18 14:02:18 +02:00
return NullUniValue ;
2012-08-21 08:21:33 +02:00
2014-10-30 03:56:33 +01:00
if ( state . IsError ( ) )
2020-03-01 21:33:52 +01:00
throw JSONRPCError ( RPC_VERIFY_ERROR , state . ToString ( ) ) ;
2014-10-30 03:56:33 +01:00
if ( state . IsInvalid ( ) )
2012-08-21 08:21:33 +02:00
{
2018-02-15 16:35:12 +01:00
std : : string strRejectReason = state . GetRejectReason ( ) ;
2014-10-30 03:56:33 +01:00
if ( strRejectReason . empty ( ) )
return " rejected " ;
return strRejectReason ;
2012-08-21 08:21:33 +02:00
}
2014-10-30 03:56:33 +01:00
// Should be impossible
return " valid? " ;
2012-08-21 08:21:33 +02:00
}
2018-05-04 22:42:39 +02:00
static std : : string gbt_vb_name ( const Consensus : : DeploymentPos pos ) {
2017-06-06 10:08:14 +02:00
const struct VBDeploymentInfo & vbinfo = VersionBitsDeploymentInfo [ pos ] ;
2017-04-11 12:53:54 +02:00
std : : string s = vbinfo . name ;
if ( ! vbinfo . gbt_force ) {
s . insert ( s . begin ( ) , ' ! ' ) ;
}
return s ;
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan getblocktemplate ( )
2012-08-21 08:21:33 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " getblocktemplate " ,
2022-05-12 22:29:17 +02:00
" \n If the request parameters include a 'mode' key, that is used to explicitly select between the default 'template' request or a 'proposal'. \n "
" It returns data needed to construct a block to work on. \n "
" For full specification, see BIPs 22, 23, and 9: \n "
" https://github.com/bitcoin/bips/blob/master/bip-0022.mediawiki \n "
" https://github.com/bitcoin/bips/blob/master/bip-0023.mediawiki \n "
" https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes \n " ,
{
2020-03-11 18:28:45 +01:00
{ " template_request " , RPCArg : : Type : : OBJ , /* default_val */ " " , " Format of the template " ,
2021-10-11 23:55:23 +02:00
{
2022-05-12 22:29:17 +02:00
{ " mode " , RPCArg : : Type : : STR , /* treat as named arg */ RPCArg : : Optional : : OMITTED_NAMED_ARG , " This must be set to \" template \" , \" proposal \" (see BIP 23), or omitted " } ,
{ " capabilities " , RPCArg : : Type : : ARR , /* treat as named arg */ RPCArg : : Optional : : OMITTED_NAMED_ARG , " A list of strings " ,
2021-10-11 23:55:23 +02:00
{
2020-08-28 15:23:24 +02:00
{ " str " , RPCArg : : Type : : STR , RPCArg : : Optional : : OMITTED , " client side supported feature, 'longpoll', 'coinbasevalue', 'proposal', 'serverlist', 'workid' " } ,
2022-05-12 22:29:17 +02:00
} ,
} ,
{ " rules " , RPCArg : : Type : : ARR , /* default_val */ " " , " A list of strings " ,
{
2020-08-28 15:23:24 +02:00
{ " str " , RPCArg : : Type : : STR , RPCArg : : Optional : : OMITTED , " client side supported softfork deployment " } ,
2022-05-12 22:29:17 +02:00
} ,
2021-10-11 23:55:23 +02:00
} ,
2019-01-29 15:55:37 +01:00
} ,
2022-05-12 22:29:17 +02:00
" \" template_request \" " } ,
} ,
RPCResult {
RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : ARR , " capabilities " , " specific client side supported features " ,
{
{ RPCResult : : Type : : STR , " " , " capability " } ,
} } ,
{ RPCResult : : Type : : NUM , " version " , " The preferred block version " } ,
{ RPCResult : : Type : : ARR , " rules " , " specific block rules that are to be enforced " ,
{
2020-08-28 15:23:24 +02:00
{ RPCResult : : Type : : STR , " " , " name of a rule the client must understand to some extent; see BIP 9 for format " } ,
2022-05-12 22:29:17 +02:00
} } ,
{ RPCResult : : Type : : OBJ_DYN , " vbavailable " , " set of pending, supported versionbit (BIP 9) softfork deployments " ,
{
{ RPCResult : : Type : : NUM , " rulename " , " identifies the bit number as indicating acceptance and readiness for the named softfork rule " } ,
} } ,
{ RPCResult : : Type : : NUM , " vbrequired " , " bit mask of versionbits the server requires set in submissions " } ,
{ RPCResult : : Type : : STR , " previousblockhash " , " The hash of current highest block " } ,
2020-08-28 15:23:24 +02:00
{ RPCResult : : Type : : ARR , " transactions " , " contents of non-coinbase transactions that should be included in the next block " ,
2022-05-12 22:29:17 +02:00
{
{ RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : STR_HEX , " data " , " transaction data encoded in hexadecimal (byte-for-byte) " } ,
{ RPCResult : : Type : : STR_HEX , " txid " , " transaction id encoded in little-endian hexadecimal " } ,
trivial: add missing rpc help messages, remove segwit references, dashify help text, undashify code comments (#5852)
## Issue being fixed or feature implemented
This pull request is a follow-up to
[some](https://github.com/dashpay/dash/pull/5834#discussion_r1470105685)
[feedback](https://github.com/dashpay/dash/pull/5834#discussion_r1467009815)
received on [dash#5834](https://github.com/dashpay/dash/pull/5834) as
the patterns highlighted were present in different parts of the codebase
and hence not corrected within the PR itself but addressed separately.
This is that separate PR 🙂 (with some additional cleanup of my own)
## What was done?
* This pull request will remain a draft until
[dash#5834](https://github.com/dashpay/dash/pull/5834) as it will
introduce more changes that will need to be corrected in this PR.
* Code introduced that is unique to Dash Core (CoinJoin, InstantSend,
etc.) has been excluded from un-Dashification as the purpose of it is to
reduce backport conflicts, which don't apply in those cases.
* `CWallet::CreateTransaction` and the `CreateTransactionTest` fixture
have been excluded as the former originates from
[dash#3668](https://github.com/dashpay/dash/pull/3668) and the latter
from [dash#3667](https://github.com/dashpay/dash/pull/3667) and are
distinct enough to be unique to Dash Core.
* There are certain Dashifications and SegWit-removals that prove
frustrating as it would break compatibility with programs that rely on
the naming of certain keys
* `getrawmempool`, `getmempoolancestors`, `getmempooldescendants` and
`getmempoolentry` return `vsize` which is currently an alias of `size`.
I have been advised to retain `vsize` in lieu of potential future
developments. (this was originally remedied in
219a1d08973e7ccda6e778218b9a8218b4aae034 but has since been dropped)
* `getaddressmempool`, `getaddressutxos` and `getaddressdeltas` all
return a value with the key `satoshis`. This is frustrating to rename to
`duffs` for compatibility reasons.
* `decodepsbt` returns (if applicable) `non_witness_utxo` which is
frustrating to rename simply to `utxo` for the same reason.
* `analyzepsbt` returns (if applicable) `estimated_vsize` which
frustrating to rename to `estimated_size` for the same reason.
## How Has This Been Tested?
## Breaking Changes
None
## 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 _(for repository
code-owners and collaborators only)_
2024-02-09 18:40:38 +01:00
{ RPCResult : : Type : : STR_HEX , " hash " , " hash encoded in little-endian hexadecimal " } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : ARR , " depends " , " array of numbers " ,
{
{ RPCResult : : Type : : NUM , " " , " transactions before this one (by 1-based index in 'transactions' list) that must be present in the final block if this one is " } ,
} } ,
trivial: add missing rpc help messages, remove segwit references, dashify help text, undashify code comments (#5852)
## Issue being fixed or feature implemented
This pull request is a follow-up to
[some](https://github.com/dashpay/dash/pull/5834#discussion_r1470105685)
[feedback](https://github.com/dashpay/dash/pull/5834#discussion_r1467009815)
received on [dash#5834](https://github.com/dashpay/dash/pull/5834) as
the patterns highlighted were present in different parts of the codebase
and hence not corrected within the PR itself but addressed separately.
This is that separate PR 🙂 (with some additional cleanup of my own)
## What was done?
* This pull request will remain a draft until
[dash#5834](https://github.com/dashpay/dash/pull/5834) as it will
introduce more changes that will need to be corrected in this PR.
* Code introduced that is unique to Dash Core (CoinJoin, InstantSend,
etc.) has been excluded from un-Dashification as the purpose of it is to
reduce backport conflicts, which don't apply in those cases.
* `CWallet::CreateTransaction` and the `CreateTransactionTest` fixture
have been excluded as the former originates from
[dash#3668](https://github.com/dashpay/dash/pull/3668) and the latter
from [dash#3667](https://github.com/dashpay/dash/pull/3667) and are
distinct enough to be unique to Dash Core.
* There are certain Dashifications and SegWit-removals that prove
frustrating as it would break compatibility with programs that rely on
the naming of certain keys
* `getrawmempool`, `getmempoolancestors`, `getmempooldescendants` and
`getmempoolentry` return `vsize` which is currently an alias of `size`.
I have been advised to retain `vsize` in lieu of potential future
developments. (this was originally remedied in
219a1d08973e7ccda6e778218b9a8218b4aae034 but has since been dropped)
* `getaddressmempool`, `getaddressutxos` and `getaddressdeltas` all
return a value with the key `satoshis`. This is frustrating to rename to
`duffs` for compatibility reasons.
* `decodepsbt` returns (if applicable) `non_witness_utxo` which is
frustrating to rename simply to `utxo` for the same reason.
* `analyzepsbt` returns (if applicable) `estimated_vsize` which
frustrating to rename to `estimated_size` for the same reason.
## How Has This Been Tested?
## Breaking Changes
None
## 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 _(for repository
code-owners and collaborators only)_
2024-02-09 18:40:38 +01:00
{ RPCResult : : Type : : NUM , " fee " , " difference in value between transaction inputs and outputs (in duffs); for coinbase transactions, this is a negative Number of the total collected block fees (ie, not including the block subsidy); if key is not present, fee is unknown and clients MUST NOT assume there isn't one " } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : NUM , " sigops " , " total number of SigOps, as counted for purposes of block limits; if key is not present, sigop count is unknown and clients MUST NOT assume there aren't any " } ,
} } ,
} } ,
2020-08-28 15:23:24 +02:00
{ RPCResult : : Type : : OBJ_DYN , " coinbaseaux " , " data that should be included in the coinbase's scriptSig content " ,
2022-05-12 22:29:17 +02:00
{
2020-08-28 15:23:24 +02:00
{ RPCResult : : Type : : STR_HEX , " key " , " values must be in the coinbase (keys may be ignored) " } ,
2022-05-12 22:29:17 +02:00
} } ,
trivial: add missing rpc help messages, remove segwit references, dashify help text, undashify code comments (#5852)
## Issue being fixed or feature implemented
This pull request is a follow-up to
[some](https://github.com/dashpay/dash/pull/5834#discussion_r1470105685)
[feedback](https://github.com/dashpay/dash/pull/5834#discussion_r1467009815)
received on [dash#5834](https://github.com/dashpay/dash/pull/5834) as
the patterns highlighted were present in different parts of the codebase
and hence not corrected within the PR itself but addressed separately.
This is that separate PR 🙂 (with some additional cleanup of my own)
## What was done?
* This pull request will remain a draft until
[dash#5834](https://github.com/dashpay/dash/pull/5834) as it will
introduce more changes that will need to be corrected in this PR.
* Code introduced that is unique to Dash Core (CoinJoin, InstantSend,
etc.) has been excluded from un-Dashification as the purpose of it is to
reduce backport conflicts, which don't apply in those cases.
* `CWallet::CreateTransaction` and the `CreateTransactionTest` fixture
have been excluded as the former originates from
[dash#3668](https://github.com/dashpay/dash/pull/3668) and the latter
from [dash#3667](https://github.com/dashpay/dash/pull/3667) and are
distinct enough to be unique to Dash Core.
* There are certain Dashifications and SegWit-removals that prove
frustrating as it would break compatibility with programs that rely on
the naming of certain keys
* `getrawmempool`, `getmempoolancestors`, `getmempooldescendants` and
`getmempoolentry` return `vsize` which is currently an alias of `size`.
I have been advised to retain `vsize` in lieu of potential future
developments. (this was originally remedied in
219a1d08973e7ccda6e778218b9a8218b4aae034 but has since been dropped)
* `getaddressmempool`, `getaddressutxos` and `getaddressdeltas` all
return a value with the key `satoshis`. This is frustrating to rename to
`duffs` for compatibility reasons.
* `decodepsbt` returns (if applicable) `non_witness_utxo` which is
frustrating to rename simply to `utxo` for the same reason.
* `analyzepsbt` returns (if applicable) `estimated_vsize` which
frustrating to rename to `estimated_size` for the same reason.
## How Has This Been Tested?
## Breaking Changes
None
## 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 _(for repository
code-owners and collaborators only)_
2024-02-09 18:40:38 +01:00
{ RPCResult : : Type : : NUM , " coinbasevalue " , " maximum allowable input to coinbase transaction, including the generation award and transaction fees (in duffs) " } ,
2020-08-28 15:23:24 +02:00
{ RPCResult : : Type : : STR , " longpollid " , " an id to include with a request to longpoll on an update to this template " } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : STR , " target " , " The hash target " } ,
Merge #17617: doc: unify unix epoch time descriptions
d94d34f05f4ae3efa07de409489d68bbcc216346 doc: update developer notes wrt unix epoch time (Jon Atack)
e2f32cb5c5c7f2b1d1fc7003587b6573fb59526a qa: unify unix epoch time descriptions (Jon Atack)
Pull request description:
Closes #17613.
Updated call sites: mocktime, getblockheader, getblock, pruneblockchain,
getchaintxstats, getblocktemplate, setmocktime, getpeerinfo, setban,
getnodeaddresses, getrawtransaction, importmulti, listtransactions,
listsinceblock, gettransaction, getwalletinfo, getaddressinfo
Commands for testing manually:
```
bitcoind -help-debug | grep -A1 mocktime
bitcoin-cli help getblockheader
bitcoin-cli help getblock
bitcoin-cli help pruneblockchain
bitcoin-cli help getchaintxstats
bitcoin-cli help getblocktemplate
bitcoin-cli help setmocktime
bitcoin-cli help getpeerinfo
bitcoin-cli help setban
bitcoin-cli help getnodeaddresses
bitcoin-cli help getrawtransaction
bitcoin-cli help importmulti
bitcoin-cli help listtransactions
bitcoin-cli help listsinceblock
bitcoin-cli help gettransaction
bitcoin-cli help getwalletinfo
bitcoin-cli help getaddressinfo
```
ACKs for top commit:
laanwj:
re-ACK d94d34f05f4ae3efa07de409489d68bbcc216346
Tree-SHA512: 060713ea4e20ab72c580f06c5c7e3ef344ad9c2c9cb034987d980a54e3ed2ac0268eb3929806daa5caa7797c45f5305254fd499767db7f22862212cf77acf236
2019-12-13 10:53:37 +01:00
{ RPCResult : : Type : : NUM_TIME , " mintime " , " The minimum timestamp appropriate for the next block time, expressed in " + UNIX_EPOCH_TIME } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : ARR , " mutable " , " list of ways the block template may be changed " ,
{
{ RPCResult : : Type : : STR , " value " , " A way the block template may be changed, e.g. 'time', 'transactions', 'prevblock' " } ,
} } ,
{ RPCResult : : Type : : STR_HEX , " noncerange " , " A range of valid nonces " } ,
{ RPCResult : : Type : : NUM , " sigoplimit " , " limit of sigops in blocks " } ,
{ RPCResult : : Type : : NUM , " sizelimit " , " limit of block size " } ,
Merge #17617: doc: unify unix epoch time descriptions
d94d34f05f4ae3efa07de409489d68bbcc216346 doc: update developer notes wrt unix epoch time (Jon Atack)
e2f32cb5c5c7f2b1d1fc7003587b6573fb59526a qa: unify unix epoch time descriptions (Jon Atack)
Pull request description:
Closes #17613.
Updated call sites: mocktime, getblockheader, getblock, pruneblockchain,
getchaintxstats, getblocktemplate, setmocktime, getpeerinfo, setban,
getnodeaddresses, getrawtransaction, importmulti, listtransactions,
listsinceblock, gettransaction, getwalletinfo, getaddressinfo
Commands for testing manually:
```
bitcoind -help-debug | grep -A1 mocktime
bitcoin-cli help getblockheader
bitcoin-cli help getblock
bitcoin-cli help pruneblockchain
bitcoin-cli help getchaintxstats
bitcoin-cli help getblocktemplate
bitcoin-cli help setmocktime
bitcoin-cli help getpeerinfo
bitcoin-cli help setban
bitcoin-cli help getnodeaddresses
bitcoin-cli help getrawtransaction
bitcoin-cli help importmulti
bitcoin-cli help listtransactions
bitcoin-cli help listsinceblock
bitcoin-cli help gettransaction
bitcoin-cli help getwalletinfo
bitcoin-cli help getaddressinfo
```
ACKs for top commit:
laanwj:
re-ACK d94d34f05f4ae3efa07de409489d68bbcc216346
Tree-SHA512: 060713ea4e20ab72c580f06c5c7e3ef344ad9c2c9cb034987d980a54e3ed2ac0268eb3929806daa5caa7797c45f5305254fd499767db7f22862212cf77acf236
2019-12-13 10:53:37 +01:00
{ RPCResult : : Type : : NUM_TIME , " curtime " , " current timestamp in " + UNIX_EPOCH_TIME } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : STR , " bits " , " compressed target of next block " } ,
{ RPCResult : : Type : : STR , " previousbits " , " compressed target of current highest block " } ,
{ RPCResult : : Type : : NUM , " height " , " The height of the next block " } ,
{ RPCResult : : Type : : ARR , " masternode " , " required masternode payments that must be included in the next block " ,
{
{ RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : STR_HEX , " payee " , " payee address " } ,
{ RPCResult : : Type : : STR_HEX , " script " , " payee scriptPubKey " } ,
{ RPCResult : : Type : : NUM , " amount " , " required amount to pay " } ,
} } ,
} } ,
{ RPCResult : : Type : : BOOL , " masternode_payments_started " , " true, if masternode payments started " } ,
{ RPCResult : : Type : : BOOL , " masternode_payments_enforced " , " true, if masternode payments are enforced " } ,
{ RPCResult : : Type : : ARR , " superblock " , " required superblock payees that must be included in the next block " ,
{
{ RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : STR_HEX , " payee " , " payee address " } ,
{ RPCResult : : Type : : STR_HEX , " script " , " payee scriptPubKey " } ,
{ RPCResult : : Type : : NUM , " amount " , " required amount to pay " } ,
} } ,
} } ,
{ RPCResult : : Type : : BOOL , " superblocks_started " , " true, if superblock payments started " } ,
{ RPCResult : : Type : : BOOL , " superblocks_enabled " , " true, if superblock payments are enabled " } ,
{ RPCResult : : Type : : STR_HEX , " coinbase_payload " , " coinbase transaction payload data encoded in hexadecimal " } ,
} } ,
RPCExamples {
HelpExampleCli ( " getblocktemplate " , " " )
+ HelpExampleRpc ( " getblocktemplate " , " " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2023-07-27 21:02:24 +02:00
const NodeContext & node = EnsureAnyNodeContext ( request . context ) ;
2014-10-19 10:46:17 +02:00
2023-07-27 21:02:24 +02:00
ChainstateManager & chainman = EnsureChainman ( node ) ;
LOCK ( cs_main ) ;
refactor: remove the g_evoDb global; use NodeContext and locals (#5058)
<!--
*** Please remove the following help text before submitting: ***
Provide a general summary of your changes in the Title above
Pull requests without a rationale and clear improvement may be closed
immediately.
Please provide clear motivation for your patch and explain how it
improves
Dash Core user experience or Dash Core developer experience
significantly:
* Any test improvements or new tests that improve coverage are always
welcome.
* All other changes should have accompanying unit tests (see
`src/test/`) or
functional tests (see `test/`). Contributors should note which tests
cover
modified code. If no tests exist for a region of modified code, new
tests
should accompany the change.
* Bug fixes are most welcome when they come with steps to reproduce or
an
explanation of the potential issue as well as reasoning for the way the
bug
was fixed.
* Features are welcome, but might be rejected due to design or scope
issues.
If a feature is based on a lot of dependencies, contributors should
first
consider building the system outside of Dash Core, if possible.
-->
## Issue being fixed or feature implemented
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->
globals should be avoided to avoid annoying lifetime / nullptr /
initialization issues
## What was done?
<!--- Describe your changes in detail -->
removed a global, g_evoDB
## How Has This Been Tested?
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->
make check
## Breaking Changes
<!--- Please describe any breaking changes your code introduces -->
none
## Checklist:
<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [x] I have performed a self-review of my own code
- [x] 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
**For repository code-owners and collaborators only**
- [ ] I have assigned this pull request to a milestone
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Kittywhiskers Van Gogh <63189531+kittywhiskers@users.noreply.github.com>
2022-12-10 18:58:17 +01:00
2012-08-21 08:21:33 +02:00
std : : string strMode = " template " ;
2015-05-13 21:29:19 +02:00
UniValue lpval = NullUniValue ;
2017-04-11 12:53:54 +02:00
std : : set < std : : string > setClientRules ;
int64_t nMaxVersionPreVB = - 1 ;
2023-07-27 21:02:24 +02:00
CChainState & active_chainstate = chainman . ActiveChainstate ( ) ;
CChain & active_chain = active_chainstate . m_chain ;
2019-08-08 17:57:08 +02:00
if ( ! request . params [ 0 ] . isNull ( ) )
2012-08-21 08:21:33 +02:00
{
2016-10-19 15:01:33 +02:00
const UniValue & oparam = request . params [ 0 ] . get_obj ( ) ;
2015-05-18 14:02:18 +02:00
const UniValue & modeval = find_value ( oparam , " mode " ) ;
2014-08-20 21:15:16 +02:00
if ( modeval . isStr ( ) )
2012-08-21 08:21:33 +02:00
strMode = modeval . get_str ( ) ;
2014-08-20 21:15:16 +02:00
else if ( modeval . isNull ( ) )
2012-09-01 09:12:50 +02:00
{
/* Do nothing */
}
2012-08-21 08:21:33 +02:00
else
2012-10-04 09:34:44 +02:00
throw JSONRPCError ( RPC_INVALID_PARAMETER , " Invalid mode " ) ;
2012-05-13 06:43:24 +02:00
lpval = find_value ( oparam , " longpollid " ) ;
2012-09-10 04:55:03 +02:00
if ( strMode = = " proposal " )
{
2015-05-18 14:02:18 +02:00
const UniValue & dataval = find_value ( oparam , " data " ) ;
2015-06-04 21:39:44 +02:00
if ( ! dataval . isStr ( ) )
2012-09-10 04:55:03 +02:00
throw JSONRPCError ( RPC_TYPE_ERROR , " Missing data String key for proposal " ) ;
CBlock block ;
if ( ! DecodeHexBlk ( block , dataval . get_str ( ) ) )
throw JSONRPCError ( RPC_DESERIALIZATION_ERROR , " Block decode failed " ) ;
uint256 hash = block . GetHash ( ) ;
2023-07-27 21:02:24 +02:00
const CBlockIndex * pindex = chainman . m_blockman . LookupBlockIndex ( hash ) ;
2018-03-13 19:04:28 +01:00
if ( pindex ) {
2012-09-10 04:55:03 +02:00
if ( pindex - > IsValid ( BLOCK_VALID_SCRIPTS ) )
return " duplicate " ;
if ( pindex - > nStatus & BLOCK_FAILED_MASK )
return " duplicate-invalid " ;
return " duplicate-inconclusive " ;
}
2023-07-27 21:02:24 +02:00
LLMQContext & llmq_ctx = EnsureLLMQContext ( node ) ;
2022-11-07 19:09:44 +01:00
2023-07-27 21:02:24 +02:00
CBlockIndex * const pindexPrev = active_chain . Tip ( ) ;
2012-09-10 04:55:03 +02:00
// TestBlockValidity only supports blocks built on the current Tip
if ( block . hashPrevBlock ! = pindexPrev - > GetBlockHash ( ) )
return " inconclusive-not-best-prevblk " ;
2019-10-30 15:27:22 +01:00
BlockValidationState state ;
2023-07-27 21:02:24 +02:00
TestBlockValidity ( state , * llmq_ctx . clhandler , * node . evodb , Params ( ) , active_chainstate , block , pindexPrev , false , true ) ;
2012-09-10 04:55:03 +02:00
return BIP22ValidationResult ( state ) ;
}
2017-04-11 12:53:54 +02:00
const UniValue & aClientRules = find_value ( oparam , " rules " ) ;
if ( aClientRules . isArray ( ) ) {
for ( unsigned int i = 0 ; i < aClientRules . size ( ) ; + + i ) {
const UniValue & v = aClientRules [ i ] ;
setClientRules . insert ( v . get_str ( ) ) ;
}
} else {
// NOTE: It is important that this NOT be read if versionbits is supported
const UniValue & uvMaxVersion = find_value ( oparam , " maxversion " ) ;
if ( uvMaxVersion . isNum ( ) ) {
nMaxVersionPreVB = uvMaxVersion . get_int64 ( ) ;
}
}
2012-08-21 08:21:33 +02:00
}
if ( strMode ! = " template " )
2012-10-04 09:34:44 +02:00
throw JSONRPCError ( RPC_INVALID_PARAMETER , " Invalid mode " ) ;
2012-08-21 08:21:33 +02:00
2022-04-23 09:46:44 +02:00
if ( ! node . connman )
Backport Bitcoin PR#8085: p2p: Begin encapsulation (#1537)
* net: move CBanDB and CAddrDB out of net.h/cpp
This will eventually solve a circular dependency
* net: Create CConnman to encapsulate p2p connections
* net: Move socket binding into CConnman
* net: move OpenNetworkConnection into CConnman
* net: move ban and addrman functions into CConnman
* net: Add oneshot functions to CConnman
* net: move added node functions to CConnman
* net: Add most functions needed for vNodes to CConnman
* net: handle nodesignals in CConnman
* net: Pass CConnection to wallet rather than using the global
* net: Add rpc error for missing/disabled p2p functionality
* net: Pass CConnman around as needed
* gui: add NodeID to the peer table
* net: create generic functor accessors and move vNodes to CConnman
* net: move whitelist functions into CConnman
* net: move nLastNodeId to CConnman
* net: move nLocalHostNonce to CConnman
This behavior seems to have been quite racy and broken.
Move nLocalHostNonce into CNode, and check received nonces against all
non-fully-connected nodes. If there's a match, assume we've connected
to ourself.
* net: move messageHandlerCondition to CConnman
* net: move send/recv statistics to CConnman
* net: move SendBufferSize/ReceiveFloodSize to CConnman
* net: move nLocalServices/nRelevantServices to CConnman
These are in-turn passed to CNode at connection time. This allows us to offer
different services to different peers (or test the effects of doing so).
* net: move semOutbound and semMasternodeOutbound to CConnman
* net: SocketSendData returns written size
* net: move max/max-outbound to CConnman
* net: Pass best block known height into CConnman
CConnman then passes the current best height into CNode at creation time.
This way CConnman/CNode have no dependency on main for height, and the signals
only move in one direction.
This also helps to prevent identity leakage a tiny bit. Before this change, an
attacker could theoretically make 2 connections on different interfaces. They
would connect fully on one, and only establish the initial connection on the
other. Once they receive a new block, they would relay it to your first
connection, and immediately commence the version handshake on the second. Since
the new block height is reflected immediately, they could attempt to learn
whether the two connections were correlated.
This is, of course, incredibly unlikely to work due to the small timings
involved and receipt from other senders. But it doesn't hurt to lock-in
nBestHeight at the time of connection, rather than letting the remote choose
the time.
* net: pass CClientUIInterface into CConnman
* net: Drop StartNode/StopNode and use CConnman directly
* net: Introduce CConnection::Options to avoid passing so many params
* net: add nSendBufferMaxSize/nReceiveFloodSize to CConnection::Options
* net: move vNodesDisconnected into CConnman
* Made the ForEachNode* functions in src/net.cpp more pragmatic and self documenting
* Convert ForEachNode* functions to take a templated function argument rather than a std::function to eliminate std::function overhead
* net: move MAX_FEELER_CONNECTIONS into connman
2017-07-21 11:35:19 +02:00
throw JSONRPCError ( RPC_CLIENT_P2P_DISABLED , " Error: Peer-to-peer functionality missing or disabled " ) ;
2022-04-23 09:46:44 +02:00
if ( node . connman - > GetNodeCount ( CConnman : : CONNECTIONS_ALL ) = = 0 )
2019-04-03 18:17:55 +02:00
throw JSONRPCError ( RPC_CLIENT_NOT_CONNECTED , PACKAGE_NAME " is not connected! " ) ;
2012-08-21 08:21:33 +02:00
2023-07-27 21:02:24 +02:00
if ( active_chainstate . IsInitialBlockDownload ( ) )
2019-04-03 18:17:55 +02:00
throw JSONRPCError ( RPC_CLIENT_IN_INITIAL_DOWNLOAD , PACKAGE_NAME " is in initial sync and waiting for blocks... " ) ;
2012-08-21 08:21:33 +02:00
2017-12-01 06:14:57 +01:00
// next bock is a superblock and we need governance info to correctly construct it
2024-02-20 05:26:12 +01:00
if ( AreSuperblocksEnabled ( * node . sporkman )
& & ! node . mn_sync - > IsSynced ( )
2023-07-27 21:02:24 +02:00
& & CSuperblock : : IsValidBlockHeight ( active_chain . Height ( ) + 1 ) )
2022-04-16 21:30:39 +02:00
throw JSONRPCError ( RPC_CLIENT_IN_INITIAL_DOWNLOAD , PACKAGE_NAME " is syncing with network... " ) ;
2017-01-01 11:18:33 +01:00
2012-08-21 08:21:33 +02:00
static unsigned int nTransactionsUpdatedLast ;
2023-07-27 21:02:24 +02:00
const CTxMemPool & mempool = EnsureMemPool ( node ) ;
2012-05-13 06:43:24 +02:00
2014-08-20 21:15:16 +02:00
if ( ! lpval . isNull ( ) )
2012-05-13 06:43:24 +02:00
{
// Wait to respond until either the best block changes, OR a minute has passed and there are more transactions
uint256 hashWatchedChain ;
2017-11-07 19:29:21 +01:00
std : : chrono : : steady_clock : : time_point checktxtime ;
2012-05-13 06:43:24 +02:00
unsigned int nTransactionsUpdatedLastLP ;
2014-08-20 21:15:16 +02:00
if ( lpval . isStr ( ) )
2012-05-13 06:43:24 +02:00
{
// Format: <hashBestChain><nTransactionsUpdatedLast>
std : : string lpstr = lpval . get_str ( ) ;
2018-09-24 20:54:10 +02:00
hashWatchedChain = ParseHashV ( lpstr . substr ( 0 , 64 ) , " longpollid " ) ;
2022-12-20 17:18:10 +01:00
nTransactionsUpdatedLastLP = LocaleIndependentAtoi < int64_t > ( lpstr . substr ( 64 ) ) ;
2012-05-13 06:43:24 +02:00
}
else
{
// NOTE: Spec does not specify behaviour for non-string longpollid, but this makes testing easier
2023-07-27 21:02:24 +02:00
hashWatchedChain = active_chain . Tip ( ) - > GetBlockHash ( ) ;
2012-05-13 06:43:24 +02:00
nTransactionsUpdatedLastLP = nTransactionsUpdatedLast ;
}
2022-05-05 16:24:51 +02:00
// Release lock while waiting
2012-05-13 06:43:24 +02:00
LEAVE_CRITICAL_SECTION ( cs_main ) ;
{
2017-11-07 19:29:21 +01:00
checktxtime = std : : chrono : : steady_clock : : now ( ) + std : : chrono : : minutes ( 1 ) ;
2012-05-13 06:43:24 +02:00
2017-11-08 21:28:35 +01:00
WAIT_LOCK ( g_best_block_mutex , lock ) ;
2018-04-13 03:13:49 +02:00
while ( g_best_block = = hashWatchedChain & & IsRPCRunning ( ) )
2012-05-13 06:43:24 +02:00
{
2018-04-13 03:13:49 +02:00
if ( g_best_block_cv . wait_until ( lock , checktxtime ) = = std : : cv_status : : timeout )
2012-05-13 06:43:24 +02:00
{
// Timeout: Check transactions for update
2022-04-23 07:48:10 +02:00
// without holding the mempool lock to avoid deadlocks
2012-05-13 06:43:24 +02:00
if ( mempool . GetTransactionsUpdated ( ) ! = nTransactionsUpdatedLastLP )
break ;
2017-11-07 19:29:21 +01:00
checktxtime + = std : : chrono : : seconds ( 10 ) ;
2012-05-13 06:43:24 +02:00
}
}
}
ENTER_CRITICAL_SECTION ( cs_main ) ;
if ( ! IsRPCRunning ( ) )
throw JSONRPCError ( RPC_CLIENT_NOT_CONNECTED , " Shutting down " ) ;
// TODO: Maybe recheck connections/IBD and (if something wrong) send an expires-immediately template to stop miners?
}
// Update block
2012-08-21 08:21:33 +02:00
static CBlockIndex * pindexPrev ;
2013-04-13 07:13:08 +02:00
static int64_t nStart ;
2016-10-18 21:11:22 +02:00
static std : : unique_ptr < CBlockTemplate > pblocktemplate ;
2023-07-27 21:02:24 +02:00
if ( pindexPrev ! = active_chain . Tip ( ) | |
2013-08-27 07:51:57 +02:00
( mempool . GetTransactionsUpdated ( ) ! = nTransactionsUpdatedLast & & GetTime ( ) - nStart > 5 ) )
2012-08-21 08:21:33 +02:00
{
// Clear pindexPrev so future calls make a new block, despite any failures from here on
2016-10-18 21:11:22 +02:00
pindexPrev = nullptr ;
2012-08-21 08:21:33 +02:00
2021-10-16 12:54:22 +02:00
// Store the ::ChainActive().Tip() used before CreateNewBlock, to avoid races
2013-08-27 07:51:57 +02:00
nTransactionsUpdatedLast = mempool . GetTransactionsUpdated ( ) ;
2023-07-27 21:02:24 +02:00
CBlockIndex * pindexPrevNew = active_chain . Tip ( ) ;
2012-08-21 08:21:33 +02:00
nStart = GetTime ( ) ;
// Create new block
2013-08-24 06:45:17 +02:00
CScript scriptDummy = CScript ( ) < < OP_TRUE ;
2024-03-02 22:26:00 +01:00
EnsureLLMQContext ( node ) ;
pblocktemplate = BlockAssembler ( active_chainstate , node , mempool , Params ( ) ) . CreateNewBlock ( scriptDummy ) ;
2012-12-19 21:21:21 +01:00
if ( ! pblocktemplate )
2012-10-04 09:34:44 +02:00
throw JSONRPCError ( RPC_OUT_OF_MEMORY , " Out of memory " ) ;
2012-08-21 08:21:33 +02:00
// Need to update only after we know CreateNewBlock succeeded
pindexPrev = pindexPrevNew ;
}
2022-02-27 11:16:35 +01:00
CHECK_NONFATAL ( pindexPrev ) ;
2012-12-19 21:21:21 +01:00
CBlock * pblock = & pblocktemplate - > block ; // pointer for convenience
2017-04-11 12:53:54 +02:00
const Consensus : : Params & consensusParams = Params ( ) . GetConsensus ( ) ;
2012-08-21 08:21:33 +02:00
// Update nTime
2017-04-11 12:53:54 +02:00
UpdateTime ( pblock , consensusParams , pindexPrev ) ;
2012-08-21 08:21:33 +02:00
pblock - > nNonce = 0 ;
2015-05-10 14:48:35 +02:00
UniValue aCaps ( UniValue : : VARR ) ; aCaps . push_back ( " proposal " ) ;
2012-09-10 04:55:03 +02:00
2015-05-10 14:48:35 +02:00
UniValue transactions ( UniValue : : VARR ) ;
2017-03-09 08:14:27 +01:00
std : : map < uint256 , int64_t > setTxIndex ;
2012-08-21 08:21:33 +02:00
int i = 0 ;
2016-11-21 10:51:32 +01:00
for ( const auto & it : pblock - > vtx ) {
const CTransaction & tx = * it ;
2012-08-21 08:21:33 +02:00
uint256 txHash = tx . GetHash ( ) ;
setTxIndex [ txHash ] = i + + ;
if ( tx . IsCoinBase ( ) )
continue ;
2015-05-10 14:48:35 +02:00
UniValue entry ( UniValue : : VOBJ ) ;
2012-08-21 08:21:33 +02:00
2020-06-18 11:17:23 +02:00
entry . pushKV ( " data " , EncodeHexTx ( tx ) ) ;
2012-08-21 08:21:33 +02:00
2020-06-18 11:17:23 +02:00
entry . pushKV ( " hash " , txHash . GetHex ( ) ) ;
2012-08-21 08:21:33 +02:00
2015-05-10 14:48:35 +02:00
UniValue deps ( UniValue : : VARR ) ;
2019-07-05 09:06:28 +02:00
for ( const CTxIn & in : tx . vin )
2012-08-21 08:21:33 +02:00
{
Ultraprune
This switches bitcoin's transaction/block verification logic to use a
"coin database", which contains all unredeemed transaction output scripts,
amounts and heights.
The name ultraprune comes from the fact that instead of a full transaction
index, we only (need to) keep an index with unspent outputs. For now, the
blocks themselves are kept as usual, although they are only necessary for
serving, rescanning and reorganizing.
The basic datastructures are CCoins (representing the coins of a single
transaction), and CCoinsView (representing a state of the coins database).
There are several implementations for CCoinsView. A dummy, one backed by
the coins database (coins.dat), one backed by the memory pool, and one
that adds a cache on top of it. FetchInputs, ConnectInputs, ConnectBlock,
DisconnectBlock, ... now operate on a generic CCoinsView.
The block switching logic now builds a single cached CCoinsView with
changes to be committed to the database before any changes are made.
This means no uncommitted changes are ever read from the database, and
should ease the transition to another database layer which does not
support transactions (but does support atomic writes), like LevelDB.
For the getrawtransaction() RPC call, access to a txid-to-disk index
would be preferable. As this index is not necessary or even useful
for any other part of the implementation, it is not provided. Instead,
getrawtransaction() uses the coin database to find the block height,
and then scans that block to find the requested transaction. This is
slow, but should suffice for debug purposes.
2012-07-01 18:54:00 +02:00
if ( setTxIndex . count ( in . prevout . hash ) )
deps . push_back ( setTxIndex [ in . prevout . hash ] ) ;
}
2020-06-18 11:17:23 +02:00
entry . pushKV ( " depends " , deps ) ;
2012-08-21 08:21:33 +02:00
2013-02-08 00:54:22 +01:00
int index_in_template = i - 1 ;
2020-06-18 11:17:23 +02:00
entry . pushKV ( " fee " , pblocktemplate - > vTxFees [ index_in_template ] ) ;
entry . pushKV ( " sigops " , pblocktemplate - > vTxSigOps [ index_in_template ] ) ;
2012-08-21 08:21:33 +02:00
transactions . push_back ( entry ) ;
}
2015-05-10 14:48:35 +02:00
UniValue aux ( UniValue : : VOBJ ) ;
2012-08-21 08:21:33 +02:00
2014-12-16 15:43:03 +01:00
arith_uint256 hashTarget = arith_uint256 ( ) . SetCompact ( pblock - > nBits ) ;
2012-08-21 08:21:33 +02:00
2017-04-11 12:53:54 +02:00
UniValue aMutable ( UniValue : : VARR ) ;
aMutable . push_back ( " time " ) ;
aMutable . push_back ( " transactions " ) ;
aMutable . push_back ( " prevblock " ) ;
2012-08-21 08:21:33 +02:00
2015-05-10 14:48:35 +02:00
UniValue result ( UniValue : : VOBJ ) ;
2020-06-18 11:17:23 +02:00
result . pushKV ( " capabilities " , aCaps ) ;
2017-04-11 12:53:54 +02:00
UniValue aRules ( UniValue : : VARR ) ;
2020-05-19 14:54:18 +02:00
aRules . push_back ( " csv " ) ;
2017-04-11 12:53:54 +02:00
UniValue vbavailable ( UniValue : : VOBJ ) ;
2016-09-27 13:25:42 +02:00
for ( int j = 0 ; j < ( int ) Consensus : : MAX_VERSION_BITS_DEPLOYMENTS ; + + j ) {
Consensus : : DeploymentPos pos = Consensus : : DeploymentPos ( j ) ;
2021-07-01 19:15:03 +02:00
ThresholdState state = g_versionbitscache . State ( pindexPrev , consensusParams , pos ) ;
2017-04-11 12:53:54 +02:00
switch ( state ) {
2020-06-09 05:44:04 +02:00
case ThresholdState : : DEFINED :
case ThresholdState : : FAILED :
2017-04-11 12:53:54 +02:00
// Not exposed to GBT at all
break ;
2020-06-09 05:44:04 +02:00
case ThresholdState : : LOCKED_IN :
2017-04-11 12:53:54 +02:00
// Ensure bit is set in block version
2021-07-01 19:15:03 +02:00
pblock - > nVersion | = g_versionbitscache . Mask ( consensusParams , pos ) ;
2017-04-11 12:53:54 +02:00
// FALL THROUGH to get vbavailable set...
2020-06-09 05:44:04 +02:00
case ThresholdState : : STARTED :
2017-04-11 12:53:54 +02:00
{
2017-06-06 10:08:14 +02:00
const struct VBDeploymentInfo & vbinfo = VersionBitsDeploymentInfo [ pos ] ;
2020-06-18 11:17:23 +02:00
vbavailable . pushKV ( gbt_vb_name ( pos ) , consensusParams . vDeployments [ pos ] . bit ) ;
2017-04-11 12:53:54 +02:00
if ( setClientRules . find ( vbinfo . name ) = = setClientRules . end ( ) ) {
if ( ! vbinfo . gbt_force ) {
// If the client doesn't support this, don't indicate it in the [default] version
2021-07-01 19:15:03 +02:00
pblock - > nVersion & = ~ g_versionbitscache . Mask ( consensusParams , pos ) ;
2017-04-11 12:53:54 +02:00
}
}
break ;
}
2020-06-09 05:44:04 +02:00
case ThresholdState : : ACTIVE :
2017-04-11 12:53:54 +02:00
{
// Add to rules only
2017-06-06 10:08:14 +02:00
const struct VBDeploymentInfo & vbinfo = VersionBitsDeploymentInfo [ pos ] ;
2017-04-11 12:53:54 +02:00
aRules . push_back ( gbt_vb_name ( pos ) ) ;
if ( setClientRules . find ( vbinfo . name ) = = setClientRules . end ( ) ) {
// Not supported by the client; make sure it's safe to proceed
if ( ! vbinfo . gbt_force ) {
// If we do anything other than throw an exception here, be sure version/force isn't sent to old clients
throw JSONRPCError ( RPC_INVALID_PARAMETER , strprintf ( " Support for '%s' rule requires explicit client support " , vbinfo . name ) ) ;
}
}
break ;
}
}
}
2020-06-18 11:17:23 +02:00
result . pushKV ( " version " , pblock - > nVersion ) ;
result . pushKV ( " rules " , aRules ) ;
result . pushKV ( " vbavailable " , vbavailable ) ;
result . pushKV ( " vbrequired " , int ( 0 ) ) ;
2017-04-11 12:53:54 +02:00
if ( nMaxVersionPreVB > = 2 ) {
// If VB is supported by the client, nMaxVersionPreVB is -1, so we won't get here
2016-08-17 12:50:28 +02:00
// Because BIP 34 changed how the generation transaction is serialized, we can only use version/force back to v2 blocks
2017-04-11 12:53:54 +02:00
// This is safe to do [otherwise-]unconditionally only because we are throwing an exception above if a non-force deployment gets activated
// Note that this can probably also be removed entirely after the first BIP9 non-force deployment (ie, probably segwit) gets activated
aMutable . push_back ( " version/force " ) ;
}
2023-12-05 09:32:18 +01:00
const bool fDIP0001Active_context { DeploymentActiveAfter ( pindexPrev , consensusParams , Consensus : : DEPLOYMENT_DIP0001 ) } ;
2020-06-18 11:17:23 +02:00
result . pushKV ( " previousblockhash " , pblock - > hashPrevBlock . GetHex ( ) ) ;
result . pushKV ( " transactions " , transactions ) ;
result . pushKV ( " coinbaseaux " , aux ) ;
result . pushKV ( " coinbasevalue " , ( int64_t ) pblock - > vtx [ 0 ] - > GetValueOut ( ) ) ;
2023-07-27 21:02:24 +02:00
result . pushKV ( " longpollid " , active_chain . Tip ( ) - > GetBlockHash ( ) . GetHex ( ) + ToString ( nTransactionsUpdatedLast ) ) ;
2020-06-18 11:17:23 +02:00
result . pushKV ( " target " , hashTarget . GetHex ( ) ) ;
result . pushKV ( " mintime " , ( int64_t ) pindexPrev - > GetMedianTimePast ( ) + 1 ) ;
result . pushKV ( " mutable " , aMutable ) ;
result . pushKV ( " noncerange " , " 00000000ffffffff " ) ;
2023-12-05 09:32:18 +01:00
result . pushKV ( " sigoplimit " , ( int64_t ) MaxBlockSigOps ( fDIP0001Active_context ) ) ;
result . pushKV ( " sizelimit " , ( int64_t ) MaxBlockSize ( fDIP0001Active_context ) ) ;
2020-06-18 11:17:23 +02:00
result . pushKV ( " curtime " , pblock - > GetBlockTime ( ) ) ;
result . pushKV ( " bits " , strprintf ( " %08x " , pblock - > nBits ) ) ;
result . pushKV ( " previousbits " , strprintf ( " %08x " , pblocktemplate - > nPrevBits ) ) ;
result . pushKV ( " height " , ( int64_t ) ( pindexPrev - > nHeight + 1 ) ) ;
2015-01-08 19:02:10 +01:00
2018-08-14 11:58:38 +02:00
UniValue masternodeObj ( UniValue : : VARR ) ;
for ( const auto & txout : pblocktemplate - > voutMasternodePayments ) {
Merge #11117: Prepare for non-Base58 addresses (#3294)
* Merge #11117: Prepare for non-Base58 addresses
864cd2787 Move CBitcoinAddress to base58.cpp (Pieter Wuille)
5c8ff0d44 Introduce wrappers around CBitcoinAddress (Pieter Wuille)
Pull request description:
This patch removes the need for the intermediary Base58 type `CBitcoinAddress`, by providing {`Encode`,`Decode`,`IsValid`}`Destination` functions that directly operate on the conversion between `std::string`s and `CTxDestination`.
As a side, it also fixes a number of indentation issues, and removes probably several unnecessary implicit `CTxDestination`<->`CBitcoinAddress` conversions.
This change is far from complete. In follow-ups I'd like to:
* Split off the specific address and key encoding logic from base58.h, and move it to a address.h or so.
* Replace `CTxDestination` with a non-`boost::variant` version (which can be more efficient as `boost::variant` allocates everything on the heap, and remove the need for `boost::get<...>` and `IsValidDestination` calls everywhere).
* Do the same for `CBitcoinSecret`, `CBitcoinExtKey`, and `CBitcoinExtPubKey`.
However, I've tried to keep this patch to be minimally invasive, but still enough to support non-Base58 addresses. Perhaps a smaller patch is possible to hack Bech32 support into `CBitcoinAddress`, but I would consider that a move in the wrong direction.
Tree-SHA512: c2c77ffb57caeadf2429b1c2562ce60e8c7be8aa9f8e51b591f354b6b441162625b2efe14c023a1ae485cf2ed417263afa35c892891dfaa7844e7fbabccab85e
* CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* fix CBitcoinAddress GetKeyID check
Signed-off-by: Pasta <pasta@dashboost.org>
* fix providertx.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* hopefully fix governance-classes.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-validators.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-classes.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* fix governance-classes.h
Signed-off-by: Pasta <pasta@dashboost.org>
* DecodeTransaction -> DecodeDestination, fix governance-validators.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* More fixes for 3294
* Move GetIndexKey into rpc/misc.cpp near getAddressesFromParams
No need to have it in base58.cpp anymore as this is only used in getAddressesFromParams
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Alexander Block <ablock84@gmail.com>
2020-01-22 11:35:04 +01:00
CTxDestination dest ;
ExtractDestination ( txout . scriptPubKey , dest ) ;
2018-08-14 11:58:38 +02:00
UniValue obj ( UniValue : : VOBJ ) ;
2020-06-18 11:17:23 +02:00
obj . pushKV ( " payee " , EncodeDestination ( dest ) . c_str ( ) ) ;
obj . pushKV ( " script " , HexStr ( txout . scriptPubKey ) ) ;
obj . pushKV ( " amount " , txout . nValue ) ;
2018-08-14 11:58:38 +02:00
masternodeObj . push_back ( obj ) ;
2015-01-08 19:02:10 +01:00
}
2018-08-14 11:58:38 +02:00
2020-06-18 11:17:23 +02:00
result . pushKV ( " masternode " , masternodeObj ) ;
result . pushKV ( " masternode_payments_started " , pindexPrev - > nHeight + 1 > consensusParams . nMasternodePaymentsStartBlock ) ;
result . pushKV ( " masternode_payments_enforced " , true ) ;
2016-08-28 12:11:36 +02:00
UniValue superblockObjArray ( UniValue : : VARR ) ;
2018-08-14 11:58:38 +02:00
if ( pblocktemplate - > voutSuperblockPayments . size ( ) ) {
for ( const auto & txout : pblocktemplate - > voutSuperblockPayments ) {
2016-08-28 12:11:36 +02:00
UniValue entry ( UniValue : : VOBJ ) ;
Merge #11117: Prepare for non-Base58 addresses (#3294)
* Merge #11117: Prepare for non-Base58 addresses
864cd2787 Move CBitcoinAddress to base58.cpp (Pieter Wuille)
5c8ff0d44 Introduce wrappers around CBitcoinAddress (Pieter Wuille)
Pull request description:
This patch removes the need for the intermediary Base58 type `CBitcoinAddress`, by providing {`Encode`,`Decode`,`IsValid`}`Destination` functions that directly operate on the conversion between `std::string`s and `CTxDestination`.
As a side, it also fixes a number of indentation issues, and removes probably several unnecessary implicit `CTxDestination`<->`CBitcoinAddress` conversions.
This change is far from complete. In follow-ups I'd like to:
* Split off the specific address and key encoding logic from base58.h, and move it to a address.h or so.
* Replace `CTxDestination` with a non-`boost::variant` version (which can be more efficient as `boost::variant` allocates everything on the heap, and remove the need for `boost::get<...>` and `IsValidDestination` calls everywhere).
* Do the same for `CBitcoinSecret`, `CBitcoinExtKey`, and `CBitcoinExtPubKey`.
However, I've tried to keep this patch to be minimally invasive, but still enough to support non-Base58 addresses. Perhaps a smaller patch is possible to hack Bech32 support into `CBitcoinAddress`, but I would consider that a move in the wrong direction.
Tree-SHA512: c2c77ffb57caeadf2429b1c2562ce60e8c7be8aa9f8e51b591f354b6b441162625b2efe14c023a1ae485cf2ed417263afa35c892891dfaa7844e7fbabccab85e
* CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* more CBitcoinAddress -> EncodeDestination in providertx.h
Signed-off-by: Pasta <pasta@dashboost.org>
* fix CBitcoinAddress GetKeyID check
Signed-off-by: Pasta <pasta@dashboost.org>
* fix providertx.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* hopefully fix governance-classes.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-validators.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* partially fix governance-classes.cpp, unable to resolve "address.IsScript()"
Signed-off-by: Pasta <pasta@dashboost.org>
* fix governance-classes.h
Signed-off-by: Pasta <pasta@dashboost.org>
* DecodeTransaction -> DecodeDestination, fix governance-validators.cpp
Signed-off-by: Pasta <pasta@dashboost.org>
* More fixes for 3294
* Move GetIndexKey into rpc/misc.cpp near getAddressesFromParams
No need to have it in base58.cpp anymore as this is only used in getAddressesFromParams
Co-authored-by: Wladimir J. van der Laan <laanwj@gmail.com>
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
Co-authored-by: Alexander Block <ablock84@gmail.com>
2020-01-22 11:35:04 +01:00
CTxDestination dest ;
ExtractDestination ( txout . scriptPubKey , dest ) ;
2020-06-18 11:17:23 +02:00
entry . pushKV ( " payee " , EncodeDestination ( dest ) . c_str ( ) ) ;
entry . pushKV ( " script " , HexStr ( txout . scriptPubKey ) ) ;
entry . pushKV ( " amount " , txout . nValue ) ;
2016-08-28 12:11:36 +02:00
superblockObjArray . push_back ( entry ) ;
}
}
2020-06-18 11:17:23 +02:00
result . pushKV ( " superblock " , superblockObjArray ) ;
result . pushKV ( " superblocks_started " , pindexPrev - > nHeight + 1 > consensusParams . nSuperblockStartBlock ) ;
2024-02-20 05:26:12 +01:00
result . pushKV ( " superblocks_enabled " , AreSuperblocksEnabled ( * node . sporkman ) ) ;
2012-08-21 08:21:33 +02:00
2020-06-18 11:17:23 +02:00
result . pushKV ( " coinbase_payload " , HexStr ( pblock - > vtx [ 0 ] - > vExtraPayload ) ) ;
2018-04-09 10:35:43 +02:00
2012-08-21 08:21:33 +02:00
return result ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2012-08-21 08:21:33 +02:00
}
2020-05-14 14:17:38 +02:00
class submitblock_StateCatcher final : public CValidationInterface
2014-10-20 06:18:00 +02:00
{
public :
uint256 hash ;
bool found ;
2019-10-30 15:27:22 +01:00
BlockValidationState state ;
2014-10-20 06:18:00 +02:00
2017-08-17 22:59:56 +02:00
explicit submitblock_StateCatcher ( const uint256 & hashIn ) : hash ( hashIn ) , found ( false ) , state ( ) { }
2014-10-20 06:18:00 +02:00
protected :
2019-10-30 15:27:22 +01:00
void BlockChecked ( const CBlock & block , const BlockValidationState & stateIn ) override {
2014-10-20 06:18:00 +02:00
if ( block . GetHash ( ) ! = hash )
return ;
found = true ;
state = stateIn ;
2017-02-02 10:21:06 +01:00
}
2014-10-20 06:18:00 +02:00
} ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan submitblock ( )
2012-08-21 08:21:33 +02:00
{
2017-06-24 15:15:06 +02:00
// We allow 2 arguments for compliance with BIP22. Argument 2 is ignored.
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " submitblock " ,
2022-05-12 22:29:17 +02:00
" \n Attempts to submit new block to network. \n "
" See https://en.bitcoin.it/wiki/BIP_0022 for full specification. \n " ,
{
{ " hexdata " , RPCArg : : Type : : STR_HEX , RPCArg : : Optional : : NO , " the hex-encoded block data to submit " } ,
{ " dummy " , RPCArg : : Type : : STR , /* default */ " ignored " , " dummy value, for compatibility with BIP22. This value is ignored. " } ,
} ,
RPCResult { RPCResult : : Type : : NONE , " " , " Returns JSON Null when valid, a string according to BIP22 otherwise " } ,
RPCExamples {
HelpExampleCli ( " submitblock " , " \" mydata \" " )
+ HelpExampleRpc ( " submitblock " , " \" mydata \" " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2016-12-05 08:07:22 +01:00
std : : shared_ptr < CBlock > blockptr = std : : make_shared < CBlock > ( ) ;
CBlock & block = * blockptr ;
2017-04-04 08:58:53 +02:00
if ( ! DecodeHexBlk ( block , request . params [ 0 ] . get_str ( ) ) ) {
2012-10-04 09:34:44 +02:00
throw JSONRPCError ( RPC_DESERIALIZATION_ERROR , " Block decode failed " ) ;
2017-04-04 08:58:53 +02:00
}
if ( block . vtx . empty ( ) | | ! block . vtx [ 0 ] - > IsCoinBase ( ) ) {
throw JSONRPCError ( RPC_DESERIALIZATION_ERROR , " Block does not start with a coinbase " ) ;
}
2012-08-21 08:21:33 +02:00
2023-07-27 21:02:24 +02:00
ChainstateManager & chainman = EnsureAnyChainman ( request . context ) ;
2014-11-18 20:09:20 +01:00
uint256 hash = block . GetHash ( ) ;
2015-04-13 18:55:41 +02:00
{
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
const CBlockIndex * pindex = chainman . m_blockman . LookupBlockIndex ( hash ) ;
2018-03-13 19:04:28 +01:00
if ( pindex ) {
2017-04-04 08:58:53 +02:00
if ( pindex - > IsValid ( BLOCK_VALID_SCRIPTS ) ) {
2015-04-13 18:55:41 +02:00
return " duplicate " ;
2017-04-04 08:58:53 +02:00
}
if ( pindex - > nStatus & BLOCK_FAILED_MASK ) {
2015-04-13 18:55:41 +02:00
return " duplicate-invalid " ;
2017-04-04 08:58:53 +02:00
}
2015-04-13 18:55:41 +02:00
}
2012-08-21 08:21:33 +02:00
}
2018-06-19 09:25:05 +02:00
bool new_block ;
2020-05-14 14:17:38 +02:00
auto sc = std : : make_shared < submitblock_StateCatcher > ( block . GetHash ( ) ) ;
RegisterSharedValidationInterface ( sc ) ;
2023-07-27 21:02:24 +02:00
bool accepted = chainman . ProcessNewBlock ( Params ( ) , blockptr , /* fForceProcessing */ true , /* fNewBlock */ & new_block ) ;
2020-05-14 14:17:38 +02:00
UnregisterSharedValidationInterface ( sc ) ;
2021-09-11 21:54:52 +02:00
if ( ! new_block & & accepted ) {
2014-11-18 20:09:20 +01:00
return " duplicate " ;
}
2020-05-14 14:17:38 +02:00
if ( ! sc - > found ) {
2017-08-02 20:35:04 +02:00
return " inconclusive " ;
2017-04-04 08:58:53 +02:00
}
2020-05-14 14:17:38 +02:00
return BIP22ValidationResult ( sc - > state ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2012-08-21 08:21:33 +02:00
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan submitheader ( )
2021-08-10 21:37:50 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " submitheader " ,
2022-05-12 22:29:17 +02:00
" \n Decode the given hexdata as a header and submit it as a candidate chain tip if valid. "
" \n Throws when the header is invalid. \n " ,
{
{ " hexdata " , RPCArg : : Type : : STR_HEX , RPCArg : : Optional : : NO , " the hex-encoded block header data " } ,
} ,
RPCResult {
RPCResult : : Type : : NONE , " " , " None " } ,
RPCExamples {
HelpExampleCli ( " submitheader " , " \" aabbcc \" " ) +
HelpExampleRpc ( " submitheader " , " \" aabbcc \" " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2021-08-10 21:37:50 +02:00
CBlockHeader h ;
if ( ! DecodeHexBlockHeader ( h , request . params [ 0 ] . get_str ( ) ) ) {
throw JSONRPCError ( RPC_DESERIALIZATION_ERROR , " Block header decode failed " ) ;
}
2023-07-27 21:02:24 +02:00
ChainstateManager & chainman = EnsureAnyChainman ( request . context ) ;
2021-08-10 21:37:50 +02:00
{
LOCK ( cs_main ) ;
2023-07-27 21:02:24 +02:00
if ( ! chainman . m_blockman . LookupBlockIndex ( h . hashPrevBlock ) ) {
2021-08-10 21:37:50 +02:00
throw JSONRPCError ( RPC_VERIFY_ERROR , " Must submit previous header ( " + h . hashPrevBlock . GetHex ( ) + " ) first " ) ;
}
}
2019-10-30 15:27:22 +01:00
BlockValidationState state ;
2023-07-27 21:02:24 +02:00
chainman . ProcessNewBlockHeaders ( { h } , state , Params ( ) ) ;
2021-08-10 21:37:50 +02:00
if ( state . IsValid ( ) ) return NullUniValue ;
if ( state . IsError ( ) ) {
2020-03-01 21:33:52 +01:00
throw JSONRPCError ( RPC_VERIFY_ERROR , state . ToString ( ) ) ;
2021-08-10 21:37:50 +02:00
}
throw JSONRPCError ( RPC_VERIFY_ERROR , state . GetRejectReason ( ) ) ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2021-08-10 21:37:50 +02:00
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan estimatesmartfee ( )
2015-11-16 21:26:57 +01:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " estimatesmartfee " ,
2022-05-12 22:29:17 +02:00
" \n Estimates the approximate fee per kilobyte needed for a transaction to begin \n "
" confirmation within conf_target blocks if possible and return the number of blocks \n "
" for which the estimate is valid. \n " ,
{
{ " conf_target " , RPCArg : : Type : : NUM , RPCArg : : Optional : : NO , " Confirmation target in blocks (1 - 1008) " } ,
2020-12-07 13:54:49 +01:00
{ " estimate_mode " , RPCArg : : Type : : STR , /* default */ " conservative " , " The fee estimate mode. \n "
2022-05-12 22:29:17 +02:00
" Whether to return a more conservative estimate which also satisfies \n "
" a longer history. A conservative estimate potentially returns a \n "
" higher feerate and is more likely to be sufficient for the desired \n "
" target, but is not as responsive to short term drops in the \n "
2020-12-07 13:54:49 +01:00
" prevailing fee market. Must be one of (case insensitive): \n "
" \" " + FeeModes ( " \" \n \" " ) + " \" " } ,
2022-05-12 22:29:17 +02:00
} ,
RPCResult {
RPCResult : : Type : : OBJ , " " , " " ,
{
{ RPCResult : : Type : : NUM , " feerate " , /* optional */ true , " estimate fee rate in " + CURRENCY_UNIT + " /kB (only present if no errors were encountered) " } ,
2020-08-13 23:57:43 +02:00
{ RPCResult : : Type : : ARR , " errors " , /* optional */ true , " Errors encountered during processing (if there are any) " ,
2020-01-09 18:00:57 +01:00
{
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : STR , " " , " error " } ,
2020-01-09 18:00:57 +01:00
} } ,
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : NUM , " blocks " , " block number where estimate was found \n "
" The request target will be clamped between 2 and the highest target \n "
" fee estimation is able to return based on how long it has been running. \n "
" An error is returned if not enough transactions and blocks \n "
" have been observed to make an estimate for any number of blocks. " } ,
} } ,
RPCExamples {
HelpExampleCli ( " estimatesmartfee " , " 6 " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2017-07-18 01:33:29 +02:00
RPCTypeCheck ( request . params , { UniValue : : VNUM , UniValue : : VSTR } ) ;
RPCTypeCheckArgument ( request . params [ 0 ] , UniValue : : VNUM ) ;
2023-02-22 08:53:20 +01:00
2023-07-27 21:02:24 +02:00
CBlockPolicyEstimator & fee_estimator = EnsureAnyFeeEstimator ( request . context ) ;
2023-02-22 08:53:20 +01:00
unsigned int max_target = fee_estimator . HighestTargetTracked ( FeeEstimateHorizon : : LONG_HALFLIFE ) ;
2021-11-14 11:02:37 +01:00
unsigned int conf_target = ParseConfirmTarget ( request . params [ 0 ] , max_target ) ;
2017-05-17 22:02:50 +02:00
bool conservative = true ;
2017-08-22 09:24:31 +02:00
if ( ! request . params [ 1 ] . isNull ( ) ) {
2017-07-18 01:33:29 +02:00
FeeEstimateMode fee_mode ;
if ( ! FeeModeFromString ( request . params [ 1 ] . get_str ( ) , fee_mode ) ) {
throw JSONRPCError ( RPC_INVALID_PARAMETER , " Invalid estimate_mode parameter " ) ;
}
if ( fee_mode = = FeeEstimateMode : : ECONOMICAL ) conservative = false ;
2017-05-17 22:02:50 +02:00
}
2015-11-16 21:26:57 +01:00
UniValue result ( UniValue : : VOBJ ) ;
2017-07-18 01:33:29 +02:00
UniValue errors ( UniValue : : VARR ) ;
2017-06-15 13:56:16 +02:00
FeeCalculation feeCalc ;
2023-02-22 08:53:20 +01:00
CFeeRate feeRate = fee_estimator . estimateSmartFee ( conf_target , & feeCalc , conservative ) ;
2017-07-18 01:33:29 +02:00
if ( feeRate ! = CFeeRate ( 0 ) ) {
2020-06-18 11:17:23 +02:00
result . pushKV ( " feerate " , ValueFromAmount ( feeRate . GetFeePerK ( ) ) ) ;
2017-07-18 01:33:29 +02:00
} else {
errors . push_back ( " Insufficient data or no feerate found " ) ;
2020-06-18 11:17:23 +02:00
result . pushKV ( " errors " , errors ) ;
2017-07-18 01:33:29 +02:00
}
2020-06-18 11:17:23 +02:00
result . pushKV ( " blocks " , feeCalc . returnedTarget ) ;
2015-11-16 21:26:57 +01:00
return result ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2015-11-16 21:26:57 +01:00
}
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
static RPCHelpMan estimaterawfee ( )
2017-05-17 22:02:50 +02:00
{
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
return RPCHelpMan { " estimaterawfee " ,
2022-05-12 22:29:17 +02:00
" \n WARNING: This interface is unstable and may disappear or change! \n "
" \n WARNING: This is an advanced API call that is tightly coupled to the specific \n "
" implementation of fee estimation. The parameters it can be called with \n "
" and the results it returns will change if the internal implementation changes. \n "
" \n Estimates the approximate fee per kilobyte needed for a transaction to begin \n "
" confirmation within conf_target blocks if possible. \n " ,
{
{ " conf_target " , RPCArg : : Type : : NUM , RPCArg : : Optional : : NO , " Confirmation target in blocks (1 - 1008) " } ,
{ " threshold " , RPCArg : : Type : : NUM , /* default */ " 0.95 " , " The proportion of transactions in a given feerate range that must have been \n "
" confirmed within conf_target in order to consider those feerates as high enough and proceed to check \n "
" lower buckets. " } ,
} ,
RPCResult {
RPCResult : : Type : : OBJ , " " , " Results are returned for any horizon which tracks blocks up to the confirmation target " ,
{
{ RPCResult : : Type : : OBJ , " short " , /* optional */ true , " estimate for short time horizon " ,
{
{ RPCResult : : Type : : NUM , " feerate " , /* optional */ true , " estimate fee rate in " + CURRENCY_UNIT + " /kB " } ,
{ RPCResult : : Type : : NUM , " decay " , " exponential decay (per block) for historical moving average of confirmation data " } ,
{ RPCResult : : Type : : NUM , " scale " , " The resolution of confirmation targets at this time horizon " } ,
{ RPCResult : : Type : : OBJ , " pass " , /* optional */ true , " information about the lowest range of feerates to succeed in meeting the threshold " ,
{
{ RPCResult : : Type : : NUM , " startrange " , " start of feerate range " } ,
{ RPCResult : : Type : : NUM , " endrange " , " end of feerate range " } ,
{ RPCResult : : Type : : NUM , " withintarget " , " number of txs over history horizon in the feerate range that were confirmed within target " } ,
{ RPCResult : : Type : : NUM , " totalconfirmed " , " number of txs over history horizon in the feerate range that were confirmed at any point " } ,
{ RPCResult : : Type : : NUM , " inmempool " , " current number of txs in mempool in the feerate range unconfirmed for at least target blocks " } ,
{ RPCResult : : Type : : NUM , " leftmempool " , " number of txs over history horizon in the feerate range that left mempool unconfirmed after target " } ,
} } ,
{ RPCResult : : Type : : OBJ , " fail " , /* optional */ true , " information about the highest range of feerates to fail to meet the threshold " ,
{
{ RPCResult : : Type : : ELISION , " " , " " } ,
} } ,
2020-08-13 23:57:43 +02:00
{ RPCResult : : Type : : ARR , " errors " , /* optional */ true , " Errors encountered during processing (if there are any) " ,
2022-05-12 22:29:17 +02:00
{
{ RPCResult : : Type : : STR , " error " , " " } ,
} } ,
} } ,
{ RPCResult : : Type : : OBJ , " medium " , /* optional */ true , " estimate for medium time horizon " ,
2021-10-11 23:55:23 +02:00
{
2022-05-12 22:29:17 +02:00
{ RPCResult : : Type : : ELISION , " " , " " } ,
} } ,
{ RPCResult : : Type : : OBJ , " long " , /* optional */ true , " estimate for long time horizon " ,
{
{ RPCResult : : Type : : ELISION , " " , " " } ,
} } ,
} } ,
RPCExamples {
HelpExampleCli ( " estimaterawfee " , " 6 0.9 " )
} ,
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
[ & ] ( const RPCHelpMan & self , const JSONRPCRequest & request ) - > UniValue
{
2017-07-18 01:33:29 +02:00
RPCTypeCheck ( request . params , { UniValue : : VNUM , UniValue : : VNUM } , true ) ;
2017-05-17 22:02:50 +02:00
RPCTypeCheckArgument ( request . params [ 0 ] , UniValue : : VNUM ) ;
2023-02-22 08:53:20 +01:00
2023-07-27 21:02:24 +02:00
CBlockPolicyEstimator & fee_estimator = EnsureAnyFeeEstimator ( request . context ) ;
2023-02-22 08:53:20 +01:00
unsigned int max_target = fee_estimator . HighestTargetTracked ( FeeEstimateHorizon : : LONG_HALFLIFE ) ;
2021-11-14 11:02:37 +01:00
unsigned int conf_target = ParseConfirmTarget ( request . params [ 0 ] , max_target ) ;
2017-05-17 22:02:50 +02:00
double threshold = 0.95 ;
2017-07-11 15:28:28 +02:00
if ( ! request . params [ 1 ] . isNull ( ) ) {
2017-05-17 22:02:50 +02:00
threshold = request . params [ 1 ] . get_real ( ) ;
}
2017-07-11 15:28:28 +02:00
if ( threshold < 0 | | threshold > 1 ) {
throw JSONRPCError ( RPC_INVALID_PARAMETER , " Invalid threshold " ) ;
}
2017-05-17 22:02:50 +02:00
UniValue result ( UniValue : : VOBJ ) ;
2021-01-11 14:27:28 +01:00
for ( const FeeEstimateHorizon horizon : ALL_FEE_ESTIMATE_HORIZONS ) {
2017-07-11 15:28:28 +02:00
CFeeRate feeRate ;
EstimationResult buckets ;
// Only output results for horizons which track the target
2023-02-22 08:53:20 +01:00
if ( conf_target > fee_estimator . HighestTargetTracked ( horizon ) ) continue ;
2017-07-11 15:28:28 +02:00
2023-02-22 08:53:20 +01:00
feeRate = fee_estimator . estimateRawFee ( conf_target , threshold , horizon , & buckets ) ;
2017-07-11 15:28:28 +02:00
UniValue horizon_result ( UniValue : : VOBJ ) ;
UniValue errors ( UniValue : : VARR ) ;
UniValue passbucket ( UniValue : : VOBJ ) ;
2020-06-18 11:17:23 +02:00
passbucket . pushKV ( " startrange " , round ( buckets . pass . start ) ) ;
passbucket . pushKV ( " endrange " , round ( buckets . pass . end ) ) ;
passbucket . pushKV ( " withintarget " , round ( buckets . pass . withinTarget * 100.0 ) / 100.0 ) ;
passbucket . pushKV ( " totalconfirmed " , round ( buckets . pass . totalConfirmed * 100.0 ) / 100.0 ) ;
passbucket . pushKV ( " inmempool " , round ( buckets . pass . inMempool * 100.0 ) / 100.0 ) ;
passbucket . pushKV ( " leftmempool " , round ( buckets . pass . leftMempool * 100.0 ) / 100.0 ) ;
2017-07-11 15:28:28 +02:00
UniValue failbucket ( UniValue : : VOBJ ) ;
2020-06-18 11:17:23 +02:00
failbucket . pushKV ( " startrange " , round ( buckets . fail . start ) ) ;
failbucket . pushKV ( " endrange " , round ( buckets . fail . end ) ) ;
failbucket . pushKV ( " withintarget " , round ( buckets . fail . withinTarget * 100.0 ) / 100.0 ) ;
failbucket . pushKV ( " totalconfirmed " , round ( buckets . fail . totalConfirmed * 100.0 ) / 100.0 ) ;
failbucket . pushKV ( " inmempool " , round ( buckets . fail . inMempool * 100.0 ) / 100.0 ) ;
failbucket . pushKV ( " leftmempool " , round ( buckets . fail . leftMempool * 100.0 ) / 100.0 ) ;
2017-07-11 15:28:28 +02:00
// CFeeRate(0) is used to indicate error as a return value from estimateRawFee
if ( feeRate ! = CFeeRate ( 0 ) ) {
2020-06-18 11:17:23 +02:00
horizon_result . pushKV ( " feerate " , ValueFromAmount ( feeRate . GetFeePerK ( ) ) ) ;
horizon_result . pushKV ( " decay " , buckets . decay ) ;
horizon_result . pushKV ( " scale " , ( int ) buckets . scale ) ;
horizon_result . pushKV ( " pass " , passbucket ) ;
2017-07-11 15:28:28 +02:00
// buckets.fail.start == -1 indicates that all buckets passed, there is no fail bucket to output
2020-06-18 11:17:23 +02:00
if ( buckets . fail . start ! = - 1 ) horizon_result . pushKV ( " fail " , failbucket ) ;
2017-07-11 15:28:28 +02:00
} else {
// Output only information that is still meaningful in the event of error
2020-06-18 11:17:23 +02:00
horizon_result . pushKV ( " decay " , buckets . decay ) ;
horizon_result . pushKV ( " scale " , ( int ) buckets . scale ) ;
horizon_result . pushKV ( " fail " , failbucket ) ;
2017-07-11 15:28:28 +02:00
errors . push_back ( " Insufficient data or no feerate found which meets threshold " ) ;
2020-06-18 11:17:23 +02:00
horizon_result . pushKV ( " errors " , errors ) ;
2017-07-11 15:28:28 +02:00
}
2020-06-18 11:17:23 +02:00
result . pushKV ( StringForFeeEstimateHorizon ( horizon ) , horizon_result ) ;
2017-07-11 15:28:28 +02:00
}
2017-05-17 22:02:50 +02:00
return result ;
Merge #19717: rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining,zmq,rpcdump)
fa3d9ce3254882c545d700990fe8e9a678f31eed rpc: Assert that RPCArg names are equal to CRPCCommand ones (rpcdump) (MarcoFalke)
fa32c1d5ec25bc53bf989a8ae68e688593d2859d rpc: Assert that RPCArg names are equal to CRPCCommand ones (zmq) (MarcoFalke)
faaa46dc204d6d714f71dbc6f0bf02215dba0f0f rpc: Assert that RPCArg names are equal to CRPCCommand ones (mining) (MarcoFalke)
fa93bc14c7411a108dd024d391344fabf0f76369 rpc: Remove unused return type from appendCommand (MarcoFalke)
Pull request description:
This is split out from #18531 to just touch the RPC methods in misc. Description from the main pr:
### Motivation
RPCArg names in the rpc help are currently only used for documentation. However, in the future they could be used to teach the server the named arguments. Named arguments are currently registered by the `CRPCCommand`s and duplicate the RPCArg names from the documentation. This redundancy is fragile, and has lead to errors in the past (despite having linters to catch those kind of errors). See section "bugs found" for a list of bugs that have been found as a result of the changes here.
### Changes
The changes here add an assert in the `CRPCCommand` constructor that the RPCArg names are identical to the ones in the `CRPCCommand`.
### Future work
> Here or follow up, makes sense to also assert type of returned UniValue?
Sure, but let's not get ahead of ourselves. I am going to submit any further works as follow-ups, including:
* Removing the CRPCCommand arguments, now that they are asserted to be equal and thus redundant
* Removing all python regex linters on the args, now that RPCMan can be used to generate any output, including the cli.cpp table
* Auto-formatting and sanity checking the RPCExamples with RPCMan
* Checking passed-in json in self-check. Removing redundant checks
* Checking returned json against documentation to avoid regressions or false documentation
* Compile the RPC documentation at compile-time to ensure it doesn't change at runtime and is completely static
### Bugs found
* The assert identified issue #18607
* The changes itself fixed bug #19250
ACKs for top commit:
fjahr:
tested ACK fa3d9ce3254882c545d700990fe8e9a678f31eed
promag:
Code review ACK fa3d9ce3254882c545d700990fe8e9a678f31eed.
Tree-SHA512: 068ade4b55cc195868d53b7f9a27151d45b440857bb069e261a49d102a49a38fdba5d68868516a1d66a54a73ba34681362f934ded7349e894042bde873b75719
2020-08-31 17:42:32 +02:00
} ,
} ;
2017-05-17 22:02:50 +02:00
}
2020-04-07 17:45:34 +02:00
void RegisterMiningRPCCommands ( CRPCTable & t )
{
2018-09-10 18:13:11 +02:00
// clang-format off
2016-03-31 10:55:06 +02:00
static const CRPCCommand commands [ ] =
2017-09-05 18:43:07 +02:00
{ // category name actor (function) argNames
2016-03-31 10:55:06 +02:00
// --------------------- ------------------------ ----------------------- ----------
2017-09-05 18:43:07 +02:00
{ " mining " , " getnetworkhashps " , & getnetworkhashps , { " nblocks " , " height " } } ,
{ " mining " , " getmininginfo " , & getmininginfo , { } } ,
{ " mining " , " prioritisetransaction " , & prioritisetransaction , { " txid " , " fee_delta " } } ,
{ " mining " , " getblocktemplate " , & getblocktemplate , { " template_request " } } ,
{ " mining " , " submitblock " , & submitblock , { " hexdata " , " dummy " } } ,
2021-08-10 21:37:50 +02:00
{ " mining " , " submitheader " , & submitheader , { " hexdata " } } ,
2017-01-10 13:52:49 +01:00
2019-03-19 08:43:37 +01:00
# if ENABLE_MINER
2017-09-05 18:43:07 +02:00
{ " generating " , " generatetoaddress " , & generatetoaddress , { " nblocks " , " address " , " maxtries " } } ,
2022-03-25 01:19:33 +01:00
{ " generating " , " generatetodescriptor " , & generatetodescriptor , { " num_blocks " , " descriptor " , " maxtries " } } ,
2024-02-25 19:19:02 +01:00
{ " generating " , " generateblock " , & generateblock , { " output " , " transactions " } } ,
2021-01-11 04:30:24 +01:00
# else
{ " hidden " , " generatetoaddress " , & generatetoaddress , { " nblocks " , " address " , " maxtries " } } , // Hidden as it isn't functional, just an error to let people know if miner isn't compiled
2022-03-25 01:19:33 +01:00
{ " hidden " , " generatetodescriptor " , & generatetodescriptor , { " num_blocks " , " descriptor " , " maxtries " } } ,
2022-03-25 01:30:06 +01:00
{ " hidden " , " generateblock " , & generateblock , { " address " , " transactions " } } ,
2019-03-19 08:43:37 +01:00
# endif // ENABLE_MINER
2017-05-17 22:02:50 +02:00
2020-01-05 03:35:56 +01:00
{ " util " , " estimatesmartfee " , & estimatesmartfee , { " conf_target " , " estimate_mode " } } ,
2017-09-05 18:43:07 +02:00
{ " hidden " , " estimaterawfee " , & estimaterawfee , { " conf_target " , " threshold " } } ,
2020-08-14 11:03:36 +02:00
{ " hidden " , " generate " , & generate , { } } ,
2016-03-31 10:55:06 +02:00
} ;
2018-09-10 18:13:11 +02:00
// clang-format on
2020-08-14 09:24:42 +02:00
for ( const auto & c : commands ) {
t . appendCommand ( c . name , & c ) ;
2022-10-30 17:42:34 +01:00
}
2016-03-31 10:55:06 +02:00
}