Integrate transaction proof verification for Monero

[ManfredKarrer]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

The Monero seller need to be able to provide a transaction proof (tx key) in case of a dispute as the XMR transfer cannot be verified on the blockexplorer like with other altcoins. There are at least 2 online services available to verify the tx key [1], [2].

We could integrate that the XMR seller need to provide the tx key in the trade process (after sending XMR) so that the buyer receives the tx key and can make an API call to one of those services (or better both).

It can be assumed that those services will not support Tor connections so we will need a relay solution similar to our price and fee estimation nodes. Those relay nodes provide a hidden service to the Bisq nodes and do the request to the http service in clearnet.

As soon the XMR buyer's Bisq app can verify the tx the trade can be completed. This would speed up the trade process and only requires that the buyer's app is online but not the manual interaction.

Alternatively a monerod integration with RPC could be used. Then the tx proof is not required as the buyer's wallet will know anyway once the tx arrived. Though that require that the buyer runs a monerod while having Bisq open, which might be a more narrow requirement as the above solution with using an API. Also integrating monerod will add new security risks.

To avoid risks with those services we could also provide our own service for providing the tx proof. Multiple services should be used and only if all match the result is considered trustworhty.

[1]
[2]

[ghost]

Question : do we know actually which ratio of XMR trades end up in a dispute ?

[erciccione]

Just jumping in to specify that xmrchain.net is open source: https://github.com/moneroexamples/onion-monero-blockchain-explorer and it does support Tor connections.

I'm posting this issue to the monero devs channel, so if somebody is interested or have suggestions can comment here.

[Gingeropolous]

ping @moneroexamples

[moneroexamples]

@Gingeropolous
Thanks for ping.

The explorer has api for proving and search for your outputs:

https://github.com/moneroexamples/onion-monero-blockchain-explorer#apioutputstxhashtx_hashaddressviewkeytxprove01

https://github.com/moneroexamples/onion-monero-blockchain-explorer#apioutputsblocks

So maybe this could be of use?

[chimp1984]

@moneroexamples I try to get the onion-monero-blockchain-explorer project running but get compiler issues.

make[2]: *** No rule to make target 'Xmr_WALLET_LIBRARY-NOTFOUND', needed by 'xmrblocks'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/xmrblocks.dir/all] Error 2

Is there a binary available as well?

[chimp1984]

@moneroexamples Do you know a service running it which has enabled the API?

[chimp1984]

Draft is implemented but missing the service response processing.
bisq-network/bisq#4378

[wiz]

Cool project. It probably makes sense for Bisq ops team to run our own federation of XMR nodes and offer this API service. If you verify against all nodes and they agree, then you can release the funds automatically.

[chimp1984]

@wiz Yes to have multiple nodes and they all need to match we gain a good level of security. Additionally one could build a watch dog service which periodically checks if the nodes are honest by testing it with data and the verify itself.

[chimp1984]

If anyone tries to complile the service, use clang as it seems it doen not work otherwise...

[MwithM]

I consider this as an approved idea, but superseeded by a most precise proposal in #239

[chimp1984]

@moneroexamples
We have implemented the auto-confirmation with the tx proof (bisq-network/bisq#4458) and at testing with an old xmr transaction I got a different address in the json as we would expect with the converted user address.

We use that code for conversion (author: @jmacxx )

  byte[] decoded = MoneroBase58.decode(address);
            // omit the type (1st byte) and checksum (last 4 byte)
            byte[] slice = Arrays.copyOfRange(decoded, 1, decoded.length - 4);
            return Utils.HEX.encode(slice);

Address from json result (convertToRawHex):
8c23cc40c40f01c5c6d8ed10d2f1707f7b855ba37f535c01f80664a3b257bf7eebba21399be830c6435e5cd2edc3b374cf40b949018ea2004205694a5400bbae
Expected (convertToRawHex):
8c23cc40c40f01c5c6d8ed10d2f1707f7b855ba37f535c01f80664a3b257bf7eebba21399be830c6435e5cd2edc3b374cf40b949018ea2004205694a5400bbae190200fd2c2d887a 

So the expected value from our address conversion has 8 bytes at the end more than the address in the json. Is it related to the address format change? This tx was nearly 1 year old.

Any idea whats the reason for the problem and how to fix it? Sorry I am not much familiar with internals of Monero.

[chimp1984]

@moneroexamples We found the issue. This was a integrated address with payment ID. Fixed with bisq-network/bisq@8682127
Do Subaddress need extra handling as well?