I was just wondering if it was possible to filter or restrict accounts that can take an offer?
For example, if I place an offer to sell some BTC, then would it be possible to prevent new accounts of below 30 or 60 days from taking my offer?
I worry a bit now when I place an offer and it is taken by an account that is just a few days old.
The reason that I am asking is obviously related to the recent charge back issues from the scammer/s on the bisq platform.
There will be a new release in the very next minutes.https://github.com/bisq-network/bisq/releases/tag/v1.1.0
1 Like
GOran
May 3, 2019, 11:12am
3
So if I update to 1.1.0 I cannot trade anymore…
If I have sent fiat to a trader today, should I issue a chargeback because I dont want to wait 1 month for my crypto? this is quite ironic.
I should clarify I dont even know if I can chargeback/reverse but this feels like I am getting scammed. Entering a trade under certain conditions only to have it change halfway through.
and lastly is there any way to get “verified” or similar so I can use Bisq again or should I look elsewhere for buying btc with fiat?
As far as I understand, you can simply create and offer to sell more than 0.01 BTC and no accounts created after 15th of March will be able to take them, since they have a limit of 0.01 now.
@GOran you can still trade. Trading is enabled for all methods again, as far as I understand. Certain countries and Interac transfers were blocked, but now the block is lifted. So you and other users can still trade, even more so in a way.
However if your account was created after 15th of March you will have a per trade limit of 0.01 BTC. You will have to make multiple trades in order to exchange bigger amounts. This is temporary however until we get a new version with new security features.
There is no reason to issue a chargeback for your current trades. And if you can do a chargeback so easily, you should tell us so we know more about payment methods that are easy to chargeback. There is no delay currently for receiving your crypto, so there is nothing to worry about there.
There is no “verifying” process, no.
Alexej996, I have had an offer to sell BTC taken this morning for more than 0.01 BTC by an account that was just 7 days old.
GOran
May 3, 2019, 12:13pm
6
uh… might as well remove fiat all together if max trade is 0.01BTC and it never increases, the limits are already very very low but since it increases over time I thought Ok lets give it a try…
is this the security features youre talking about? Distributed reputation system · Issue #78 · bisq-network/proposals · GitHub
this went from really great to pretty shit in just a few days
huey
May 3, 2019, 7:23pm
7
After your first trade your account will start to age and your limits will increase.
You can follow and contribute on
opened 10:44PM - 22 Apr 19 UTC
closed 10:40AM - 05 Feb 20 UTC
was:approved
> _This is a Bisq Network proposal. Please familiarize yourself with the [submis… sion and review process](https://docs.bisq.network/proposals.html)._
In a discussion with @mpolavieja we developed a feasible solution for a distributed reputation system based on the account age witness but including a proof of a bank transfer. It is bases on an existing trusted element (arbitration) and from there we can build up a hierarchy of trusted traders.
The arbitrators could sign with their key all account age witness data from fiat traders who had completed the trades (fiat was trnasferred) and which have been older then 2 months. The P2P network payload data will contain the signature, the account age witness data (hash) and the public key of the arbitrator and it is distributed to all nodes. Anyone can verify the signature with the public key of the arbitrator. This will create the root of trust where the arbitrators are a semi-centralized trust root and they give those traders trust level 1.
We apply that to both buyers and sellers. It is guaranteed that the buyer did not has made a chargeback in that time frame. The seller does not give that guarantee but it is very unlikely that the scammer used his own account to receive the Fiat so it seems reasonable to include sellers and gain 50% more of initial level 1 peers.
For signing we might need to use the hard coded EC key as only that is persistant. The normal signature key would not be available anymore once an arbitrator has revoked as it is only part of the arbitrators P2P payload data. We need to think here about the future changes with integration of check for validity of an arbitrator depending on acceptance and locked up bond in the DAO. The current hard coded pubKeys will become obsolete then.
If a new user with a fresh account is trading with one of those traders who have received a signature from the arbitrators the trusted user will sign the untrusted one's account age witness data. By that he will gain trust level 2 but it will require some aging until it is considered trustworthy (e.g. the peer could still make a chargeback in the upcoming weeks). We could use a linear function to derive some trust score from that age.
It is an open question if a single signature is enough here or if we should require up to 3 signatures from 3 different trusted traders. Collusion risk between a potential scammer with a trusted peer is probably a very low risk. If we require too many it leads to some privacy loss for the trusted peer as with his public key anyone can see how often he has traded. If the number of such signing interactions are rather low the visible nr. of trades is much lower than the real number of trades and the problem is less severe.
Another open question is if the signing only would apply to buyers or both to buyers and sellers? Again if the seller is the scammer he would receive the funds on a stolen account which is unlikely that he want to do. If the victim sees incoming money he might get alerted as well and the account can get closed. So we prefer that the process of building up trust happens faster by doing it both ways rather that to be too restrictive.
All that signing and data publishing would happen without user interaction in the background.
A bigger challenge than the implementation of that part is the user experience aspect. We need to find a way to communicate those complex concepts in a simple way to users: The untrusted user need to understand why he has a low trust score and what he can do to increase that. The trade peer need to understand what risk he is willing to take (by trading with low trusted peers) and what are the usability consequences (delayed payout).
It has to be combined with the other proposal about the delayed payout. We need to support both the current account age witness system and that enhanced one with the signature of a trusted peer who has trades with you. With the current weaker account age reputation we are not protected against a scammer who is willing to wait for 1 months without using the stolen account. With the enhanced system one's account age would only start aging once you have done a trade with a trusted peer. New users would prefer to trade with a trusted peer so that they can get faster a good trust score. All that need to be packed into the UI in a way to not confuse users and to not add too much requirement for reading and understanding all that background. Probably the biggest challenge in that proposal....
opened 07:58AM - 25 Apr 19 UTC
closed 12:01PM - 31 May 21 UTC
was:stalled
a:proposal
re:features
> _This is a Bisq Network proposal. Please familiarize yourself with the [submis… sion and review process](https://docs.bisq.network/proposals.html)._
### Introduction
This is a proposal related with this other one "Certification for ownership of a bank account" #23, but instead of basing the certification of ownership on performing a series of comprobation procedures through trusted intermediaries (arbitrators or validators) the system would rely on each user providing proof of ownership of his bank account data by signing it with a digital certificate in which the ID of the owner has been verified externally to Bisq.
Ideally, we should use digital certificates attested by a decentralized ID infrastructure (see [here](https://w3c-ccg.github.io/did-spec), [here](https://identity.foundation/) or [here](https://github.com/decentralized-identity/ion)) but as there is none still deployed we can only rely on centralized issued digital certificates (private or government issuers). Therefore, if we rely on government infrastructure is just for convenience, as the core idea is not based on any centralized / government infrastructure but on open source digital signature standards.
Moreover, there is a reasonable chance that the development could be ported without much effort from centralized to decentralized, as today's centralized infrastructures are already using open source cryptographic standards such as ECDSA or SHA256.
### Goal
Given that fiat bank accounts require providing personal information, the main goal of this proposal is to prevent the fraudulent impersonation of fiat bank account details within Bisq network, and at the same allowing **honest users** to override account age trading limitations (i.e. delays and max trade sizes), or to directly jump to a specific higher trusted level if a rating system is implemented.
This procedure is **optional** and **does not need** trusted intermediaries within Bisq nor any centralized storage of ID personal data.
There is no KYC service provider involved. In this case the equivalent to the KYC provider would be the digital certificate issuers, who will not know nor need to know absolutely anything about Bisq.
**Assumptions:**
- It is unlikely that a scammer has managed to steal both access to a bank account and to the private keys of a digital certificate.
- There is a significant Bisq user base that has easy access or already has an ID validated digital certificate
- Standard Digital Certificates won´t provide significant additional information than the information the user is already providing on his bank account details. Maybe national ID number which anyway is already rather easy to find publicly once you know the name and last name of the user. It is important to note that if the digital certificate is to be used also for encrypting and signing emails and the user provides his real email in the certificate generation process for that purpose, then his email address will be part of the Digital Certificate. In this respect I ask for feedback from the community to review their certificates to see what kind of additional information is included.
### Implementation overview
**Initial caveat:** If the implementation of this optional feature is considered incompatible with Bisq core principles by the Bisq community, it could be derived onto a second layer that interacts with Bisq liquidity network, where a Bisq node could allow other traders to interact only with him (using a Bisq fork or other Bisq protocol compatible app in that second layer) under the condition of having his bank details signed as outlined in this proposal.
There is already a rather widespread standard in Europe called **Advanced Electronic Signature (AdES)** that is legally and technically regulated by the European Union. The definition of AdES is: _“It is the electronic signature that allows to identify the signatory and to detect any subsequent changes of the signed data, which is linked to the signatory in a unique way and to the data to which it refers and which has been created by means that the signatory can maintain under its exclusive control”_.
AdES signatures are not legally equivalent to handwritten signature but shall not be rejected by the mere fact that they are electronic (i.e. if legally challenged, the signer bears the burden of the proof). **Qualified Electronic Signatures (QES)** are legally fully equivalent to handwritten signatures (i.e. if challenged, it is the challenger who bears the burden of the proof), and the additional requirement in comparison with AdES is that they also require a specialized hardware for each signature, such as the chips embedded on some National ID cards, which requires a hardware chip reader that almost no one has. So QES are not yet a practical path, AdES should be good enough. In the event we decide AdES is not good enough (i.e. weak personal identificatiojn procedure or 2FA not mandatory for signing), maybe this proposal won´t be feasible until better standards are available.
Because AdES based certificates must be accepted as legally valid on all EU member states, this would cover most SEPA countries, therefore it would cover a very significant proportion of SEPA Bisq EUR-BTC trading volume. It could even cover all SEPA countries if Bisq accepts AdES signatures of Bank account details from non EU countries such as Switzerland if Swiss users have an AdES compliant certificate. It could be also considered if this AdES digital certificates would be also valid outside Europe (US, Venezuela, Brazil, etc)
There are several formats of AdES, for internal use probably XAdES (based on XML) could be best, if we want it human readable another option is PAdES (final result is a pdf file). For more general details see https://en.wikipedia.org/wiki/Advanced_electronic_signature For detailed technical information, there are available libraries and technical support for the AdES standards:
- https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature+Service+desk
- https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/DSS
The AdES standard requires that the Certification Authority verifies the Identity of the user, but it does not necessarily require a physical verification nor a 2FA procedure for signing, so if for Bisq we require one or both of those requisites, then we should filter and therefore maintain a whitelist to exclude certification authorities that do not require what we want. For example, Spanish government digital certificates required physical ID verification until June 2017 and do not require 2FA for signing. The european union based on its AML regulations allows each country to establish remote identification procedures for AdES and QES digital certificates. See Spain´s example here: https://www.sepblac.es/wp-content/uploads/2018/02/Autorizacion_video_identificacion.pdf)
In Spain, the government digital certificate issuer recently launched an Android application that allows to obtain a certificate by remote ID verification (through streaming video I believe, the details on how they verify ID within the android app are not available at this moment on issuer website).
Other AdES private certification authorities make remote verification ID procedures, and also require 2FA for signing, such as those adhered to https://cloudsignatureconsortium.org/.
### Description and UI overview
When setting up a bank account in Bisq, the user would have the option to sign his account details with the digital certificate installed on his computer. **The name inputted in the Bank account details must match exactly with the name of the digital certificate**. The process would follow these steps:
1. Bisq would make a call to the operating system to prompt the user to select a digital certificate
2. User signs the payload data (his name and IBAN number)
3. Bisq would have to check that the certificate is still valid and not revoked (TOR might require doing this through a relay), and that it belongs to Bisq minimum standards. IMO Bisq should just require AdES, because maintaining an ad-hoc whitelist would add complexity and possibly centralization.
4. Bisq would verify that the name in the payload and the Bank details match (this could be done separately for name and surname).
5. If names don't match, a pop up message should be shown to warn the user that names do not match and the signing process fails
6. If names match, then Bisq stores the payload data and the digital signature together with the public key of the certificate.
When a trading peer opens a trade with that self-certified user, the process would be as follows:
1. If the certificate is valid (not revoked and complies with the required standard), a “verify signature” option would be enabled within the user profile contextual menu
2. The trading peer then could click that option and Bisq would verify the signature and payload data against the name specified in the bank account details and if successful would show a pop up with the message “Name specified in the bank details fully matches the name on user´s digital certificate”
3. The pop-up contains a button that would make a call to the operating system to show the user certificate so it could be manually reviewed and verified by the trading peer.
Those 3 steps above could be abstracted away by showing a green / red signature icon if Bisq is able to do all the verification above in the background. The same way a closed / green lock works on the navigation bar of a browser when https is working.
### Attack Vectors
If a scammer manages to fully compromise a computer, it is likely that he could obtain access to both user bank accounts and user digital certificate. Digital certificates that require 2FA from a different device for signing could be rather resilient to this attack.
### Possible digital certificate providers
Apart from governments and specialised private certification authorities, in some countries such as Norway, Sweden or Finland Banks provide AdES compliant digital certificates to their clients. See the following links:
- Sweden:https://www.bankid.com/en/
- Norway: https://www.bankid.no/en/about-us/,
- Finland: https://www.nets.eu/developer/e-ident/eids/Pages/TupasFI.aspx
Private certification authorities that issue AdES compliant digital certificates at a reasonable cost that I have found are the following:
- https://infocert.digital/cloud-id/ for 29.90€ / year
- https://store.intesigroup.com/qualifiedCS.php For 45€ / year.
- http://cloudsignature.transsped.ro/ For 22.50€ / year.
**Note:** National ID cards with embedded cryptographic chips require a hardware reader and might require to additionally get a Digital Certificate from a certification authority (maybe at a cost) depending on the country. RFID chips on passports are a memory that carries the passport’s data (name, high resolution picture, etc) but is not capable to perform cryptographic functions such as signing.
### Feedback request to Bisq community
For me it is a bit difficult to find out in which countries digital certificates to interact with the government are free for private individuals. If you guys are so kind to provide me the following data from your country:
- Cost: free / if not, yearly cost
- Name of the Issuer and website
- Type of Issuer: Government / Bank / other private certification authority
- 2FA for signing: Yes / No
- Allows remote ID verification?
I will collect it and update it in the following table:
| Country | Cost | Type of Issuer | 2FA | Name or website of Issuer| Remote ID verification |
| ------------- | ------------- | ------------- | ------------- | ------------- | ------------- |
| Austria | Free | Government | No? | ?| |
| Spain | Free | Government | No | www.fnmt.es| Yes |
| Sweden | Free | Bank | Yes? | Any bank adhered to BankID ||
| Germany | | | | ||
| France | | | | ||
| Portugal | | | | ||
GOran
May 4, 2019, 11:24am
8
Not anymore, it seems if your account was created after 15 March the limit is 0.01 BTC forever.
@Petyr-Baelish Either I misunderstood the release notes then or it is a bug.
@GOran It is not forever, as far as I understand, just until a new release. It should be a temporary solution until devs figure out a more long-term solution.
