Open hinto-janai opened 1 month ago
I'd put in a vote for supporting a --regtest
flag. When I was working on ETH<->XMR atomic swaps, we made extensive use of both the --regtest
flag and generateblocks
in our tests. If you are writing client RPC libraries and other tooling, it is also very useful to spin up a test instance for tests to query. I'm assuming it would be less work and code to maintain than having a simulator like Hardhat for Ethereum.
What
This is a discussion for daemon RPC calls in
cuprated
that will behave differently thanmonerod
or not be supported.The RPC calls considered are the publically available ones from
cc73fe7
.In general, adhoc
string
fields inmonerod
(including errors) will most likely differ incuprated
.Different behavior
This table describes RPC calls that will exist in
cuprated
but will have slightly different behavior thanmonerod
.get_connections
peer_id
,connection_id
: https://github.com/Cuprate/cuprate/issues/278#issue-2518048784get_info
update_available
,version
fieldsversion
/set_log_level
cuprated
's log levels may differ frommonerod
's/set_log_categories
/update
cuprated
?generateblocks
monerod
's--regtest
, willcuprated
have--regtest
?flush_cache
cuprated
havem_invalid_blocks
? Should this only flush the txpool?sync_info
overview
: https://github.com/Cuprate/cuprate/pull/320#discussion_r1811063772Not supported
This table describes RPC calls which exist in
monerod
but will not be supported incuprated
.This may mean they return a
404
or return some special error message that indicates it isn't supported./start_mining
,/stop_mining
,/mining_status
,/set_log_hash_rate
cuprated
will not include a miner/get_info
,/start_save_graph
,/stop_save_graph