Bisq Monero Wallet

[niyid]

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

CC: @ManfredKarrer, @HarryMacfinned, @ripcurlx

Dear All,

This proposal is related to:

• proposal Add Monero wallet features to Bisq #51
• issue Propose how to integrate Monero wallet into Bisq bisq#1863.
• proposal Integrate transaction proof verification for Monero #86
• proposal Automate altcoin trading #87

CYCLE 6: PROJECT INITIATION

Taking it forward and as suggested by @ManfredKarrer, the user will be responsible for running monerod locally or setting up a remote Monero node via Tor (or any remote Monero node for that matter via Tor). Of course the user will be able to either select a local Monero node (monerod running on localhost) or a remote Monero node via Tor in User Preferences.

The wallet will be accessible at Account > Wallets > Monero. The Wallets screen will allow future support for other wallets.

The Monero wallet will be based on the monero-java-rpc library and support basic functionality as follows:

• Create (or connect to) 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 sub0-address [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 sub-addresses in account 1 which can be split into multiple transactions
• Get a wallet transaction by id

Non-basic functionality and integration into Bisq are:

• Automatically send/receive Monero from/to the wallet to in trading involving Monero.
• Proof verification for Monero transactions.

ADDENDUM: screenshots with latest build below.

SCREENSHOTS - LATEST MERGED BUILD

CYCLE 7: MILESTONES & FINANCIAL ESTIMATES

The milestones and cost estimates are as show in the attached below.

Proposal_110_Milestones.xlsx

The trade interface mentioned in the spreadsheet is as shown below with the 4 trading steps.

The interface will change in line with the suggestion in issue #3375: there will be two top level menus to replace the current Buy BTC and Sell BTC - Buy/Sell BTC (merger of the two foregoing current trade menus) and Buy/Sell XMR (the addition to cater to Monero).

Trading fee calculations will remain consistent with those in current use.

I look forward to your comments.

UPDATE

Keeping in line with protocol v1.2.0, the multisig functionality will now be 2/2 and not 2/3.

[erciccione]

Pinging @woodser (maintainer of Monero-java) and @rbrunner7, Monero dev who already explored the possibility to integrate monero into Bisq in past. Do you have any opinion/suggestion about the integration?

[rbrunner7]

Well, splendid if somebody starts to work on this in earnest! All the best wishes.

About the architecture of the integration: I think the potential for variations and choices is small. It's simply not possible with a reasonable effort to make a Monero integration into software like Bisq as slick and as seamless as their Bitcoin integration, which needs neither daemon (because it itself can connect directly to the network) nor any dedicated wallet program (because wallet can get fully integrated as well).

What remains and what is feasible is a setup with Monero daemon (local or remote) plus Monero wallet through RPC and the monero-wallet-rpc binary. This is what I currently implement for OpenBazaar, just in Go instead of Java like here. It's not very elegant for the user, but it works, and the integration code itself tends to stay refreshingly small.

[woodser]

The Java library supports most (all?) of the functionality listed in this issue so I expect most of the work will be in integrating the library into Bisq's current framework.

I'd recommend using the native Java binding to Monero's wallet now that it's available instead of shipping and starting monero-wallet-rpc as part of the Bisq application which might simplify things some.

Is multisig intended to be integrated? The library supports multisig but coordinating and exchanging multisig information among participants is outside of the scope of the library, which @rbrunner7's mms may be useful for (can/should something similar be implemented in Java? Would that help?). I expect some of the challenge will be in UX while the multsig wallet is synced among participants during creation and transacting.

I think a daemon should be shipped with Bisq but the user should be able to select their own daemon by URL.

This issue references proving transactions which I think getTxKey()/checkTxKey(), getTxProof()/checkTxProof or getSpendProof()/checkSpendProof() provides the functionality for.

Also, it is possible to register listeners to wallet events like when funds are sent or received if some action should automatically be done then.

[rbrunner7]

I'd recommend using the native Java binding to Monero's wallet now that it's available instead of shipping and starting monero-wallet-rpc as part of the Bisq application which might simplify things some.

I am curious about the details how that would work on a technical level, because right now I have difficulties to see it clearly: Would that mean to link a large part of Monero's code, compiled from C++, into the Bisq executable and call into the wallet2 class directly from Java code? Are things compatible on such a low binary level, with calling conventions, data types, stack, heap, etc.?

Or would you turn those large parts of Monero's C++ code into a dynamic library and call into that from Bisq's executable?

Or are my assumptions how that "native Java binding to Monero's wallet" works on a technical level simply off the mark by a wide margin?

Curious former 6502 assembly programmer wants to know :)

[niyid]

@rbrunner7 @woodser @erciccione

I have been working on this for a couple of weeks now and made good progress with monero-wallet-rpc. Still early days though as I have a few more weeks to confidently announce completion.

I will also look at the alternative suggested - Monero Native Java bindings - once I am comfortable that the monero-wallet-rpc alternative is good enough to ship.

[woodser]

@rbrunner7 It is the latter of what you described: Monero's C++ code is compiled to a dynamic library which is specific to the platform it is running on. Java then uses that dynamic library to make native function calls to C++ using JNI to handle the mappings between languages.

Running monero-wallet-rpc is not technically that different; it is running C++ code which wraps core wallet logic but which has been compiled as a standalone executable instead of a dynamic library for other libraries to use. The difference of course is that monero-wallet-rpc must be launched as a server in the background and all communication must go through its port. Not sure how much of a burden that is, but I do hope it is all transparent to the user.

For comparison, the monero-wallet-rpc executable is 24.4 MBs on my system while the libmonero-cpp.dylib (the dynamic library built from C++ containing wallet2) is 24.9 MBs (similar because they wrap the same code).

@niyid The RPC and JNI wallet implementations conform to the same interfaces, so it should be easy to switch from one implementation to the other if you decide to.

[rbrunner7]

@woodser : Thanks for this interesting info.

Asthonishing that something like that can be made to work reliably. If it really does: I for one would probably always produce nagging questions in my mind, in a low "voice", questions like "Well, do callbacks really work?" or "Do threads and atomics and stuff still work as intended?" or "Will JNI cope if a C++ compiler update starts to produce a slightly different memory layout for some structs?" and so on.

But I guess the JNI creators and maintainers made and still make all this work in some rather monumental effort :)

[woodser]

Yeah I guess that was the challenge that the designers of JNI were confronted with. Importantly it's still running as native C++, so callbacks, threads, etc work exactly as they should. JNI just provides a layer on top to hook into and interact with the C++ execution.

Also worth noting that the library does use callbacks and threads, which are tested.

[niyid]

@niyid The RPC and JNI wallet implementations conform to the same interfaces, so it should be easy to switch from one implementation to the other if you decide to.

@woodser Thanks for the information. It should make things a lot easier.

[niyid]

Hello All,

I need to get this clear: it appears to me that with the automated XMR trading that this provides, there will be no need for arbitration (as the funds get deposited directly from one XMR address to another). Is this a correct assessment?

[chimp1984]

Please be aware of some plans: #118

[niyid]

Please be aware of some plans: #118

Thanks for this piece of information. Since the 2 models will be maintained for a while, I do not believe the plans for the new arbitration model have a near term significant impact on this proposal. Are there any dissenting impact assessments?

[sqrrm]

@niyid I don't see why this proposal would rid us of the need for arbitrators. The transaction process for xmr trades would be smoother but there are no guarantees. You still need to handle the case of one side not sending the coin, either on purpose or due to technical issues.

[niyid]

@niyid I don't see why this proposal would rid us of the need for arbitrators. The transaction process for xmr trades would be smoother but there are no guarantees. You still need to handle the case of one side not sending the coin, either on purpose or due to technical issues.

@sqrrm Indeed after earlier posting and giving further thought, I reached the same conclusion as you did. Thanks for the feedback.