A few issues

[OxMarco]

Nice job but I think there's still a few limitations.

First of all, can JSON config files use a similar structure? Something like this:

{
  "daemon_url": "",
  "rpc_url": "",
  "user": "",
  "pass": "",
  "destination": "",
  "refund": ""
}

Apparently, it only supports BTC as scripted coin. I tried with two machines vm1: $ ./asmr --scripted-config ../../config_example/monero.json host IP:port btc-xmr vm2: $ ./asmr --scripted-config ../../config_example/bitcoin.json client IP:port btc-xmr

I get two errors. On vm1 thread 'main' panicked at 'Failed to create unscripted verifier: No such file or directory (os error 2)', src/main.rs:59:7 and on vm2 thread 'main' panicked at 'Failed to create scripted host: missing fieldurlat line 8 column 1', src/main.rs:54:7

[kayabaNerve]

The JSON configs should be merge-able, leaving a good amount of unused fields for some coins. From an end-user perspective, we can also merge destination/refund, as those are just used for easy distinction on which path executed. That said, I don't see a benefit to merging them like you describe due to the nature of this project, especially considering we'd still need documentation over used fields.

As for the config options, you're not specifying them properly. If you don't want to use the config folder by cloning config_example, you can use those options, but both instances needed their scripted and unscripted config specified.

./asmr --scripted-config ../../config_example/bitcoin.json --unscripted-config ../../config_example/monero.json host IP:port btc-xmr ./asmr --scripted-config ../../config_example/bitcoin.json --unscripted-config ../../config_example/monero.json client IP:port btc-xmr

Please make sure you insert the IP/port, that you have Electrum Testnet running for BTC, and monerod regtest/monero-wallet-rpc running for Monero.

[OxMarco]

I was mainly referring to the naming of logically-similar data like the cryptocurrency daemon URL ("btc_url" for bitcoin and "daemon" for monero). It would make config files more consistent with each other, then you can add custom elements accordingly.

Going to the IP/Port parameter, does any unused port work?

[kayabaNerve]

In that aspect, yes, we should rename the fields.

Yep. I personally like 2931, but there wasn't a benefit in setting a port so we didn't.