Reduce maximum trade size for unsigned payment accounts #322
Comments
|
I agree that we need to lower the unsigned offer limit. Just changing both placing and taking requirements simultaneously would cause issues for traders with open offers for 0.01 since upgraded clients wouldn't be able to take those offers. I think it makes sense to limit new offers to 0.0025 but still allow taking of unsigned 0.01 offers as a first step. Then in a later release the taking of 0.01 offers would be restricted to 0.0025. That's still backwards incompatible but I think the effect on users would be minimal since most 0.01 offers would be gone by the time they're no longer possible to take. |
|
(1) There was talk on various forums/places about accounts not being signed (when they should have, and was a bug). Has that been addressed at all? (2) This is going to kick the can down the road ONCE AGAIN. Why is it not possible to mark it as a fixed % of current BTC price in fiat terms? (3) I am principally for no minimum security deposits at all (once signed), and no maximum limit either (once signed). It's a voluntary contract between two people, and Bisq is the protocol. (4) I am also for allowing DIFFERENT security deposit %'s to be set for MAKER and for TAKER... |
|
@Conza88 There was one user who had trouble getting signed. Turned out his account data had not propagated on the network so the signed wasn't able to sign. Once the user removed the account and created it new with a different salt they got signed. I guess it would be possible to use the current bisq price feed to set a limit in USD, problem is that some offers would then move out of range as BTC prices move up, and the amounts are locked in the offer since they're attached to a fee transaction. If we can get the no fee tx protocol going it should be possible to make offers in fiat amounts rather than BTC as well (ie. flexible BTC amounts) since the offer is only funded once taken. Security deposit is discussed in #323 |
|
Another option to deal with it and which makes it easier to deal with future price increases (e.g. if BTC goes to 200k we will have more such events) is to deploy a filter fields with the limit and to show a popup to makers who have offers which are above that limit. Once that limit is deployed such offers cannot be taken anymore. To shoothen the process we can add a data to that limit change when it becomes active, so makers have a few days time to react and only at activation time the new limit is a strictly enforced protocol parameter. We will need an option to change those offers trade amount which can work technically as we only want to decrease of trade amount (as reserved for funds don't allow increase). So we can add a feature to support decrease of the trade amount in edit offer, but not increase. |
|
@chimp1984 I think it's more transparent to add this in code rather than as a filter. Best would probably be as a DAO parameter but that would take a while to implement. My suggested changes would allow for immediate deployment in the coming release with cutoff tomorrow and the follow up on limitation in the release after. |
|
I worry about the negative user experience impact decreasing the trade size for unsigned accounts will have. My assumptions are:
Based on the table below average sats/vb fees result in a fee of approximately $8.33 per transaction. This would be result in a $25 for taking an offer of 0.0025 BTC (currently $140). Therefore as a percentage of the trade amount this is 17.9% of trade amount. Now assuming the maker of the offer is also going to have to pay $8.33 mining fees to make the offer. I would expect a premium of 20% would be about average. So now a new user will be spending $25 + premium of $28 to acquire $140 worth of BTC. These fees totaled represent 34.3% of the trade amount. I think this will make new buyers give up on Bisq before they become signed.
To run the numbers with the current trade limit of 0.01 BTC for comparison. $25 for taking an offer of 0.01 BTC (currently $560). Therefore as a percentage of the trade amount this is 4.5% of trade amount. Buyer premium of approx. 10% So with 0.01 BTC a new user will be spending $25 + premium of $56 to acquire $560 worth of BTC. These fees totaled represent 14.5% of the trade amount. This is still high but a lot more workable. I share the concerns with risks associated with increased prices for 0.01 BTC, is there a way of reducing these risks in a way other than decreasing limits for account signing? Maybe there could be other ways to achieve account signing eg: New users take offers of fixed price of $100 or equivalent from bonded sellers, thus reducing the need for security deposit, BTC transfer can be done without multi-sig requirements. Following this trade the 30 day timer would start reducing the ability of fraudster that has temporary access someone else's account. The above could even be done outside of the signing system, and another level eg pre-signing introduced before a trader can do any trades? |
|
Just to share some anecdotal experiences from my limited experience on https://bisq.wiki/Keybase-Buy_Bitcoin for small amounts of BTC.
|
|
Euro should not be subject to these limits, since SCA as part of PSD2 is being rapidly implemented in the Euro-area with most countries being fully compliant and the rest following in rapid succession: https://okaythis.com/blog/sca-deadlines-across-europe The consensus within Bisq is that traders are extremely sensitive already to the trading fees (average about 0.4%). One should thus be very cautious to increase the relative mining fees, which in the example of @pazza83 are 4.5-14.5% for new traders even now. |
|
I am disappointed this was not discussed further. |
|
Is this ACTUALLY a problem? Where is the data? How many unsigned amounts over this ended up falling/getting escalated?! Or is this theoretical fear based on "what if"? And consequences are reducing liquidity even further!? |
|
As it seems to be this change needs more discussion going forward please leave a 👍 if bisq-network/bisq#5318 should be reverted for the v1.6.0 release and on master. |
I can confirm that within Austria of the four banks I'm using all of them have 2FA with a mobile app already in place. |
|
Nothing about this proposal is theoretical...allowing trades larger than 100 USD without safeguards was a problem in the past which almost crippled the network. I don't remember the exact figures but I believe some of the chargebacks in early 2019 were for smaller 300-400 USD amounts. The result: all new users were barred from buying more than 0.01 BTC at a time for 6+ months of 2019. Talk about rough onboarding. The fact that a similar sort of crisis hasn't happened yet (in the past couple of months since the BTC price pop) is just a matter of sheer dumb luck. Ideas to improve the current mechanism should be devised and discussed, but it doesn't make sense to hold off on this change since no firm ideas to improve the status quo are close to being rolled out. |
|
I see it as a principle that changes should be made through following Bisq's project management process I think the hast to implement a fix has meant that the process has not been followed as it should have. I think more discussion is needed regardless of outcome. |
|
This topic has been under discussion since January and it's been almost a week here. It's a matter of network security, and given the risks at hand, I don't think any of the objections so far warrant avoiding this change in the upcoming release. Short-term fluctuations in growth and adoption won't matter if a few bad actors do chargebacks and undermine confidence for all new and prospective users. Also this is not a project, so that project management process isn't really relevant. |
|
What payment methods does this effect specifically? All that require signing? |
Yes. |
Yes, but no consensus was reached on #295 and from my perspective no consensus was reached on this thread. I was surprised when I saw it was being implemented: bisq-network/bisq#5318 I was not aware the process was different for proposals. I assumed a rough consensus would still be needed.
There has to be a balance between network security and accessibility. My thoughts are a 0.0025 BTC limit for all payment methods that require signing pushes this balance too far and has a negative impact on users. Maybe we should consider which payment methods are more at risk from fraud and decrease their limits rather than apply to all methods that require signing. |
|
Or maybe we could choose something in the middle between 0.0025 and 0.01. |
|
I don't think limiting trade amount is the solution. After all a signed account states that the peer successfully traded ONE time (at least). To me this doesn't seem like a proper measure of a peer's reliability, a scammer could get signed before and chargeback later. Limiting trades is a rather unelegant and superficial way to patch the problem. I believe in giving peers the power to choose which users to accept and which not. Account age and signing status is not a bad idea, I remember entering Bisq the first time and feeling safe trading with a 200+ days-old peer, it just needs to be implemented better since Bisq needs adoption! Limiting trades amount with this kind of fees (and the other problems) will hit everybody. Maybe educating users and highly discouraging trading at high amounts with unsigned peer is an option. |
|
The model put in place a couple of years ago was a hard coded limit at around USD100 in BTC. This risk model hasn't changed and no new consensus has been found so it makes sense to keep this limit until we have a new consensus. I understand that a lot of new contributors were not around and might not be aware of the previous discussions and past issues with scammers. The result of those discussions is what I as a developer use as guidance until a new consensus is found. I will also concede that with the ongoing discussions it might have been a bit rushed to just implement and merge this change. |
|
Another option, as mentioned in the opening post of this proposal in the "Workarounds" section, is to keep the limit high and make it extra-clear to sellers that offers in the 0.0025 - 0.01 range carry more risk. Ideally this would be accompanied by an option for sellers to specify that their offers only be take-able by signed buyers. With the above solution, the signing trade amount could be removed entirely, leaving it up to the selling peer to determine how much risk they want to take on. The problem is -- such a solution, and any other proposal deviating from the fundamental way things are currently done, would require time to develop and test and roll out (in addition to determining consensus for the concept in the first place). Does the network have this time? Bisq releases tend to be monthly, so we're talking about 1 to 3+ months which means 4,000 to 12,000+ trades that will take place until a better mechanism is put in place. So until then, we leave the status quo? While BTC price continues to moon? Is this smart? I'm not sure. |
|
Well Bob enters Bisq v1.6.0, sees that the only tx he can take are ~24% up in seller's premium, he then proceeds to deinstall Bisq, forget it and never check it out 3/4 months later. Then Alice also enters Bisq v1.6.0, sees that the only tx she can take are ~24% up in seller's premium, she's disappointed but proceeds to take the offer, but as soon as she sees the high fees which in proportion to her trade are really high, just gives up and deinstalls Bisq, forget it and never check it out 3/4 months later. And so I guess that the 3/4 of new possible users reaching Bisq in these 3 months will just go away... in a period where Bitcoin is skyrocketing and interest is never been so high? I do get the issue here, but it's also not smart to block novice users and traders... |
Most of the volume for fiat on unsigned accounts go through:
I would argue SEPA is very low risk. |
We could see the actual data if: @wallclockbuilder's #320 gets over the line. |
|
Zelle is generally low risk but chargebacks are possible...it should still require signing, I think. I believe the past chargebacks were carried out with SEPA and Zelle. Seems like things may be changing soon with SEPA but I'm not aware of any such changes with Zelle. To add some perspective: payment account security has always been problematic for new user experience. Before account signing was account aging (introduced in late 2017 I think), which required all payment account trade limits to be capped at 0.0625, wait 30 days for limits to be raised to 0.125 BTC, and then 60 days for limits to be raised to 0.25 BTC. This was for all account types, even low-risk ones, and it included seller limits too (!). Recall that BTC was under 10,000 USD for much of 2018 and 2019, so 99.9% of new users were punished with extremely low limits for the first 1-2 months they used Bisq. UX sucked. You might be thinking, well 0.0625 BTC @ 10,000 USD is about 625 USD, which is not far from where we are now with a 0.01 limit. Well you'd be right, which is exactly why some scammers took advantage of the aging mechanism and forced the network to impose tougher limits on buying for new users, so signing was introduced, but not before all new users were capped to buying 0.01 of 7 months of 2019. UX really sucked. Then account signing was introduced, which imposed a 0.01 limit for new users buying with risky payment accounts, which was about 100 USD for most of the time it's been around. The aging mechanism remained in place for non-risky payment accounts. UX sucked even more. It wasn't until recently that buying and selling limits were removed altogether for non-risky payment account types, and that selling limits were removed altogether for all payment account types. Why do I say all this? To show that network security has always took precedence over UX. Why trade on Bisq if you can't be confident the trade will go securely? If I were selling on Bisq right now all my offers would be >0.01, no question. Even by being so conservative in the past, the network still got stung. With this background, the need is so clear to me I never expected this to be a contentious proposal. Will new user growth be hampered? Yes of course. But I'll reiterate that I think it's better to lower limits now and drive for a better solution in the next 1-2 releases than take the chance of something happening and then scrambling to control fallout. |
What does scrambling to control the fallout look like? So bulk chargebacks from scammers? More support tickets? A hot fix attempt to change? |
|
If it's anything like last time, I believe trading was blocked altogether for certain high-volume payment methods, then trading for all new risky accounts was limited to 0.01 BTC indefinitely (ended up being ~7 months), and the whole time people were wondering just what the heck was going on. Bisq trading activity is 2x - 4x what it was in those days. And its public profile is much higher...so the FUD would be that much worse. Also it's precisely these kinds of bad headlines that put projects [even higher] on regulator radars. What it essentially sounds like you're saying is to just chance the goodwill and reputation Bisq has built over the past 5 years. I think that is highly irresponsible and unwise. A good thing to do, I think, is recognize this situation as a high near-term project priority, get serious about developing a better concept for payment account security, and implement that concept ASAP. The wrong thing to do, I think, is to shoot down a preventive measure without a plan and just assume everything will be ok. |
|
Is there any 'compromise' position between the two current takes? An easier thing for all to accept short term, until next release? |
|
I would say that if signing limits are not reduced in 1.6.0, there should at the very least be a pop-up displayed on the make-offer screen for sellers clarifying the situation so they can deal accordingly. Maybe a toggle to require that takers for particular offers be signed or unsigned could be added in an upcoming release, which would absolve the need for this signing limit entirely. @sqrrm further details such an approach here. @BtcContributor proposed making the limit 0.005 instead. Another possibility, as suggested by @pazza83, could involve reducing the signing trade limit for some payment methods and not others, but I'm not sure if that's technically feasible. In any case, it would further complicate the already-complicated account signing mechanism for users. |
I am continually for allowing choice to users (buyers/sellers), along with the proper education (UX) to assist in that decision making process. What the risk/rewards are, so no-one can claim to be uninformed. Whether that's informative "(i)" hover overs, or links to wiki pages. (1) So very much on board with ability for makers to toggle whether signed or unsigned can accept their trades. Trade off between more liquidity, and less essentially. If there was a way for it to be like editing a trade, and it's not permanent when the trade is made - that would work better e.g. I make it so signed only (no-one takes, then I go screw it - want to allow unsigned as well). (2) Don't like the sound of more complexity etc. And think the longer term solution is as above, remove limits and allow traders the choice with informed info. (3) Short term interim, would prefer the 'compromise' 0.005 instead of what is currently intended. If any issues arise, I think hot fix should be working towards above longer term changes. Goal should always be: how do we have to never deal with this again. |
Totally agree with last part -- this is something we should work toward never encountering again. But I would be cautious about settling on a compromised reduced limit:
Part of the initial reason for this proposal (and my desire to get it in 1.6.0) was a gut feeling that a better signing mechanism wouldn't be feasible to roll out in the short-term. It was really hard to get what we currently have conceptualized and built, and alternative approaches never materialized, so the odds of doing it now off-the-cuff seemed rather slim. But if we can be confident that the account signing changes in this discussion can be made in the short-term, such that the signing trade limit can be removed entirely in the next 1-2 months, it might be more advisable to just do a pop-up now and leave the limits as they are. |
Good points. Geezus, that's drawn out. Especially around re-education, and when signing limit will be removed anyway (ideally)...
That's fair enough.
Yep, definitely onboard with that. Pop-up or altered gives knowledge about risk/circumstance etc. awareness for those accepting risk. And limits as is, doesn't inhibit introduction of new onboarding users etc. I guess feedback on feasibility of that taking place in next few months? |
Exactly, would be best to avoid such friction points, or at least consolidate them as much as possible.
Yes I think feedback from developers @sqrrm @jmacxx and others would be important to get an idea of if/how this could happen. |
As SEPA is our biggest "signed account" market and most of the EU countries will follow suit in providing 2FA (non-sms) by end of March, except UK (> 14th Sept), Belgium (> 18th May), Ireland (>1st July), Switzerland (> 15th Sept), we could remove the signing limitations for SEPA, SEPA Instant, National Bank, Same Bank and Specific Bank with release (v1.6.1) on a country basis. So signing will only be required for Zelle, Interac, Revolut, Chase Quick Pay, Popmoney, Moneybeam, Uphold and SEPA & SEPA Instant for countries that haven't implemented SCA requirements yet (current new final deadline is 14th of Sept 2021 https://www.fca.org.uk/news/statements/strong-customer-authentication-and-coronavirus). Please 👍 if you think we should remove signed account limitations for countries that implemented SCA. |
|
As I'm about to merge the revert of the "Lower tolerated small amount". @m52go Could you please come up with a text for the case someone is making a sell offer <= 0.01 BTC or when taking a buy offer <= 0.01 BTC of an unsigned account? @jmacxx Would you have time to implement those popups for the v1.6.0 release? |
|
I think a long term solution is needed. When limits were set at 100 USD mining fees as a percentage to BTC trade amount where a lot lower. From my perspective an initial 0.0025 max limit seems low for unsigned accounts when accounts that do not require signing can trade immediately at 0.25 BTC levels. This is a 100 fold increase. To me this seem disproportionate. If we do nothing and BTC price doubles in 6 months the limits for unsigned accounts would be closer to 1000 USD. If we reduce the max trade amount for unsigned accounts to 0.0025 BTC and BTC price doubles in 6 months (and mining fees stay the same or rise) the premium to buy 0.0025 BTC could rise to 50-70%. Neither of the above options is good, but one or the other is a likely scenario. Buyers are sensitive to price premiums. 50-70% premiums would lead to a minority of new users trading with signed accounts. If signing is needed for accounts where there is a higher risk of chargeback we should reconsider their inclusion in Bisq, or only allow trading with them if the users are made aware of the possible risks. Proposals to reduce network fees will really help but they might not arrive before BTC prices force one of the above scenarios. |
|
Yes, this proposal is more intended of a stop-gap measure for the immediate future. I think the worst thing that could have been done for the 1.6.0 release is nothing. Preventing fraud is a pretty hard problem for billion-dollar companies with tons of information, so for a fledgling peer-to-peer network predicated on privacy, I think account signing has worked rather well so far. But you're certainly right that it's not a very sustainable way forward, at least as it works right now, and I agree with everything you said. |
|
How about considering other ways to decrease fraud rather than lowering trade sizes. Would it be possible to add into the protocol a 7 day period where the seller can wait before releasing funds to buyer to ensure no chargebacks etc. This waiting period prior to singing would protect the seller from any chargebacks and buyer would still get their BTC as the agreed price albeit with a 7 day wait. I would imagine most cases of fraud are discovered and actioned by banks / account holders within a 7 day day period. |
|
@pazza83 I remember you proposing the idea of a longer trade period for signing trades on Keybase last week...I think it's a nice solution, in theory. I'm not sure 7 days is long enough, but however long the period is, the prospect of locking BTC for several days will probably be unattractive for both parties (especially buyers). Still, time really is the key to proving integrity in a transaction facilitated by a single payment method, so it sounds worth exploring to me. I wonder if there is some creative approach to mitigating the downsides...such that buyers aren't scared away from having BTC locked for so long, and sellers are sufficiently motivated to make offers with reasonable premiums to justify having their deposits locked for so long. |
This seems to be agreed. Are any devs able to implement this? @ripcurlx would you like me to create a separate issue for this request? |
|
@pazza83 please open a separate issue, under bisq-network/bisq to track this to avoid muddling the discussion in this issue. |
After reviewing this and considering the comments from @RefundAgent:
I think it is not appropriate to remove Signing Requirements for SEPA. SEPA chargebacks would still be an issue. SEPA payment scheme has provision for 'Request for Recall" for multiple reasons. More information can be found here: EPC135-18 v2.0 Guidance on Reason Codes for SCT R-transactions.pdf The fact that a request for recall exists means that change backs are a risk and therefore all SEPA payment methods should keep there account signing requirements. |
Maximum trade size for unsigned payment accounts should be addressed quickly.
The last proposal on this was open since January but bogged down and stalled by a mix of concerns. Here I want to solely address maximum trade size for unsigned accounts.
It is currently possible to trade >500 USD without signing with risky payment accounts in active markets. A year or so ago this would have been unthinkable...signing was implemented to prevent trades beyond 80 USD. This amount has now ballooned over 7x. I don't think it's an overstatement to call it a considerable risk to the project.
I think this unsigned maximum trade limit should be reduced to 0.0025 BTC. The current range for valid signing trades is 0.0025 - 0.01, so essentially I'm proposing to make the range fixed to this lower amount (unless there is a technical/other reason for this amount to be a range).
At current rates, 0.0025 BTC is still well over 100 USD. The BTC/USD rate could crash by 20,000 and 0.0025 BTC would still be close 100 USD, which has been the target for this unsigned maximum.
Hard Fork
As noted here, this change would require a hard fork. I think the gain in network security is worth it. As noted above, the change still allows for relatively generous trade sizes, and would still be reasonable in case of a BTC/USD crash.
Mining Fees
There was a point here about this change causing mining fee proportion of total trade size to increase, making trades look unattractive. I agree this is a downside, but it's more of a downside of Bisq's trade protocol that will need to be addressed in other ways.
Workarounds
Another way of achieving this without explicitly changing the limit is putting guidance in the software to encourage sellers to make smaller offers (i.e., make <0.01 offers even smaller in order to avoid 400 EUR payments from unsigned accounts, thus reducing the number of <0.01 offers on the network for unsigned buyers to take). This would avoid a hard fork, but might not be very effective unless sellers had a way of limiting their offer to being takeable by unsigned accounts only.
It would also hurt liquidity for users with signed payment accounts in the <0.01 range, which is not a great idea.
Relation to General Trade Limits
A reduction in overall trade limits should be considered too, but that will be proposed separately since it's distinct from this topic. The maximum per-trade exposure of the DAO (which is currently >100,000 USD). I mention it here because it is somewhat related and will also require a hard fork.
The text was updated successfully, but these errors were encountered: