The calculations seem to be valid considering on the assumptions they are based on.
One difference between traditional (centralized) exchanges and BCE is the fee model.
At traditional exchanges you pay a fee for a successful transaction (buy/sell), but nothing for placing or deleting orders.
Thatās different at BCE, because each transaction has a size and requires a fee.
So BCE is foremost interesting for buying and selling big amounts (values) of coins. Itās interesting because the security of BCE is higher than that of centralized exchanges and the fee is not per transaction (value of transaction) amount, but per transaction volume (transaction size in the blockchain).
For that reason I expect BCE to āunderperformā in terms of āfee per transaction volume (USD)ā compared to the exchanges we know.
It will be hard to change that. Raising the fees would be an obvious measure to adjust this, but if BCE really wants to be decentralized, it should not offer a decentralized trading place for whales, but for all people.
Thatās the reason why the fee per byte should only be raised to a certain level.
Iād very much like to see a layered fee model where customers can choose the security level by choosing different m-of-n multi signature options that can have different fees per byte.
That way you could keep BCE affordable for people trading comparably small amounts while requesting a disproportionately higher fee for big (USD volume) transactions (disproportionately, because more signatures already lead to bigger transaction sizes).
Now Iām far from understanding the inner working of BCE and Iām not sure whether the details are already designed.
So far I only know about multi signature related to deposit addresses. I donāt know how order transactions will be designed.
By current BCE design (page 3) only one level of multi signature will be voted on by the shareholders
So the only way to steer the āfee per traded USD valueā is to make use of another vote that is in the design
If you limit the maximum trade size you effectively have a kind of āfee per traded USD volumeā
My idea regarding different fee levels might make things overly complicated (or impossible at all).
Following the Unix philosophy (and I recognize the Peershares design follow that very successful philosophy) it might be better to create another fork (or forks) of BCE with a different set of āmulti signature / maximum trade sizeā settings. Maybe I should call that instance instead of fork.
Technically it would be a fork, but from customer perspective it might be an instance, still BCE, but with a different flavor.
Transferring coins between different BCE instances would only be a matter of transferring them between āaccountsā as the UTXO from the multi signature addresses would only be sent to a different multi signature address (on another BCE instance) in a combination of a withdraw (from one BCE instance) and a deposit (on another BCE instance).
Even 0-confirmation transactions between BCE instances might be possible, because either one or the other multi signature address would be in control of the coins. That would require to identify the deposit address as a BCE multi signature address (not sure whether and if how that is possible).
As long as the protocol for different BCE instances stays the same, the development efforts should not be much higher compared to one BCE instance.
Economically the different instances would need to be treated as different corporations, different entities with independent ownership.
Initially the shareholders would be identical. And even if that changes over time thereās a big incentive for shareholders not to hard fork from (the) other BCE instance(s) and follow the development of the main dev team.
I want to voice idea that early - it might be included in development decisions; just in case that sounds usefulā¦