How is this possible? (mining fees)

soloelsol · June 28, 2019, 2:49pm

How is possible to charge 22,56% when i want to buy 0,01 btc (max because i have less than a month in bisq), it is abussive, i think, why always comission to buy, send or recibing btc? I understand the miners need to get paid but i think this is too much, am i wrong? Is it very cheao to buy, send or recibing btc but only the fees ara for me? I change btc between wallets (0,0005 btc, 5 eur!, sometimes 3!, if the amount is little it is almost the half!) How is this possible? What i am doing wrong! Thanks

a123b · June 28, 2019, 3:27pm

The problem is that you can’t make it right for everyone. Make the fees low and you’ll get many people complaining that they have to wait 3 days for the trades to start. Make them high and many will complain that they need to give a huge percentage of the trade amount to miners, especially for low volume trades, like in your example.
I would personally rather wait even a week for my trades to start than pay an equivalent of 20 € in fees every time I accept an offer. But there are many people who feel exactly the opposite way.

As for why the fees are so high, when you take an offer, you actually pay the fee for three different transactions, and these are also a little bit bigger than your usual “transfer x BTC from wallet A to wallet B” transaction. To give you an idea, a typical non-segwit spend transaction with change is about 225 bytes big, while an offer taker in Bisq could easily have to pay for 1200 bytes of blockchain space.

The situation could improve soon, I heard the devs are already in the process of adding support for segwit addresses, which would decrease the necessary fees at least a little bit.
The best solution for low volume trades with near-zero transaction fees would be to implement Lightning Network trades into Bisq. It is definitely possible to implement multisig using Lightning, I heard the Hodl Hodl exchange is already experimenting with it, for example.
But I think for Bisq, Lightning is still far, far in the future…

soloelsol · June 28, 2019, 4:35pm

Ok, let’s forget about bisq; so, you are telling me that btc is never gonna be money to achieve little things, like a t shirt or a donnut, yes? btc is like gold in some way, it is not useful for buying common things, is it?

a123b · June 28, 2019, 4:50pm

There isn’t really a place for such small transactions directly on the blockchain. That’s going to have to be handled by a second layer on top of the Bitcoin blockchain, like the Lightning Network is. This should enable instant transactions without any fees (well, almost no fees, like a fraction of a cent).

soloelsol · June 28, 2019, 5:27pm

Thanks, and how and where i could use lighting network?

huey · June 28, 2019, 6:53pm

Hodl Hodl has implemented it.

Ricardosaurio · June 29, 2019, 7:54am

devs, wen segwit ?

huey · June 29, 2019, 11:30am

soloelsol · June 30, 2019, 9:50pm

Today bisq wanted to charge me 223% of mining fees…, of course i did not make the transation but after i moved funds by coinomi and i chose a low rate of satoshi/byte and it has worked well, so, i come back to bisq discussion, this plataform has to do something because if not it is impossible for new users to start because if you buy btc in 10000 $ it cost to you 12500, and this is to much. Thanks

huey · June 30, 2019, 10:22pm

The mining fees differ from the above as they aren’t related to the trade amounts but to the size, urgency and number of bitcoin transactions.

ManfredKarrer · July 1, 2019, 8:23am

No
The mining fees are independent on the amount, so for small test trades they can be very high in relation to the trade amount (223%) but for big amounts that % value would go down to 0.01% (e.g. 1 BTC trade with 10 000 USD and a miner fee of 10 USD.

There are open tickets since long with requests for developers to use a better fee estimation service than earn.com which is used and which is very bad and overpays often. But the Bisq devs are too busy with other high prio stuff and there is a shortage on devs anyway ;-(. https://bitcoiner.live/ and https://whatthefee.io/ would be good candidates to use instead. Any Java dev could implement that, its just reading calls from an API…

Setting the fee estimation too aggressive can disrupt the trade experience heavily if a transaction never gets confirmed. So it is not only about the delay (which also would lead to more dispute cases) but also to have more problems with never confirmed txs and the need to resync your wallet (BitcoinJ is not handling that well).

Also consider that high fees happen usually at times of high volatiility. Delays might lead to big price changes between take-offer time and settlement time, again increasing dispute rate and lowering user experience. So there is no easy solution to that.

Native segwit was on the shorterm roadmap but the BitcoinJ dev we had has left recently ;-(. So again shortage on devs…

Beside all that there are longterm plans to move to an offchain trade protocol. See Off chain trade protocol using BSQ bonds · Issue #32 · bisq-network/proposals · GitHub
That would eliminate the fee problem in a similar way like lightning network. But that will require also more devs and also that the Bisq DAO and BSQ are more established in the Bisq userbase.

loko · July 1, 2019, 9:53am

Seems to be a chicken and egg problem then.
Fees deter users, less users mean less devs and less money to pay them. Vicious circle indeed.

Hopefully while we wait for someone to pick that back up again https://github.com/bitcoinj/bitcoinj/issues/1869 gets done.

ManfredKarrer · July 1, 2019, 4:28pm

BIP 44 is implemented in the BitcoinJ version of Bisq.

loko · July 1, 2019, 8:05pm

It is about 49&84 mostly. Anyway we need to get developers to get the issue list down and more and less important things in.

huey · July 2, 2019, 1:06pm

@ManfredKarrer Bisq uses the “fastestFee” key from the api, right?

soloelsol · July 18, 2019, 8:41pm

ok, thanks, i like bisq because it is truly descentralize but the fees are hihg for low volume and as a new user only can buy 0,01 btc, so…, it is a problem…, anyway: when could i buy more than 0,01 btc, i have read it was a month but still i can not buy more than 0,01 btc? Why?

huey · July 18, 2019, 9:03pm

Those limits are in place to counter fraud. There is a proposal in development but has yet to be finished.

github.com/bisq-network/proposals

Implementation of protection tools: strengthening Account Age by requiring payments from 2 Bank Accounts

opened 04:28PM - 21 May 19 UTC

closed 10:34PM - 05 Nov 19 UTC

m52go

was:approved

> _This is a Bisq Network proposal. Please familiarize yourself with the [submis…sion and review process](https://docs.bisq.network/proposals.html)._ _This proposal is designed to protect users against scammers using stolen bank accounts. To protect against scammers using stolen identities and money launderers, we are evaluating the idea of adding another step in the trading process where a buyer can assure the seller using various verification mechanisms (like those in #83) before the sellers' payment details are ever shown to the buyer. As this change would require more considerable development work, we leave it out of this proposal._ _We strongly believe P2P chat is a critical part of achieving protection against both types of scams, so we highly recommend implementing that as soon as possible—details below._ ## Introduction This is a proposal for trade protection mechanisms from @mpolavieja and myself, and as it is the number 1 development priority outlined in #91 by @manfredkarrer, we would like to discuss it with the community before writing a tech spec. We tried to integrate the most robust ideas from previous proposals #77, #78, and #83, and leave some of the more significant mechanisms for future implementation (see note above). As we think it is important to move forward quickly, if you clearly don’t approve this approach please just down-vote it and write a short comment on why you don’t like it, we kindly ask not to propose alternatives within the comments for this proposal (please submit a different proposal). If you like the core idea of this approach but you want to suggest improvements, changes or corrections, please comment. ## Goal The goal of this proposal is to strengthen the account age concept, as it has been already proven that it does not deter scammers as it was initially expected. Keeping it unchanged would be irresponsible so we have to either downgrade it to a local scope parameter or strengthen it if we want to maintain its network (global) scope. The strengthening is based on the very basic concept that payment accounts would begin to age only if certain conditions are fulfilled. These additional conditions should not be interpreted as a reputation system. _They are just about account age_, and despite the added conditions, account age will still mean just that: Account Age, and nothing more. As such, it is not any bullet-proof protection mechanism, so due diligence of each trading peer will still always be required. **Moreover, this protection measure is fully compatible with other local/P2P protection developments**, such as not revealing seller payment account data to the buyer until the seller has somehow verified the buyer (see proposals #90, #83 and #79), negative reputation system (see #27) or a LinkedIn-like relationship (see @flix1's proposals, like [here](https://github.com/bisq-network/proposals/issues/78#issuecomment-490123550)). ### Assumptions * New users are incentivized to trigger their account age above zero, so they can enjoy higher trading limits. * It is unlikely that a scammer manages to control two different bank accounts from different banks from the user. * This proposal does not provide prevention measures from a scammer stealing or buying IDs and opening several bank accounts, following the rules and doing real fiat trades in order to gain account age and become a user that can trigger account age for other users. However, this proposal provides a procedure to immediately abort corruption of the account age parameter once the illicit activity is detected. ## UX impact overview Most trades would not be affected at all by this implementation. For new users there is a one-off UX drawback. With respect to the current UX experience this implementation would involve the following changes on UX/UI: * A new user would need to set up 2 accounts and point to a secondary bank account within his main account configuration, if he wants his limits to go up. * A new user would have to understand that he needs to make a trade with an old user in order to begin to gain higher trading limits. * Old users need to understand that when a new user wants to trigger their account age with them, the payment is split in two and they have to verify both payments (same name, different banks). * Once it is triggered, the account age parameter would work the same way is working now from UX pov (we need to internally handle a subtle exception for accounts created between 1-March-2019 and the date this implementation is deployed) A procedure for banning and blacklisting users needs to be implemented. The UX of this procedure is similar to that of current disputes with arbitrators. ## Implementation overview This implementation applies to all bank account payment methods and it is based on payment accounts beginning to age only if certain conditions are fulfilled. For this purpose we need users that perform the role of “age triggering”. For a payment account to become age triggering for other accounts is just a matter of time and not being banned (i.e. not being accused of scamming). Users don’t have to learn or understand how their payment accounts achieve that status. It is a passive role. It is new users who are incentivized to reach them. This proposal could be improved by optionally offering different conditions to trigger account age, or by additionally requiring more conditions to trigger account age. Ideally, those additional conditions should be verifiable by third parties. As a first step, we strongly believe that **the trader P2P chat** should be implemented along with this proposal so sellers can freely decide how to verify users, and that would be a really helpful feedback on what verification methods should we implement. Account age would be calculated and displayed individually for each payment account, but when a payment account is banned, all “brother” fiat payment methods from the parent onion address will be also banned. A bootstrapping procedure to enable a curated list of triggering users could be done, but it is not completely necessary as we could assume users older than 1-March-2019 as triggering users. If something goes wrong, the banning procedure should kick in. All the terms used in this proposal are technical terms (triggering user, triggering account age, etc) in order to be as specific as possible. Those terms are not necessarily intended to be used for the UI. ### Account age calculation procedure When enforcing the trading limits or interacting with any trading peer, the Bisq client would check the following: * The onion address of the peer is not banned. * The onion address of the peer´s triggering user is not in the blacklist * The user is older than 1-March-2019 or the user carries Triggering User witness data that fulfills the necessary age conditions (i.e. older than 1-March-2019 or greater than 6 months from 1-Sept-2019). If all of the above are fulfilled, the account age of the peer is calculated by verifying the witness data of the peer (witness data would also include the necessary data from the triggering user). If any of the above conditions is not fulfilled the account age of the trading peer would return 0. Note that if the onion address of the triggering user is in the blacklist, all its “sons” (“brothers” and “cousins” from the alleged scammer account) are automatically under suspicion and de facto included in the blacklist. ### Account age triggering procedure The following prerequisites are needed: * An option should be added to payment accounts to select a secondary payment account from the other accounts configured by the user. The name and last name must be the same for the two payments methods and Banks must be different. This would be an “age triggering account”. * The buyer must use a “triggering account” if he wants his account age to be triggered. Unlike it is implemented now, account age of risky fiat payment methods would remain at 0 until the user conducts a trade as a BTC buyer with fiat that fulfills the following: 1. The buyer is not banned. 2. Seller’s account is not banned (it wouldn’t even be shown as old for the buyer). 3. Seller’s account has not reached its maximum of triggered payment accounts. 4. Triggering User of the seller account is not in the blacklist 5. Seller’s account age is older than 1-March-2019. From 1-Sept-2019 we would require the seller to be older than 1-March-2019 OR more than 6 months old and having successfully overcome this procedure. 6. The seller is instructed that the payment is coming from 2 different accounts and that he should not confirm until he receives the 2 payments. 7. The verification of names and different banks would be **manually performed** by the seller. 8. The seller finally confirms the payments. If all the above are fulfilled, the account age witness of the buyer would be generated using both the private key of the buyer and the seller and including the account age witness of the seller (from now on Triggering User). If the buyer was in the blacklist as a suspicious “cousin” and he successfully overcomes the above procedure, he will be removed from the blacklist. However, for these cases the seller could require more details from the buyer, the P2P chat for traders would be very helpful here. To avoid strong disruption on the network (i.e. too many “cousins” being suspicious), each triggering payment account can trigger account age for a maximum of 3 new payment accounts. A maximum of 1 per week (if it is possible to implement) We suggest a longer time limit of 21 days for this type of initial trades, so the seller can gain a bit more comfort that if chargeback occurs at least he is not going to lose his BTC and the victim will recover his money. This could be lowered in the future if additional verification methods are added. ### Blacklisting and Banning Procedures As stated in the Introduction section, the account age parameter is not bullet-proof so we cannot implement this proposal without a blacklisting procedure. This procedure is a **must**. Arbitrators would manage a ban list for permanent bans and a blacklist for suspicious triggering users. In the future blacklisting could be done without arbitrators as well. For now, the procedure would be as follows: * The seller selects the conflictive trade and clicks the dispute button to initiate the procedure. Now the dispute option has to be also enabled for settled trades. * The user explains to the arbitrator, and if the arbitrator thinks the complaint is legit, he asks the buyer to send back the BTC if he has received the money back. * If the buyer does not respond, or if his answers are suspicious, then the arbitrator includes the onion address of the buyer in the **ban list** so he cannot trade anymore. The onion address of triggering user of the buyer is included in the blacklist so he cannot trigger account age for any new user. If the triggering user was already in the blacklist, then he would be totally banned from all activity. * By including the triggering user, all “cousin” payment accounts are de facto temporarily blacklisted so they need to overcome a new age triggering process to get removed from the blacklist. As a general rule, the banning / blacklisting procedure has to be categorical. The arbitrator shall not hesitate to ban the buyer if the seller provides enough proof of the chargeback. Only if the arbitrator suspects that the seller tries to unfairly slander the buyer he should refrain from banning. Internal guidelines for the arbitrators will be prepared.

soloelsol · July 19, 2019, 11:17am

I agree, but this is not my point, my point is: I have already 1 month in Bisq, and I remember reading that these limits would be increase until 0,02 btc after first montk, or maybe i am in a mistake, and I should remain in 0,01 btc as limit to purchase forever, i do not know
thanks

MnM · July 19, 2019, 4:55pm

It was something like what you say in the past, before some chargebacks from a user were made a few months ago. Now, you and all “new” accounts (created after May) still have a 0.01btc trade limit and it won’t be raised until the security measures are adopted.
It was debated if your limit should be 0.02 btc to reduce pain for new users. That change wasn’t done, but on the next release things will be back to normal and you will be able to raise your limit over 0.02btc.

Read the full twitter thread, there’s more info.

https://twitter.com/bisq_network/status/1151224905515425792

soloelsol · July 20, 2019, 9:44am

Ok, thanks, i hope the limit will raise soon