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
This has been a recurring issue in the past, and has been requested just now about Pix.
It is a shared concern between traders to know whether their peers are businesses (bound to send financial information to the powers that be) or not, to avoid trading with such entities altogether.
Whatever it will come of this request, I understand the resources to add such a feature on Bisq1 are just not there, so this is a feature request I'm doing on behalf of the users for Bisq2, and a place to maybe discuss this topic, as I don't think it would involve too much work per se, but rather needs to be discussed on a matter of principle.
An argument that could be made, and has been made in the past, is that being bitcoin fungible, and KYC not welcome, discriminating peers based on business status is not "right".
I personally think both points to be moot, because in a free trade environment, anyone should be free to place limitations to whom he wants to trade with, and payment details are shared between peers no matter what, so even without such a flag, anyone can look up the details to find out whether the peer is a business, anyway.
Preventive KYC will not be made in any case, as potential takers who are business and hit a "no-business" offer, won't be able to take it, without sending any further sensitive information to the maker.
The text was updated successfully, but these errors were encountered:
I think adding this tag would provide unnecessary additional information to the user accounts. Bisq Easy also makes if straightforward for buyers to walk away from trades if they so desire.
The theory that business share information with the powers that be is also somewhat flawed. In most countries I am aware of businesses report their profit and loss and do not provide itemized accounts for each transaction.
I think adding this tag would provide unnecessary additional information to the user accounts. Bisq Easy also makes if straightforward for buyers to walk away from trades if they so desire.
True, BE allows more freedom, my reason for opening this issue here though is for the multisig protocol port, considering how no matter the outcome of the discussion, something like this will not be considered in bisq1.
I was voicing a concern that I have met here and there with users, either asking me directly or seeing the topic being brought up, and while I think this to be a useful additional feature for a subset of users who feel the need to differentiate between peers, I also have no personal preference, except believing that adding choices for traders is useful.
This has been a recurring issue in the past, and has been requested just now about Pix.
It is a shared concern between traders to know whether their peers are businesses (bound to send financial information to the powers that be) or not, to avoid trading with such entities altogether.
Whatever it will come of this request, I understand the resources to add such a feature on Bisq1 are just not there, so this is a feature request I'm doing on behalf of the users for Bisq2, and a place to maybe discuss this topic, as I don't think it would involve too much work per se, but rather needs to be discussed on a matter of principle.
An argument that could be made, and has been made in the past, is that being bitcoin fungible, and KYC not welcome, discriminating peers based on business status is not "right".
I personally think both points to be moot, because in a free trade environment, anyone should be free to place limitations to whom he wants to trade with, and payment details are shared between peers no matter what, so even without such a flag, anyone can look up the details to find out whether the peer is a business, anyway.
Preventive KYC will not be made in any case, as potential takers who are business and hit a "no-business" offer, won't be able to take it, without sending any further sensitive information to the maker.
The text was updated successfully, but these errors were encountered: