Onion Information

Page Clicks: 0

First Seen: 03/11/2024

Last Indexed: 10/25/2024

Domain Index Total: 237

DAO technical overview From Bisq Wiki Jump to navigation Jump to search In this technical overview , you will see: what BSQ tokens actually are, how they’re created, and how they’re destroyed the various functions of the Bisq DAO and how BSQ enables them Several example transactions are included so you can explicitly see the processes. Contents 1 BSQ token 2 Infrastructure 2.1 Nodes 2.1.1 Full nodes 2.1.2 Lite nodes 2.2 Seed nodes 2.3 External DAO monitor 2.4 BSQ block explorer 3 BSQ integration in Bisq 3.1 Wallet 3.2 Application internal DAO monitor 3.3 Snapshots 3.4 Snapshots shipped in releases 4 Blockchain-related data 4.1 Genesis tx 4.2 Transfer BSQ tx 4.3 Trade fee tx 4.4 Proposal tx 4.5 Compensation request tx/Reimbursement request tx 4.6 Blind vote tx 4.7 Vote reveal tx 4.8 Lockup tx 4.9 Unlock tx 4.10 Asset listing fee tx 4.11 Proof of burn tx 5 P2P network payloads 5.1 Temporary proposal payload 5.2 Proposal payload 5.3 Blind vote payload 6 Governance 6.1 Phases 6.1.1 Proposal phase 6.1.2 Blind Vote phase 6.1.3 Vote reveal phase 6.1.4 Vote result phase 6.2 DAO Parameters 6.3 Bonded roles 6.4 Bonded reputation 6.5 Asset listing fee 6.6 Proof of burn 7 Disclaimer BSQ token BSQ is a colored coin based on Bitcoin. One BSQ is represented by 100 bitcoin satoshis. The colored coin concept does not require OpReturn data but uses the transaction graph to determine if a tx output originates in either the genesis tx or an issuance transaction. BSQ inherits all the transaction rules from Bitcoin and adds some additional rules. Even though BSQ transactions do not require OP_RETURN , it will be used for certain specialized transactions (voting, compensation requests, etc). Aside from the ancestry to the genesis or an issuance transaction, there is another important rule: the outputs are parsed in a way that the first outputs are interpreted as BSQ as long there is sufficient BSQ value available from the inputs. So the order of BSQ and BTC outputs is essential! For inputs the order is irrelevant. Any violation of those rules would make BSQ invalid. There are many more details which are not currently covered in this document. We use the Bisq P2P network as a carrier for content-rich data like that of proposals or voting. The blockchain is used for timestamping that data. Both the P2P network data and the tx are linked together and are used for creating network consensus. BSQ is a result of blockchain-related data and P2P network data. Infrastructure The Bisq DAO is based on Bitcoin blockchain data as well as on data from the Bisq P2P network. Each Bisq application verifies the rules of the DAO. The degree of trust to data delivered from other nodes can be determined by the user. Running a full DAO node requires running bitcoind with RPC enabled. The DAO state can be rebuilt from the genesis transaction. The only remaining trusted entity are then the seed nodes which deliver past P2P network data. As seed node operators are bonded, risk for abuse is very limited. There are (at the moment) 8 seed nodes and all need to be in consensus on P2P network data. The user can see the consensus in the application (Network Monitor tab). Nodes 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. Full nodes A fully-validating BSQ node requires a Bitcoin Core node to verify blockchain data. RPC is used for communication. Setup details are in source code documentation . Full nodes receive a notification from Bitcoin Core at each new block, scan the block for BSQ transactions and broadcast those to the Bisq P2P network. Every transaction with any BSQ input or output (issuance) is considered a BSQ transaction. The full node also listens to network messages from lite nodes which request BSQ blocks from a certain block height. The full node sends back the list of all blocks since the requested height. The bandwidth requirements for this will depend on the number of BSQ transactions, but rough estimations suggest that there will be no considerable issues. Bisq seed nodes are used as full nodes since those are the first nodes to which a user gets connected and we can use the existing connection to transmit the additional data early in the startup process. Lite nodes Most users will likely operate in lite node mode. They have to trust the seed node operators that they are not all colluding and holding data back. If at least one operator is honest the lite node can detect a conflict and would re-validate each block from the last snapshot or even from the genesis block. The UI will notify the user about conflicting data from seed nodes. At startup, a lite node requests the missing BSQ blocks from the seed node and then validates those blocks to achieve a local state of valid and unspent BSQ outputs. In case of chain splits it can be that one of the seed nodes is on another chain and conflicting blocks get propagated. This would trigger a re-validation of all blocks from the latest snapshot for the lite node. The last received block would be considered the current state but the user will see a message saying there are conflicts (and that it is recommended to wait for more than one confirmation before considering a BSQ transaction as valid). Only after all full nodes (seed nodes) have the same state again will the lite node exit the "warning" state. If the user waits for a sufficiently high number of confirmations (4-6) he will not risk that his validation was based on an orphaned chain and that he could become victim of a double spend. 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. External DAO monitor Monitoring of DAO-related data and infrastructure will be added to 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. BSQ block explorer BSQ block explorers show 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. BSQ integration in Bisq The Bisq DAO and BSQ are fully integrated into the Bisq UI. It comes with a BSQ wallet and UI for creating proposals, participating in voting, and taking part in other DAO functions. Wallet 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. Application internal DAO monitor 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. Snapshots 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. Snapshots shipped in releases 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. Blockchain-related data One part of the DAO is based on Bitcoin blockchain data. We only use the blockchain for timestamping. Transactions do not carry content-rich data-this data is stored on th