You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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.
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).
The text was updated successfully, but these errors were encountered: