Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Issue is that on creation of an asset, a portion of the fee is moved over to the pool automatically (as a pre-fill) ..
If you let it run out, can't users pay in BTS?sure they can
And can you tell how much users have to pay per transaction to do PoW? (If the cost is linear, bots are less likely to come to the exchange)
Why is this conversation taking place? At the current price, a 1 BTS order placement fee would cost an active bot about $3 per 1,000 cancelled trades. Are you seriously saying that someone operating such a bot would be looking to avoid $3 in fees? So now we have to remove the order placement fee, which in turn exposes us to DDOS, and now the answer is switch to PoW?
What about refunding accounts their order creation fees at the end of the week/month?
If the account is involved in DDOS it will be red-flagged and those fees won't be re-imbursed.
How can you prevent DDos without charging any costs on them in DEX? It's impossible unless you verify users' identity.
No. I'm talking per account. If an account does what I mentioned above, that account's fees scale or get delayed.
Well other chains might have other methods to deal with this problem.
But in BTS, specifically, what if witnesses detected the spamming and simply didn't include those transactions on the blocks? I mean, this would be a very serious action, they would need to be sure but... Or why not make fees escalate if they're done within X blocks? That makes sense? If number of tx > X and the transaction IDs are all within [w, z] blocks, they scale up.
If it passes that defined threshold then fees go up OR transactions get delayed and spread throughout the next X number of blocks as a mean to distribute it evenly
I am not sure that users really care about the temporal fee of 1 BTS per creating order during DDOS.
If you want to be more active, you can charge much more fees during DDOS (say, 10 BTS by adjusting CER), collect BTS from the attacker, and payback to normal users for their fees paid during the DDOS. Isn't it a good idea?
Regarding DDOS, By charging order creation fee (without refund when cancelled) during the DDOS, you can effectively prevent the attack. In centralized exchanges, users sometimes cannot use the service due to DDOS. DEX has better option. They choose not to use the service to avoid additional fees, or choose to use the service with small amount of fees.
If an attack happens, you first can decrease CER to discourage the attacker. But if the attack lasts or you cannot detect the attack early, your fee pool will be 0, and users cannot make transaction unless they have BTS. So my point is (1) fee pool balance = maximum damage you potentially get. (2) You can stop the attack by decreasing CER. (3) If attack lasts you can suspend your service by maintaining fee pool 0.
@monsterer
I think you can handle the attacking problem by changing CER. You may want to set CER very high so users don't pay any UIAs as a fee, while you pay the fee via fee pool.
If an exploiter begins attack, you can decrease the CER and he/she will has to pay fees for the attack. And you can limit your damage by not putting enormous amount of BTS in the fee pool (if fee pool is 0, people have to pay fees in BTS)
