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

Allow seller to be offline and still get the payout tx signed for altcoins #241

Closed
chimp1984 opened this issue Jul 27, 2020 · 3 comments
Closed
Labels
an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features

Comments

@chimp1984
Copy link

To prevent the cases where the seller does not confirm the altcoin receipt we can add support for automated payment receipt for altcoins by lookup of blockexplorers. For XMR there is already a PR in progress.

This still require that the sellers app is online at the time when the altcoin gets confirmed. To mitigate that requirement we could add a delegation model for providing the signature for the payout tx to the buyer.

Concept:
Seller creates at take offer time his signature for the payout tx and splits it into chunks which he sends to different bonded nodes. Those nodes listen for altcoin payment confirmation of those who requested their service. Once they see the altcoin has been transferred they take the associated chunk of the signature and send it to one chosen node (selection done by deterministic selection based on the data similar like we select mediator). This selected node will send the full signature once it has received all chunks to the buyer (mailbox msg). The seller still can auto comfirm himself if he is online as well do a manual confirmation. So there are 2 levels of further redundancy of the system would fail (e.g. a msg does not arrive).

Security and privacy issues:
Those nodes learn about the onion addressed of both traders as well as the altcoin address and the deposit tx (trade amount). If all those nodes collude or if they get hacked the btc in the trade can be stolen without the altcoin transfer. There will be also a threshold of a subset of signatures which allow a successful brute force attack. There might be smarter schemes to split the signature (not sure if Schamir helps here).

@MwithM
Copy link

MwithM commented Jul 27, 2020

If it's possible to release the coins without the proper altcoin payment, this proposal reminds me to the federation of burningman role proposal which was rejected a few months ago. One of the reasons to reject it was that it creates a TTP:

But beside that it would introduce again the old problem of the legacy arbitrator and just mitigate it by distributing it to a group of people instead of one person, but that would likely not lower the legal risks that this group could be interpreted as TTP. Using all team leads for that group would be an "invitation" how to shut down Bisq on the human resource side by applying legal pressure....

Is this proposal creating federated nodes with parts of a signature very similar to an arbitrator but on the mediation dispute resolution level?

Also, privacy would be reduced to a level that some traders won't feel comfortable with: AFAIK now noone can collect maker and taker onion addresses, alt address associated with trade amounts... this info is only shared when mediation is opened.

@chimp1984
Copy link
Author

@MwithM I agree with your statements and concerns. I just wanted to share the idea, not sure if its a good idea ;-).

@chimp1984
Copy link
Author

Privacy issues might be mitigated to use temporary onion addresses for those connections. So service only learn that a certain altcoin tx was a Bisq trade but cannot map identity clusters.

@MwithM MwithM added an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features labels Aug 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
an:idea https://github.com/bisq-network/proposals/issues/182#issuecomment-596599174 re:features
Projects
None yet
Development

No branches or pull requests

2 participants