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.


Messages - clayop

Pages: 1 ... 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 ... 136
136
General Discussion / Re: poll for the percent based transfer fee
« on: January 22, 2016, 07:47:37 pm »
I think it has to be higher than the actual fee or every person planning on something related to the referral program will be disapointed. We need to be VERY carefull with that decision. The low fees of the big mass of tiny transactions has to be compensated by some of the big one to average fees around what we have now.
Someone sending 1000€ doesn't care about the fee beeing 30 or 90 cents.
The 0.1% fee, cap 3bts / 300bts seems decent.
I guess it's too complicated to have 0.1% up to 100€ and 0.05% up to 10 000€ and cap there at 500 bts ?

Given 0.1% fee / 300 BTS, changing min fee from 1 BTS to 3 BTS only increases 1.7%. I think that it's not worth to get 1.7% more fee while discouraging many potential micro-transaction activities. It's totally undesirable.

137
General Discussion / Re: poll for the percent based transfer fee
« on: January 22, 2016, 05:59:43 pm »
With the information we got today on mumble it seem that the minimum fee for transcations would be around 1 cent.

So it would make sense to use around 2-3 bts as the cheapest fee (around 1 cent but slightly below to have a nice selling agrument).

(Here comes the limit of my hability to express myslef clearly in english ...)

To avoid to hurt referral program, wich is a very sensible subject, we could have something like 150-300 bts as the upward cap fee.

The low cap is easy to decide, it's the minimum fee that doesn't allow anyone to hurt the ecosystem. The top cap is more tricky !!!

To define the top cap, maybe we could create a poll and get an estimation of how much transactions (in volume) we would have with fees of 3 bts  / 30 bts  / 100 and the  maximum fee (let's say 300)

With something like  20 members participating in the evaluation we would have something close to what we would have. With simple math we could determine what would be the highest fee asked to keep (more or less) the same effect on the referral program and probably decide to take something a little higher to be sure.

This would be to avoid guessing in the dark and change it in 5 weeks with all the fudders enjoying the oportunity to say that "we are always changing everything and bla bla bla fud fud fud"

Is that making sense ?

I fully disagree with the 3 BTS minimum fee idea. This makes no sense in terms of efficiency.

Given 0.2%, 300 BTS maximum, changing from 1 BTS to 3 BTS increases total fee collected only 1.1%. Meanwhile, many micro-transactions have to pay 300% more fees. This will clearly discourage micro-transactions.

138
 +5% Thanks for the info @TravelsAsia

139
How can you prevent DDos without charging any costs on them in DEX? It's impossible unless you verify users' identity.

PoW is the only way this makes sense, I think.

I think you do now want to resolve the problem with existing solutions. You just want to introduce PoW. I'm not saying PoW idea is wrong, but you're just insisting your thoughts although there are many ways with existing features to resolve the issue you now have.

Why not whitelisting? Why not temporal small fee with full refund after an attack?
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)

140
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?

No, I don't think it is. Charging users to place or modify orders will cause them to seek another exchange which doesn't charge them. Trading bots execute thousands of such actions per day in the busiest exchanges.

You never want to charge any fees on users at any time. But users include normal users as well as DDoS attackers

How can you prevent DDos without charging any costs on them in DEX? It's impossible unless you verify users' identity.

I think my previous suggestion can work. Users end up with no fee costs because you can refund the fees to them (or can additionally distribute collected fees from attackers).

Or, alternatively, you can use whitelist feature with some basic identification as like centralized exchanges.

141
General Discussion / Re: poll for the percent based transfer fee
« on: January 21, 2016, 04:51:45 pm »
Quick report:

New analysis confirms me minimum fee does not change a lot, consisting with previous conclusion. So 1 BTS makes sense.
And I found 0.2% is an efficient fee level.

To reach the same level of the actually collected fee, we can choose 100 BTS maximum.
50 BTS maximum generates about 60%, and 20 BTS maximum 30%.

Based on this, I could choose 0.2%/1/50, much closer to bitcrab's suggestion.

142
General Discussion / Re: poll for the percent based transfer fee
« on: January 21, 2016, 04:24:10 pm »
OOPS... I made a great mistake and should re-run my analysis. Sorry for this guy. I will do this ASAP.

143
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.

All that happens then is users are forced to move away from this exchange to another one which doesn't charge them fees (for creation/change); therein the DDOS attack succeeds. Motivation for the attack in this case is clear: competitors.

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?

144
The killer problem with this idea is DDOS. This is a major problem for real exchanges and actually gets worse for exchanges thinking of decentralising to bitshares transparently.

Fees are the issue. Creating/changing an order has an associated cost. Exchanges are forced to swallow this cost, or attempt to offset it by charging more for fills, but this does not mitigate the DDOS problem.

A motivated attacker can easily game this system by creating/modifying orders using a bot over and over until it triggers whatever mechanism the exchange has to prevent it. If the attacker uses enough accounts to mount this attack it becomes very difficult to repel, and will effectively DDOS the entire exchange.

Fee issue can be abated by reducing order creation fee (say to 1 BTS) and set a minimum order amount (e.g. under 0.2% fee, 500 (1 BTS / 0.2%) BTS worth).

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.

145
General Discussion / Re: poll for the percent based transfer fee
« on: January 21, 2016, 08:51:41 am »
Thanks for your hard work @clayop .
One more thing need to be considered add into analysis: If we apply % fee to an asset, hopefully quantity of micro payments in that asset will increase, and perhaps quantity of big payments will decrease. If we make an estimation for example apply *5 to the former and 1/3 to the latter(depends on the parameters change), how will the result change?

//For example, 30BTS is unacceptable for most of tipping UIAs, so there are very few tips in the historical data. If we set the fee to 1BTS, perhaps tipping would get much more active.

I will do it when I have time. But I think big transfers won't decrease much, because they are real demands. On the other hand, we can expect more micro-transactions, but I cannot guess the number because if some services using micro-payment (e.g. messaging / telecommunications) are really successful, they can increase the number dramatically. Assuming 10,000 messages are sent a day, the total fee goes up from 600k to 1.1mil BTS.
Yes, you got my idea definitely. That's why we tried to design a percentage based fee structure.
Charge a little more on real demands, charge less on small payments to attract more uses.
+5%
With your development, we will be able to have decentralized message app with instant smartcoin tipping features ;)

146
General Discussion / Re: poll for the percent based transfer fee
« on: January 21, 2016, 08:29:34 am »
Thanks for your hard work @clayop .
One more thing need to be considered add into analysis: If we apply % fee to an asset, hopefully quantity of micro payments in that asset will increase, and perhaps quantity of big payments will decrease. If we make an estimation for example apply *5 to the former and 1/3 to the latter(depends on the parameters change), how will the result change?

//For example, 30BTS is unacceptable for most of tipping UIAs, so there are very few tips in the historical data. If we set the fee to 1BTS, perhaps tipping would get much more active.

I will do it when I have time. But I think big transfers won't decrease much, because they are real demands. On the other hand, we can expect more micro-transactions, but I cannot guess the number because if some services using micro-payment (e.g. messaging / telecommunications) are really successful, they can increase the number dramatically. Assuming 10,000 messages are sent a day, the total fee goes up from 600k to 1.1mil BTS.

147
General Discussion / Re: poll for the percent based transfer fee
« on: January 21, 2016, 06:52:41 am »
OK, here'are some summaries of analysis.

1. Minimum fee does not significantly influence total fee. Given 1% and 300 max (as suggested by jakub), min fee change from 1 to 6 only increases 1.8% of total fee. So I easily conclude that minimum fee is not that important, and lower minimum fee is more preferable to encourage micro-transactions. However, the minimum fee should be efficient to prevent spam. Therefore, I fixed the minimum fee to 1 BTS.

2. Given 1 BTS minimum, I tested scenarios proposed by bitcrab and jakub (0.1%/20 and 1%/300). Bitcrab's was 137k BTS fee in total while Jakub's is 1,830k BTS. I think the former is too small compared to transfer fees collected with 30 BTS flat fee. (137k vs. 13,212k, roughly 1%). While, the latter is 14%.

3. I tried to find a way to have the same level of fee as actually collected. But all scenarios are less then the 13mil BTS. So I conclude that it is impossible to have equal amount of fee under percentage-based fee system.

4. I checked how many txs are supposed to pay more (over 30 BTS) under 1% fee. It is found that 45% (7317/16243) of all transfers are affected implying more burdens in general. However, the rate decreases to 30% with 0.1% fee, and 25% with 0.05%. Meanwhile, 55% of transfers are benefited with 1% fee system, 69% with 0.1%, and 75% with 0.05%. The ratio of minimum-fee-paying transfers are 37%, 50%, 53% respectively (under 1%/0.1%/0.05% fee system).

These are my findings so far, and the followings are my opinions and suggestions.

1. I tried to have 5% of total fee actually collected. That is around 600k BTS.

2. I compared two fee rates, 0.1% and 0.05%. With 0.1%, 150 BTS maximum has 593k BTS fee. With 0.05%, 300 BTS maximum has 615k BTS fee.

3. I think lower percentage+high maximum is preferred to higher percentage+low maximum, because it is easy to justify "the bigger, the more". Given 0.05%/300, transfers over 600k BTS ($1800) pay the maximum fee of 300 BTS ($1).

So my suggestion is 0.05%/1/300. If you want to analyze by yourself, https://cryptofresh.com/bts_tx_history.csv will be the starting point (Thanks Roadscape).


Something I made wrong significantly. (didn't remove non-BTS). I will make it again soon.

148
General Discussion / Re: 10k of bitUSD just got destroyed for no reason
« on: January 21, 2016, 01:37:20 am »
It settles $10k short positions from the bottom collateral level. Buy orders never be matched.

Well there is no reason it shouldn't it shouldn't take any buy ordrers  that are above the feed price first is there?

As far as I saw, there were no orders over the feed price when he settled bitUSD.

my order price of 322 is still there and you can see on the blockchain that it was there at 12:56 when the feed price was lower

He settled about 24h ago.

He requested settlement 24hrs ago yes but the settlement occurred an hour ago. look at his account it says order filled at 321

You may misunderstand about settlement. It has no relationship with buy orders.

I understand settlement well.
His order to force settle was filled at 23:56 24hrs after he requested settlement.

It is equivalent to a bts buy order which you know will execute in 24hrs at feed price with guaranteed liquidity.

It buys BTS collateral of lowest shorts, not BTS on the orderbook.

149
General Discussion / Re: 10k of bitUSD just got destroyed for no reason
« on: January 21, 2016, 01:16:58 am »
It settles $10k short positions from the bottom collateral level. Buy orders never be matched.

Well there is no reason it shouldn't it shouldn't take any buy ordrers  that are above the feed price first is there?

As far as I saw, there were no orders over the feed price when he settled bitUSD.

my order price of 322 is still there and you can see on the blockchain that it was there at 12:56 when the feed price was lower

He settled about 24h ago.

He requested settlement 24hrs ago yes but the settlement occurred an hour ago. look at his account it says order filled at 321

You may misunderstand about settlement. It has no relationship with buy orders.

150
General Discussion / Re: 10k of bitUSD just got destroyed for no reason
« on: January 21, 2016, 12:48:54 am »
It settles $10k short positions from the bottom collateral level. Buy orders never be matched.

Well there is no reason it shouldn't it shouldn't take any buy ordrers  that are above the feed price first is there?

As far as I saw, there were no orders over the feed price when he settled bitUSD.

my order price of 322 is still there and you can see on the blockchain that it was there at 12:56 when the feed price was lower

He settled about 24h ago.

Pages: 1 ... 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 ... 136