[bisq-network/proposals] Make burning man a tradebot and add BSQ auction market (#304)

chimp1984 notifications at github.com
Tue Feb 2 16:10:43 CET 2021


> _This is a Bisq Network proposal. Please familiarize yourself with the [submission and review process](https://docs.bisq.network/proposals.html)._

To get rid of the Burningman(BM) role (not entirely but to a large extent) we could use a trading bot and special transaction which is an atomic swap combined with burning BSQ as well as a auction market of partially signed transactions (maker do not need to be online).

### Swap'n'burn transaction
This transactions has following structure:
Input [n]: BSQ input(s) from trader
Input [n]: BTC input(s) from BM
Output 1: Optional BSQ change to trader (need to be first output)
Output 2: BTC to trader

The transaction is signed with a SIGHASH_ALL | ANYONECANPAY sighash (Sign its own input and all outputs).

The BSQ part gets burned because the amount of the BTC output is larger than the (remaining) BSQ input so the BSQ get invalidated (burned). We use the burned BSQ for minerfee and if there is something left to reduce the required BTC input for the BM.

As the sighash does not allow to alter the outputs we cannot add a change output for the BM's BTC input. This is unfortunate but can be resolved by making a preparation tx before where the exact output needed for the input is created. 

### Auction market
The trader creates an offer transaction where he sets the BSQ to be burned and the BTC they want to receive [1]. That relation defines the BSQ/BTC price of that offer. The trader signs his BSQ input with the SIGHASH_ALL | ANYONECANPAY sighash and post that transaction to the auction offerbook. The trader do not need to be online when the BM takes the offer.

### BM takes offer
The BM will select the best offer (best price) and sets the missing BTC input, signs the tx and publish the tx. If the trader would have spent the BSQ already it would be detected as the BSQ input would be invalid. Such offers would be removed automatically from the auction offerbook.

### Trade schedule/algorithm
The exact algorithm how the BM selects and at which schedule need to be further explored. But basic idea is that it tries at certain intervals and/or balance thresholds to fill the best offers with the available BTC funds. It calculates the price based on the required input and not with the BTC output as the miner fee and the BTC value of the burned BSQ need to be taken into account.

To avoid that BSQ txs become very large we should not use the many small inputs from trade fee txs but consolidate periodically such transactions to an accumulated tx ouput and use those for the trades. We should use a scheduler which waits until the miner fees are low to save costs.

To avoid certain attack scenarios in case the liquidity in the auction offerbook is low the bot can set certain constraints like that it does not trade if the prcie of the best offer is outside a defined tolerance window.

The bot should try to trade frequently to avoid to accumulate large amounts. For funds received from delayed payout transactions that might be more problematic as those can be 2.6 BTC and it might take a bit to trade such high amounts.
We can consider to split the BM into 2 bots for BTC trade fee and for delayed payout transactions.
If we implement https://github.com/bisq-network/proposals/issues/303 the frequency of delayed payout transactions might get reduced as well.

### Repoting
The bot should publish peridic reports which might be accessible via a web interface. This helps for monitoring and accounting.

### UI
The UI for that auction market should be separate from the normal offerbook. It can be a simple table of open offers and a simple create offer screen (set BSQ to burn, set price/expected BTC). It does not need to have a trade fee. To avoid spam risk we could add PoW (not needed initially I assume). Offers can be removed from the auction any time by the maker, thought there might be race conditions where the BM just took the offer but that should be rare. Only spending the BSQ will guarantee that the offer cannot be taken anymore.
There is no risk that anyone else takes the offer as they would give away BTC for free, and if that happens its a donation to the DAO ;-).

### BSQ UTXO management
We need to find a way to mark the BSQ used for offers as reserved so they do not get spent by other transactions. We should avoid the mistakes in the design of the AddressEntyList and use a different model based on utxo. We should investigate if the BitcoinJ wallet extension feature would be a better way to persist the flag rather to create a custom data store for it.

### Implementaion
I think it is more flexible to implement that directly in Java and not use the API via a script as we can benefit from callbacks on events like when a new block arrives and have full access to the DAO data model. As the BM bot is run only by 1 or 2 instances we could keep the specific code in a separate module (or branch) which gets only included in the BM application and not in the normal desktop app or API app. This would help to reduce attack surfaces. 

One problem is that there are many small transacations from trade fees which blow up the BitcoinJ wallet a lot. A spv resync will become very expensive over a longer period of time. We should consider to backup the spv file as well so in case we need a spv resync we can use abackup file. Beside that we should rotate to new wallets after a certain time. As the fee receiver is in the filter that should not be hard to manage.

We should also include monitoring via mempool explorer to detect quickly if a transaction did not end up in the mempool and start a spv resync in such a case. There might be the race condition that the trader spends the BSQ in the same tx as the BM takes the offer. If the swap tx does not make it into the block it would require a spv resync. Other scenarios are if the miner fee was too low and the tx gets cleared out of the mempool after a while. We can avoid that by using only confirmed transactions as inputs (trade fee txs could have that problem as well). For swap txs it is not critical as there is no change output for the BM, so no risk that a invalid tx propagates outputs to other transactions.

### Security risks
If anyone gets access to the hosted instance they would get access to the funds of the trade bot. 
To limit potential theft we can monitor it closely and block the address to be used via the filter. Trade fees are streamed slowly over time so the risk is rather limited. For funds from the delayed payout transactions it could be higher amounts but an attacker would not know when such larger amounts would arrive. We could add a multisig address and require a separate co-signer hosted by another contributor on another hosting platform to reduce risks further. I guess it is not needed and adds too much complexity and new potential error modes.  
We must not rely on the bots monitoring output as if it got hacked that can be manipulated as well, so a separate monitor of the address balance as well as the swap transactions and trade prices is required.

We need to take care that the bot cannot be gamed by actors who try to manipulate the BSQ market and try to get the BTC with a lower BSQ amount (too high BSQ price). The BSQ price is not a secure source of data as it could be manipulated by publishing fake trade statistics. We likely need to use a manually set price similar as we did for the average price for compensation requests. But first we need to define more in detail the schedule and algorith how the bot selects offers.

[1] Note that we cannot do it the other way round (that BM makes the offers) because the missing BSQ could be abused by using a small amount of BTC and so makes the tx valid according to the Bitcoin rules. So the BTC input would get swapped by anyone who would add that tiny amount of BTC missing by satisfying the rule that the inputs >= outputs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/304
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210202/2b46fece/attachment-0001.htm>


More information about the bisq-github mailing list