Bisq DAO technical overview

A user can decide to run the application as lite node or full node. By default it runs as lite node as that does not require any additional setup.

Seed nodes act as providers for P2P network data and filtered blocks from the Bitcoin blockchain for lite nodes. When a node starts, it requests all P2P network data from several seed nodes.

Monitoring of DAO-related data and infrastructure will be added to the Bisq monitoring. This should help us spot any potential consensus or network conflict early.

This is not deployed at the moment, but will be integrated soon.

The BSQ block explorer shows all BSQ transactions with some metadata (transaction type, etc). It gives also some statistical data about the network. It is a very basic version at the moment, but we are working on a more sophisticated version. Any BSQ transaction can be looked up in a normal Bitcoin block explorer as well, but of course those explorers will not show any DAO-related context. If looking up a BSQ address on a normal Bitcoin block explorer, a user needs to remove the B prefix so the address is considered a valid BTC address.

The Bisq application provides an integrated BSQ wallet with basic features for receiving and sending BSQ, as well as a transaction history screen. The wallet is based on BIP 44 and uses registered coin type 142. This provides extra protection against the risk of accidentally using the BSQ wallet as a BTC wallet (e.g., when restoring from seed words). To avoid users from needing to backup 2 different sets of seed words, we use the same seed for both the BSQ and the BTC wallets, even though they are stored in different files. To further avoid mixing BSQ with normal Bitcoin, we use a "B" as address prefix for BSQ addresses in the user interface. Internally that prefix does not exist, as a BSQ address is a normal BTC address, and BSQ transactions are normal BTC transactions.

BSQ token transactions and balances are represented inside the application but there is also a web-based BSQ block explorer.

A BSQ transaction is valid only after a blockchain confirmation. However, for better usability, we allow users to spend their own change outputs. This involves no risk, as a user would render all follow-up transactions invalid if he tries to double-spend. Unconfirmed BSQ received from others is not spendable.

Inside the application we maintain a hash chain of states and P2P network data. The overall DAO state gets hashed at each new block which contains the previous hash, thus forming a chain of hashes. If the last hash is correct, all the previous must be correct as well. Each node receives the last 10 hashes from seed nodes and compares it with its local hash. If there is any conflict, it shows a warning and requests to rebuild the DAO state. At each new block, each peer broadcasts its local hash to its neighbors. That way, the node also receives hashes from normal peers.

Similar to DAO states, we also maintain a hash chain for proposal data and blind vote data. These hashes are created only once per voting cycle at an appropriate block height (i.e., when it is expected that the whole network has received all data).

There are valid cases when consensus could be temporarily broken. In case of a chain split, nodes can have different DAO states, as the Bitcoin block hash is part of the data, and if 2 nodes are on a different chain they will have different block hashes.

In case some P2P network data was not distributed well in the network, there may be temporary conflicts of the relevant hash chains. An application restart should usually resolve such issues. If not, rebuilding the DAO state forces all P2P network data to be reloaded.

To avoid reevaluating all history at each startup, we use a snapshot mechanism.

Every 20 blocks a snapshot mechanism is triggered. The current state is cloned and kept in memory, and if a previous clone exists, it is persisted. At the next snapshot trigger event, the last clone is persisted and a new clone is cached. In this way, the snapshot is always at least 20 blocks old.

The lite node requests the blocks since the latest snapshot only, so that will usually be 20-40 blocks (maximum). The only exception to this is on first startup after a new install, when a lite node only has the snapshot shipped with the binary—in this case, requested blocks might consume a bit more bandwidth.

If we maintain a monthly release schedule, there can be about 4500 blocks in a month, but even with that we expect not more than 1-5 MB of bandwidth to receive the initial blockchain data.

Each application release is updated with a recent snapshot version of the DAO state. This data will be used for new users who have not created their own snapshot yet. This saves new users from needing to download all historical data and rebuilding DAO state from genesis.

The user still can rebuild from genesis if he does not want to trust that developers have shipped a correct snapshot. Any discrepancy would be easily detected.

We use BTC from our donation address to fund the input for the genesis tx. We will issue 3 657 480 BSQ which is equivalent to 3.65748 BTC. The amount of 3 657 480 BSQ is the sum of the 2 500 000 BSQ which we distributed as symbolic testnet BSQ to past contributors back in July 2017 and 1 157 480 BSQ contributors have earned since we started the DAO Phase Zero in October 2017.

The outputs are the BSQ addresses of all contributors who have contributed to Bisq before we start the DAO on mainnet. All outputs are by definition valid BSQ. The genesis tx is funded with the exact amount, including the miner fee, so there is no change output.

Sending BSQ to another address is a simple transaction without OpReturn. It requires a BSQ input for the transferred BSQ as well as a BTC input to cover the miner fee. The outputs are the receiver’s BSQ address, an optional BSQ change output, and an optional BTC change output.

A transaction to send 10 BSQ could look like this:

We invalidate a small amount of BSQ for the trade fee payment. Since the burned amount is used as miner fee and not as a regular tx output, we are not restricted by the dust limit of 546 satoshis, and can spend fees as little as 0.01 BSQ (equivalent to 1 BTC satoshi). The fee is the difference of the BSQ input and the BSQ output.

In this case, we only used 9.50 BSQ of the 10.00 BSQ from the input. Since the second output is spending more than the remaining 0.50 BSQ, it is an invalid BSQ output so we consider it a BTC output. The remaining 0.50 BSQ which was not used in the first output will be used for the mining fee, thus reducing the mining fee which is paid from the BTC input (input 2).

A proposal transaction contains an OpReturn output which indicates the type and carries the hash of the proposal payload data.

OpReturn data:

The hash is created from the bytes of the proposal payload with tx ID set to null using protobuffer serialization. It is first hashed with Sha256 and then with Ripemd160 to get a 20 byte hash.

Compensation request tx and reimbursement request txs are technically the same and inherit the properties of a proposal tx but have some additional requirements. They add a BTC output which will be interpreted as a BSQ output at the vote result phase in case the request is accepted by voting.

OpReturn data:

The blind vote tx contains the hash of the blind vote payload and uses the vote stake as input. The stake is blocked from spending during this phase and is only unlocked by the vote reveal tx. If another transaction spends the stake, the blind vote becomes invalid. The blind vote requires a fee in BSQ.

OpReturn data:

To create the encrypted votes we use following data:

We use protobuffer serialisation for the bytes which will be encrypted with the secret key.

The vote reveal tx consumes the stake output from the blind vote tx as the only BSQ input. It does not require a BSQ fee.

In the OpReturn data we add the secret key for decrypting our blind vote and a hash of the blind vote list to ensure consensus of the P2P network data used in voting. This hash will be used in the vote result phase to determine a majority in case different users get a different list of blind votes, which would lead to different vote results, and therefore cause consensus failures.

OpReturn data:

The hash of the blind vote list is made using all blind vote payload data received in the cycle and sorted by blind vote tx ID. The secretKey is the encoded byte representation of the secret key.

The lock tx can be use for locking up funds for a bonded role or for bonded reputation: a certain amount of BSQ is locked for a defined lock time (in blocks). Only an unlock tx can unlock locked funds. Once the unlock tx is confirmed, the lock time will be used to determine when the funds can be used in a normal transaction again. While funds are locked, they cannot be moved, or they are invalidated. While funds are locked, or are in an unlocking state, funds can be confiscated by voting.

OpReturn data:

The hash in case of a bonded role is created from immutable data of the bonded role. Currently we use hashCode but that should be changed to a cryptographic hash. The hash for a reputation is derived from a salt. The salt is by default a random string as hex or can be any string defined by the user.

The unlock tx takes the lockup tx output and use the lock time encoded in the OpReturn to determine the unlock time. The BSQ output cannot be used in another tx until the lock time is over. During that time it is in the unlocking state. Afterwards it is in the unlocked state and can be spent like any normal BSQ output.

The asset listing fee tx is used for paying listing fees for an asset. The ticker symbol of the asset is specified in the OpReturn data to bind the tx to a specific asset. If the BSQ fee is more than the required mining fee, we do not use a BTC input, and add the remaining BTC to the BTC output.

OpReturn data:

We take the bytes of the ticker symbol as UTF-8 string and hash it with Sha256 and then with Ripemd160.

A user can put the hash of an arbitrary string (pre-image) into a proof of burn tx and burn a specified amount of BSQ. He can later use the pre-image to prove to any party that he has created that hash. He can also sign any challenge message and the challenger can verify that he is the key holder of the first input used in that tx.

OpReturn data:

We take the bytes of the pre-image as UTF-8 string and hash it with Sha256 and then with Ripemd160.

During the proposal phase the user can add and remove proposals. For removing we use the public key which was added when publishing a proposal and verify with a signature if the remove attempt is coming from the same owner. This is the same model as we use in other P2P network data like offer payloads. The data has a time to live of 60 days, and after that, it is removed from local storage.

There are several different types of proposals:

The proposal contains the tx ID of the proposal transaction. When creating the transaction we add the 20-byte hash of the proposal data to the OpReturn data of the proposal tx. As the tx ID would be part of the proposal data and cannot be known before the tx is created, we leave it empty and set it afterwards. That way we get a mapping in both directions and can verify later that a proposal payload has a valid tx and that the tx data matches the proposal data.

During the break after the proposal phase, all nodes publish their proposal payload, which uses proposals from the temporary proposal payload. This data is now immutable and will be used for voting.

Blind vote data are published when the user makes his blind vote tx and are managed in the same way as proposal payloads (append-only data).

Phases are defined by block height. Each phase is separated with a break to avoid issues with reorgs.

Here are the phases and the initial duration values (they can be changed by voting):

The full cycle will last 4680 blocks which is about one month if one block takes an average of 10 minutes.

There are many different parameters which can be changed by voting. Trading fees, voting parameters (threshold and quorum), durations of the phases, and many more.

See the Param class for a complete list.

All roles in the Bisq DAO which can potentially create severe damage are handled as bonded roles. To become a role owner one need to make a request for a bonded role, and once accepted by voting, the person needs to lock up the defined bond. The role only is only considered active when the bond is locked up.

The required amount for the bond is defined in BondedRoleType enum. The unlock time is 110 days for all roles.

In severe cases, BSQ stakeholders can make a proposal to confiscate a bond. This will require a very high threshold in voting and is considered an exceptional case which hopefully never happens.

Most bonded roles are connected to environments which cannot interact with the Bisq DAO directly. For example, the Github Admin role cannot be revoked by confiscating the role owner as the Bisq DAO has no power over GitHub. The only exceptions are mediators and arbitrators, since people can be verified as valid bonded role owners before they are used for dispute resolution. This is not implemented yet and will be part of the new trade protocol update in the next few months.

Similar to bonded roles, a user can lock up a bond to prove reputation. There is no concrete use case for this in Bisq at the moment, but we might use it in the future for new forms of trade protocols which are based on bonded reputation.

Assets added to Bisq need to gain enough traders to reach a minimum trade volume over a certain time period. These parameters are DAO parameters and can be changed by voting. If an asset does not satisfy these parameters, such as trading volume thresholds, it will be removed from the list of assets when creating an altcoin payment account or selecting the preferred currencies in the software preferences.

Anyone can pay a fee in BSQ to gain access to a trial period where requirements to reach trade volume thresholds are lifted. Usually the coin issuers do this, but it can be done by anyone interested in trading a particular asset. The fee is initially 1 BSQ per day for a trial period, with a minimum of 30 days. The fee can be changed by voting.

If an asset gets removed by a Remove Asset Proposal, it can no longer be reactivated by the listing fee. Listing fees already paid are lost in this case.

This advanced feature does not have a concrete use at the moment, but might be used in the future. Burning BSQ can be used as a form of reputation. If one is willing to burn some money, and can use that proof for other activities (e.g. securing a trade), they might be interested that this form of reputation by burning BSQ will not become pointless in case he was publicly proven as scammer. The user can prove that he was the originator of the transaction by providing the pre-image to a hash, which gets added to the OpReturn data and he can sign any challenge message to prove he had funded the transaction. We use the EC key from the first input for the signature.