Allow non-absent Trade Peer to Claim Funds Before Arbitration

[alvasw]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Introduction

Most arbitration tickets are opened because one of the trading peers disappears without confirming the payment. In the current protocol, the non-absent peer sends the funds to the burning men and opens an arbitration ticket. If the trade amount is below a certain amount the refund-agent pays out the amount to him and creates a reimbursement request. If the trade amount is too high the trader gets a partial reimbursement, and he has to create a reimbursement request to get remaining the amount in BSQs. This is time-consuming and frustrating for traders. Furthermore, it is hard to sell large amounts on the BSQ market without making a loss.

I want to propose an upgrade to current protocol that allows the non-absent peer to claim all funds from the locked multi-sig transaction after a predefined time-lock. The other peer can react and publish another transaction redirecting the funds to the burning men before the time-lock expires. This would open a normal arbitration ticket.

Advantages

Firstly, we reduce the number of arbitration tickets significantly, and consequently the refund-agent's and the DAO's financial burden. Secondly, if one of the trading parties disappears the other party gets compensated by getting all funds.

Implementation

Let's say Alice and Bob start a trade and lock-up their funds in a multi-sig transaction. In the new protocol, two warning transactions, two claim transactions, and two redirection transactions replace the delayed payout transaction. After the warning transaction is confirmed the time-lock starts. Alice or Bob can claim all funds after the time-lock expires with the claim transaction. The redirection transaction allows the other party to react and redirect the claim to the burning man before the time-lock expires, thus opening an arbitration ticket.

Warning transaction

• txin count:1
  • txin[0] outpoint: locked-multi-sig txid and outpoint_index=0
  • txin[0] script bytes: 0
  • txin[0] witness: 0 <alice_signature> <bob_signature>

Output script:

OP_IF
    # redirect to burning men
    2 <alice_pubkey> <bob_pubkey> 2 OP_CHECKMULTISIG
OP_ELSE
    # refund claim
    `protocol_delay`
    OP_CHECKSEQUENCEVERIFY
    OP_DROP
    <alice_pubkey>/<bob_pubkey>
    OP_CHECKSIG
OP_ENDIF

The publisher of this transaction can claim the funds after the time-lock expired by creating an input with the nSequence set protocol_delay and a witness: <alice_pubkey>/<bob_pubkey> <empty_vector>.

The other party can publish the redirection transaction before the time-lock expires.

Redirection Transaction

• txin count:1
  • txin[0] outpoint: alice's_claim/bob's_claim txid and outpoint_index=0
  • txin[0] script bytes: 0
  • txin[0] witness: 0 <alice_signature> <bob_signature> 1
• txouts: burning men

Credits

• @sqrrm came up with the idea quite some time ago
• This proposal is inspired by "BOLT #3: Bitcoin Transaction and Script Formats". Thank you for @HenrikJannsen for directing me to the Lightning Network protocol.

[pazza83]

Thanks @alvasw for this proposal.

This would be a fantastic update to the protocol and address the frustration caused to users when trades go to arbitration as a result of an unresponsive peers. In the proposed protocol traders would be effectively compensated for dealing with non-responsive peers. I hope this would also cause an increase in trading volume and re-attract traders lost caused by the frustrations caused with the last change in protocol #386.

All arbitration cases last cycle were as a result of unresponsive peers so, therefore, this proposal if implemented would reduce arbitration cases to only a very few cases where a dispute was present after mediation. This also effectively removes the refund agent as being a point for any attack on Bisq.

Any ideas how long the peer would have to react to the claim transactions and publish redirection transaction? My thoughts are it should be a similar amount of time to the initial time lock. This would allow support staff to help a user to publish the claim transactions or redirection transaction in the event of them losing access to their Bisq instance.

There are usability aspects to consider with the implementation so it is as easy as follow as possible for users within the Bisq UI. Also in the event of a user losing access to their UI or a problem with the trade I suppose the mediator or another member of support team should be able to assist with the claim transactions and publish redirection transaction so it would need to be added to the payout tool (Ctrl+G) or something similar.

I am assuming the claim transaction when broadcast will be visible on-chain?

[counterweightoperator]

I think the aim for better UX is great, and this looks very promising. I have a few questions:

• How long would be the time period in which the potential absentee can react? Is this something that could be set in the offer conditions when posting it, or would this be defined at the protocol level for all trades?
• Do you have in mind implementing this for Bisq 1, or instead to leave it as-is and only bring this improvement when Bisq 2 implements the multisig protocol?
• Would there be any cost or penalty for the non-absent trader if he claims the funds AND the potential absentee appears again and redirects to the burning man? Should there be one?

[alvasw]

@pazza83:

Any ideas how long the peer would have to react to the claim transactions and publish redirection transaction? My thoughts are it should be a similar amount of time to the initial time lock. This would allow support staff to help a user to publish the claim transactions or redirection transaction in the event of them losing access to their Bisq instance.

We can define all time periods. The timer for the redirection transaction starts after the claim transactions is confirmed. The time periods are open for discussion.

I am assuming the claim transaction when broadcast will be visible on-chain?

That's correct! After the claim transaction is confirmed the other party has time to react and redirect it to the burning men. We can define the time the other party has to react. I would propose 1 or 2 weeks.

@counterweightoperator:

How long would be the time period in which the potential absentee can react? Is this something that could be set in the offer conditions when posting it, or would this be defined at the protocol level for all trades?

The time periods are open for discussion, and they will be defined at the protocol level. In the current protocol, both traders can publish the delayed payout transaction after 10 days in altcoin trades and after 20 days in fiat trades (see [1] for details).

Do you have in mind implementing this for Bisq 1, or instead to leave it as-is and only bring this improvement when Bisq 2 implements the multisig protocol?

This is for Bisq 1.

Would there be any cost or penalty for the non-absent trader if he claims the funds AND the potential absentee appears again and redirects to the burning man? Should there be one?

No, if the absentee reappears and redirects the funds to the burning man the trade goes to arbitration (as in the current protocol).

[1] https://bisq.wiki/Arbitration#FAQ

[sqrrm]

As noted elsewhere by @stejbac on a similar proposal, if the redirection tx fee is too low to get mined, there is an attack vector. If there is no way to increase the fee or cpfp for the redirection tx, then there might be times when it would be worth publishing the claim tx to hope that the redirection tx never gets mined, assuming there is a side channel to get the clam tx mined.

I think there are options to mitigate this, like adding an output owned by the redirector among the burning men outputs that they could use to cpfp the redirection tx.

[HenrikJannsen]

I think easiest is to add an output to the one who does the redirect tx so in case the tx does not get confirmed in time they can boost it with a followup tx.

[HenrikJannsen]

Also would like to give credit to @sqrrm . I think he was the first one who came up with the idea quite some time back....

[pazza83]

I would like to request that a change to the trade payout protocol consider the issue of abandoned trade multisigs (approximately 20 trades per year never pay out).

At the time of the trade both peers could sign a transaction to distribute trade funds to the burning men in about 26,000 blocks (6 months). In the case of neither peer publishing the claim transaction within this time period the trade would pay out to the burning men.

Sellers that wanted to claim any bitcoin that was distributed this way would be able to sign a message to prove ownership of the maker or taker payout address used in the trade and request reimbursement from the DAO in the usual way.

The benefit is that it would remove funds from being locked indefinitely either through both users being non responsive or in case where one user is non responsive and the other user has technical issues.

[clearwater-trust]

The benefit is that it would remove funds from being locked indefinitely either through both users being non responsive or in case where one user is non responsive and the other user has technical issues.

This sounds like a feature, not a bug.

We should applaud the security of our great blockchain that allows funds to be locked forever.

😄

[HenrikJannsen]

The benefit is that it would remove funds from being locked indefinitely either through both users being non responsive or in case where one user is non responsive and the other user has technical issues.

I discussed yesterday with @alvasw scenarios where users loss access to their tx data.
This is more important/risky in that protocol as a trader who have lost access is at risk that the peer takes all funds. In the current DPT version the user can contact the arbitrator and convince them to do the payout, so there is a human security shield. In the new protocol that is only the case if the user has the redirect tx.

Our proposed solution for that is that both traders send their relevant txs (claim tx and redirect tx) encrypted to the arbitrator. The wallet password would be used for encryption. We would need to enforce that users who do trades have set up a password. The password has the benefit over using a wallet key that it is very likely that the user remembers it even if they have a hard disc crash and lost all data. Sure its no guarantee that the users remembers their password (in case they used a pw manager) and we could combine the scheme with a wallet key which can be recovered from seed words as additional feature. Details need to still worked out. But basic idea is to use the arbitrator as kind of cloud backup at the take offer process, so the likelihood that the tx data become inaccessible becomes very low.

I do not see a need for another payout tx as with that model the user can always reach out to the arbitrator. The arbitrator alone cannot do anything with the encrypted data and the only thing he learns is the number of trades happening at a certain time.

At the time of the trade both peers could sign a transaction to distribute trade funds to the burning men in about 26,000 blocks (6 months). In the case of neither peer publishing the claim transaction within this time period the trade would pay out to the burning men.

I think that might be legally risky. I would prefer to keep funds locked and have the ability to recover them by the above mentioned scheme. As long as one trader is interested in the funds the money should not stay stuck. If both are not interested the money should not go automatically to the DAO.

[HenrikJannsen]

We could add a further improvement to make reimbursement cases even less likely.

With the above idea we solve the problem of non-responding traders. Then all the funds can be claimed by the active trader after the time-lock.

We could add another stage to give the traders an option to publish a cooperatively created transaction which distributes the funds according to the suggestion of the arbitrator (similar as in mediation). This give them the option to avoid the reimbursement path. If they cannot find an agreement in the given time (defined by the 2nd timelock) any of the traders can publish that distribution tx and then the case has been closed and the winning party need to do the reimbursement request.
As the security deposit of the peer is lost in that case there is a financial incentive to find an cooperate to create a custom Resolution tx instead.

Transaction structure:

2 versions of the warning tx:

Warning tx (Alice is publisher):

• input: output from deposit tx
• if-case:
  • output: spendable by Alice after timelock 1
• else-case:
  • output: 2of2 MS, all funds go to the Dispute Tx

Alice's claim tx (only valid after timelock 1):

• input: output from warning tx (if-case)
• output: Alice's address

Warning tx (Bob is publisher):

• input: after timelock output from deposit tx
• if-case:
  • output: spendable by Bob after timelock 1
• else-case:
  • output: 2of2 MS, all funds goes to the Dispute Tx

Bob's claim tx (only valid after timelock 1):

• input: output from warning tx (if-case)
• output: Bob's address

Dispute Tx:

• input: output from warning tx (else-case)
• if-case:
  • output: 2of2 MS, usable by both after timelock 2 (-> Distribution Tx)
• else-case:
  • output: 2of2 MS, not-pre-signed Resolution Tx

Distribution Tx (only valid after timelock 2,:

• input: output from dispute tx (if-case)
• output n: distributed BM

Resolution Tx:

• input: output from dispute tx (else-case), signed cooperatively at dispute process
• output to Alice: Alice's address
• output to Bob: Bob's address

All transactions beside the Dispute resolution Tx are signed by both traders before the deposit tx is getting published. Only the Resolution Tx will be signed on demand in the arbitration process.

Downside of all that is the added complexity. Not 100% sure if its worth in Bisq 1 for the maybe small benefit to give the traders an option to cooperatively agree (they could have done already at mediation).

[pazza83]

Would this not have this issue where a user could potentially be dis-incentivized to accept the mediation proposal in the hope their peer will be unresponsive when they publish the claim transaction. If their peer is responsive they get a second change to then do a collaborative transaction.

• The dispute process would become more complex
• The users at mediation (where they have assistance from a mediator) might be less incentivized to accept the proposal knowing they will have two more steps to pass though before arbitration (and the next step gives them the possibility of claiming all funds with no downsides)
• The proposed step would require additional support
• The dispute process would be dragged out

What examples would there be of traders that have failed to agree terms in mediation, being able to agree terms at a new introduced stage (potentially without assistance of a mediator)?

[pazza83]

Maybe there could be a way to publish the claim transaction prior to mediation being opened:

Process could be:

• Claim transaction / Redirection transaction (non responsive peers lose funds before mediation is entered into)
• Mediation
• Arbitration

This way only responsive peers enter mediation.

The downside is the risk that a user would be unaware of the claim transaction being published by their peer and therefore lose funds.

Also the problem that more cases might enter mediation as a result of users wanting to try their luck with a claim transaction first.

I think the way originally proposed would be best:

• Mediation
• Claim transaction / Redirection transaction
• Arbitration

[HenrikJannsen]

dis-incentivized to accept the mediation proposal

Yes that's a good point. I agree that overall the proposed addition is not worth it and might even make it worse.

Claim transaction / Redirection transaction before mediation sounds dangerous to me...

[pazza83]

Marking this proposal as approved but will leave open for discussion

[HenrikJannsen]

I started to work on it but as it turned out at be more complex as initially assumed (it requires an extra roundtrip of messages) and I had limited time and preferred to focus on Bisq 2 work to get it ready for launch I dropped my work on it.
My draft PRs got closed as stale and they have been WIP, but if someone feels to want to work on it they can build on top of those are use it as inspiration. No need to keep my authorship in case parts are reused.

But any dev taking that task should be aware that this is high risk area and requires very careful work and experience with the Bisq code base and protocol development.

@stejbac : I would consider you as a perfect candidate for such a task if you would be available.

[stejbac]

@HenrikJannsen sure, I would be happy to work on the trade protocol change now. (Sorry, I've been a bit distracted by #412 recently.) What is the name of the branch/PR with your unfinished changes?

One thing that's a bit concerning to me is that even if an anchor output is added to the redirection tx to allow it to be accelerated with CPFP before the claim tx can be used, the fee needed to do so could be very high, since there are so many outputs (with more likely in the future as more active BM appear). For example, each DPT now is around 800vB in size, so if the redirection txs were prepared with a mining fee of 10 sats/vB but the fees went up to 250 sats/vB (like the fees recently reached) and stayed there for a while, the trader would have to pay nearly 200,000 sats (or around $75) to get it to confirm on time.

I suppose one could add a smaller staging redirection tx between the warning tx and the final tx which pays the BM, but that might be complicating things a bit. Alternatively, one could make the OP_CSV-controlled timelock on the warning tx output script rather long and then maybe just agree to reimburse the trader in the unlikely event that there is a spike in the network fees coinciding with the window in which to publish the redirection tx.

[HenrikJannsen]

@stejbac Thats great news!!!! Thank you!

Here are my branches: https://github.com/HenrikJannsen/bisq/branches
The ones with the enumerations are the work in progress on the protocol change. They are likely missing something important and not in a working state.

Good spot with the fee issue, but I think if the high fee environment becomes a persistent reality then small amount trades are less likely to happen and thus a larger fee payment is still worth it as the relationship of the trade amount to the fee is what matters. For small amount trades the DAO could cover the potential loss. I think the extra complexity and risks of a technical solution with an additional stage is not worth it.

Btw. If you are interested on implementing the Multisig protocol in Bisq 2 you are very welcome! Bisq 2 should be launched soon with Bisq Easy protocol (we use a simple FSM framework for the protocol - if you find time to review that would be great as well, but don't want to bury you with tasks ;-)). And after the launch and potential bug fixing period and having integrated light wallet support (Bitcoin core and Electrum are integrated, but we consider to use something different to Electrum) we want to start on the Multisig protocol with all the potential improvements. Maybe Taproot can be utilized as well for Bisq 2.

[onlymarcus]

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

Implementation

Let's say Alice and Bob start a trade and lock-up their funds in a multi-sig transaction. In the new protocol, two warning transactions, two claim transactions, and two redirection transactions replace the delayed payout transaction. After the warning transaction is confirmed the time-lock starts. Alice or Bob can claim all funds after the time-lock expires with the claim transaction.
The redirection transaction allows the other party to react and redirect the claim to the burning man before the time-lock expires, thus opening an arbitration ticket.

In this case, if the absent trader reappears at the end and opens arbitration, will the non-absent trader be compensated with the security deposit?
What I have noticed is that someone is taking advantage of this to eliminate competition in the XMR/BTC pair. Someone is taking competitors' offerings and disappearing, making room for him to sell XMR without competitors. There has to be a way to stop this sabotage.

[pazza83]

In this case, if the absent trader reappears at the end and opens arbitration, will the non-absent trader be compensated with the security deposit?

If the non absent peer reappears then the trade will go to arbitration. I think the compensation made available to the original responsive peer will still be as detailed in the issue here: #411

That is the larger the deposit the more they will be compensated.

What I have noticed is that someone is taking advantage of this to eliminate competition in the XMR/BTC pair. Someone is taking competitors' offerings and disappearing, making room for him to sell XMR without competitors. There has to be a way to stop this sabotage.

I am in touch with a BTC seller that had a few trades end in arbitration. I think it is more likely that the reason for their non-responsiveness is due to bisq-network/bisq#6948 rather than sabotage. I think implementing this would be beneficial to mitigate this, as the majority of trades would not end up being paid out to the burning men.

[suddenwhipvapor]

Closing this as it's been approved, and no new discussion is currently ongoing.
I can reopen it by request.