[bisq-network/bisq] Autoconfirm XMR trade if tx check was validated by proof service (#4421)

James Cox notifications at github.com
Thu Aug 20 20:24:47 UTC 2020 

This is a follow-up PR to #4378 by @chimp1984

Implements bisq-network/proposals#86


### Features:

* XMR seller is prompted to enter txId and viewkey.

On the XMR buyer side,
* looks up the XMR transaction to verify that it has confirmed (using [onion-monero-blockchain-explorer](https://github.com/moneroexamples/onion-monero-blockchain-explorer))
* user can run their own validating service, or use the ones provided
* 100% agreement of all chosen services is necessary for confirmation
* feature can be configured and turned on/off from settings screen
* feature can be globally turned off via admin filter
 

### Implementation notes

Auto confirmation entails API requests to multiple autoconf service providers.  If the responses all show that the required number of confirmations have been reached the trade will be auto confirmed.

The user still has the option to confirm manually just as if auto confirm were not enabled.

Any service failure will abort the attempt at auto confirming.
- if a service is down, we fail with CONNECTION_FAIL
- if a service returns garbage response, we fail with API_INVALID
- if a service returns a different address, we fail with ADDRESS_INVALID
- if a service returns a different txId, we fail with TX_HASH_INVALID
- if a service returns a different viewkey, we fail with TX_KEY_INVALID
- if a service returns a match, but the amount is different we fail with AMOUNT_NOT_MATCHING
- if a service returns transaction not found we wait then re-try
- if a service returns less than the required confirm count, we wait then re-try
- if a service returns >= the required confirm count, TradeManager decrements its count of outstanding service calls.  Once the count reaches zero it transitions the trade to confirmed.

In any of these cases the status is shown on screen.  It also shows the progress of the confirmation count.

The general approach to implementing this feature was to keep it as simple as possible.  

Auto confirmation is a one-shot process triggered by receipt of `counterCurrencyExtraData` in the `CounterCurrencyTransferStartedMessage` from the counterparty.  

Auto-confirmed status of a trade is not persisted.  If Bisq is closed while auto confirmation was pending, when it re-starts the trade will show auto conf status disabled.  


### Testing

In regtest use a clearnet service address, e.g. `78.47.61.90:8081` (from @Emzy)

In mainnet over tor this would be `monero3bec7m26vx6si6qo7q7imlaoz45ot5m2b5z2ppgoooo6jx2rqd.onion` which is included as a default setting.

To try out this feature without making a live XMR trade, the following example TX proofs may be used.

    Sent 0.12121212 XMR (for sell 0.0012 BTC @ price 0.0099)
    to:  4ATyxmFGU7h3EWu5kYR6gy6iCNFCftbsjATfbuBBjsRHJM4KTwEyeiyVNNUmsfpK1kdRxs8QoPLsZanGqe1Mby43LeyWNMF
    tx:  0d0d5e74e56c9060095e62b92bce2c7fe8da43a28d3e11a7c51ffe0749fe4dd4
    key: 443263d31c8b05f5dd5734128fcb3cac83d0fd3c90b03ec19d5131216a5e3505

    Sent 0.1 XMR (for sell 0.001 BTC @ price 0.01)
    to:  4ATyxmFGU7h3EWu5kYR6gy6iCNFCftbsjATfbuBBjsRHJM4KTwEyeiyVNNUmsfpK1kdRxs8QoPLsZanGqe1Mby43LeyWNMF
    tx:  e8dcd8160aee016d8a0d9c480355d65773dc577313a0af8237c35f9d997b01c0
    key: 300fa18ff99b32ff097d75c64d62732bdb486af8c225f558ee48c5f777f9b509


Automated testing routines were created to verify the API JSON response handling.

Checking iteroperability between new and old clients.
- If BTC Seller = new BTC buyer = old, the buyer is not prompted for txId and key and the new proto field is not sent to the BTC seller.  Therefore auto-confirmation will not be started and the trade will operate in the old way, manual confirmation.
- If BTC Seller = old BTC buyer = new, the buyer provides txId and key and sends the new proto field to the BTC seller.  The BTC seller does not handle the new field and the trade will operate in the old way, manual confirmation.


### Discussion

* Perhaps some XMR sellers may not want (or be able) to provide the txId and viewkey?  In interest of flexibility, the UI allows those values to be optional and simply disables autoconf for the trade if the keys are empty or do not pass validation.




You can view, comment on, or merge this pull request online at:

  https://github.com/bisq-network/bisq/pull/4421

-- Commit Summary --

  * Add basic support for validation for XMR transfer with tx key
  * Add trade date
  * Implement XMR tx proof autoconfirm feature

-- File Changes --

    M assets/src/main/java/bisq/asset/CryptoNoteAddressValidator.java (18)
    M core/src/main/java/bisq/core/account/witness/AccountAgeWitnessService.java (59)
    M core/src/main/java/bisq/core/filter/Filter.java (20)
    M core/src/main/java/bisq/core/trade/Trade.java (22)
    M core/src/main/java/bisq/core/trade/TradeManager.java (201)
    A core/src/main/java/bisq/core/trade/asset/xmr/XmrProofInfo.java (155)
    A core/src/main/java/bisq/core/trade/asset/xmr/XmrProofResult.java (96)
    A core/src/main/java/bisq/core/trade/asset/xmr/XmrTransferProofRequester.java (126)
    A core/src/main/java/bisq/core/trade/asset/xmr/XmrTransferProofService.java (85)
    A core/src/main/java/bisq/core/trade/asset/xmr/XmrTxProofHttpClient.java (32)
    M core/src/main/java/bisq/core/trade/messages/CounterCurrencyTransferStartedMessage.java (18)
    M core/src/main/java/bisq/core/trade/protocol/tasks/buyer/BuyerSendCounterCurrencyTransferStartedMessage.java (1)
    M core/src/main/java/bisq/core/trade/protocol/tasks/seller/SellerProcessCounterCurrencyTransferStartedMessage.java (12)
    A core/src/main/java/bisq/core/user/AutoConfirmSettings.java (59)
    M core/src/main/java/bisq/core/user/Preferences.java (21)
    M core/src/main/java/bisq/core/user/PreferencesPayload.java (11)
    M core/src/main/resources/i18n/displayStrings.properties (21)
    A core/src/test/java/bisq/core/trade/asset/xmr/XmrProofInfoTest.java (129)
    M core/src/test/java/bisq/core/user/UserPayloadModelVOTest.java (3)
    M core/src/test/java/bisq/core/util/FeeReceiverSelectorTest.java (2)
    M desktop/src/main/java/bisq/desktop/bisq.css (4)
    M desktop/src/main/java/bisq/desktop/main/MainView.java (5)
    M desktop/src/main/java/bisq/desktop/main/MainViewModel.java (12)
    M desktop/src/main/java/bisq/desktop/main/overlays/windows/FilterWindow.java (5)
    A desktop/src/main/java/bisq/desktop/main/overlays/windows/SetXmrTxKeyWindow.java (94)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/PendingTradesDataModel.java (10)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/PendingTradesViewModel.java (64)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/steps/buyer/BuyerStep2View.java (150)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/steps/buyer/BuyerStep4View.java (20)
    M desktop/src/main/java/bisq/desktop/main/portfolio/pendingtrades/steps/seller/SellerStep3View.java (43)
    A desktop/src/main/java/bisq/desktop/main/presentation/SettingsPresentation.java (69)
    M desktop/src/main/java/bisq/desktop/main/settings/SettingsView.java (17)
    M desktop/src/main/java/bisq/desktop/main/settings/preferences/PreferencesView.java (154)
    M proto/src/main/proto/pb.proto (11)

-- Patch Links --

https://github.com/bisq-network/bisq/pull/4421.patch
https://github.com/bisq-network/bisq/pull/4421.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/4421
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200820/bffa52b2/attachment-0001.html>

More information about the bisq-github mailing list