Proposal to mitigate abandoned trade multisigs

[pazza83]

References

• Proposal to analyze blockchain data of Bisq trades to report on failed trades, arbitration instances and long-term locked funds #352
• @jmacxx's python script and report to action the above proposal

Background

This proposal is a result of the original proposal above, the work done to complete the proposal by @jmacxx and on/off discussions with the support team over the last ~6 months.

Definitions

An abandoned trade multisig is when a Bisq trade does not complete for whatever reason and arbitration is not started.
A review by the Bisq support team of trades since 2020 showed at least 58 abandoned multisigs totaling 5.94173536 BTC.

Problem:

There are cases where both traders are not able to publish the delayed payout multisig.

Examples are: hard drive crash, tails cleared all data, users go AWOL.

In these cases the trade multisig is no longer accessible and the BTC contained within the multisig is 'lost'. This has lead to traders losing access to being able to send their funds to the donation address and as a result ending up out-of-pocket.

Outcome:

This proposal seeks to achieve the following outcomes:

• Reduce the frequency of abandoned multisigs.
• Reduce the number of traders ending up out-of-pocket as a result of abandoned trade multisigs.
• In cases where both traders have gone AWOL the BTC can be sent to the Bisq donation address rather than remaining inaccessible.

Proposal:

This proposal would seek to achieve the above outcomes with the following solution:

• At trade init, send the signed delayed payout tx to the Refund Agent in a network message.
• The Refund Agent will have a screen that lists abandoned trades greater than 60 days old.
• Provide a means for the Refund Agent to publish the delayed payout tx from that list.
• The delayed payout tx can only be published to the Bisq Donation address (obvious, but needs to be stated for those unaware).

Technically, the delayed payout tx can be published 20 days after the trade date (hard limit) however the workflow on the screen will make the tx available for publishing after 60 days (or whatever the design decision is).(a soft limit)
Allow users to opt-out to this functionality via a config setting.

If this proposal is actioned it would allow traders, for example with corrupted hard drives, to initiate arbitration outside of Bisq for which a protocol already exists. Validation that they are indeed the user would still be required. This could be achieved though singing a message to prove they are in control of the BTC payout address in the trade contract, or in the cases where the BTC wallet is inaccessible some other method that satisfies the Refund Agent's requirements for proof.

Goals:

No change to trade init negotiation protocol. Just a network message sent to Refund Agent at end of trade init.

Tagging: @refund-agent2 as this proposal if accepted would have an implication to their role.

[chimp1984]

I consider that a risky change which changes the control about the delayed payout tx. It adds risk to the Refund Agent as they could publish the tx without the consent of the traders. Also I think the proof will be very difficult for those cases where both users have lost control over their app data. Also it would decrease privacy as each trade would send that message to the Refund agent. Now only disputed trades will get visible to the RF. Even if its only blockchain data its decreasing privacy.

[pazza83]

Many thanks for the comments.

I am not able to respond to the privacy concerns as it goes beyond my understanding. Is there an alternative way to achieve the outcomes and mitigate these concerns?

With regards to the comments on risk of the to the Refund Agent. Whilst true they could publish the delayed payout transaction without the consent of the traders this would only be the case where both traders have not opted out of this implementation, and where both traders have not accepted mediation or where both are non-responsive. Risk is also mitigated somewhat in that the Refund Agent would be sending the funds to the donation address, an address outside of their control. It is also worth bearing in mind that currently consent of only one trader is required to publish the payout to donation address. With this implementation it might be the case that one trader wants to send the BTC to the donation address but is prevented from doing so due to a bug , software or hardware issue.

With regards to the comments on proof. I think this will not be as difficult as anticipated.

Most of the cases I have dealt with the traders with lost funds have access to their Bisq instance (usually via a backup). This gives them the ability to sign a message to prove address ownership but (unless the backup is post the trade with locked funds) they do not have the ability to sign the delayed payout transaction to send the BTC contained in the multisig to the donation address.

Another possible solution for proof would be the following:

• Trader confirms they have control of the fiat account used for the trade via Arbitration.
• Trader confirms they have control of the alt coin address used for the trade via Arbitration.
• Trader confirms they have control of the onion address used for the trade via Arbitration.

Mainly this proposal seeks to address the frustrations caused where one trader trades with an unresponsive counterparty and has a issue that means they are unable to access a dump of their delayed payout transactions preventing them from initiating arbitration and having to leave their BTC locked in the multisig.

[chimp1984]

Re privacy:
The delayed payout tx contains the MS address and that the inputs of boths traders. So if the RA gets all those txs it becomes a honey pot for tracking all trade txs.

Most of the cases I have dealt with the traders with lost funds have access to their Bisq instance (usually via a backup).

If that is the case we should try to make a more solid dump of the delayed payout tx. I think its stored already, but maybe that can be improved. If not I doubt that sending the tx would be more reliable (storing to disk has much less risk as sending via P2P network to RA).

[pazza83]

If that is the case we should try to make a more solid dump of the delayed payout tx. I think its stored already, but maybe that can be improved. If not I doubt that sending the tx would be more reliable (storing to disk has much less risk as sending via P2P network to RA).

Yes, this was also proposed as a solution. I think there was a discussion around possible cloud storage and if that could be made safe.

Storing to a local disk at the time of trade might not give much protection if there is a hardware failure as it would reply on a backup being made post trade. I suppose a separate local disk could be used but this might not be an option for some traders.

[chimp1984]

After more discussion with @pazza83 I agree that sending to the RA might be the best option.
Its mainly for the case where the user has lost access to their data directory but has their seed words, and with that they can proof that they have been part of the trade.

[ghost]

Here is my design outline which uses Bisq P2P storage for saving encrypted delayed payouts. Only the user that created it can decrypt it, so it is safe from (a) custody issues, and (b) tampering.

I'd like to get feedback before continuing dev.

---

Design spec for Delayed Payout TX backup

What this solves:

• See Proposal to analyze blockchain data of Bisq trades to report on failed trades, arbitration instances and long-term locked funds #352 and Proposal to mitigate abandoned trade multisigs #381

How it works:

• At end of trade init, a Bisq node publishes an encrypted backup of the existing delayed payout tx to the P2P network.
• At trade payout, a Bisq node will remove their delayed payout tx backup from the Bisq P2P network. This prevents the list from growing too much.
• A user can at any time view their own backed-up delayed payout txs from a new tab in the ctrl-g UI (emergency payout tool).
• A mediator/arbitrator can view backed up delayed payout txs if they are provided with an encryption passkey from the user.
• A decrypted delayed payout tx may be copied to clipboard or broadcast directly from the tool.

Details:

• Encryption passkey = sha256(seed phrase) so passkey can be shared without revealing seed phrase.
• Encryption method=AES256 (see https://stackoverflow.com/questions/992019/java-256-bit-aes-password-based-encryption)
• Publish to network using "AddDataMessage"
• Remove from network using "RemoveDataMessage" (only same user that published it)
• Protected storage "DelayedPayoutStore" fields: encryptedTxBytes

Assumptions:

• Should be always enabled, seems that having yet another config setting would be overkill.

[alvasw]

This is in general a good idea and Ilike this proposal. Thank you for taking your time to plan it! 👍

However, how are we protecting the network against a denial of service attack (a user publishing 1,000,000 "backups")?

Comments:

Encryption passkey = sha256(seed phrase) so passkey can be shared without revealing seed phrase.

This scheme does not provide forward secrecy. If a user ever restores one backup the mediator/arbitrator can access all previous and future "backups".

Encryption method=AES256 (see https://stackoverflow.com/questions/992019/java-256-bit-aes-password-based-encryption)

Do you want to use CBC or a different chaining mode? The linked post even mentions that CBC is not the most secure. Or do you want to use a ADEAD? As far as I know bisq depends on bouncycastle (we can use reuse it).

[w0000000t]

For what my opinion is worth, since I am not able to review the code myself but just the outline in your post, I like the feature now even more than how I liked it when you described it during our support call.

[ghost]

Thanks for the comments!

Re: spamming one million records -- There is no protection in place for existing record types like TempProposalPayload, OfferPayload etc. I checked this in regtest. Seems it is a systemic issue that needs to be addressed separately.

Re: forward secrecy -- Most users could be guided through the recovery without having to divulge their passphrase, the same way they are guided through manual payouts without having to divulge their private keys. Or the user should start a new wallet after recovery, which would make future backups inaccessible.

Re: CBC or ADEAD -- Not a cryptography expert, personally I am aiming for something equivalent to how I use GPG: gpg --cipher-algo AES256 --symmetric plain.file. After reading the linked stackoverflow topic, I think the solution storing an Initialization Vector along with the encrypted payload will be sufficient. I will paste sample code for your review.

[alvasw]

Re: spamming one million records -- There is no protection in place for existing record types like TempProposalPayload, OfferPayload etc. I checked this in regtest. Seems it is a systemic issue that needs to be addressed separately.

Ok, I thought that there is some TTL or size limit.

Re: forward secrecy and CBC or ADEAD

That's smart! GPG uses hybrid encryption with a public key. We could use the EC MultiSig key of the trade. This key is derivable with the seed.

[pazza83]

Updating status to approved due to comments.

@chimp1984 gave a thumbs down but then changed his mind later in the issue.

[pazza83]

@jmacxx FYI closing as approved.

[ghost]

Implemented & fully tested. Doubts expressed in the PR.