search

bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
44 stars 16 forks source link

Proposal to mitigate abandoned trade multisigs #381

Closed pazza83 closed 1 year ago

pazza83 commented 2 years ago

References

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:

Proposal:

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

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 commented 2 years ago

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 commented 2 years ago

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:

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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:

How it works:

Details:

Assumptions:

alvasw commented 2 years ago

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

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

Updating status to approved due to comments.

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

pazza83 commented 1 year ago

@jmacxx FYI closing as approved.

ghost commented 1 year ago

Implemented & fully tested. Doubts expressed in the PR.