Make burning man a tradebot and add BSQ auction market #304
Comments
|
It's an interesting concept to auto burn BSQ in an ANYONECANPAY market. I think could work since the BSQ inputs are actively signed and the anyonecanpay input is only for BTC. I don't know if it's a good idea to split the market though. I think it would be better to keep all offers in the same order book and let the bot trade as per normal, but with the option of BSQ auto burn trades. So normal users would not see the auto burn protocol option, but would be able to trade with the bot that initiates the auto burn protocol rather than the normal atomic protocol. The user would see no difference as they receive the same amount of BTC (this is only for users buying BTC). The handling of fee txs and delayed payout transaction could be handled outside of the bisq client, preferably with an offline wallet. Add a script that consolidates the fees and payouts and send reasonable sized tx outputs to the bot bisq wallet and the bot could then trade using only a single input to minimize fees on the trade and avoid bloating the spv wallet. Those tx outputs would then decide the sizing for the bot trades. |
|
Yes, valid concerns regarding segmenting the market. And would be less effort to only automate the trade with current protocol. |
|
There are no disputes with the atomic swap protocol, either it goes through or there are no funds tied up, so I think that's not an issue. |
Ah I overlooked that you refer to the atomic swap. Yes once that is available would be better of course. |
Very interesting. And great idea to consider. The technicalities go a bit over my head, but super intrigued from an economics perspective. What about mimicking bitcoin and looking towards for solution? Just putting some considerations out there. I'm not suggesting BSQ BM takes an offer roughly every 10 minutes... So someone buys a ton of BSQ from BM e.g. 10% of the allocated % for this DAO cycle - it adjusts to LESS frequent auctions? How this effects those who are rewarded BSQ for compensation/work would need to be considered i.e. if the supply increases now more than it otherwise would, then price will decrease as a result. So they're competing with BM? Consistent supply increases (all else being equal) with a 0% premium? I suppose since it is an AUCTION and a long enough period, it would just tend towards the market rate then. |
|
I can't see any problem using Perhaps instead of creating a separate auction UI, the above could be implemented as a new payment method & trade protocol for offers in the BTC-BSQ offer book, as @sqrrm suggests but open to all takers, much like the proposed atomic swaps. Then the BM bot would be given the same status as any other BSQ buyer. The new payment method would only be available for BSQ sellers as makers (who would no longer need to be online while the offer is available) and BSQ buyers as takers. Also, it would be possible for a maker to securely lower his BSQ asking price when amending the offer, but not to raise it (as one cannot unpublish the old prepared txs). The latter would require moving the BSQ UXTO and recreating the offer (though possibly without having to repay the maker fee). Moving the UXTO would also be required to securely cancel the offer. |
|
Some prepared transaction is need anyway either from the bot to add the exact BTC input or in your suggestion to avoid BSQ outputs. To avoid BSQ outputs reduces the risk to burn BSQ if the tx is not correctly constructed. Though SIGHASH_SINGLE has an issue in the case that there are more inputs than outputs (http://joncave.co.uk/2014/08/bitcoin-sighash-single). A swap with 10k BSQ to 1 BTC from 2 users with 10k and 20k ignoring miner fees would look like: input 1: 10000 BSQ signed by user A I agree that the option to stack multiple auction offers is interesting and will allow smaller trade amounts. The point for not being able to cancel the offer without spending the utxo is not great. Have not thought about that first. |
|
Hi @chimp1984 I am doing some housekeeping on the proposals. Please can you take steps to move this forward or alternatively close the proposal. Many thanks. |
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 #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.
The text was updated successfully, but these errors were encountered: