Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop requesting traders private keys for Manual payout #4061

Closed
huey735 opened this issue Mar 14, 2020 · 6 comments · Fixed by #4899
Closed

Stop requesting traders private keys for Manual payout #4061

huey735 opened this issue Mar 14, 2020 · 6 comments · Fixed by #4899

Comments

@huey735
Copy link
Contributor

huey735 commented Mar 14, 2020

Description

At present, in the rare cases Mediators need to create manual payout transactions to release the funds from the multisig, they need to request the private keys of both traders and sign the transaction for them. This is a terrible violation of one of the core Bitcoin principles.

Expected behaviour

Once a trader opens mediation the mediator gets access to the trade's contract with all the necessary information to create the transaction. They should do so and share the unsigned transaction to the traders so they can sign and broadcast it.

Actual behaviour

The mediator creates. signs the transaction for both traders and broadcasts it.

Screenshots

emergencyMultisigPayoutTool

Additional info

I've created a guide for an alternative method using tools outside of Bisq. It'd be great if we could add the following functions to the Bisq software:

  1. verify and sign message with a specific address
  2. verify and sign a transaction
  3. encrypt and decrypt message with a specific address

It's imperative that the sign, encrypt and decrypt functions are done inside the Bisq software due to the need of private key. Electrum and Coinbin's UI may be worth copying.

Related
Legacy Manual payout process
Update to new protocol - #3694

ping @bisq-network/mediators @wiz @Bisq-knight

@wiz
Copy link
Contributor

wiz commented Mar 14, 2020

Well yes, but the "emergency multisig payout tool" is only for emergency recovery of lost funds due to bugs in Bisq, of course nobody thinks we should be sending private keys to each other.... unfortunately until we make Bisq 100% bug-free this tool will be necessary...

That being said, if there are existing tools we can use to have users sign a transaction instead of sending their private key, we should try using those. I agree we should totally add this functionality into Bisq, including the ability to sign a message with your Tor onion key. I wrote a gist for doing this on the command line a while back but we should add it into the app GUI: https://gist.github.com/wiz/c4008ff485e9f773e81fb7b9471039e3

@Bayernatoor
Copy link
Contributor

I agree with @huey735 - i've got a support case which may require multiple manual payouts and I must say that I feel uncomfortable asking the parties for their priv keys. Some Bisq users may not realize the inherent risk in doing this and therefore it could encourage a more relaxed attitude towards the sharing of private keys.

@huey735's wiki guide is a good step towards putting the responsibility in the users hands and removing any trust.

@stale
Copy link

stale bot commented Jun 23, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the was:dropped label Jun 23, 2020
@stale
Copy link

stale bot commented Jul 1, 2020

This issue has been automatically closed because of inactivity. Feel free to reopen it if you think it is still relevant.

@stale stale bot closed this as completed Jul 1, 2020
@ghost
Copy link

ghost commented Jul 7, 2020

verify and sign message with a specific address
verify and sign a transaction
encrypt and decrypt message with a specific address

I would like to work on this - @huey735 could you re-open if still wanted?

@huey735
Copy link
Contributor Author

huey735 commented Nov 26, 2020

@jmacxx I think @ripcurlx needs to be the one to re-open it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants