maflcko

> Don't we have plethora of well documented guides and specifications on the JSON-RPC api ? No. I'd highly doubt that there is a better source of the documentation and...

> https://bitcoincore.org/en/doc/ Yes, I am aware. They are based on the `help` RPC reply. However, they are not machine readable, at least not in a standard format, so I don't...

I can only recall the gRPC (https://github.com/bitcoin/bitcoin/issues/16719) and CBOR (https://github.com/bitcoin/bitcoin/issues/22866) discussions, but those are serialization related, not about a standardized machine-readable interface documentation and specification.

Using `char` is not allowed in serialization code, because the sign of `char` is unknown/unclear. However, on some systems, `int8_t==char`, which means that `signed char` has no serialization helper. This...

Happy to review a pull, if someone creates one.

Is this related to bbe82c116e72ca0638751e063bf564cd1fe5c4d5?

Maybe there should be an assertion failure in the fuzz tests, if log messages have been written to the buffer, but logging is still disabled when the program exits?

Reminder for myself: https://github.com/bitcoin/bitcoin/pull/29623#discussion_r1535417573

Personally I like the append approach, because it specifies that everything is the "default" plus the given flags appended. Otherwise there would be ambiguity and hard-to-debug issues which default flags...

If the CI uses the same patterns that end-users will use, that is ideal. If it does not, then it is fine, too.