-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Re activate confirm buttons again #4602
Re activate confirm buttons again #4602
Conversation
Add util methods to DisputeState Impl. paymentReceivedEnabled method for SellerProtocol Impl. paymentStartedEnabled method for BuyerProtocol Remove notDisputed method as not used anymore Add final keywords
Use it in view to disable button
…re the amount is needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK - thank you very much
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
Code looks fine. Maybe could be improved by adding a label next to the deactivated confirm button or at least a tooltip what needs to be done to proceed with the trade.
Why is only fiat mentioned and not alts? Isn't it indifferent? As buyer for an instant alt trade if seller clicks "payment received" 3 days late I'm being aggravated. |
@MwithM |
If there's supposed to be a reason to delay btc release for fiat (chargeback risk) but not for alts, it makes more sense to be able to punish altcoin sellers, because they can't even have an excuse to release the btc payment late. Even if there's no economic incentive to release btc late, sellers have less value locked and can break trading rules without consequences if they don't need their btc soon. To me, this is something that needs to be fixed. I know that the first implementation to solve it has been a pain for moderators and traders who open mediation too early or without a valid reason (I suffered that myself) but still there's got to be a way to make sellers more responsible. |
Do you know if there are such cases and if so how many? As said the option has the cost/risk that it ends up in arbitration and thats much worse then lack of punishment. |
From my experience, this didn't happen very much, only a couple times. But it makes any trading period window just a promise that can be easily not kept, generating two issues that potentially affect all trades:
This might not be the most important issue Bisq needs to fix, but it needs to be fixed and it's been known for a long time. I don't know if it's feasible, but after traders solve the issues when they're not related with an unresponsive seller, could it be possible to make mediators re-activate the "payment sent" button when they get notification from seller that payment has been received? That way only seller needs to take action. |
I think we should not over-interpret that. It does not seem to be a big problem and confirming late is a "soft" violation and they always can lie in dispute so it cannot be fixed anyway reliably. I think a better approach is to look into options to expand the reputation feature. Currently one can only locally mark good and bad traders or block them even. It would be more useful if we find ways how to bring that to a more network wide scale. The negative score idea was one approach. The account age witness signing is an implementation for a special case of a distributed reputation system. Maybe we can find other solutions for the satisfaction level with the peer. Not easy but likely possible. |
Confirming late should not be a soft violation, specially with 10 and 20 days to start arbitration. Just because they can lie, it doesn't matter what explanation they give, unless it's a clear bug and they collaborate with the mediator to solve it. Reputation just doesn't work with altcoins, and can be easily faked. That's why Bisq uses security deposits instead of reputation systems like localbitcoins. |
Implements what we discussed in #4562