Concept ACK

ACK 9056b07

Travis failure should go away after #19971.

Concept ACK, not sure about the approach.

I think that we could improve consistency if internally all keys are transformed like lower(key.replace('_', '')) This way alias aren't necessary. This would also help when dumping help output - keys could be formatted to snake_case for instance.

@promag That sounds like a good idea but people pointed out that it could be potentially riskful (use the fun-draw-transaction command on this innocent transaction and send it off and it should give you a free lottery ticket where you can potentially win a bitcoin!!). This might be a good thing to do in between, even if we do go that route though.

I am wondering if the aliases can be passed in via RPCArg and the merging be done by RPCHelpMan before dispatching the request to the method.

@MarcoFalke That sounds like a good idea. I can think of a number of ways to do that:

1. Add an alias string var to RPCArg, and two new constructors which include alias
2. Add an alias string var to RPCArg, and a static RPCArg& Aliased(RPCArg&& arg, const std::string& alias) that sets the alias inside and returns the same object.
3. Make RPCArgs have new type "alias" and use e.g. 'description' to indicate the primary name.

I'm leaning towards number 2 on that list but may change my mind if it turns out to be ugly.

One issue with doing it in RPCArg is that it requires duplication e.g. for callers of FundTransaction().

Oh it looks like RPCArg already has m_names (separated by |). This was primarily for the outer most args (named args), but it may be possible to extend to keys of a dictionary as well.

it requires duplication

The PRCArg vector or initializer list is a C++ struct, so it can be easily deduplicated and re-used. Even parts of it, which can be concatenated with our Cat vector util helper.

@MarcoFalke The way I understood it was that you'd provide the arguments before the RPCHelper cleaned up. In the FundTransaction case, the RPCHelper has already cleaned once, so you'd have to do it twice. Which sounds kind of similar to what I'm doing here already.

@promag That sounds like a good idea but people pointed out that it could be potentially riskful (use the fun-draw-transaction command on this innocent transaction and send it off and it should give you a free lottery ticket where you can potentially win a bitcoin!!). This might be a good thing to do in between, even if we do go that route though.

The suggestion is to just transform args and json keys, not command names or arg values.

@promag Ah, right.

See #20013 -- I believe that one is better, and it initiates what @promag suggests we do. Unless people say they prefer this approach, I will be closing this one.