Fix JSON parameter parsing in warnet bitcoin rpc command

[b-l-u-e]

Description

This PR addresses issue #714 by implementing JSON parameter handling for the warnet bitcoin rpc command. Currently, the command fails when users attempt to pass JSON parameters due to missing parameter processing logic.

Problem Analysis

The issue manifests when users attempt to pass JSON parameters to Bitcoin Core RPC methods:

$ warnet bitcoin rpc tank-0000 getblock '["146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805"]' 'true'
error code: -8
error message: blockhash must be of length 64 (not 66, for '[146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805]')
command terminated with exit code 8

Root Cause: The current _rpc() function has incorrect parameter handling:

1. Function signature expects params: str but should be params: List[str]
2. No JSON parameter processing logic exists
3. Shell parsing breaks JSON arrays into separate arguments
4. Bitcoin Core receives malformed input like [146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805] instead of the actual hash

Technical Solution

Parameter Type Fix

• Function Signature: Change params: str to params: List[str] to properly handle multiple arguments
• Argument Processing: Add proper parameter reconstruction and processing logic

JSON Reconstruction Logic

Add _reconstruct_json_params() function that:

1. Detects Split JSON: Identifies when JSON structures are fragmented across multiple arguments
2. Reconstructs Parameters: Joins split JSON parts back together
3. Quote Restoration: Adds quotes to unquoted string arrays ([network] → ["network"])
4. Validation: Ensures reconstructed JSON is syntactically valid

RPC Parameter Processing

Enhance _rpc() function with:

• JSON Array Handling: Properly process JSON arrays for bitcoin-cli
• Type Preservation: Handle boolean, numeric, and string values correctly
• Backward Compatibility: Maintain support for non-JSON parameters

Verification

Current Behavior (Broken)

$ warnet bitcoin rpc tank-0000 getblock '["146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805"]' 'true'
error code: -8
error message: blockhash must be of length 64 (not 66, for '[146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805]')

Expected Behavior (After Fix)

$ warnet bitcoin rpc tank-0000 getblock '["146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805"]' 'true'
{
  "hash": "146cc34515ae4ad2e938c4b8a899ac2889b37f603e9bba51854eb14540250805",
  "confirmations": 1,
  ...
}

Impact

This fix will enable:

• Proper JSON Parameter Handling: Support for arrays, objects, and complex parameters
• Bitcoin Core RPC Compatibility: Correct parameter formatting for bitcoin-cli
• Shell Safety: Robust handling of shell argument parsing edge cases
• Backward Compatibility: Existing non-JSON RPC calls continue to work

Files Modified

• src/warnet/bitcoin.py: Fix parameter type and add JSON reconstruction logic

Fixes #714

[pinheadmz]

Expected this to work:

 --> warnet bitcoin rpc tank-0001 logging '["http","rpc"]'
error: Error parsing JSON: http
command terminated with exit code 1

It did work with slashes:
warnet bitcoin rpc tank-0001 logging '[\"http\"]'

[pinheadmz]

Another thing that may be out of scope for this PR is there can be a swallowed error
bash: line 1: /usr/local/bin/kubectl: Argument list too long

for example this beast, which I'd love to see working at some point:

warnet bitcoin rpc tank-0001 importdescriptors '"descriptors":[{"desc":"pkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/44h/1h/0h/0/)#ulcldqpa","timestamp":1750949660,"active":true,"internal":false,"range":[0,999],"next":0,"next_index":0},{"desc":"pkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/44h/1h/0h/1/)#dta7s439","timestamp":1750949660,"active":true,"internal":true,"range":[0,999],"next":0,"next_index":0},{"desc":"sh(wpkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/49h/1h/0h/0/))#ygm43e8l","timestamp":1750949660,"active":true,"internal":false,"range":[0,999],"next":0,"next_index":0},{"desc":"sh(wpkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/49h/1h/0h/1/))#ztns25vt","timestamp":1750949660,"active":true,"internal":true,"range":[0,999],"next":0,"next_index":0},{"desc":"tr(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/86h/1h/0h/0/)#6pett65n","timestamp":1750949660,"active":true,"internal":false,"range":[0,999],"next":0,"next_index":0},{"desc":"tr(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/86h/1h/0h/1/)#t4u2k0yt","timestamp":1750949660,"active":true,"internal":true,"range":[0,999],"next":0,"next_index":0},{"desc":"wpkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/84h/1h/0h/0/)#8rwp50x9","timestamp":1750949660,"active":true,"internal":false,"range":[0,1000],"next":1,"next_index":1},{"desc":"wpkh(tprv8ZgxMBicQKsPdDAbWAtdMmeLt8H9t8aTwHARZ2paraAf3D167mWwqvxUcpmFmPb538Ymepz1cPLjiwzGkR7ep7yxFATw4sX2BFmqsPJYnoW/84h/1h/0h/1/)#khtqf6ka","timestamp":1750949660,"active":true,"internal":true,"range":[0,999],"next":0,"next_index": 0}]'

[pinheadmz]

This seems like a lot of work, implementing our own JSON parsing? Did you try any other approaches? Is there a better way to get the raw input string from click perhaps?

[b-l-u-e]

i will adjust the changes..thank you for the review

[pinheadmz]

I cherry-picked the lint fix to main, if you wanna rebase to run ci

[b-l-u-e]

The following is fixed:

• JSON arrays for logging: '["http","rpc"]'
• JSON arrays for getblock: '["blockhash"]' → extracts blockhash
• Plain string parameters still work: getblock 'blockhash'
• Empty arrays handled correctly

[b-l-u-e]

#725 (comment)

For the long importdescriptors command you mentioned, a few potential solutions could be explored in a future PR:
maybe file-based approach writing the descriptor data to a temporary file and pass the file path instead of the raw JSON
or perhaps chunking like split large descriptor arrays into smaller batches or use a different method to pass large data (like environment variables or stdin)

[pinheadmz]

I still don't think we need to maintain our own JSON parsing code like this. I think the issue in #714 is that @click.argument("params", type=str, nargs=-1) returns a List of what it thinks are separate arguments separated by spaces. I'm wondering if its easier to just get sys.argv and try to pass all the bitcoin-cli args as one single string. The commands are executed inside the pod itself , currently like f"bitcoin-cli {method} {params}" so we should be able to rely on bitcoin-cli interpreting the argument string correctly, as long as it is sent to the shell inside the pod correctly.