algo always displayed with getinfo RPC #147

algo always displayed with getinfo RPC
algo will properly display N & K values
algo will properly display default N & K values for Hush (200 * 9)

@jahway603 this looks very good, very close.

I think it makes the most sense to just have one "algo" key for Equihash. So if the algorithm is the default Equihash (200,9) , we should see:

"algo" : "equihash (200,9)"

If different N/K values are chosen, they would show up as:

"algo" : "equihash (N,K)"

for those values of N,K.

Here is code that will do that:

char *equihash_algo;
sprintf(equihash_algo, "equihash (%s,%s)", ASSETCHAINS_NK[0] ? ASSETCHAINS_NK[0] : "200" , ASSETCHAINS_NK[1] ? ASSETCHAINS_NK[1] : "9");
obj.push_back(Pair("algo",equihash_algo);

It didn't like it when I tried what you suggested. Is there another way of writing this?

I get the following before it bails:

rpc/misc.cpp: In function ‘UniValue getinfo(const UniValue&, bool, const CPubKey&)’:
rpc/misc.cpp:353:74: error: operands to ?: have different types ‘uint64_t’ {aka ‘long unsigned int’} and ‘const char*’
  353 |             sprintf(equihash_algo, "equihash (%s,%s)", ASSETCHAINS_NK[0] ? ASSETCHAINS_NK[0] : "200" , ASSETCHAINS_NK[1] ? ASSETCHAINS_NK[1] : "9");
      |                                                        ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
rpc/misc.cpp:353:122: error: operands to ?: have different types ‘uint64_t’ {aka ‘long unsigned int’} and ‘const char*’
  353 |             sprintf(equihash_algo, "equihash (%s,%s)", ASSETCHAINS_NK[0] ? ASSETCHAINS_NK[0] : "200" , ASSETCHAINS_NK[1] ? ASSETCHAINS_NK[1] : "9");
      |                                                                                                        ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
rpc/misc.cpp:354:53: error: expected ‘)’ before ‘;’ token
  354 |             obj.push_back(Pair("algo",equihash_algo);
      |                          ~                          ^
      |                                                     )

The data types are not matching

@jahway603 yeah sorry, I was just writing code off the top of my head. It looks like you need to remove the double quotes around "200" and "9" and then maybe it will work

@duke I've changed up the data types in that code snippet and even though I was able to get hushd to build with those changes & this is what happens:

I run hushd

I run ./src/hush-cli getinfo & get

$ ./src/hush-cli getinfo
error: couldn't connect to server at port 18031 : EOF reached (code 1)
(make sure server is running and you are connecting to the correct RPC port)

``

hushd then bombs out at the exact moment I run hush-cli getinfo

GetBlockSubsidy: nHeight=4634
hush_sc_block_subsidy: subsidy=1125000000 at height=4634 with ASSETCHAINS_HALVING[curEra]=340000
*** buffer overflow detected ***: terminated
Aborted (core dumped)

``

I know the solution I came up with in this PR is a bit "hacky", but it works and it works well.

@jahway603 I think it will work with equihash (%u,%u) but maybe not. The code I wrote would work in Perl but C++ is dumb. You don't need to use my code, it was just an example, you can use more straightforward if statements if you want.

The main issue is not that your code is "hacky" it's that there is no "algo N" nor "algo K" and the code that consumes this output would need to check the value of "algo" to know if "algo N" or "algo K" would exist, which makes it more complicated. All the data should be in a single key, "algo", which always exists. That means the code that uses this data can be simple.

I don't know how to do that in C++, so I tried and it failed.

I did what I could and rewrote "algo N" to "equihash N" (as it will only be displayed if it is an equihash algo) and did the same with the K value. Currently this PR in its current state fixes Issue #146.

A new separate issue can be opened to change it all to be on one line as "equihash (N, K)".

@jahway603 you are right, we can just merge this as is and I will likely massage everything into a single JSON key, because I believe that will make using this data easier. For instance, SD can just get a single JSON key and render the data as is, instead of looking for multiple keys and putting them together.

Just noticed that this PR is into the randomx branch, which was correct at the time, but now the code needs to go into dev. I will deal with that.

I just opened PR #151 to bring these new commits into the dev branch