haveno-dex / haveno

Decentralized P2P exchange built on Monero and Tor

|

What is Haveno?

Haveno (pronounced ha‧ve‧no) is a platform for people who want to exchange Monero for fiat currencies like EUR, GBP, and USD or other cryptocurrencies like BTC, ETH, and BCH.

Main features:

• All communications are routed through Tor, to preserve your privacy

• Trades are peer-to-peer: trades on Haveno will happen between people only, there is no central authority.

• Trades are non-custodial: Haveno provides arbitration in case something goes wrong during the trade, but we will never have access to your funds.

• There is No token, because we don't need it. Transactions between traders are secured by non-custodial multisignature transactions on the Monero network.

• The revenue generated by Haveno will be managed by an entity called Council (more info soon), composed by members of the Monero/Haveno community, not the Haveno Core Team and will be used to fund Haveno and Monero development.

See the FAQ on our website for more information.

Status of the project

A live test network is online and users can already run Haveno and make test trades between each others using Monero's stagenet. See the instructions to build Haveno and connect to the network. Note that Haveno is still very much in development. If you find issues or bugs, please let us know.

Main repositories:

• haveno - This repository. The core of Haveno.
• haveno-ui - The user interface.
• haveno-ts - TypeScript library for using Haveno.
• haveno-meta - For project-wide discussions and proposals.

If you wish to help, take a look at the repositories above and look for open issues. We run a bounty program to incentivize development. See Bounties

The PGP keys of the core team members are in gpg_keys/.

Keep in touch and help out!

Haveno is a community-driven project. For it to be successful it's fundamental to have the support and help of the community. Join the community rooms on our Matrix server:

• General discussions: Haveno (#haveno:monero.social) relayed on IRC/Libera (#haveno)
• Development discussions: Haveno Development (#haveno-dev:monero.social) relayed on IRC/Libera (#haveno-dev)

Email: [email protected] Website: haveno.exchange

Running a local Haveno test network

See docs/installing.md

Contributing to Haveno

See the developer guide to get started developing for Haveno.

See docs/CONTRIBUTING.md for our styling guides.

If you are not able to contribute code and want to contribute development resources, donations fund development bounties.

Bounties

To incentivize development and reward contributors we adopt a simple bounty system. Contributors may be awarded bounties after completing a task (resolving an issue). Take a look at the issues eligible for a bounty on the dedicated Kanban board or look for issues labelled '💰bounty' in the main haveno repository. Details and conditions for receiving a bounty.

Support and sponsorships

To bring Haveno to life, we need resources. If you have the possibility, please consider becoming a sponsor or donating to the project:

Monero

42sjokkT9FmiWPqVzrWPFE5NCJXwt96bkBozHf4vgLR9hXyJDqKHEHKVscAARuD7in5wV1meEcSTJTanCTDzidTe2cFXS1F

If you are using a wallet that supports OpenAlias (like the 'official' CLI and GUI wallets), you can simply put [email protected] as the "receiver" address.

Bitcoin

1AKq3CE1yBAnxGmHXbNFfNYStcByNDc5gQ

haveno's Issues

Create document to guide design of Haveno

This issue requests documenting key goals of Haveno (e.g. simplicity) and differences from Bisq (e.g. 2/3 multisig vs 2/2 multisig + refund process) in order to guide user interface design.

Trade within Open Trade view indicates false errors

Once a taker takes an offer, the trade in Open Trades shows errors: N/A for "Taker fee transaction ID" and "The peer's taker fee transaction is missing". These errors do not prevent trades from completing. Error checks and the legacy gui need updated to reflect the new trade protocol which does not have separate fee transactions.

Reduce the number of requests to poll a Monero daemon [$800]

"Currently, wallets make up to 4 requests each time a wallet polls a daemon: get_info, get_transaction_pool_hashes, get_transactions, and get_blocks.bin.

As a result, daemons must service up to 4 requests for each client poll, and the user may experience a noticeable delay before their wallet even starts to sync blocks if their connection is slow."

See the issue on the Monero repo for the full details: monero-project/monero#7571

Set up CI

It's very important to have continuous testing. We should set up a CI service to test at least incoming PRs and the master branch. Probably the best option would be to use GitHub's workflows, but we could also consider other tools like Travis.

Add API function to get market depth data of a trade pair [$250]

This issue requests adding new API functions to get market depth data of a trade pair.

This API call will provide market depth data for the UI:

The following function is a requested addition to HavenoDaemon.ts. Feedback is welcome.

API Function	Return	Description
havenod.getMarketDepth(currencyCode)	MarketDepth	Get market depth data for a trade pair

The following type is returned:

MarketDepth
currencyCode: string
buyPrices: double[]
buyDepth: double[]
sellPrices: double[]
sellDepth: double[]

How to implement

This new API function should be added to the Price service of Haveno's protobuf definition, to be named GetMarketDepth.

It should return the same data points as currently used in the desktop app.

Follow these instructions to add and test the new API function end-to-end.

Support creating crypto payment accounts from grpc api

Currently, creating crypto payment accounts is unsupported using the grpc api.

This issue requests implementing support for crypto payments over the grpc api here:

haveno/core/src/main/java/bisq/core/api/CorePaymentAccountsService.java

Line 102 in 59f3fc6

PaymentAccount createCryptoCurrencyPaymentAccount(String accountName,

To run a test which exercises the grpc call to create a crypto payment account:

1. Set up the ui poc: https://github.com/haveno-dex/haveno-ui-poc
2. npm test
3. Observe that the test "Can create crypto payment account" fails due to unsupported api

This test should pass after support is implemented.

Fix 'key cancellation' and 'address hostage' bugs on Monero multisig [$1000]

Monero's multisig implementation has some vulnerabilities:

• Key cancellation attack: during address construction, the attacker can 'cancel' the share components of other participants, giving himself full authority to spend funds
• Address hostage attack: during address construction, the attacker can add a non-shared key, forcing all participants to collaborate with him on any signature

These bugs need to be fixed before Haveno goes live. @UkoeHB is working on a PR.

Add API functions to manage Monero daemon connections [$1000]

This issue requests adding new API functions to manage Monero daemon connections.

These API calls will feed the UI to select and connect to a daemon connection:

The following API functions are requested additions to HavenoDaemon.ts. Feedback is welcome.

API Function	Return	Description
havenod.addMoneroConnection(connection: UriConnection)	void	Add managed connection.
havenod.removeMoneroConnection(Uri: string)	void	Remove managed connection.
havenod.getMoneroConnection()	UriConnection	Get current connection.
havenod.getMoneroConnections()	UriConnection[]	Get all managed connections, never returns their login credentials.
havenod.setMoneroConnection(Uri: string)	void	Set current connection based on current state.
havenod.setMoneroConnection(connection: UriConnection)	void	Set current connection, overwrite login credentials.
havenod.checkMoneroConnection()	UriConnection	Check status of current connection
havenod.checkMoneroConnection(connection)	UriConnection	Check status of given connection.
havenod.checkMoneroConnections()	UriConnection[]	Check status of all managed connections
havenod.startCheckingConnection(refreshPeriod: number)	void	Automatically check the current connection status in a fixed period loop.
havenod.stopCheckingConnection()	void	Stop automatically checking the current connection status.
havenod.getBestAvailableConnection()	UriConnection	Get best available connection, null if no connections available. Checks all connections.
havenod.setAutoSwitch(autoSwitch: boolean)	void	Automatically switch to best available connection if current connection disconnects.

UriConnection
Uri: string
username: string
password: string
priority: int // the higher the number, the higher the relative priority
isOnline: boolean // whether or not the daemon is online
isAuthenticated: boolean // null if no authentication, true if authenticated, false if not authenticated

The following untested pseudocode demonstrates how the API can be used in the UI:

// get haveno's preset localhost connection
let localConnection;
for (let connection of await havenod.getMoneroConnections()) {
  if (connection.getUri().contains("localhost")) {
    localConnection = connection;
    break;
  }
}
if (!localConnection) throw new Error("Haveno expected to have preset localhost");

// connect to localhost if available
localConnectionStatus = await havenod.checkMoneroConnection(localConnection); // check localhost connection status
if (localConnectionStatus.isOnline()) {
  if (localConnectionStatus.isAuthenticated() === false) {
    localConnection.setCredentials("superuser", "abctesting123"); // set credentials if needed
    await havenod.setMoneroConnection(localConnection); // overwrite connection credentials
  } else {
    await havenod.setMoneroConnection(localConnection.getUri()); // connect without changing login credentials
  }
}

// select among connections
else {
  let connections: UriConnection[] = await havenod.checkMoneroConnections();
  let selectedConnection = connections[0]; // selectedConnection.isOnline() === true
  if (selectedConnection.isAuthenticated() === false) {
    selectedConnection.setCredentials("superuser", "abctesting123");
    await havenod.setMoneroConnection(selectedConnection);
  } else {
    await havenod.setMoneroConnection(selectedConnection.getUri());
  }
  
  // verify connection
  let connectionStatus = await havenod.checkMoneroConnection();
  assert(connectionStatus.getUri() === selectedConnection.getUri() && connectionStatus.isOnline() && connectionStatus.isAuthenticated() !== false);
}

How to implement

These new API functions should be added as a new service, e.g. MoneroConnections, in Haveno's protobuf definition.

They should be implemented using monero-java's MoneroConnectionManager on the backend, which provides a direct mapping to these API calls.

Some hardcoded connections should be automatically added to the manager, e.g. http://localhost:38081 for default local stagenet.

Any managed connections should be persisted to disk and loaded on startup using the UriConnection type.

Any connection passwords should probably be encrypted with the user's account password.

Follow these instructions to add and test new API functions end-to-end.

Labels and Priorities

Labelling system

We use a labelling system to keep things organized and to make easy for potential contributors to jump in. These labels are purposely generic, so to be helpful, but not restricting or too time consuming.

We have 4 main categories of labels. Every issue should have at least the label specifying the issue type (is:), but would be also good to include the 'about' label, to specify what section of Haveno the issue is about (a:). The priority label (Pn) is not strictly necessary, but it's helpful to make clear how urgent is the issue/request.

What the issue is about (a:)

The part of Haveno the issue is about. Will help people to filter only the issues related to the area they are interested to.

Some examples:

• a:documentation
• a:monero
• a:network
• a:trade process
• a:UI
• a:18n

Issue type (is:)

The type of issue/request.

some examples:

• is:bug
• is:enhancement
• is:question
• is:refactor

Priority (Pn)

A simple priority process. Issues with higher priority should be worked first.

• P1 - The issue is prioritary and should be resolved ASAP
• P2 - The issue is high priority, but P1 issues should be resolved first
• P3 - This is the normal priority for scheduled issues
• P4 - Scheduled issue, but not a priority

Action needed (needs:)

These labels will be used as needed, for both issues and pull requests. They usually imply that the issue is blocked until a problem is solved or some info are provided.

some examples:

• needs:discussion
• needs:investigation
• needs:more info
• needs:review

Mixed

We might use other labels when needed. As said at the beginning, this structure aims to be simple and not too strict.

Reset git history

Bisq's history is heavy and messed up. Better to reset it.

Price per XMR is not accurate

Currently the price per XMR actually shows the price per BTC.

This issue requests fixing the price to be accurate.

Fix price feed and support XMR/BTC trades

This issue requests fixing the price feed for the BTC/XMR pair.

Steps to reproduce:

1. launch alice or bob desktop app
2. add BTC as a new "altcoin account"
3. in the price pull down in the upper right, observe that the BTC/XMR price is N/A whereas it should be correct
4. start creating a new offer to buy or sell XMR for BTC
5. observe that there is no "below % from market price" input box, whereas this box exists for other crypto accounts

"Error in the pull function." when attempting to clone

When attempting to clone the repository by running:

git clone https://github.com/haveno-dex/haveno.git

I get the following output:

Cloning into 'haveno'...
remote: Enumerating objects: 268676, done.
remote: Counting objects: 100% (286/286), done.
remote: Compressing objects: 100% (200/200), done.
error: RPC failed; curl 56 GnuTLS recv error (-54): Error in the pull function.
fatal: the remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Add API functions to get wallet transfers and withdraw funds [$400]

This issue requests adding new API functions to get transfers and withdraw funds.

These API calls will feed the UI wallet functionality:

The following functions are requested as additions to HavenoDaemon.ts. Feedback is welcome.

API Function	Return	Description
havenod.getXmrTxs()	XmrTx[]	Get all transactions with transfers from or to Haveno's Monero wallet.
havenod.createXmrTx(destinations: XmrDestination)	XmrTx	Create but do not relay a transaction to send funds from Haveno's Monero wallet.
havenod.relayXmrTx(txMetadata: string)	string	Relay a previously created transaction.

XmrTx
hash: string
timestamp: timestamp
transfers: XmrTransfer[]
metadata: string // used to later relay the transaction

XmrTransfer
address: string
amount: BigInt // as string in gRPC
isIncoming: boolean
destinations: XmrDestination[] // only present on outgoing transfers from local wallet data

XmrDestination
address: string
amount: BigInt // as string in gRPC

Note these wallet functions are already implemented:

API Function	Return	Description
havenod.getNewDepositSubaddress()	string	Get a new subaddress in the Haveno wallet to receive deposits.
havenod.getBalances()	XmrBalanceInfo	Get the user's Monero balances.

How to implement

A test should be added to HavenoDaemon.test.ts to test all Haveno wallet functions including sending and receiving funds and testing wallet balances and transactions.

Follow these instructions to add and test new API functions end-to-end.

Update to Tor v3 [$200]

This issue requests updating Haveno to use Tor v3.

See relevant issues in Bisq for reference: bisq-network/projects#23

Fix Fiat <-> XMR trades

At the moment XMR <-> Fiat trades are broken. The market appears always as xmr/xmr, even if we use fiat currencies (tested with EUR and USD).

To reproduce:

1. Alice adds her fiat account. Payment method: revolut
2. Bob adds his fiat account. Payment method: revolut
3. Both Alice and Bob have XMR on their account
4. Alice initiate a trade to sell 0.0625 XMR for USD

When looking at the "buy xmr" tab from Bob's window, Alice's offer is grey. When clicking on "TAKE OFFER TO SELL XMR", i get a pop up saying "No matching payment account" and suggest me to create one, but the payment account exists.

Disable dependency on BTC node [$250]

Currently Haveno depends on a Bitcoin node, Bitcoin-Qt, for proper startup and function.

This issue requests removing this dependency completely disabling the BTC dependency, since it's not necessary for XMR as a base pair.

XMR <-> Crypto trades fail

To reproduce:

1. Alice initiates a trade to sell 0.01 XMR for ETH
2. Bob takes the offer
3. deposit transactions recognized and confirmed
4. Bob clicks on "Start payment"
5. Results in an error in the UI, which doesn't allow to complete the trade:

 An error occurred at task: BuyerCreateAndSignPayoutTx
 Exception message: not enough money

Error in Bob's terminal:

Feb-20 15:06:02.109 [JavaFX Application Thread] ERROR bisq.common.taskrunner.Task: An error occurred at task: BuyerCreateAndSignPayoutTx
Exception message: not enough money 
Feb-20 15:06:02.116 [JavaFX Application Thread] ERROR b.common.taskrunner.TaskRunner: Task failed: BuyerCreateAndSignPayoutTx / errorMessage: An error occurred at task: BuyerCreateAndSignPayoutTx
Exception message: not enough money 
Feb-20 15:06:02.119 [JavaFX Application Thread] ERROR b.c.t.protocol.TradeProtocol: Task runner failed with error An error occurred at task: BuyerCreateAndSignPayoutTx
Exception message: not enough money. Triggered from PAYMENT_SENT

Log file from: bisq.log

Implement efficient generation of multisig wallet addresses [$2500]

Currently a taker must pay a trade fee before initializing the multisig wallet with the maker and arbitrator in order to prevent takers from spamming peers with unpaid work by creating multisig wallets.

As a result, the taker must have 2 outputs available in order to take a trade, one to cover the trade fee and one to deposit to multisig, which complicates the user experience. If the multisig wallet address could be known ahead of time, the taker could use one output to pay both the trade fee and the deposit tx in a single transaction.

Chapter 10 of Zero to Monero describes a way to derive the address of a multisig wallet before initializing the wallet among peers. The first two peers (maker and arbitrator) create a shared secret and publish its public key which the third peer (the taker) can use to derive the multisig address before the wallet is initialized among them.

This issue requests implementing the ability to derive multisig wallet addresses using this method. The implementation should be added to monero-project.

Build fails because checksum for jtorctl fails

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':desktop'.
> Checksum failed for com.github.JesusMcCloud:jtorctl:389d61b1b5a85eb2f23c582c3913ede49f80c9f2b553e4762382c836270e57e5

Bisq seems to be having the same issue.

Update copyright headers of all files

All files have a copyright header which says This file is part of Bisq.[...].

All these headers will have to say This file is part of Haveno.[...]. I have a PR read, but on a second thought it's probably better to wait until we start to heavily trim the code of Bisq content we don't need. A lot of file will be deleted, no reason to change their copyright header now.

Fix 'Wagner/Drijvers attack' in Monero multisig [$2500]

Monero's multisig is vulnerable to the Wagner attack, where if multiple signatures are constructed for a given address, and the wagner attack is executed, then the attacker can learn the private key shares of other participants.

This (and #102 ) has been discussed with Monero's core team (@luigi1111) and researchers (@moneromooo-monero, @SarangNoether and @UkoeHB.)

Sarang's suggestion is to fix the vulnerability by implementing the constructions specified in MRL-0009. Discussions are ongoing.

Backup XMR wallets

This issue requests support to periodically backup all XMR wallets and the BTC wallet in the application folder to ./xmr_stagenet/wallet/backup like what is currently done with the BSQ wallet.

Add API functions to initialize Haveno account [$1500]

This issue requests adding new API functions to create or restore a Haveno account on startup.

These API calls will be used to feed Haveno's startup UI:

The following API functions are requested additions to HavenoDaemon.ts. Note it is also considered if Haveno should manage multiple accounts, identified by pathname, under one directory provided at startup. Feedback is welcome.

API Function	Return	Description
havenod.accountExists()	boolean	Indicates if the Haveno account is created.
havenod.isAccountOpen()	boolean	Indicates if the Haveno account is open and authenticated with the correct password.
havenod.createAccount(password: string)	void	Create and open a new Haveno account. Throw error if accountExists().
havenod.openAccount(password: string)	void	Open existing account. Throw error if `!accountExists()
havenod.closeAccount()	void	Close the currently open account. Throw error if !isAccountOpen().
havenod.backupAccount()	zip bytes for download	Backup the account to a zip file. Throw error if !accountExists().
havenod.deleteAccount()	void	Permanently delete the Haveno account.
havenod.restoreAccount(zip: zip)	void	Restore the account from a zip file. Throw error if accountExists().
havenod.changePassword(password: string)	void	Change the Haveno account password. Throw error if !isAccountOpen().

How to implement

Currently, ./haveno-daemon automatically initializes an account folder with the name provided at startup using the --appName argument.

Instead, ./haveno-daemon should start its gRPC API and wait for createAccount() or restoreAccount() to be called to initialize the account folder.

These API calls should be added as a new service, e.g. HavenoAccount, in Haveno's protobuf definition.

Follow these instructions to add and test new API functions end-to-end.

Why fork bisq?

Curious why you've decided to entirely fork bisq when they're already looking at adding this?

Relevant issue set:

• bisq-network/bisq#5285
• bisq-network/projects#50

I mean all the power to you but just seems like burning rubber on many roads.

Review, finalize, and harden core trade protocol and code

There are many details to consider, finalize, and harden in the core trade protocol and code.

Priorities

• stress test
• implement scheduling for trades, other
• trade completion refactoring
• auto start seed node
• auto start funding wallet
• never wait for onArrived() or ack in protocols? (ProcessDepositResponse, ArbittratorSendsInitTrade*, ProcessInitMultisigRequest)
• allow node address to change; temp node address vs trusting/persisting into trade model
• test recovery from disconnecting or sleeping at various stages (balances stop updating)
• understand how arbitrator key is revoked, ensure new trader can verify past signatures and know if revoked (see bannedDisputeAgents)
• arbitrator api to register keys and resolve dispute?
• all api calls denominated in xmr atomic units
• show percent progress syncing daemon and wallet on startup
• wallet rpc authentication based on user/wallet password?
• test offers with trade range
• allow offers with multiple payment methods?
• do not update offers which would invalidate arbitrator signature (OpenOfferManager.maybeUpdatePersistedOffers())
• arbitrator TradeStepView errors / payment started button during trade
• connection manager autodetect peer connections
• signatures can be bytes per DipsuteResult.abitrator_signature
• btc atomic swaps
• funding wallet needs manually funded if cannot mine to it
• in offer counterCurrencyCode='XMR', baseCurrencyCode='ETH' ?
• CurrencyUtil:435 base currency and counter currency switched
• loss of precision handling BigInteger as long? e.g. XmrBalanceInfo? switch to strings in pb?
• test creating hundreds of new deposit addresses
• switch to native wallets?
• arbitrator broadcasts reserve tx if offer opened with same tx key within e.g. 1 second
• changeWallet() opens and syncs every wallet at once
• limit maximum number of wallets open at a time
• increase sync period (e.g. 10 or 15 seconds) for remote daemon connections
• backup multisig wallets of open trades
• "We found an outdated addressEntry for openOffer" for past trades
• delete multisig wallets if payout not confirmed after X blocks or when payout tx unlocks
• test that funds unreserve if arbitrator doesn't sign offer
• bitcoinj warning about threading
• full code refactor from big picture architecture
• use proof of reserves instead of specific key images?
• performance analysis of initializing trade
• TradeManager.closeDisputedTrade() should be called by arbitrator when dispute closed
• ArbitratorSendsInitTradeAndMultisigRequests sends multisig requests on ack but should skip if maker not reserved
• test completing trade with peers offline between messages
• switch ui tests to logging library
• send PayoutTxPublishedMessage to peer and arbitrator once signed
• test resolving dispute after payment started
• refactor dispute resolution; dispute opener includes updated multisig hex, arbitrator sends payout tx and updated multisig hex to opener, opener signs, broadcasts payout, and sends response / PayoutTxPublishedMessage
• optimize keeping wallets open and syncing, or syncing on unlock and then not re-syncing
• ensure OPenDispute ack comes back before re-opening/syncing wallet; analyze when all all wallets opened, closed, synced

Trade Completion

• review payout process
• #143
• support arbitration fee and reimbursing trader fee
• verify payout txs
• accurate fee estimation for tx verification
• close arbitrator trade at completion
• test arbitrator trade state in api tests
• don't delete trade wallets until payout tx unlocks

Optimizations / Performance

• optimize offer key image verification (only verify offers presented to ui? batch key image verification?)
• optimize number of open wallets and refresh period, especially arbitrator (see TradeManager.initPersistedTrades(), XmrWalletService.getMultisigWallet())

API Functions

• #161
• #136
• #137
• #138
• #139
• #140
• #141
• #142
• #147

Needs Consideration

• completely replace errorMessageHandler with regular exception handling
• send payment info on deposit unlock instead of deposit broadcast?
• clarify arbitrator/mediator/refund agent terminology and use throughout application
• switch base unit long from centineros to atomic units
• "No refund agents available" after idling
• "We found a closed trade with locked up funds" error
• "Wallet missing deposit tx" error
• "We had an old offer in the list with the same offer id"
• one TraderProtocol which supports maker, taker, buyer, seller methods to prevent duplicate implementations?
• flatten ProcessModel into Trade / other model refactors?
• refactor State/Phase for CleanupTradeableOnFault
• test retaking failed trade. change naming convention and create new multisig wallet or replace? cannot reuse
• TradeDataValidation.validateDepositInputs() needs updated for XMR, consolidate tx validation there?
• Create multisigs as offsets from main mnemonic, allow users to recreate multisig?

Note additional core todos are throughout the code prefixed with TODO (woodser).

Create Documentation How to Set Up Haveno for Development in Eclipse

It'd be helpful if there was some guidance how to set up this repository in Eclipse. In particular:

• How to configure Eclipse to use the wrapped Gradle or alternatively how to configure Eclipse's Gradle wrapper (so that sources compile eventually)?
• What project natures to configure?
• How to start Haveno from Eclipse (to be able to debug etc.)?

Since the .gitignore contains .project, I assume that developers are using Eclipse, too. Maybe it's also an option to commit such configuration (I also can imagine committing a physical Eclipse run configuration).

Creating such guide would ease the life of new potential developers/contributors.

Support atomic swaps with BTC

This issue requests support for atomic swaps between XMR and BTC using Farcaster, COMIT, or other suitable project to facilitate the trade protocol.

Return key images or output indices of spent outputs in monero-wallet-rpc transfer and transfer_split

Haveno depends on the ability to get key images or output indices of spent outputs from transfer and transfer_split in monero-wallet-rpc, so this issue requests implementing that functionality in monero-project. See existing issue

Create proof of concept bridging between Java and React

Haveno's user interface is currently written in Java which limits design flexibility compared to modern UI frameworks like React and tightly couples frontend with backend application logic.

This issue requests a proof of concept demonstrating React communicating with the Haveno Java backend. For example, the React application could simply display posted offers or the user's open trades.

Possible technical approaches:

• Start JVM process and communicate in terminal
• Create a proper Java server (or "daemon") for the React application to use locally
• node-java for direct API binding in js
• WebSockets
• Any other viable method

Rename bisq-* cli tools to haveno-*

This issue requests the ./bisq-* cli tools be renamed to ./haveno-*..

Provide reports on Haveno's performance[ɱ2]

Haveno's Java backend currently consumes significantly more computing resource than is necessary.

For example, performance analysis revealed the Bisq DAO to consume significant resources which will be resolved when the DAO is removed.

This issue requests detailed reports on Haveno's current resource usage in order to achieve significant performance improvements.

Specifically requested is a list breaking down top time consumers while running the application, including references to related code in order to inform where optimizations are needed and focus developer effort.

For example, this performance analysis on Monero's daemon breaks down time consumers and related code: monero-project/monero#7913 (comment)

There are many tools to analyze performance of a Java application like JVM Monitor built into Eclipse or VisualVM.

Add API functions to start and stop local Monero node [$300]

This issue requests adding new API functions to start and stop a local Monero node.

The following functions are requested as additions to HavenoDaemon.ts. Feedback is welcome.

API Function	Return	Description
havenod.startMoneroNode(rpcUsername: string, rpcPassword: string)	void	Start local monerod process, throw error if fails.
havenod.stopMoneroNode()	void	Stop local monerod process, throw error if fails.

How to implement

Start an internal monerod process using a constructor in MoneroDaemonRpc.java.

Refer to how monero-wallet-rpc instances are started and stopped in Haveno for reference as this pattern will be similar.

Follow these instructions to add and test new API functions end-to-end.

Add script to launch a local network

This issue requests a script which starts Haveno test nodes in 4 terminal tabs:

• ./bisq-seednode --baseCurrencyNetwork=BTC_REGTEST --useLocalhostForP2P=true --useDevPrivilegeKeys=true --nodePort=2002 --appName=bisq-BTC_REGTEST_Seed_2002 --daoActivated=false
• ./bisq-desktop --baseCurrencyNetwork=BTC_REGTEST --useLocalhostForP2P=true --useDevPrivilegeKeys=true --nodePort=4444 --appName=bisq-BTC_REGTEST_arbitrator --daoActivated=false
• ./bisq-desktop --baseCurrencyNetwork=BTC_REGTEST --useLocalhostForP2P=true --useDevPrivilegeKeys=true --nodePort=5555 --appName=bisq-BTC_REGTEST_Alice --daoActivated=false
• ./bisq-desktop --baseCurrencyNetwork=BTC_REGTEST --useLocalhostForP2P=true --useDevPrivilegeKeys=true --nodePort=6666 --appName=bisq-BTC_REGTEST_Bob --daoActivated=false

Note the node names also need to be renamed to ./haveno-*: #24

Check what git lfs is used for and get rid of it if we don't need it

Bisq was using it, but we probably don't need it as it seems to be used to store DAO-related files. Files stored using git lfs:

f485f1a26f * p2p/src/main/resources/AccountAgeWitnessStore_BTC_MAINNET
0feba11eb9 * p2p/src/main/resources/BlindVoteStore_BTC_MAINNET
f56bde9875 * p2p/src/main/resources/DaoStateStore_BTC_MAINNET
ef168a7a11 * p2p/src/main/resources/ProposalStore_BTC_MAINNET
f91435a2a5 * p2p/src/main/resources/SignedWitnessStore_BTC_MAINNET
c6b7362593 * p2p/src/main/resources/TradeStatistics2Store_BTC_MAINNET

Change the logo in the desktop client

This issue requests changing the Bisq logo currently used in the desktop client with Haveno's logo.

Add ability to freeze and thaw outputs using monero-wallet-rpc

Haveno depends on the ability to freeze and thaw outputs from monero-wallet-rpc, so this issue requests implementing that functionality in monero-project. See existing issue

Increase fiat trade limits

Currently fiat trades are limited to 0.01 XMR or ~4.72 USD. This issue requests increasing the limit.

Change displayed balances

Currently the following balances are displayed:

• Available balance: funds available to start a new trade or withdraw
• Reserved: funds reserved in trades (does not currently count all funds: #26)
• Locked: locked funds which can be used to start a new trade or withdraw when unlocked

This issue requests the displayed balances be changed to:

• Balance: total balance (including locked funds) to start a new trade or withdraw
• Available balance: available balance to start a new trade or withdraw
• Reserved: funds reserved in trades (needs to include funds in accounts 1+ and all active multisig wallets: #26)

Accounts age and status determined by user not by individual form of payment account

Changing the Revolut account on Bisq, it use to be that on the Revolut account you had to put username and phone number, later that was changed to just the username.
Changing just the account of Revolut to a username only on Bisq means to delete the account and lose the signed status and age. I thought that it would by nice that in Haveno there was a possibility to transfer that aged status with a private key for an upgrade account that benefits privacy, or accounts age and status to be determined by user not by individual from of payment.
As is likely that services will change overtime and they may offer a better alternative as it was on Revolut that might help having more privacy having that feature would be good for the traders to preserve status, aged and signed

Reserved balance should include all funds reserved for trades

Currently the reserved balance does not include all funds reserved in trades. This issue requests that all funds reserved for trades be included. That includes:

• All funds in account index 1 and after
• All funds in multisig wallets associated with open trades

Remove DAO [$600]

Everything related to the Bisq DAO needs be removed from the platform and the repository, as we don't use it.
Feel free to open other issues related to removing the DAO, but use this one as reference of the status of the entire effort.

Make GitHub actions use the Makefile

At the moment our github action workflow calls ./gradlew build. We should change it to use the newly added Makefile instead (#105)

Deploy shared test network

Currently Haveno is only tested using local test networks on developer machines.

This issue requests deploying a shared test network using Haveno seed nodes for developers to test.

Support multiple destinations in make_uri and parse_uri [$350]

This issue requests supporting multiple addresses and amounts in monero-wallet-rpc's make_uri and parse_uri.

This will be used to deposit 2 outputs to the Haveno wallet, one to cover the deposit amount and one to cover the trade fee, in order to allow trades to be posted and taken once funds are available.

See monero-project/monero#7731

Build fails because downloading jackson-module-jaxb-annotations dependency gives a 404 error

https://mvnrepository.com/com/fasterxml/jackson/module/jackson-module-jaxb-annotations/maven-metadata.xml seems to not exist anymore.

./gradlew build --scan:

> Configure project :desktop
Evaluating project ':desktop' using build file '/haveno/desktop/build.gradle'.
Failed to get resource: GET. [HTTP HTTP/1.1 403 Forbidden: https://mvnrepository.com/com/fasterxml/jackson/module/jackson-module-jaxb-annotations/maven-metadata.xml)]
Verifying aopalliance:aopalliance
Verifying ch.qos.logback:logback-classic
Verifying ch.qos.logback:logback-core
Verifying com.fasterxml.jackson.core:jackson-annotations

FAILURE: Build failed with an exception.

Sanity check for BTC addresses (altcoin account) always fails

When trying to add a Bitcoin address as an "altcoin" account the sanity check fails. I tried all types of Bitcoin address, but hey all fail.

Legacy arbitration dispute tab does not appear for Alice or Bob on first dispute

The legacy arbitration tab does not appear for Alice or Bob when opening their first dispute.

The legacy arbitration tab displays correctly after restarting the application.

Add woodser's gpg key to gpg_keys/

My key was added with #133.

Add API function to get market prices for all trade pairs [$250]

This issue requests adding a new API function to get market prices of all trade pairs.

This API call will provide market prices for the UI:

The following API function is a requested addition to HavenoDaemon.ts. Feedback is welcome.

API Function	Return	Description
havenod.getMarketPrices()	MarketPrice[]	Get market price data for all trade pairs.

This function returns an array of MarketPrice types, each with the following attributes:

MarketPrice
currencyCode: string
price: double // price per XMR

Note: the 24 hour price change and volume are not currently supported.

How to implement

This new API function should be added to the Price service of Haveno's protobuf definition, to be named GetMarketPrices.

Follow these instructions to add and test the new API function end-to-end.