Bisq v2 #118
Comments
|
Why do we need specifically BSQ token for bonding? Because we need confiscatability by the DAO. Ideally though users should be able to bond BTC. But then we lose confiscatability. Or do we? What if we invented a way to make BTC bond confiscatable by the DAO? Not even sure it's possible - just food for thought. |
Burning BTC is possible but the economic effect is different. With BSQ it goes back to stakeholders. With BTC it goes to miners or icase it get destroyed (e.g. by sending as op_return), then it goes to all BTC holders as the total supply is a bit smaller. As the confiscation of a bond comes usually with a reimbursement for the victim it will be a zero sum game for the DAO (x BSQ confiscated/burned - x BSQ issued by reimbursement). With BTC we would not have that symmetry and all BSQ stakeholders would basically pay for a reimbursement due the supply increase/inflation. |
I think the easiest way to apply fees is to use the proof-of-burn feature. After x trades (e.g. 10 trades) the user needs to pay the accumulated trade fees in one batch tx by burning BSQ and delivering a proof-of-burn to the next trader. The protocol for tracking the bond need to support that so that it is required after x+1 trades to attach that proof of the fee payment, otherwise the peer would reject the trade. Better would be that each following trader verifies the fee payment to avoid that a self-trade with a manipulated code could be used to avoid a fee payment. |
Yes, that is a very good point and very nice property to have (a symmetry of burned vs reimbursed). Although from an outsider perspective this will look like we force buying and hodling BSQ onto users (which is arguably suboptimal to hodling BTC). I'm afraid that never mind how good is our justification the question "why can't I simply bond BTC" will pop up over and over again. I'm worried that even the Bitcoin OGs may not have the inclination to understand and defend the BSQ position. Tricky! |
Wouldn't one rather reset the identity than pay the "surprise 10-nth trade fee"? If we want to batch fees then maybe pre-paid would be better? Maybe fee payment batching should be optional to avoid trades linkability? |
|
The bond is already linking trades together so a fee payment linked to that bond would be equally linkable either as individual fee txs or as batched fees. I think it makes sense to do it similarly to the proof of bond, by adding a salted hash of the proof of burn such that only trade peers can verify that the fee is paid upon presentation of the salt. After trading with a lot of peers there will however be a lot of peers that can link those trades together, but keeping it at the same level of linkability as the bond seems reasonable. Maybe there is some crypto magic that could be done to avoid linkability of the trades through the bond (and fee) with zero knowledge proofs. This is outside of my are of expertise. |
|
@sqrrm are you suggesting that the participants must prove to each other that the fee has been burned before executing the trade? Do you mean for past trades that the bond was used for or the current trade? |
@bodymindarts Yes, that's my thinking. For the bonding to work the peers need to verify the bond of the counterparty. That includes checking the current outstanding liens on the bond which necessitates checking all liens on the bond and verifying which ones are currently in effect. Similarly the batched fees would not be tied directly to a trade so the complete history of trades and their respective fees would have to be calculated to compare to the fees paid for the bond. The other option is to specify individual trades when paying the fee which would be impossible to do for pre payment of fees. Post payment would be able to specify the trades but it would then be too late for the past counterparties to verify that the fee was paid. At that point the whole history of trade fees need to be shared with future counterparties, essentially having the same effect as the non specific trade fee payment. |
|
I think 1 fee burn per trade per party is certainly less complex to understand for the user and probably to code. It does however open up potential for collusion. |
|
I think as a general principle (and not limited to v2) we should attempt to make user trades as unlinkable as possible. At minimum, we should have plausible deniability. I do recognize I am making already hard problem even harder... :( |
|
The proposal assumes reusing a single BSQ bond for multiple trades - both in amount dimension and in time dimension. The rationale (I guess) is to cut down on Bitcoin fees. Bitcoin fees are expected to skyrocket so this is very important consideration (and colored transactions are even more expensive). However, if we forget about tx costs for a second, we could consider a bond-per-trade. Then suddenly everything seems easy. No linkability. Trivial to apply fees. Less potential for security critical bugs. Easier to understand for the user. Easier to code (although not exactly? should be compatible w/ future batching?) Maybe privacy by default, bond reuse as option? |
|
@battleofwizards 1 bond per trade is always going to be possible. Users who don't want their transactions linkable can create as many bonds as they like (including 1 per trade). |
|
@bodymindarts it's all about what your encourage in the UI as default or recommended flow. |
|
@battleofwizards If users don't take care of on-chain privacy (coin merge) they would make one bond linked to the next bond. That is even worse with BSQ than with plain BTC because you cannot use CoinJoin for BSQ. |
|
@battleofwizards Update: |
|
My concern about bonding and DAO confiscation of the bonds is that it is not very scalable. Imagine having 1 million users and 0.1% of them being scammers... 1000 scammers could create 1000s of conflicts a month... would we need a DAO confiscation vote for each? It could easily turn into a DDOS attack vector. With a pure Mutually-Assured-Destruction 2-of-2 multisig protocol you could have bonds (in BSQ or BTC) without the need for the DAO to intervene. I believe that with: -2-of-2 multisig security deposit (up to 110% of trade amount) You could have a safer, more scalable system which also requires less radical changes to Bisq... |
|
Having said that... decoupling the trade protocol from the security protocol has huge advantages on other fronts... for example for the creation of decentralized financial instruments. You could build an uncensorable FX platform on Bisq 2.0 with CFDs, options, futures, etc.. If it can be made scalable... |
Agree on that, but probably the risk of losing the bond would discourage scammers from such DDoS attack. I am more concerned about legal liability of BSQ holders, as it is almost certain that in the case of legal conflict the Bisq DAO will never be considered a limited liability entity in most jurisdictions, so the BSQ holders would be directly liable.... This is quite disturbing. Maybe a fee structure like the following would ensure that the DAO almost never has to decide on trade reimbursments?:
|
Those 1000 scammers will quickly learn that it was a huge mistake to try to scam. The DAO stakeholders are not judges, just executors and only in weird cases where the reliability of mediations get questioned they would need more effort/time. |
|
@mpolavieja |
That is tricky. In order for this claim to succeed all the process and the wording should be carefully designed. Regarding the process, the decission of a mediator should never be questioned by the DAO. In case of a Mediator going rogue, its bond should be confiscated afterwards, and then another reimbursment requested in next cycle based on the Mediator having been banned (but then the DAO is making a decission on the reimbursment so probably another mediation process would be needed). Regarding the wording, a reimbursment request should be made to the mediator instead of to the DAO, and the DAO request should be a "Mediator decission execution request" instead of a reimbursment request. In any case, the bond confiscation processes are always a DAO decission, aren´t they? |
|
The decisions are only executable by DAO voting. Mediators give their judgement (like a judge) and the DAO executes it (like police) if they dont have any doubt on the mediators quality of work. It is a feature that this is not automated and a human layer is in place as a corrective. So DAO voters should make their due diligence but they are not investigating the case. But a mediator with many weird cases and much public disputes around their cases needs close attention. Wish more policemen would question the decisions of their authorities as well before they beat up peaceful demonstrants (who pay their salaries with their taxes...) - but thats another topic ;-).... |
MwithM
added
an:idea
|
Closed as stalled |
and others
I would like to give a rough overview and the more broad picture how the off-chain trade protocol would impact and change Bisq. In fact I think it will be such a radical change that it will require to be deployed as a new application and justifies the upgrade to version 2. The current trade protocol can continue in parallel and might fade out one day when most user have migrated.
The core change is that the trade protocol is decoupled from the security protocol.
Security for the trade is based on a BSQ bond. Once a bond is set up it can be reused for multiple trades in parallel up to the amount of the bond. E.g. You set up a 10 000 BSQ bond and start one trade with 4000 USD against 3600 EUR (no need that the trade contains any crypto currency). Lets assume 1 BSQ = 1 USD. So your available bond for further trades is now reduced to 6000 BSQ. You do another trade with 5000 USD and you still have 1000 BSQ left. You cannot do any trade > 1000 USD now until you have completed one of the open trades. After that, the amount from the completed trade increases your available bond again.
The bond/trade tracking is based on cryptographic pimitives like hashing and signatures and uses the Bisq P2P network. It is described at the end of the #32 proposal (and require still some work to make sure it is solid).
The way how we use bonds has some similarities to opening a channel in Lightning network.
The trade protocol itself is trivial. You make an offer and define the mediator to be used in case of a dispute. A taker agrees to your contract and then both have to exchange their currencies over the payment method defined in the contract.
In case of a dispute the mediator investigates and delivers both traders a signed result which states who violated the contract. That can be used for a confiscation request and the BSQ stakeholders would take the mediators result as orientation for their vote. This human barrier gives extra security against malicious mediators (they risk their bond).
Confiscation is considered an exeption and should happen very rarely. It is similar like ending up in court in normal business relationships. Its an exeptional outcome and both partied usually try to avoid that as far as possible.
With this new model we get tons of benefits and it resolves so many problems which seems basically unsolveable with the current model:
There are also some downsides and risks:
Roadmap
UPDATE:
The protocol for keeping track of bond usage need more time for design and analysis. Until that is completed that proposal is on hold.
The text was updated successfully, but these errors were encountered: