dcrdex v0.1.5

DCRDEX v0.1.5

This patch release provides several important bug fixes.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

The user's account ID is now logged on connect and authentication with a DEX server. (8ce328c)

Fixes

• Fix a possible panic when reconfiguring a wallet that is not connected. (dfe4cd1)
• When resuming trades on startup and login, counterparty contract audits now retry repeatedly, as is the case when an audit request is initially received. This prevents a match from being incorrectly revoked on startup if the wallet/node fails to locate the counterparty contract immediately. (172dbb7)
• The client's database subsystem is always started first and stopped last. (b4ef3ff) This is a prerequisite for the following wallet lock-on-shutdown change.
• On shutdown of client Core, the wallets are now locked even if the PromptShutdown function is not used. This does not affect dexc users, only direct Go consumers of the client/core.Core type. (70044e6)
• Fix a possible interruption of the DEX reconnect loop if the config response timed out. (4df683a)
• Update the crypto/x/blake2 dependency to prevent silent memory corruption from the hash function's assembly code. (c67af3f)
• Handle orders that somehow loose their funding coins. Previously, such orders would forever be logged at startup but never retired, and any matches from such orders that required swap negotiation of other recovery would have been improperly abandoned. (a7b5aa0)

Server (dcrdex)

There are no substantive server changes, just a few logging improvements.

Code Summary

11 commits, 13 files changed, 564 insertions(+), and 254 deletions(-)

v0.1.4...v0.1.5

3 contributors

• Brian Stafford (@buck54321) (review)
• David Hill (@dajohi) (blake2 fix)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.4

DCRDEX v0.1.4

This patch release makes a number of small UI improvements, including showing the user's account ID on the settings page, focusing password field, and colorizing various buy/sell elements, and fixes several bugs. The main bug fixes deal with wallet settings changes, deposit address revalidation, Decred withdrawals working for the full balance, and historical order and match display.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

• The account ID for each configured DEX server is now displayed on the settings page.
  When not logged in, there is a placeholder that says to login to display the account ID. (1a5c070)
• Focus password field in order dialogs. (5eb9fb2)
• Colorize the "Side" column in the orders table. (83b07cd)
• The registration fee address is no longer logged if there is a funding error since there is nothing a user can do with the address other than shoot their self in the foot and send to it manually. Registration fee payment should only be done via the app. (dc67cdb)
• Wallet balances are updated on all wallet settings changes. (8ff4d94)
• Wallet sync status is more consistently checked on wallet (re)connect events, and continually check sync status on RPC errors as it is common for node/wallet startup to initially error and then start reporting status (e.g. bitcoind's "verifying blocks..." error while starting up). (1c9ca02, 53194c6)

Fixes

• Fix changing wallet settings possibly interrupting active swaps. (f0a304f)
• Fix a case where a wallet can become unlockable without restarting dexc if dexc were started with both active orders and an unlocked wallet. (f8c47a1)
• Fix duplicate notify_fee requests that resulted from multiple fee coin waiters being created for the same coin. (ee1bd84)
• Fix retrieving the full list of historical orders (2846814)
• Fix incorrect year displayed for a match's date. (a347b0f)
• Wallet deposit addresses are validated and more often refreshed whenever the wallet is connected (c3990c7, 6a66a1c)
• Correctly handle chain sync status when in initial block download state, but blocks are up-to-date with headers. This is only possible in practice with simnet. (3523de1)
• Fix DCR withdraws in various cases. (d0ba1e5)
• Allow dexc to shutdown without hanging if a wallet was unexpectedly shutdown first. (7321c36)
• When loading active matches on login, correctly skip adding cancel order matches to the trades map. (61697bb)
• Prevent login while already logged in from re-creating the entries in the trades map. (b6f81ad)
• Resolve a data race on wallet reconfigure for DCR. (bca1325)
• Avoid a possible deadlock on wallet reconfigure. (4bed3e2)

Developer

• Simnet harnesses are quicker to start, being based on archives, and more well funded. (0de8945)
• Update simnet trade tests for current wallet unlocking system and more well funded harnesses. (e198b1f)

Server (dcrdex)

Create a fee rate scaling administrative endpoint. (7a3f183) The endpoint is api/asset/{sym}/setfeescale/{scale}, using a GET request instead of POST for convenience.

Code Summary

27 commits, 52 files changed, 1582 insertions(+), and 890 deletions(-)

v0.1.3...v0.1.4

6 contributors

• Amir Massarwa (@amassarwi)
• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)
• Kevin Wilde (@kevinstl)
• @peterzen

dcrdex v0.1.3

DCRDEX v0.1.3

This patch release includes a workaround for a bug in the Safari browser, an important fix to a possible deadlock (client hang), and a minor fix to the client's validation of the server's order matching.

NOTE: If you use the dexcctl program (an optional command line tool), you will need to move any dexcctl.conf file from the ".dexc" folder to a new ".dexcctl" folder.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Fixes

• Eliminate a possible deadlock (hang) introduced in v0.1.2. (65c9830)
• Fix the client's validation of the server's deterministic epoch matching result. This avoids an error message in the logs, but the bug was otherwise not a problem. (10b4689)

Other

The location of the dexcctl.conf file is now in ~/.dexcctl instead of ~/.dexc (or the corresponding "appdata" folders on Windows and macOS) (16a0fb0)

Server (dcrdex)

There are no server changes.

Code Summary

5 commits, 17 files changed, 188 insertions(+), and 174 deletions(-)

v0.1.2...v0.1.3

2 contributors

• Brian Stafford (@buck54321)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.2

DCRDEX v0.1.2

This patch release improves handling of slow contract audits, fixes a bug on 32-bit systems, automatically unlocks wallets to avoid swap failures if the wallet unexpectedly became locked, and improves the display of canceled orders. There are also a few usability improvements for developers.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

User-facing

• When already logged in, automatically attempt to unlock wallets as needed for trades. This helps prevent users from breaking their swaps by accidentally locking their wallets. (de40913)
• Display cancel order matches differently from trade matches. (b013581)

Developer

• Create a Ready method so consumer packages know when the client core is done starting up. (c3d9e80)
• Increase notification channel capacity to prevent dropped notifications when there are many simultaneous events. (2de62a3)
• Remove the obsolete (and incomplete) terminal UI. (75ff8d0)

Fixes

• Workaround for 64-bit atomic variable access on 32-bit platforms. (3abaf43)
• Prevent contract auditing from blocking incoming messages. Continue to search for counterparty contracts until it succeeds or the match is revoked, and log a warning if the audit is taking a long time. (23f2f36)

Server (dcrdex)

There are no server changes.

Code Summary

9 commits, 44 files changed, 621 insertions(+), and 2,652 deletions(-)

v0.1.1...v0.1.2

3 contributors

• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.1

DCRDEX v0.1.1

This patch release addresses two important match recovery bugs, and a number of minor bugs. This release also includes several improvements to the client's user interface. New client features include Tor proxy support and new deposit address generation.

Please read the initial release (v0.1.0) notes for important information and instructions.

Client (dexc)

Features and Improvements

• Add the mainnet "client quick start" guide. (a383d5e)
• Tor support for connections with DEX servers. (824f1c0) WARNING: This should be used with caution since Tor is slow and unreliable.
• On dexc start-up, display a link (URL) to the browser page, and if there are active orders, warn the user. (a01e403)
• Add the ability to generate new deposit addresses. (860af3e)
• Various browser UI improvements, including order dialog wording and button formatting. (dbf9d2c)
• Dialogs now have a close/cancel button. (6716b58)
• Taker redemption transactions are more readily batched, potentially requiring fewer transactions for a taker order that matches with multiple maker orders. (3ea75a9)
• When any node (e.g. bitcoind and dcrd) is still synchronizing with the network, new orders cannot be placed. (2cac73a)

Fixes

• Match recover is more robust, with fixes to revoked match handling on reconnect or restart. (9790fb1)
• Resolve a potential deadlock during match status resolution, (c09017d)
• Explicitly set js Content-Type in webserver to workaround misconfigured operating systems, such as Windows with misconfigured CLASSES_ROOT registry entries. (f632893)
• Delete obsolete notifications on frontend. (8a69e99)
• Avoid harmless but confusing warnings about returning zero coins when resumed trades are later completed. (a01e403)
• Avoid redundant swap negotiation invocations on restart with unknown matches reported from a server. (c0adb26)
• Orphaned cancel orders that could be created in certain circumstances are now retired during status resolution of the linked trade. (867ba89)

Server (dcrdex)

• Fix book purge heap orientation. (eb6ccd4)
• Avoid orphaned epoch status orders when shutting down via SIGINT without a preceding suspend command. (d463439)
• When any node (e.g. bitcoind and dcrd) is still synchronizing with the network, relevant markets will not accept new orders. (2cac73a)

Code Summary

17 commits, 66 files changed, 2216 insertions(+), 566 deletions(-)

release-v0.1.0...release-v0.1.1

3 contributors

• Brian Stafford (@buck54321)
• David Hill (@dajohi)
• Jonathan Chappelow (@chappjc)

dcrdex v0.1.1 BETA1 (prerelease)

This contains fixes and improvements to the initial release (v0.1.0).

The primary fix included in this patch release is meant to address the possibility of a failure to properly recover from a revoked match in certain circumstances, resulting in a "order not reported by the server on connect" error message (e.g. from redeemMatches during recover on startup or reconnect) instead of automatically completing the revoked swap via refund or automatic redemption.

dcrdex v0.1.0 - First release of DCRDEX

DCRDEX v0.1.0 (beta)

Important Notices

• Ensure your nodes (and wallets) are fully synchronized with the blockchain network before placing orders. The software will verify this for you in the next patch release.
• Never shutdown your wallets with dexc running. When shutting down, always stop dexc before stopping your wallets.
• If you have to restart dexc with active orders or swaps, you must immediately login again with your app password when dexc starts up. The next patch release wil inform you on startup if this is required.
• There is a ~10 minute "inaction timeout" when it becomes your client's turn to broadcast a transaction, so be sure not to stop dexc or lose connectivity for longer than that or you risk having your active orders and swaps/matches revoked. If you do have to restart dexc, remember to login as soon as you start it up again.
• Only one dexc process should be running for a given user account at any time. For example, if you have identical dexc configurations on two computers and you run dexc and login on both, neither dexc instance will be adequately connected to successfully negotiate swaps. Also note that order history is not synchronized between different installations at this time.
• Your DEX server accounts exist inside the dexc.db file, the location of which depends on operating system, but is typically in ~/.dexc/mainnet/dexc.db or %HOMEPATH%\Local\Dexc\mainnet\dexc.db. Do not delete this account or you will need to register again at whatever server was configured in it.
• If you use a non-default bitcoin wallet name, don't forget to set it in bitcoin.conf with a wallet={insert wallet name here} line so that bitcoind will load it each time it starts. Otherwise dexc will give you a "wallet not found" error on startup and login.
• bitcoind's "smart" fee estimation needs plenty of time to warm up or it is not so smart, potentially leading to you creating redeem transactions with low fees that can make the transaction take a very long time to mine (get confirmed). Either keep your bitcoind running for a couple hours after starting it up after it had been stopped for a long time (any more than ~1hr) prior to starting it, or ensure that the value returned from a bitcoin-cli call to estimatesmartfee 1 returns a "feerate" close to what https://mempool.space/ reports as "High priority".

Overview

This release of DCRDEX includes a client program called dexc and a server called dcrdex. Users run their own wallets (e.g. dcrwallet or bitcoind), which dexc works with to perform trades via atomic swaps. dcrdex facilitates price discovery by maintaining an order book for one or more markets, and coordinates atomic swaps directly between pairs of traders that are matched according to their orders. The server is generally run on a remote system, but anyone may operate a dcrdex server.

This release supports Decred, Bitcoin, and Litecoin.

Client (dexc)

• Provides a browser-based interface, which is self-hosted by the dexc program, for configuring wallets, displaying market data such as order books, and placing and monitoring orders.
• Communicates with any user-specified dcrdex server.
• Funds orders and executes atomic swaps by controlling the external wallets (dcrwallet, etc.).

Server (dcrdex)

• Accepts orders from clients who prove ownership of on-chain coins to fund the order.
• Books and matches orders with an epoch-based matching algorithm.
• Relays swap data between matched parties, allowing the clients to perform the transactions themselves directly on the assets' blockchains.
• Has a one-time nominal (e.g. 1 DCR) registration fee, which acts as an anti-spam measure and to incentivize completing swaps.
• Enforces the code of community conduct by suspending accounts that repeatedly violate the rules.

Features

Markets and Orders

The server maintains a familiar market of buy and sell orders, each with a quantity and a rate. A market is defined by a pair of assets, where one asset is referred to as the base asset. For example, in the "DCR-BTC" market, DCR is the base asset and BTC is known as the quote asset. A market is also specified by a lot size, which is a quantity of the base asset. Order quantity must be a multiple of lot size, with the exception of market buy orders that are necessarily specified in units of the quote asset that is offered in the trade. The intent of a client to execute an atomic swap of one asset for another is communicated by submitting orders to a specific market on a dcrdex server.

The two types of trade orders are market orders, which have a quantity but no rate, and limit orders, which also specify a rate. Limit orders also have a time-in-force that specifies if the order should be allowed to become booked or if it should only be allowed to match with other orders when it is initially processed. The time-in-force options are referred to as "standing" or "immediate", where standing indicates the order is allowed to become booked while immediate restricts that order to being a taker order by only allowing a match when it is initially processed.

The following image is an example order submission dialog from a testnet DCR-BTC market with a 40 DCR lot size that demonstrates limit order buying 2 lots (80 DCR) at a rate of 0.001207 BTC/DCR using a standing time-in-force to allow the order to become booked if it is not filled:

Checking the "Match for one epoch only" box above specifies that the limit order's time-in-force should be immediate, while unchecking it allows the order to be booked if it does not match with another order at first. The concept of epochs is described in the Epoch section.

Order Funding

Since orders must be funded by coins from the user's wallets, placing an order "locks" an amount in the relevant wallet. For example, a buy order on the DCR-BTC market marks a certain quantity of BTC as locked with the user's wallet. (This involves no transactions or movement of funds.) This amount will be shown in the "locked" row of the Balances table.

It is important to note that the amount that is locked by the order may be larger than the order quantity since the "locked" amount is dependent on the size of the UTXO (for UTXO-based assets like Bitcoin and Decred) that is reserved for use as an input to the swap transaction, where the amount that does not enter the contract goes in a change address. This is no different from when you make a regular transaction, however because the input UTXOs are locked in advance of broadcasting the actual transaction that spends them, you will see the amount locked in the wallet until the swap actually takes place.

Depending on the asset, there may be a wallet setting on the Wallets page to pre-size funding UTXOs to avoid this over-locking, but (1) it involves an extra transaction that pays to yourself before placing the order, which has on-chain transaction fees that may be undesirable on chains like BTC, and (2) it is only applied for limit orders with standing time-in-force since the the UTXOs are only locked until the swap transaction is broadcasted, which is relatively brief for taker-only orders that are never booked.

Epochs

An important concept with DCRDEX is that newly submitted orders are processed in short windows of time called epochs, the length of which is part of the server's market configuration, but is typically on the order of 10 seconds. When a valid order is received by the server, it enters into the pool of epoch orders before it is matched and/or booked. The motivation for this approach is described in detail in the DCRDEX specification. The Your Orders table will show the status of such orders as "epoch" until they are matched at the end of the epoch, as described in the next section.

Order cancellation requests are also processed in the epoch with trade (market/limit) orders since a cancellation is actually a type of order. However, from the user's perspective, cancelling an order is simply a matter of clicking the cancel icon for one of their booked orders.

Matching

When the end of an epoch is reached, the orders it includes are then matched with the orders that are already on the book. A key concept of DCRDEX order matching is a deterministic algorithm for shuffling the epoch orders so that it is difficult for a user to game the system. To perform the shuffling of the closed epoch prior to matching, clients with orders in the epoch must provide to the server a special value for each of their orders called a preimage, which must correspond to another value that was provided when the order was initially submitted called the commitment. This is done automatically by dexc, requiring no action from the user.

If an order fails to match with another order, it will become either booked or executed with no part of the order filled. The Your Orders table displays the current status and remaining quantity of each of a user's orders. If an order does match with another trade order, the order status will become settling, and atomic swap negotiation begins.

Settlement

When maker orders (on the book) are matched with taker orders (from an epoch), the atomic swap sequence begins. No action is required from either user during the process.

In the current atomic swap protocol, the maker initiates by broadcasting a transaction with a swap contract on the relevant asset network, and informing the server of the transaction and the full contract. The server audits the contract, and if it is successfully validated, the information is relayed to the taker, who independently audits the contract to ensure it meets their expec...