Add info if peer has enabled XMR auto-confirmation

[chimp1984]

An sell offer of a maker who has enabled the XMR auto-confirmation is more attractive to takers as it can be assumed that the payout will be much faster then in manual mode. We should make this information visible.

We could add to the extraMap an entry if the maker has the autoConf enabled. In the offer book we can then show a new icon to signal to takers that this offer will likely be confirmed fast.
If the maker changes the setting after offer-creation we would need to update the offer (remove old once and add new one with updated extraMap). Still there might be a gap that the maker deactivates the auto-conf after a taker has taken the offer but before the XMR got confirmed, thus leading to a wrong expectation for the taker. I think that cannot be avoided and enforcing to use auto-conf once set in the offer might be too harsh/confusing.

If the maker is the buyer and would only like to accept takers who have auto-conf enabled we could add another entry in the extraMap to signal that. But it might be a bit too much UX hassle to explain this to makers at offer creation (e.g. "Do you want to only accept takers who have auto-conf enabled?").

Another approach might be to add a new payment method ALTCOIN_AUTO_CONF similar to SEPA_INSTANT. But I guess that would cause more effort and has the risk to partition the market. Also it will require more changes of the handling of the setting, as for normal XMR it would be taken from preferences, for the ALTCOIN_AUTO_CONF trades it would be enabled by default and cannot be changed.

So there are several paths to get there:

1. Add flag to offer and show it in offerbook
2. Update offer once maker changes autoconf
3. Add support that maker only accepts takers which have autoconf enabled (only if roles of taker is seller)

Or
Add new payment method type and enforce that any trade of that type require the auto-conf to be set.

I think to keep effort in limits we should start with option 1 and impl. it step by step and even roll it out if only step 1 is implemented.

Any comments?

[chimp1984]

I implemented the first part:

https://github.com/chimp1984/bisq/tree/show-if-maker-has-xmr-autoconf-enabled

Auto-conf offers get now a "rocket" ;-)

[sqrrm]

Using the extradata seems most reasonable. It's always possible to spoof this whichever method we use so a simple indication seems the most honest. It's likely the offer will use autoconf, but we cannot enforce that.

If we split the market with a new account type that could still not be guaranteed to use autoconf, the client could be modified to not use it and then we split the market for nothing.

Requiring takers to have autoconf carries a similar problem, but it's not as strongly dividing of the market I think. Might be worth it.

[RefundAgent]

I think for now that testing "1 Add flag to offer and show it in offerbook" should be enough. I think this will be very popular by the traders but I may be wrong. If it increases the volume of XMR-trades and/or is seen to be popular by trader-comments on e. g. Keybase then one should contemplate to extend it to include 2 and 3 also. I don't really see any incentives for the traders to advertise auto-confirm and then disable it.

[chimp1984]

Agree. So lets keep it simple for now, enough other stuff we need to get into the next monster release....

[ripcurlx]

I'm also for the first option. It will also help us to evaluate the usage of this new feature to see if it is actually used. @wiz @devinbileck @Emzy Do we have any data from the XMR infrastructure how often it was accessed already?

[wiz]

The Monero Explorer API was queried over Tor what looks about 15 ish times so far

[07/Sep/2020:01:09:13 +0000] 
[07/Sep/2020:01:09:13 +0000] 
[07/Sep/2020:17:18:03 +0000] 
[07/Sep/2020:17:20:36 +0000] 
[07/Sep/2020:17:22:08 +0000] 
[07/Sep/2020:17:23:40 +0000] 
[07/Sep/2020:17:25:12 +0000] 
[07/Sep/2020:17:26:43 +0000] 
[07/Sep/2020:17:28:15 +0000] 
[07/Sep/2020:17:29:47 +0000] 
[07/Sep/2020:17:31:20 +0000] 
[14/Sep/2020:12:55:10 +0000] 
[17/Sep/2020:21:43:54 +0000] 
[19/Sep/2020:08:39:38 +0000] 
[19/Sep/2020:14:42:15 +0000] 
[19/Sep/2020:14:43:47 +0000] 
[19/Sep/2020:19:55:00 +0000] 
[19/Sep/2020:20:44:25 +0000] 
[20/Sep/2020:20:54:01 +0000] 
[22/Sep/2020:04:43:45 +0000] 
[22/Sep/2020:06:00:08 +0000] 
[22/Sep/2020:11:45:07 +0000] 
[23/Sep/2020:00:58:00 +0000] 
[23/Sep/2020:07:07:47 +0000] 
[23/Sep/2020:07:08:22 +0000] 
[23/Sep/2020:13:40:12 +0000] 
[23/Sep/2020:15:39:08 +0000] 
[25/Sep/2020:10:11:25 +0000] 
[26/Sep/2020:14:36:51 +0000] 
[26/Sep/2020:15:17:35 +0000] 
[26/Sep/2020:16:50:09 +0000] 
[26/Sep/2020:16:51:41 +0000] 
[27/Sep/2020:14:54:23 +0000] 
[27/Sep/2020:14:55:54 +0000] 
[27/Sep/2020:14:57:25 +0000] 
[27/Sep/2020:14:58:56 +0000] 
[27/Sep/2020:17:17:54 +0000] 
[27/Sep/2020:18:26:34 +0000] 
[27/Sep/2020:19:13:27 +0000] 
[27/Sep/2020:20:53:58 +0000] 
[27/Sep/2020:22:28:56 +0000] 
[27/Sep/2020:23:10:20 +0000] 
[29/Sep/2020:04:29:24 +0000] 
[29/Sep/2020:06:13:17 +0000] 
[29/Sep/2020:11:08:23 +0000] 
[29/Sep/2020:14:36:26 +0000] 
[30/Sep/2020:06:51:57 +0000] 
[30/Sep/2020:06:53:43 +0000] 
[30/Sep/2020:12:02:23 +0000] 
[30/Sep/2020:12:17:37 +0000] 

[chimp1984]

The repeated one with 90 sec diff. are from the same trade probably (until xmr got conffirmed), so does not look it was used a lot so far. Will neeed more PR I guess...

[cd2357]

Was this addressed with PR #4578?

Cause then we could close it.

[ripcurlx]

Was this addressed with PR #4578?

Cause then we could close it.

Yes, closing as complete.