Add dev_portal (#17)

* adds dev_portal

* change project name from dev-portal to dev_portal

dev_portal/docs/intro.md

@@ -0,0 +1,31 @@
+---
+title: 'Introduction'
+sidebar_position: 1
+slug: /
+---
+
+Welcome to Ark's documentation. Here you can learn more about the protocol, how to join the Ark and spend your coins off-chain in a fast and secure way.
+
+- Be part of the community [joining our Telegram channel](https://t.me/ark_network_community).
+- To report bugs or ask for support [open an issue on the Github repository](https://github.com/ark-network/support/issues/new).
+- To propose improvements on protocol [open an issue on the Github repository](https://github.com/ark-network/boats/issues/new).
+
+### What is Ark?
+
+Ark is a second-layer solution designed to help scale Bitcoin transactions by using a shared utxo model that enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (ASP). ASPs are always-on servers that provide liquidity to the network, similar to how Lightning service providers work.
+
+Ark is a scaling category of its own and is not a state channel design or a rollup. Ark is a liquidity network like Lightning that operates without introducing liquidity constraints or a direct link between the sender and receiver. It uses virtual utxos, to enable anonymous, scalable, off-chain payments.
+
+## Get started
+
+### [Join the Ark](user/intro.md)
+
+### [Create the Ark](provider/intro.md)
+
+## Protocol Specifications
+
+[Learn more about Ark](specs/00-index.md)
+
+## Copyright
+
+By contributing to this repository, you agree to license your work under the MIT license unless specified otherwise at the top of the file itself. Any work contributed where you are not the original author must contain its license header with the original author(s) and source.

dev_portal/docs/provider/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Create an Ark",
+  "position": 4
+}

dev_portal/docs/provider/coordinator/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Coordinator",
+  "position": 3
+}

dev_portal/docs/provider/coordinator/configure-cli.md

@@ -0,0 +1,46 @@
+---
+sidebar_position: 5
+title: Configure the CLI
+---
+
+Now that your service is up and running you can configure the `coordinator` CLI to interact with it.
+
+The CLI makes use of a configuration file stored in its datadir - defaults to `~/.coordinator-cli` on Linux, `~/Library/Application\ Support/Coordinator-cli` on MacOS.
+
+You can customize the datadir path of your coordinator cli by exporting the environment variable `export ARK_COORDINATOR_CLI_DATADIR=path/to/datadir`.
+
+:::tip
+Add this env var to your bash profile otherwise you'll need to always export it when running `coordinator` commands.
+:::
+
+You can manage the configuration of your CLI with the features of the `coordinator config` command. Following, you can learn all what you can do with this command.
+
+### Initialize CLI config
+
+You can initialize the configuration of your CLI by the means of flags
+
+```bash
+$ coordinator config init
+```
+
+This command brings the configuration of your CLI to its default status unless you don't specify a flag for those params you want to tweak.
+
+Run `coordinator config init --help` to see all available configuration flags.
+
+### Customize CLI config
+
+You can change granular params of the CLI's configuration by using the `set` subcommand as shown below:
+
+```bash
+$ coordinator config set no-tls true
+```
+
+### Show CLI config
+
+You can take a look at the configuration of your CLI with:
+
+```bash
+$ coordinator config
+```
+
+You've learned everything about configuring the CLI, let's see how it does let you interact with the Coordinator.

dev_portal/docs/provider/coordinator/configure-service.md

@@ -0,0 +1,26 @@
+---
+sidebar_position: 4
+title: Configure the Coordinator
+---
+
+The Coordinator can be configured by exporting environment variables at startup, or by adding a configuration file to its datadir.
+
+### Configure with environment variables
+
+The following table lists all the environment variables available, along with a brief description and their default values:
+
+| Name | Description | Default Value |
+|---|---|---|
+| ARK_COORDINATOR_DATADIR | Let's you change the service's datadir path | `~/.coordinatord` (Linux).<br/><br/>`~/Library/Application\ Support/Coordinatord` (MacOS). |
+
+### Configure with file
+
+You can configure the Coordinator by adding a `config.json` file to its datadir.
+
+Below, you can see all the props you can add to the config file:
+
+```json
+{
+  //TBD
+}
+```

dev_portal/docs/provider/coordinator/intro.md

@@ -0,0 +1,17 @@
+---
+sidebar_position: 1
+title: Overview
+---
+
+# Ark Coordinator
+
+The Coordinator handles the perpetual creation of new Ark rounds every 5 seconds.
+
+It can be served in one of the following ways:
+
+* [Dockerized application](run-docker.md)
+* [Standalone application](run-standalone.md)
+
+<!-- any dependency? -->
+
+Once your coordinator is up and running you can [configure the CLI](configure-cli.md) to interact with it.

dev_portal/docs/provider/coordinator/run-docker.md

@@ -0,0 +1,30 @@
+---
+sidebar_position: 3
+title: Run with Docker
+---
+
+The Coordinator can be served as a dockerized application by following the steps below:
+
+1. Install [Docker](https://docs.docker.com/engine/install) - if you're on Linux, don't forget the [post-installation steps](https://docs.docker.com/engine/install/linux-postinstall/)!
+2. Download the latest image of the connector with `docker pull ghcr.io/ark-network/coordinatord:latest`
+3. Create a `coordinatord/` folder in your current directory - to mount the datadir as external volume - and start the dockerized service with
+
+```bash
+$ docker run -it -d --name coordinatord \
+  -u
+  -v "$(pwd)/coordinatord:/home/ark/.coordinatord" \
+  -e ARK_COORDINATOR_LOG_LEVEL=5 \
+  ghcr.io/ark-network/coordinatord:latest
+```
+
+You can check the logs of the service at anytime by running `docker logs coordinatord`.
+
+The dockerized Coordinator can be configured by the means of environment variables or by adding a `config.json` file to the `coordinatord/` folder you've created. Learn more about this by visiting [this section](configure-service.md).
+
+The service comes also with an embedded CLI, so it's enough for you to create an alias like the following to use it:
+
+```bash
+$ alias coordinator="docker exec coordinatord coordinator"
+```
+
+Take a look at how to [configure the CLI](configure-cli.md) before start interacting with the running Coordinator.

dev_portal/docs/provider/coordinator/run-standalone.md

@@ -0,0 +1,23 @@
+---
+sidebar_position: 2
+title: Run Standalone
+---
+
+The Coordinator can be served as a standalone binary by following the steps below:
+
+1.  Download the lastest [release](https://github.com/ark-network/ark-coordinator/releases) of the service and the CLI for Linux or MacOS.
+2.  Rename the binaries `coordinatord` and `coordinator` , move them to your _PATH_ (eg. `/usr/local/bin`), and grant them exec permissions with `chmod +x /usr/local/bin/coordinatord` and `chmod +x /usr/local/bin/coordinator`.
+3.  Start the service with
+
+```bash
+ARK_COORDINATOR_LOG_LEVEL=5
+coordinatord & > ~/ark-logs/coordinator.logs.txt &
+```
+
+The command above redirects all the logs to the file `~/ark-logs/coordinator.logs.txt`. Therefore you can check the logs of the service at anytime by consulting that file.
+
+The Coordinator service makes use of a datadir - defaults to `~/.coordinatord` on Linux, `~/Library/Application\ Support/Coordinatord` on MacOS - that can be customized by exporting the environment variable `export ARK_COORDINATOR_DATADIR=path/to/datadir` at its startup.
+
+You can configure the Coordinator by the means of environment variables or by adding a `config.json` file to the service's datadir. Learn more about this by visiting [this section](configure-service.md).
+
+Once the service is started you can [configure the CLI](configure-cli.md) and start interacting with it.

dev_portal/docs/provider/coordinator/use-cli.md

@@ -0,0 +1,56 @@
+---
+sidebar_position: 6
+title: Use the CLI
+---
+
+Now that your CLI is configured to connect with the running Coordinator, let's take a look at what it makes you capable of.
+
+### List pool transactions
+
+You can retrieve the list of pool transactions made in a certain time range with:
+
+```bash
+$ coordinator pools --start --end
+```
+
+You can omit the `--end` flag if you want to retrieve all pool transactions from a certain time unitl now.
+
+For each pool tx, you can see details like the txid, status, and amount of liquidity added to the Ark.
+
+You can also list all pool transactions created so far with:
+
+```bash
+$ coordinator pools --all
+```
+
+Run `coordinators pools --help` to see the full list of available flags.
+
+### Get pool transaction details
+
+You can get details about a specific pool transaction with:
+
+```bash
+$ coordinator pool --id <txid>
+```
+
+### Register inputs and outptus
+
+You can manually register the VTXOs you're going to spend and the related receivers with:
+
+```bash
+$ coordinator register --inputs '[{"txid": "<txid>", "vout": <vout>}]' --outputs '[{"pubkey": "<pubkey>", "amount": <amount>}]'
+```
+
+The Coordinator answers with a message containing the virtual (forfeit) transaction spending your coins and the list of all the new VTXOs created in the next round - including those you registered.
+
+<!-- Ref to some toool that allows to revealing the congestion control tree -->
+
+### Finalize input and outputs
+
+Once you signed the virtual transaction you can send it back to the Coordinator and finalize the process with:
+
+```bash
+$ coordinator finalize --vtx <signed_vtx>
+```
+
+In response you get the id of the pool transaction that is going to be broadcasted by the server.

dev_portal/docs/provider/gateway/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Gateway",
+  "position": 2
+}

dev_portal/docs/provider/gateway/intro.md

@@ -0,0 +1,8 @@
+---
+sidebar_position: 1
+title: Overview
+---
+
+# Ark Gateway
+
+The Gateway handles users' requests to onboard (join) and offboard (leave) the Ark.

dev_portal/docs/provider/intro.md

@@ -0,0 +1,11 @@
+---
+sidebar_position: 1
+---
+
+# Ark Service Provider
+
+The Ark Service Provider (ASP) is composed by 3 services that have different responsibilities:
+
+- Gateway, handles (on/off)boarding requests
+- Coordinator, handles coinjoin rounds and creation of pool txs (every 5 secs)
+- Treasury, handles verification & approval of pool txs, and operations altering the capacity of the service

dev_portal/docs/provider/treasury/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Treasury",
+  "position": 4
+}

dev_portal/docs/provider/treasury/intro.md

@@ -0,0 +1,10 @@
+---
+sidebar_position: 1
+title: Overview
+---
+
+# Ark Treasury
+
+The Treasury is in charge of verifying and approving pool transactions created by the Coordinator.
+
+It does also handles the management of the ASP capacity - ie. depositing or removing funds - and liquidity - monitoring/sweeping expired VTXOs.

dev_portal/docs/specs/00-index.md

@@ -0,0 +1,24 @@
+---
+sidebar_position: 1
+title: 'BOAT#0: Index'
+---
+
+# Index and Overview
+
+Welcome! These **Basics of Ark Technology (BOAT)** documents describe the Ark protocol, a second layer solution that enables anonymous, off-chain payments through an untrusted intermediary that provides liquidity to the network.
+
+## Index
+
+- [BOAT #0: Index](00-index.md)
+
+## Overview
+
+Ark is a second-layer solution designed to help scale Bitcoin transactions by using a shared utxo model that enables anonymous, off-chain payments through an untrusted intermediary called the Ark Service Provider (**ASP**). ASPs are always-on servers that provide liquidity to the network, similar to how Lightning service providers work.
+
+Ark has a utxo set that lives off the chain. These utxos are referred to as virtual utxos or **VTXOs** in short. VTXOs are like short-lived notes that expire after four weeks. Users must spend their VTXOs upon receiving them within this four-week timeframe or return them to themselves to reset the four-week timer.
+
+Users can acquire VTXOs from someone who already owns them or use a process called **onboarding**, which is an atomic two-way peg mechanism that doesn't require trust. Onboarding lets users lift their on-chain utxos off the chain for a 1:1 virtual utxo. Users can unilaterally redeem a virtual utxo for an on-chain utxo without asking for ASP cooperation.
+
+‍When sending funds, users coin-select and redeem their VTXOs and create new ones for the recipient (plus change) in a coinjoin round where ASP is the blinded coordinator. ASP funds the coinjoin with their own on-chain funds in exchange for VTXO redemptions. Therefore, the coinjoin transaction that hits on-chain has only one or a few inputs provided by the ASP.
+
+The newly created VTXOs of the coinjoin round are bundled and nested under a shared transaction output. This shared output expires four weeks after its creation, and once it expires, the ASP who funded the shared output in the first place can solely sweep the shared output. All nested VTXOs under this shared output are expected to be redeemed in this window period.

dev_portal/docs/specs/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Protocol",
+  "position": 2
+}

dev_portal/docs/specs/nomenclature.md

@@ -0,0 +1,91 @@
+---
+sidebar_position: 2
+title: 'Nomenclature'
+---
+
+## Intervenients
+
+### ASP
+
+Ark is a second-layer solution designed to help scale Bitcoin transactions by using a shared UTXO model that enables anonymous, off-chain payments through an untrusted intermediary called the **Ark Service Provider** (ASP). ASPs are always-on servers that provide liquidity to the network, similar to how Lightning service providers work.
+
+### Users
+
+Any user that onboards the Ark or receives a payment inside an Ark.
+
+### VTXO
+
+Ark has a UTXO set that lives off the chain. These utxos are referred to as virtual UTXOs or VTXOs in short.
+
+## Moments
+
+### Onboarding the Ark
+
+When a User sends funds to the Ark and gets VTXOs in return.
+
+### Unilateral exit
+
+When a user decides to withdraw his funds from the Ark to mainchain, without asking the ASP.
+
+### Round
+
+Periodic transaction crafted by the ASP that hits mainchain and creates new VTXOs.
+
+## Transactions
+
+**Note:** In an optimistic scenario, transactions marked with a **\*** should never hit onchain.
+
+### Funding transaction
+
+- When Alice wants to enter the Ark
+
+| Inputs              | Outputs (locking script)            |
+| ------------------- | ----------------------------------- |
+| Alice’s segwit UTXO | `(Alice + ASP) or (ASP in 1 month)` |
+
+### Redeem transaction \*
+
+- Insurance for Alice, in case the ASP stops responding
+- Allows Alice to receive funds back from the Ark
+
+| Inputs                                     | Outputs                                |
+| ------------------------------------------ | -------------------------------------- |
+| Funding transaction spending `Alice + ASP` | `(Alice + ASP) or (Alice in 24 hours)` |
+
+### Forfeit transaction \*
+
+- Insurance for the ASP, in case Alice tries to double spend her VTXO after spending it inside Ark
+- Before the ASP funds Bob’s VTXO in the next Pool transaction, he must receive this transaction signed by Alice
+- Uses a connector from the next Pool transaction to achieve atomicity
+
+| Inputs                                    | Outputs |
+| ----------------------------------------- | ------- |
+| Redeem transaction spending `Alice + ASP` | `ASP`   |
+| Connector from next Pool transaction      |
+
+### Pool transaction (aka Ark transaction)
+
+- Funded by the ASP, creates VTXOs
+- After 4 weeks, the ASP can get their funds back
+- Multisig `n-of-n` where `n` is the number of participants
+- A new transaction is broadcasted every 5 seconds
+
+| Inputs   | Outputs                                     |
+| -------- | ------------------------------------------- |
+| ASP UTXO | Shared output: `n-of-n or (ASP in 1 month)` |
+
+### Shared output (aka Shared UTXO)
+
+- Represents a binary tree of transactions
+- In an optimistic scenario, this tree is never revealed
+
+![Docusaurus Plushie](../img/shared_output.png)
+
+### VTXO \*
+
+- Similar to Redeem transaction
+- Can be broadcasted anytime, on the condition that previous transactions on the transaction tree (up to the Pool transaction) are confirmed or broadcasted at the same time
+
+| Inputs                                  | Outputs                                |
+| --------------------------------------- | -------------------------------------- |
+| Previous transaction on the binary tree | `(Alice + ASP) or (Alice in 24 hours)` |

dev_portal/docs/specs/timeline.md

@@ -0,0 +1,51 @@
+---
+sidebar_position: 3
+title: 'Timeline'
+---
+
+### Onboarding the Ark
+
+1. Alice creates a [Funding transaction](#funding-transaction):
+   - adds any segwit output as an input (<u>must be segwit</u>)
+   - adds output locked by `(Alice + ASP) or (ASP in 1 month)`
+   - sends it to ASP, not signed
+2. Alice receives a [Redeem transaction](#redeem-transaction-) from the ASP:
+   - signed by the ASP, spends Funding transaction (1) via `Alice + ASP`
+   - has one output locked by `(Alice + ASP) or (Alice in 24 hours)`
+3. Alice signs and broadcasts Funding transaction (1)
+   - Is now safe for Alice to broadcast this funding transaction because now she can leave anytime with
+     [Redeem transaction](#redeem-transaction-) (2) spending `Alice in 24h`, i.e. Alice will be able to get
+     her funds back in 24 hours.
+4. ASP (with Alice) prepares next [Pool transaction](#pool-transaction-aka-ark-transaction)
+5. Alice creates a [Forfeit transaction](#forfeit-transaction-):
+   - spends from Redeem transaction (2) via `Alice + ASP`
+   - adds connector output from Pool transaction (4) as input
+   - signs (SIGHASH_ALL) and sends it to the ASP
+6. ASP broadcasts [Pool transaction](#pool-transaction-aka-ark-transaction) (4)
+7. Alice has now a [VTXO](#vtxo)
+8. After 1 month ASP spends Funding transaction (1) via `ASP in 1 month`
+
+### Payment to Bob
+
+1. Alice tells ASP to send [VTXO](#vtxo) to Bob
+2. ASP (with Alice) prepares next [Pool transaction](#pool-transaction-aka-ark-transaction)
+3. Alice creates a [Forfeit transaction](#forfeit-transaction-):
+   - spends from VTXO (1) via `Alice + ASP`
+   - adds connector output from Pool transaction (2) as input
+   - signs (SIGHASH_ALL) and sends it to the ASP
+4. ASP broadcasts [Pool transaction](#pool-transaction-aka-ark-transaction)
+5. Bob has now a new [VTXO](#vtxo)
+6. For at most 4 weeks, Alice will be able to double spend her’s [VTXO](#vtxo), but if she does it, the ASP will have time to grab the funds from the [VTXO](#vtxo) to itself using the [Forfeit transaction](#forfeit-transaction-)
+
+### Exiting the Ark
+
+1. Alice tells ASP she wants to trade [VTXO](#vtxo) for UTXO
+2. ASP (with Alice) prepares next [Pool transaction](#pool-transaction-aka-ark-transaction):
+   - an additional output is added, locked by `Alice`
+3. Alice creates a [Forfeit transaction](#forfeit-transaction-):
+   - spends from VTXO (1) with `Alice + ASP`
+   - adds connector output from Pool transaction (2) as input
+   - signs it and send it to the ASP
+4. ASP broadcasts [Pool transaction](#pool-transaction-aka-ark-transaction)
+5. Alice has now a new UTXO
+6. For at most 4 weeks, Alice will be able to double spend her’s [VTXO](#vtxo), but if she does it, the ASP will have time (24 hours) to grab the funds from the [VTXO](#vtxo) to itself using the [Forfeit transaction](#forfeit-transaction-)

dev_portal/docs/user/_category_.json

@@ -0,0 +1,4 @@
+{
+  "label": "Join the Ark",
+  "position": 3
+}

dev_portal/docs/user/intro.md

@@ -0,0 +1,8 @@
+---
+sidebar_position: 1
+title: Overview
+---
+
+You can join the Ark with one of the following apps:
+- [Noah CLI](noah-cli.md)
+

dev_portal/docs/user/noah-cli.md

@@ -0,0 +1,70 @@
+---
+sidebar_position: 2
+title: Noah CLI
+---
+
+The Noah CLI allows you to interact with the Ark Service Provider (ASP). It is a command line tool that can be used to create and manage your Ark Wallet.
+
+## Configure the CLI
+
+The noah CLI requires a set of variables to be set, use flags to set them.
+
+```bash
+noah config connect <ARK_URL>
+```
+
+## Set up Noah wallet
+
+`noah init` is a command that sets up a Noah wallet with a 32-bytes private key and a password in order to encrypt the private key.
+
+```bash
+noah init --password <PASSWORD> [--prvkey <PRIVATE_KEY>]
+```
+
+## Receive VTXO
+
+### Get receiving address
+
+You can use the noah CLI to print your Ark address. This can be used to receive VTXO.
+
+```bash
+noah receive
+```
+
+:::tip
+testnet only: `noah faucet <AMOUNT>` to receive newly created VTXO from the service provider.
+:::
+
+### Print balance
+
+```bash
+noah balance
+```
+
+`balance` returns the sum of all VTXOs belonging to the Noah wallet.
+
+## Send VTXO(s)
+
+```bash
+noah send --receivers '[{"to": "<ARK_ADDRESS", "amount": <AMOUNT>}, ...]'
+```
+
+Noah CLI is responsible to select the coins to send for the given amount. It will sync with the service provider to forfeit the VTXO(s) and create a new VTXO belonging to the recipient. A change VTXO will be created if needed. Asks user password before signing.
+
+## Redemption
+
+### Collaborative redemption
+
+```bash
+noah redeem --address <ONCHAIN_ADDRESS> --amount <AMOUNT>
+```
+
+Noah CLI will sync with the service provider in order to redeem onchain the given amount in the next round, any remaining change will become a new vTXO. Asks user password before signing.
+
+### Unilateral redemption
+
+```bash
+noah redeem --address <ONCHAIN_ADDRESS> --force
+```
+
+With the `--force` flag Noah CLI will unilateraly redeem all VTXOs by signing the psbt(s) and broadcast them. Asks user password before signing.