Merge pull request #6 from Permissionless-Software-Foundation/ct-unstable

Updating dev docs and specification

dev-docs/README.md

@@ -17,10 +17,26 @@ There are three major pieces of software behind the bch-dex concept. They work t
 The arrows in the image represent the information flow between the three pieces of software:
 
 - The _Client_ is essentially a 'dummy terminal' with a bidirectional interface to bch-dex. bch-dex does the heavy lifting, and the _Client_ is a 'thin' UI wrapper.
-- `bch-dex` imports data from the global P2WDB database into its local database, using a [webhook](https://en.wikipedia.org/wiki/Webhook) (dashed line). It can also custody funds, pay transaction fees, and create an _Order_ by submitting the data to the P2WDB to generate an _Offer_ (solid line).
+- `bch-dex` imports data from the global P2WDB database into its local database, using a [webhook](https://en.wikipedia.org/wiki/Webhook) (dashed line). It can also custody funds, pay transaction fees, and create an _Offer_ by creating an _Order_ and submitting the data to the P2WDB (solid line).
 
 This architecture keeps the global database highly censorship resistant, while allowing local installations to maintain tight control over the user experience. The goal is to have many redundant copies of `bch-dex` on the network, and to empower individual traders to run their own, private copy, while maintaining a single source of truth via the P2WDB.
 
+# Definitions
+
+The workflow of a token trade has three parts:
+1. **Make** - An *Offer* to buy or sell tokens is generated by a user, known as the *Maker*.
+2. **Take** - A second user, known as a *Taker*, will *take* the *Offer* by issues a *Counter Offer*
+3. **Accept** - The original *Maker* checks the *Counter Offer* and *Accepts* it by signing and then broadcasting the transaction.
+
+Trades done in this way are both *trustless* and *atomic*:
+- **Trustless** - This means that neither party needs to trust the other. The *Maker* gets to review the *Counter Offer* before broadcasting it. The *Maker* can not alter the *Counter Offer* after the *Taker* has signed it.
+- **Atomic** - The trade happens in a single transaction. There is no middle-state where the trade can get stuck. It either happens or doesn't, it's state is binary and atomic.
+
+Specific *Entities* are defined in the [specification](./specification.md), but here is a brief summary:
+- **Order** represents the *Maker* side of the trade. This entity is internal to `bch-dex`. It is used to track tokens set aside for sale and managed by the wallet controlled by `bch-dex`.
+- **Offer** contains most of the same information as an **Order**, but is external to `bch-dex`. This is data submitted to the P2WDB and visible to all users on the network.
+- **Counter Offer** is generated by a *Taker*, in order to take the other side of the trade. It contains a partially-signed transaction, ready for review by the *Maker*.
+
 # Back End
 
 This section provides additional information on `bch-dex` and P2WDB back end software.
@@ -45,19 +61,38 @@ This section describes the protocols for the database interactions between the t
 
 These are just a brief, high-level overview. Review the [Specifications](./specification.md) for more details.
 
-## Writing to the Global Database
+## Reading from the Local Database
+
+The *Client* reads data from the local database stored by `bch-dex`, and does not read the P2WDB global database directly. This gives `bch-dex` the opportunity to filter and modify the data locally, for a more controlled user experience.
+
+## Making an Offer
 
 Adding data to the global P2WDB is triggered by the _Client_ calling a REST API endpoint on `bch-dex`. The [p2wdb npm library](https://www.npmjs.com/package/p2wdb) can be leveraged for easy reading and writing to the P2WDB.
 
 Writing data follows these steps:
 
 - Tokens and BCH are held by a wallet which is under the controlled of `bch-dex`.
-- The _Client_ submits data to the POST `/offer` REST API endpoint to create a new Offer.
-- `bch-dex` will move the funds into a segregated UTXO, and will use that UTXO to create an Offer. The Offer data is written to the P2WDB. The Offer data is also saved to the local MongoDB.
-- After submitting the data to the P2WDB, `bch-dex` will receive a webhook call to its POST `/order` endpoint by the P2WDB. This event will trigger the import of the new data into the apps local Mongo database, and generate a new Order model.
-- This webhook event is mirrored by every instance of `bch-dex` on the network. Each P2WDB peer on the network will independently validate the new database entry and create a new Order model.
+- The _Client_ submits data to the POST `/order` REST API endpoint to create a new Order.
+- `bch-dex` will move the funds into a segregated UTXO, and will use that UTXO to create an Order. The Order data is written to the P2WDB. The Order data is also saved to the local MongoDB.
+- After submitting the data to the P2WDB, `bch-dex` will receive a webhook call to its POST `/offer` endpoint by the P2WDB. This event will trigger the import of the new data into the apps local Mongo database, and generate a new Offer model.
+- This webhook event is mirrored by every instance of `bch-dex` on the network. Each P2WDB peer on the network will independently validate the new database entry and create a new Offer model.
 
+## Taking an Offer
 
-## Reading from the Local Database
+Users can browse the Offers tracked by a local `bch-dex` by using a *Client*. When they find an Offer they want to to take, they'll use some UI element that will send data to the POST `/offer/take` REST API endpoint. These series of steps happen:
 
-The *Client* reads data from the local database stored by `bch-dex`, and does not read the P2WDB global database directly. This gives `bch-dex` the opportunity to filter and modify the data locally, for a more controlled user experience.
+- The `bch-dex` checks to see if the wallet it controls has enough BCH to take the other side of the Offer. If it does, the funds for the offer are moved to a segregated UTXO.
+- The new UTXO is used to generate a *Counter Offer*, which contain a partially signed transaction saved as a hex string.
+- The *Counter Offer* is submitted to the P2WDB. This triggers a webhook event in every running instance of `bch-dex` on the network.
+- When the webhook is triggered, `bch-dex` will check to see if the *Counter Offer* matches an *Order* under its control. If a match is found, it will trigger an *Accept* event.
+
+## Accepting a Counter Offer
+
+This part of the process is automated and does not require input from the user.
+
+- When a *Counter Offer* is received that matches an *Order* tracked by the local copy of `bch-dex`, it will trigger the *Acceptance* phase.
+- In the *Acceptance* phase, the transaction will be checked to see if it matches the conditions in the original *Order*. If all checks pass, `bch-dex` will sign the transaction and broadcast it, completing the trade.
+
+## Maintenance
+
+Occasional maintenance functions will be called by an interval timer. The primary purpose of these functions is to check the UTXOs in the Order, Offer, and Counter Offer entities. If any of these UTXOs are spent, the entity is deleted from the local Mongo database.

dev-docs/specification.md

@@ -15,89 +15,115 @@ Entities make up the core business concepts. If these entities change, they fund
 
 ### Order
 
-An order is created from data passed to the app by the P2WDB webhook.
-It is destroyed when the UTXO described in the Signal has been detected as spent.
+An Order Entity is nearly the same as an Offer. The Order is generated first, but is always internal to the bch-dex system. Most of the data in an Order is submitted to the P2WDB, which generates an Offer (external) Entity.
+
+The Order tracks the [HD index address](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#hd-wallets-bip-32bip-44) used to hold tokens or BCH for sale. This is the part of the app concerned with the custody of the funds. It creates a segregated [UTXO](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc#transaction-outputs-and-inputs) to hold the offered asset. The Order is automatically destroyed if the UTXO is spent.
 
 Order entities have the following properties:
 
-- _tokenId_ - The unique ID that identifies the class of token being offered for sale.
-- _buyOrSell_ - A string with a value `buy` or `sell` indicating which type of offer this is.
-- _rateInSats_ - The rate in terms of tokens-per-currency-unit.
-  - For Bitcoin, the min currency is sats.
-  - For AVAX, the min currency is nano-Avax.
-  - for eCash, the min currency is bits.
-- _minSatsToExchange_ - The minimum order size accepted.
-- _signature_ - A message signed by the address which created the order.
-- _sigMsg_ - The clear-text message used to generate the signature.
-- _utxoTxid_ - The TXID of the UTXO used in the order.
-- _utxoVout_ - The vout of the UTXO used in the order.
-- _numTokens_ - The maximum number of tokens offered for sale.
-- _timestamp_ - The ISO time when the order was created.
-- _localTimestamp_ - The localized time when the order was created.
-- _p2wdbTxid_ - The TXID proof-of-burn used to add the order to the P2WDB.
-- _p2wdbHash_ - The hash used to identify the order entry in the P2WDB.
-- _lokadId_ - Not used. Provided for future functionality.
-- _messageType_ - Not used. Provided for future functionality.
-- _messageClass_ - Not used. Provided for future functionality.
+- Token Data:
+  - _tokenId_ - The unique ID that identifies the class of token being offered for sale.
+  - _utxoTxid_ - The TXID of the UTXO representing the token or BCH being offered for sale.
+  - _utxoVout_ - The vout of the UTXO representing the token or BCH being offered for sale.
+
+  - Trade Data:
+    - _buyOrSell_ - A string with a value `buy` or `sell` indicating which type of offer this is.
+    - _numTokens_ - The maximum number of tokens offered for sale.
+    - _rateInBaseUnit_ - The rate in terms of currency-unit-per-token. Ex: 1000 = 1000 sats per token
+      - For Bitcoin, the min currency is sats.
+      - For AVAX, the min currency is nano-Avax.
+      - for eCash, the min currency is bits.
+    - _minUnitsToExchange_ - The minimum order size accepted.
+
+  - Authentication Data:
+    - _signature_ - A message signed by the address which created the order.
+    - _sigMsg_ - The clear-text message used to generate the signature.
+    - _offerBchAddr_ - The BCH address controlling the offer.
+    - _offerPubKey_ - The public key used to generate the BCH address, used for encryption.
+
+  - Wallet Data:
+    - _hdIndex_ - The HD index of the wallet used to generate the keypair to store the UTXO being offered for sale.
+
+  - SWaP Protocol properties:
+    - _lokadId_ - Not used. Provided for future functionality.
+    - _messageType_ - Not used. Provided for future functionality.
+    - _messageClass_ - Not used. Provided for future functionality.
+
 
 ### Offer
 
-An Offer Entity is nearly the same as an Order. But while an Order is generated
-by a webhook from P2WDB, the Offer Entity is created internally. It is used
-to track an 'Order' generated and managed by this application.
-
-The Offer tracks the [HD index address](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc#hd-wallets-bip-32bip-44) used to hold tokens or BCH for sale. This is the part of the app concerned with the custody of the funds. It creates a segregated [UTXO](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc#transaction-outputs-and-inputs) to hold the offered asset. The Offer is automatically destroyed if the UTXO is spent.
+An offer is created from data passed to the app by the P2WDB webhook.
+It is destroyed when the UTXO described in the Signal has been detected as spent.
 
 Offer entities have the following properties:
 
-- _offerIpfsId_ - The IPFS ID of the instance of `ipfs-swap-service` that is managing the offer.
-- _offerBchAddr_ - The BCH address controlling the offer.
-- _offerPubKey_ - The public key used to generate the BCH address, used for encryption.
-- _tokenId_ - The unique ID that identifies the class of token being offered for sale.
-- _buyOrSell_ - A string with a value `buy` or `sell` indicating which type of offer this is.
-- _rateInSats_ - The rate in terms of tokens-per-currency-unit.
-  - For Bitcoin, the min currency is sats.
-  - For AVAX, the min currency is nano-Avax.
-  - for eCash, the min currency is bits.
-- _minSatsToExchange_ - The minimum order size accepted.
-- _signature_ - A message signed by the address which created the order.
-- _sigMsg_ - The clear-text message used to generate the signature.
-- _utxoTxid_ - The TXID of the UTXO used in the order.
-- _utxoVout_ - The vout of the UTXO used in the order.
-- _numTokens_ - The maximum number of tokens offered for sale.
-- _timestamp_ - The ISO time when the order was created.
-- _localTimestamp_ - The localized time when the order was created.
-- _p2wdbTxid_ - The TXID proof-of-burn used to add the order to the P2WDB.
-- _p2wdbHash_ - The hash used to identify the order entry in the P2WDB.
-- _lokadId_ - Not used. Provided for future functionality.
-- _messageType_ - Not used. Provided for future functionality.
-- _messageClass_ - Not used. Provided for future functionality.
+- Token Data:
+  - _tokenId_ - The unique ID that identifies the class of token being offered for sale.
+  - _utxoTxid_ - The TXID of the UTXO representing the token or BCH being offered for sale.
+  - _utxoVout_ - The vout of the UTXO representing the token or BCH being offered for sale.
+
+- Trade Data:
+  - _buyOrSell_ - A string with a value `buy` or `sell` indicating which type of offer this is.
+  - _numTokens_ - The maximum number of tokens offered for sale.
+  - _rateInBaseUnit_ - The rate in terms of currency-unit-per-token. Ex: 1000 = 1000 sats per token
+    - For Bitcoin, the min currency is sats.
+    - For AVAX, the min currency is nano-Avax.
+    - for eCash, the min currency is bits.
+  - _minUnitsToExchange_ - The minimum order size accepted.
+  - _p2wdbTxid_ - The TXID proof-of-burn used to add the order to the P2WDB.
+  - _p2wdbHash_ - The CID used to identify the order entry in the P2WDB.
+
+- Authentication Data:
+  - _signature_ - A message signed by the address which created the order.
+  - _sigMsg_ - The clear-text message used to generate the signature.
+  - _offerBchAddr_ - The BCH address controlling the offer.
+  - _offerPubKey_ - The public key used to generate the BCH address, used for encryption.
+
+- Utility Data:
+  - _timestamp_ - The ISO time when the order was created.
+  - _localTimestamp_ - The localized time when the order was created.
+
+- SWaP Protocol properties:
+  - _lokadId_ - Not used. Provided for future functionality.
+  - _messageType_ - Not used. Provided for future functionality.
+  - _messageClass_ - Not used. Provided for future functionality.
+
+
+### Counter Offer
+
+A Counter Offer is the other side of an Offer. It contains a partially signed transaction, created by the Taker. The Maker will review the Counter Offer before accepting and finalizing the trade.
+
+Details TBD.
 
 ## Use Cases
 
 Use cases are verbs or actions that is done _to_ an Entity or _between_ Entities.
 
-### Order
-
-- **`createOrder()`** - This method is triggered by a webhook from the P2WDB. It will take the data provided by the P2WDB and create a new Order entity in the local database.
-
 ### Offer
 
+- **`createOffer()`** - This method is triggered by a webhook from the P2WDB. It will take the data provided by the P2WDB and create a new Order entity in the local database.
+
+### Order
+
 - **`ensureFunds()`** - Ensure that the wallet has enough BCH and tokens to complete the requested trade.
-- **`moveTokens()`** - Move the tokens indicated in the offer to a temporary holding address. This will generate the UTXO used in the webhook message. This function moves the funds and returns the UTXO information.
-- **`createOffer()`** - A macro command that leverages `ensureFunds()` and `moveTokens()`, to create a new Offer and submit it to the P2WDB.
+- **`moveTokens()`** - Move the tokens indicated in the order to a temporary holding address. This will generate the UTXO used in the webhook message. This function moves the funds and returns the UTXO information.
+- **`createOrder()`** - A macro command that leverages `ensureFunds()` and `moveTokens()`, to create a new Order and submit it to the P2WDB.
+
+### Counter Offer
+
+TBD
 
 ## Controllers
 
 Controllers are inputs to the system. When a controller is activated, it causes the system to react in some way.
 
-### Orders
-
-- **POST /order** - This POST REST API endpoint will be triggered by a webhook generated from P2WDB. This will notify the `bch-dex` that a new entry has been added to the P2WDB that matches the `appId` of `swap-<chain>`, where `<chain>` has a value of `avax`, `bch`, or `ecash`. It's a new entry that should be evaluated for inclusion in the `ipfs-swap-service` local database.
-
 ### Offers
 
-- **POST /offer** - This POST REST API endpoint can be triggered by the Client or a simple curl call. It passes in the data needed for `ipfs-swap-service` to generate and track a new Offer, then submit the data to the P2WDB to generate an Order that is tracked by all other instances of `ipfs-swap-service`.
+- **POST /offer** - This POST REST API endpoint will be triggered by a webhook generated from P2WDB. This will notify the `bch-dex` that a new entry has been added to the P2WDB that matches the `appId` of `swap-<chain>`, where `<chain>` has a value of `avax`, `bch`, or `ecash`. It's a new entry that should be evaluated for inclusion in the `ipfs-swap-service` local database.
+
+### Orders
+
+- **POST /order** - This POST REST API endpoint can be triggered by the Client or a simple curl call. It passes in the data needed for `bch-dex` to generate and track a new Order, then submit the data to the P2WDB to generate an Offer that is tracked by all other instances of `bch-dex`.
 
 ## Adapters
 

src/adapters/localdb/models/offer.js

@@ -1,25 +1,33 @@
 const mongoose = require('mongoose')
 
 const Offer = new mongoose.Schema({
+
+  // Token data
+  tokenId: { type: String },
+  utxoTxid: { type: String },
+  utxoVout: { type: Number },
+
+  // Trade data
+  buyOrSell: { type: String },
+  numTokens: { type: Number },
+  rateInBaseUnit: { type: String },
+  minUnitsToExchange: { type: String },
+  p2wdbTxid: { type: String },
+  p2wdbHash: { type: String },
+
+  // Authentication data
+  signature: { type: String },
+  sigMsg: { type: String },
+
+  // Utility data
+  timestamp: { type: String },
+  localTimestamp: { type: String },
+
   // SWaP Protocol Properties
   lokadId: { type: String },
   messageType: { type: Number },
-  messageClass: { type: Number },
-  tokenId: { type: String },
-  buyOrSell: { type: String },
-  rateInSats: { type: String },
-  minSatsToExchange: { type: String },
-  signature: { type: String },
-  sigMsg: { type: String },
-  utxoTxid: { type: String },
-  utxoVout: { type: Number },
-  numTokens: { type: Number },
-  hdIndex: { type: Number }, // HD index address holding the UTXO for this offer.
+  messageClass: { type: Number }
 
-  //
-  offerIpfsId: { type: String },
-  offerBchAddr: { type: String },
-  offerPubKey: { type: String }
 })
 
 module.exports = mongoose.model('offer', Offer)

src/adapters/localdb/models/order.js

@@ -1,24 +1,33 @@
 const mongoose = require('mongoose')
 
 const Order = new mongoose.Schema({
+  // Token data
+  tokenId: { type: String },
+  utxoTxid: { type: String },
+  utxoVout: { type: Number },
+
+  // Trade data
+  buyOrSell: { type: String },
+  numTokens: { type: Number },
+  rateInBaseUnit: { type: String },
+  minUnitsToExchange: { type: String },
+  p2wdbTxid: { type: String },
+  p2wdbHash: { type: String },
+
+  // Authentication data
+  signature: { type: String },
+  sigMsg: { type: String },
+  offerBchAddr: { type: String },
+  offerPubKey: { type: String },
+
+  // Wallet Data
+  hdIndex: { type: Number }, // HD index address holding the UTXO for this offer.
+
   // SWaP Protocol Properties
   lokadId: { type: String },
   messageType: { type: Number },
-  messageClass: { type: Number },
-  tokenId: { type: String },
-  buyOrSell: { type: String },
-  rateInSats: { type: String },
-  minSatsToExchange: { type: String },
-  signature: { type: String },
-  sigMsg: { type: String },
-  utxoTxid: { type: String },
-  utxoVout: { type: Number },
-  numTokens: { type: Number },
-  timestamp: { type: String },
-  localTimestamp: { type: String },
-  p2wdbTxid: { type: String },
-  p2wdbHash: { type: String },
-  orderStatus: { type: String }
+  messageClass: { type: Number }
+
 })
 
 module.exports = mongoose.model('order', Order)