Propose how to integrate Monero wallet into Bisq

[ManfredKarrer]

This is a bounty task for writing a clearly thought out proposal how to integrate a Monero wallet into Bisq.
Basic idea is to connect with RPC to monderod and provide a basic wallet UI in Bisq for Monero. A second step would be to make sending and receiving Monero in the trade process automated.
It should be designed with iterative release cycles in mind. Start with minimal vialbel product and then move to the next level.
Security is an important factor to keep in mind.
Proposal author should be very familiar with Monero from tech and community side.
The proposal needs to have contain research in the technical feasibility and solutions (e.g. which Java library to use for RPC,...).

I suggest 500 BSQ for such a proposal. But it is open for discussion.

[scottAnselmo]

This issue was mentioned at the tail end of the monero-dev meeting yesterday and is now also mentioned to the broader Monero community: https://np.reddit.com/r/Monero/comments/9ugtzj/propose_how_to_integrate_monero_wallet_into_bisq/

[ManfredKarrer]

Thanks for sharing!

[antoinebechamp]

a random thought on this: perhaps a daemon could be implemented that sits between bisq and monerod and emulates the specific bitcoind RPC calls that are used by bisq.

as I understand it, bisq now has a mode that can utilize bitcoind running on localhost via RPC (instead of bitcoinj library). So, if a piece of software can implement those RPC calls and translate/forward them instead to a running monerod instance, neither bisq nor monerod would need to be modified.

It's an open question (area for research) how closely the bitcoind RPCs can be emulated for monerod. Many concepts are similar though. I found this mapping of api calls, as a basic starting point. Since that time, monero now supports subaddresses, which work a bit more like getnewaddress.

The main benefits I see to this approach (if feasible) are that:

• anyone can implement it in any language. no need to be familiar with bisq code, java, or monero code.
• the RPC proxy daemon can be useful to other software/devs. There is a large ecosystem of code that uses bitcoind RPCs. A monero compatibility layer could make monero easier to integrate.
• possibly the fastest way to get basic monero functionality into bisq.

The main drawback is that some features of the monero api would not be accessible from bisq this way, for example options related to mixin, ring size. Configurable defaults would be used in daemon.

If bisq devs find this approach interesting, I think a next step would be to list here all the bitcoind RPC calls used by bisq, and then an on-paper mapping of calls, params, and return values could be attempted to judge the feasability and identify any problem areas.

[erciccione]

@antoinebechamp FYI a detailed list of RPC calls for both daemon and CLI wallet can be found here: https://ww.getmonero.org/resources/developer-guides/

I can't evaIuate it technically, but like the idea of a "neutral" daemon in the middle, i think it could make implementation much easier.
For readers interested in the implementation: There are a lot of repositories which could be useful for this integration. Please take a look at the repositories in the Monero Ecosystem project. An interesting source of info about Monero's wallets/daemon is Monerodocs.
To contact Monero developers, join #monero-dev or #monero on Freenode (channels relayed also on matrix and MatterMost)

[ManfredKarrer]

@antoinebechamp
Bisq is not using bitcoind but bitcoinj (java bitcoin lib) for the wallet. Only the Bisq DAO is using bitcoind (for getting all txs from a block to filter out BSQ txs).
So that approach - though it is interesting - will not be feasible. I think there is a java RPC lib for Monero so that should be not a big problem to use that. Then there is the question what is the minimum viable version to make a XMR send tx and get notified about a receipt. With those 2 functionalities the XMR transfer and trade could be automated.

[ManfredKarrer]

Here is a rough overview:

BTC buyer side
Get notification from Bisq trade domain that the deposit tx is confirmed, the UI goes to step 2 and the BTC buyer needs to send the XMR. Currently thats manual.

To make it automatic we need to make a rpc call to monerod with amount and receiver address. All other params (fee,...) can be left to default for the start. After the XMR is successfully sent (need notification for success from rpc lib or poll for state change) the buyer send the payment started message to the peer. That is done now ny the button click, with automated version the XMR sent success message triggers that sending.

So the interaction with monerod is:

1. Send [amount] XMR to [address]
2. Listen for tx success

BTC seller side
The BTC seller also gets notified once the deposit tx is confirmed and then waits for the "payment started message". Once he received that he will check his monero wallet if he recived the correct amount. If received, he clicks the button "payment received" and with that the payout will be done.

For the automated version we should listen immediately when the deposit tx is confirmed for the received XMR (in some cases the payment sent message does not arrive (bugs, network connectivy or use forget to click). So as soon the seller gets notified about the receipt of the trade amount that notoification triggers the payout.

So the interaction with monerod is:
Listen for incoming tx with expected [trade amount]

One issue is that he does not see the senders address. In case he expect 2 payments with exactly the same trade amount he does not know which peer has sent it. Not a big problem in reality - I don't remember any case that there was that problem. But could be fixed if we include the XMR tx ID - or maybe use payment ID? - in the "payment started message". I am not familiar with payment ID. Though as we want to support automated trades to any altcoin in future a more generic solution (include txid in message) might be better.

I think that for a minimal version no XMR wallet UI is required. The user runs monerod or UI wallet anyway and can use that for checking txs. But of course a nice next step could be to add a basic UI for the monero wallet. But I would prefer to start with a MVP.

One problem is that when you send XMR mostly your balance is locked for a while. So we need to detect that case to get notified once the required wallet balance is available.

Interaction with monerod is:
Listen for balance state updates and get available balance

Once reported available balance is >= trade amount to send the app can trigger the send call.

[antoinebechamp]

Bisq is not using bitcoind but bitcoinj (java bitcoin lib) for the wallet

Oh my mistake. nevermind about that approach then.

You are likely aware of monero-java-rpc for RPC calls. I guess it should do what is needed, though waiting for confirmations might require polling, I haven't looked into that.

Or also I found moneroJavaLibrary

I guess @ManfredKarrer you already made a pretty solid proposal in your comment.

[ManfredKarrer]

@antoinebechamp
Thanks for the links! I heard of those but did not had time to look into it. As we only need very basic features I assume those should be covered by the libs.
All in all I think it should not be a very difficult and time consuming task. But to get that all preduction ready it will require a bit of knowledge about the Bisq code base. Unfortunately all such devs are completely busy with other high prio work atm. But any dev who is interested to get hand on it is welcome!

[niyid]

Hi @ManfredKarrer

What is the status of this proposal?

If it has not yet been taken up, I will like to take it up.

I plan to use the monero-java-rpc library which provides the following features (which I believe should suffice):

• Create a wallet that uses a monero-wallet-rpc endpoint with authentication
• Get wallet balance as BigInteger/long (for consistency in Bisq use long)
• Get wallet primary address
• Get address and balance of subaddress [1, 0]
• Get incoming and outgoing transfers
• Get incoming transfers to account 0
• Send to an address from account 0
• Get all confirmed wallet transactions
• Send to multiple destinations from multiple subaddresses in account 1 which can be split into multiple transactions
• Get a wallet transaction by id

The wallet account 0 is populated from Account > ALTCOIN ACCOUNTS.

And of course it will automatically send/receive Monero from/to the wallet to in trading involving Monero.

If there are any further requirements or features/functions please let me know.

Regards.

[ManfredKarrer]

@niyid Ah cool!

Status is not much more as in the above comments, nobody worked on it.
I would not put it into the DAO section as it has nothing to do with the DAO. Better the account section in a new tab there.
Integration in the trade screens would be nice. Have not thought about details but best to come up with some suggestion and we can discuss then.

[niyid]

OK. It has nothing to do with DAO. I have removed the suggested location in DAO.

Does the following apply:

The wallet account 0 is populated from Account > ALTCOIN ACCOUNTS?

And then when the Monero account is created, the wallet appears after ALTCOIN ACCOUNTS > IMPORT ACCOUNTS? This tab is empty if no Monero accounts exist.

Does that work?

By the way, the issue has not yet been assigned to me. I will start working on it anyway.

[ManfredKarrer]

I would not recommend to mix the currnet "account" terminology and context with the monero wallet integration. Atm an account is just a altcoin address and you can create multiple XMR accounts with diff. addresses if you want.
I would handle it completely different from altcoin accounts in a new fixed tab showing first: "Integrate local Monero wallet" and then once setup is done showing the important data fields there. Not sure if multiple need to be supported, just makes things more complicate for nearly no addistional user benefit (who wants to have multiple local monero wallets?)

[ManfredKarrer]

Also - even possible - I dont assume that other altcoins will get added with wallet integration. So would not consider that atm as requirement.

[niyid]

@ManfredKarrer

Thanks for the insights. When will this be assigned?

[niyid]

Hello? Any updates on assignation?

[ghost]

A little reminder about 2 other related proposals:

• Integrate transaction proof verification for Monero proposals#86
• Automate altcoin trading proposals#87

Maybe bisq-network/proposals#86 is easier to implement ?

[ghost]

For information:
a_native_java_binding_and_c_library_to_monero
https://www.reddit.com/r/Monero/comments/cpv0hx/a_native_java_binding_and_c_library_to_monero/

[niyid]

@ManfredKarrer @HarryMacfinned,

I found the solution that aligns best with Bisq architecture is to connect to a TOR remote node. Does Bisq currently maintain any such nodes? Comments please.

[ghost]

Hello @niyid ,
Please see bisq-network/roles#72 (Tor relay operator).
Sorry for the delay, I was absent the last days.

[niyid]

Thanks. Will do.

…

On Tue, Aug 20, 2019, 09:52 Harry MacFinned ***@***.***> wrote: Hello @niyid <https://github.com/niyid> , Please see bisq-network/roles#72 <bisq-network/roles#72> (Tor relay operator). Sorry for the delay, I was absent the last days. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1863?email_source=notifications&email_token=AE2MWR75FBTL2REW6CADEX3QFOWDRA5CNFSM4GBVYIK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VSCCI#issuecomment-522920201>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2MWR23ED2ENIY2T5DN3VTQFOWDRANCNFSM4GBVYIKQ> .

[ghost]

@niyid

I found the solution that aligns best with Bisq architecture is to connect to a TOR remote node. Does Bisq currently maintain any such nodes? Comments please.

In fact, what you would like is a monero remote node, running over Tor.
Like indeed Bisq does with bitcoin nodes running over Tor, and reachable thru an onion address.

For information, installing a monero node is not so hard, and only needs a medium sized disk. The monero blockchain is < 80GB atm. It can even run on a Raspberry Pi.
I'm running a monero node, but only episodically because it runs on clearnet.
I have some docs about peoples running monerod over Tor ... but it seems not so simple.
I'll try to do that with my monero node, and I'll provide you the onion address when/if I succeed.

[niyid]

@HarryMacfinned Great! This is exactly what I needed (I suppose I did not initially communicate in clearer terms). I felt being a Bisq requirement, we should have our own trusted Monero remote nodes running over Tor. Many monero remote nodes may not be trustworthy or efficient enough to support Bisq. Maybe @sqrrm could also be of some assistance?

…

On Wed, Aug 21, 2019, 18:12 Harry MacFinned ***@***.***> wrote: @niyid <https://github.com/niyid> I found the solution that aligns best with Bisq architecture is to connect to a TOR remote node. Does Bisq currently maintain any such nodes? Comments please. In fact, what you would like is a monero remote node, running over Tor. Like indeed Bisq does with bitcoin nodes running over Tor, and reachable thru an onion address. For information, installing a monero node is not so hard, and only needs a medium sized disk. The monero blockchain is < 80GB atm. It can even run on a Raspberry Pi. I'm running a monero node, but only episodically because it runs on clearnet. I have some docs about peoples running monerod over Tor ... but it seems not so simple. I'll try to do that with my monero node, and I'll provide you the onion address when/if I succeed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1863?email_source=notifications&email_token=AE2MWR6DJICTAB6GJLN3TILQFVZPLA5CNFSM4GBVYIK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD42NUIQ#issuecomment-523557410>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2MWR2GKXJGQ7FXJCZ3PSLQFVZPLANCNFSM4GBVYIKQ> .

[sqrrm]

@niyid I'm not sure we want to run monero nodes as a part of Bisq contributions, it seems somewhat outside of the Bisq scope. Better for users that care about that to run their own private nodes.

Regarding the TOR relays run under the tor node operator role, they're meant to be pure relays to support the TOR network since Bisq relies on the TOR network.

The best way to continue would be to write up a proper proposal on how to do this monero integration. This will allow for a more structured discussion.

[erciccione]

I'm not sure we want to run monero nodes as a part of Bisq contributions, it seems somewhat outside of the Bisq scope.

As @HarryMacfinned mentioned (and i agree would be the best option), Monero nodes could run the same way btc nodes are managed. In that case we would have a new role: XMR node operator. The user could have the possibility to run their own local node or use another one not managed by bisq operators.

A monero Node is much smaller than a bitcoin node.

I also wanted to mention that the present Tor-Monero integration is very new and will be greatly improved (see for example monero-project/monero#5793 )

[niyid]

I'm not sure we want to run monero nodes as a part of Bisq contributions, it seems somewhat outside of the Bisq scope.

As @HarryMacfinned mentioned (and i agree would be the best option), Monero nodes could run the same way btc nodes are managed. In that case we would have a new role: XMR node operator. The user could have the possibility to run their own local node or use another one not managed by bisq operators.

A monero Node is much smaller than a bitcoin node.

I also wanted to mention that the present Tor-Monero integration is very new and will be greatly improved (see for example monero-project/monero#5793 )

@sqrrm , @erciccione , @HarryMacfinned , @ManfredKarrer

That is exactly what I suggested. Let me know which direction is decided on.

Regards.

[niyid]

@sqrrm

Can you please assign bisq-network/proposals#86 and bisq-network/proposals#87 or merge them along with #1863 with proposal bisq-network/proposals#110 please? They have all been incorporated into the proposal bisq-network/proposals#110

Thanks.

A little reminder about 2 other related proposals:

• bisq-network/proposals#86
• bisq-network/proposals#87

Maybe bisq-network/proposals#86 is easier to implement ?

[sqrrm]

@niyid just reference them from bisq-network/proposals#110 until there is some kind of conclusion.

[niyid]

Great. I already did. Thanks.

…

On Mon, Sep 2, 2019, 17:53 sqrrm ***@***.***> wrote: @niyid <https://github.com/niyid> just reference them from bisq-network/proposals#110 <bisq-network/proposals#110> until there is some kind of conclusion. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1863?email_source=notifications&email_token=AE2MWRZCVWZ3Y2J2MM2XSMLQHVAG3A5CNFSM4GBVYIK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5WH7FQ#issuecomment-527204246>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE2MWR53B45RWITGS6WY6ODQHVAG3ANCNFSM4GBVYIKQ> .