[Passed] Motion to provide seed funding for B&C Exchange - a decentralized exchange built on the Peershares platform

cryptog · July 22, 2015, 11:35am

I have another set of questions about the design of B&C.

In my understanding, a trader that wants to use B&C Exchange will only need to access the Web interface (provided by a server) without having to download any blockchain.

So the following risks still remain:

risk of DDoS of the web site: no access to the web site
–> Any particular envisioned way to minimize that?
hacking of your account: a rogue user could steal your login credentials and steal your money.
–> Would your password be stored in the server or in the browser a la blockchain.info or somewhere else?

In order words, no “money” would be stored by a hot/cold wallet centralized by the service itself but you could still be stolen your account.

Am I correct?

Thank you.

JordanLee · July 22, 2015, 8:55pm

Such websites permit access to the B&C Exchange network, but they will not actually be a part of the network. In order to provide access, such websites will run the B&C Exchange client (either on the same server but ideally a separate one) and allow the web server to access the B&C Exchange client to communicate with the B&C Exchange network. So, even if the DDoS attack is severe and extremely successful, it will have zero effect on the B&C Exchange network, because it will only affect the web server.

Because the website will use only the B&C blockchain as its database, users will not be dependent on the website to access their exchange account. They can use another website or the B&C Exchange client itself.

It is possible to launch a DDoS against B&C Exchange. Such an attack would be extremely lucrative for BlockShare holders, so we can only hope someone is foolish enough to do it. While the fees for B&C Exchange will be determined by shareholders in real time, one BlockCredit per kilobyte might be a reasonable choice. In that case, a DDoS attack will bring revenues of around $1000 per minute.

Login credentials will be nothing more than a BlockCredit private key, which will never be known to the server. It will stay in the browser using javascript, in some ways similar to blockchain.info. It is different from blockchain.info in that they store encrypted private keys on their servers, and there will be no need to do that in our case. Without a backup, blockchain.info users cannot access their Bitcoins if blockchain.info suddenly ceases operations. In contrast, B&C Exchange users will be able to access their exchange account if the website suddenly ceases operations through any other user interface.

It is true that if an attacker gains access to one’s BlockCredit private key they can steal all funds in the exchange account, just like if an attacker gains access to a Bitcoin private key they can steal the Bitcoins.

Raythma · July 23, 2015, 12:14pm

Is there any data about Centralized and decentralized Exchange’s Average No. of daily trades So we can Roughly Calculate B&C’s Profitability?
Unlike Nu, B&C is not the first, and historical data should be used to assist Expected Revenues and Compare it to the Blockshares Current Price, At least as a Marketing move!

mhps · July 23, 2015, 12:47pm

My quick and dirty attempt.

If B&C volume is 1% of today’s total BTC volume ($0.3M, size of bittrex), divendends is $0.2/10k/mo. Reaching 10% (BTC-e) the dividends will be $2/10k/mo. Reaching 30% (Bitfinex) it will be $6.7/10k/mo.

note that 10k bks then is 1 bks now.

Raythma · July 23, 2015, 1:22pm

I did my own Too dirty attempt minute ago depending on JL calculations by assuming that the DDoS attack would need 1000 times the usual network transactions!

and surprisingly it turned out to give the same result as your least expectation

Thanks @mhps , this helps.

masterOfDisaster · July 23, 2015, 2:18pm

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…

tomjoad · July 23, 2015, 3:07pm

That’s a neat idea. B&C Exchange for everyday transactions using a lower m-of-n requirement, and B&C Exchange Premium for whale trading at higher m-of-n (and higher fee) requirements, all packaged together in one web UI. As you mention, an interesting result would be that BKS and BKS-Premium shares would mirror each other in ownership initially (if a 1-1 ratio was held for creation), but would quickly have different owners who place different valuations on each business.

I suspect that if competitors choose to create forks of B&C Exchange, changing the signing requirements and transaction fees will be one way they attempt to differentiate themselves. Your idea above strategically gets in front of a duplication attempt.

masterOfDisaster · July 23, 2015, 3:37pm

Absolutely!
My intention when I thought about a staged fee model was to provide customers with the best offer for their needs while giving BCE the chance to get appropriately paid for its service.
Having market needs/niches filled by BCE casually protects BCE from competitors trying to fill that market niche.

Competitors that fork BCE will already have a hard time being successful without the support of a stable crypto currency like NBT. As it’s unlikely that Nu will support that anytime soon (due to at least 40% of BCE being in the hands of Nu at the beginning) they need to find other support.
1:0 for BCE

Providing a BCE instance with the same basic data as a potential competitor’s will be more convenient for customers already familiar with BCE.
2:0 for BCE

It should lower the attractiveness of copying BCE very much having instances provided by BCE that support the major needs of customers

mhps · July 24, 2015, 1:14am

That is probably true. But B&C could out perform in terms of “fee per transaction”. It makes more on transactions of small amounts than percentage based fee policy. One needs to model to find out which policy is more profitable. The effect could be strong on algo bots which tend to execute a lot of small orders according price actions (guess this will discourage such bahavior therefore spread on B&C might be bigger?)

cryptog · July 24, 2015, 1:25am

By the way, thinking about it, the API of BCE would be simpler than current centralized exchanges.
It would be just running BCE commands, in my interpretation.

masterOfDisaster · July 24, 2015, 6:02am

Creating orders and removing them requires transactions. They cost money (BKC). This will have an effect on the spread (as well as other aspects do, like transaction volume, transaction frequency, etc.).

As both transaction volume and transaction frequency are associated with a price (denominated in BKC), the spread will likely be a depending on the parameters “fee per byte” and “max (single) order size”.

If the result is regarded an issue that requires treatment, it can be addressed seamlessly by adjusting the values of the parameters (BKS holder voting).

Even if the spread did stay bigger than on centralized exchanges, educated customers might regard that as part of the price they’d willingly pay for a more secure exchange - a kind of insurance against exchange default.

mhps · July 24, 2015, 6:31am

Right. I didn’t quite realize this. So the friction of bidding and asking is bigger. Could this hinder adoption and cause the positive feed back effect of volume (exchange with more volume attract more volume) to work against B&C?

Could this also cause Nubits pegs to have bigger spread?

masterOfDisaster · July 24, 2015, 6:43am

If it seriously hinders adoption, make “promotional fees” that are low enough to be attractive. I think it’s important to point that out to customers if the fees are too low to make a sustainable business model based on them. Tell them, it’s “promo time” and the normal level will be somewhat closer to x.
Otherwise it could look shady. On the other hand I’m bot very familiar with marketing

It depends on the trading pair and on the way you look at it
NBT/BKC is expected to have a small spread.
NBT/BTC is expected to have a bigger spread.
Tell me: does that mean the spread for BTC and NBT is bigger or is NBT stable (1 NBT = 1 USD = 1 BKC) and the spread of BTC absorbs the not existing spread of NBT?

cryptog · July 24, 2015, 7:05am

So the BlockCredit private key enables you to basically run RPCs for trading whether directly within the QT client or via a Web interface.
You only need to trust the Web site interface not to get this private key in any circumstances which can be guaranteed if the code that is provided by the Web site server is open.
Are you gonna open it?

masterOfDisaster · July 24, 2015, 7:50am

Opening the source code of such a website or providing reliable and trusted audits to guarantee the proper function (I consider the latter insufficient, but customers will decide…) is up to the owner of the website.

I’m not aware of such a website being part of the development road map of BCE (albeit the design paper might lead to the conclusion that BCE will provide such a website “A web based interface that will be familiar to users of centralized cryptoasset exchanges will be offered.”, page 1, second paragraph).
As there’s no development road map that comes as no surprise that I’m not aware of it

I expect third party providers to provide this service (likely for a fee).

What BCE is going to provide is a client that does the job. This client will be used by website providers.

Foresight:
tech savvy people will want to create their own website to access the blockchain via web interface (e.g. from smartphone). The challenge doing that shouldn’t be very big.

Foremost you need a web site that controls the BCE client via RPC. That’s most of it.
Things like “owncloud” plugins or alike might be created to make this convenient.

Or “RaspBCE” for RaspberryPi. Download image, dd it to the RaPi, power up the RaPi, forward TCP/443 (or whatever) to the RaPi.
Your own private BCE web site is running!
Share it with your friends, install a paywall (require x NBT to be sent an address to receive an access code via OP_RETURN message) for paid access or allow free access for all the world.

DigitalOcean droplets (just a random example for virtual servers), installation packages for Linux distributions, installer for other operating systems, etc. are possible as well.

Via BCE exchange web sites you effectively can create something similar to e.g. blockchain.info, but in an improved version:
Web access to BCE provides BCE with a kind of online wallet capabilities - similar to blockchain.info.
Transactions (e.g. withdraw) can be executed using a web site - similar to blockchain.info.
This requires coins to be available in a multi signature deposit address - assumably better security that at blockchain.info (does blockchain.info support multi signature addresses and if what level?).

You can execute payments with all coins supported by BCE by creating a withdraw (to the payment deposit address) on any BCE exchange web site - that’s way more flexible than at blockchain.info which only supports BTC.
And if you don’t have enough BTC, trade some of your deposited LTC or whatever first - that’s way more flexible than at blockchain.info.

But the major benefit over central wallets is this:
there’s no risk to get your funds seized by taking down a central service or stolen by that central service.
The central server as single point of failure is gone.
All relies on the (distributed) reputed signers which can’t be tracked easily if ever.
If you host your own web site, this is a quite secure way to create this kind of online wallet.

For all who are already ensnared by the beauty of NBT, NuDroid is the more elegant way to do that.
Legions of people who use blockchain.info or similar will find an alternative in BCE.

It will be necessary to verify the integrity of all those ways to create a BCE web interface with a few clicks or command lines.
Educated BCE users should be aware of associated risks and use the BCE native client when handling big amounts,

Convenient ways to access BCE (via web access) will be created if BCE is successful!

Much of the above is dreaming, but I bet some of it will come true.

mhps · July 24, 2015, 1:56pm

Suppose my wallet had an NSR address with some balance when the B&C snapshot was taken. Then I transfer the balance to a new address and the old address is empty. What happens if I import that wallet from B&C wallet? Will the import process find the empty address in my NSR wallet and credit me BKS by the snapshot amount?

cryptog · July 24, 2015, 2:13pm

I think so since it all depends on the amount at a certain point in time.

masterOfDisaster · July 24, 2015, 2:55pm

The balance on an NSR address at snapshot time is what counts. That amount gets converted to an amount of BKS by importing that NSR wallet into the BCE client.
This is the way I understand that process and the meaning of the snapshot that was taken.

JordanLee · July 24, 2015, 6:36pm

cryptog and masterOfDisaster are correct. It doesn’t matter what happens to the NSR balance after 3 July. While the initial plan was to fork the Nu blockchain and use an exact copy of it, sigmike and erasmospunk had a better idea. We created enough BlockShares to distribute to everyone and then used a modified version of the Nu client to distribute BlockShares to NuShare holders as dividends using the dividend distribution system. Instead of Peercoins, BlockShares were distributed.

This has an important implication that has been generally overlooked. The B&C blockchain had all the NSR balances (except for undistributed NSR specifically excluded). However, the Nu blockchain is hundreds of megabytes while the B&C blockchain was around one megabyte. We have proven that we can transfer the balances of a production blockchain into another production blockchain (OK, release candidate for now) with a dramatically smaller size. We can truncate production blockchains while preserving all balances. The transaction history is lost from the new blockchain, but the full history still exists in the old blockchain. I expect in the future we will use a variation of this demonstrated technique to allow normal shareholders that just want to verify new transactions and vote to use a truncated blockchain while those that want the full transaction history (such as blockchain explorer hosts) will continue to use the full blockchain. The bottom line is that our solution is very scalable in terms of hard disk space. It is also quite scalable in other ways with modest additional changes.

desrever · July 25, 2015, 8:06am

As soon as I read the design document this was my first concern, and we discussed it at length. Excluding algo/bot-trading or discouraging it will also cause liquidity to be drastically reduced (generally this is the HFT-fanboy-argument) . I am not sure what is the figure we are talking about but I imagine somewhere around 60%?

And then comes nubot : it will be also needed to keep liquidity and track prices for Nu .

Imagine NuBot working on a NBT/BTC pair, with parametric order book ok and BTC volatility high enough . The bot would need to cancel all orders and replace them at new price, probably tens of times per hour to track the price of 1$ in BTC reliably. That means a figure of 100-300 orders per hour which the bot operator must pay for.

There are many possible solutions each one with their pros and cons :

Bot operators should ask for a BlockCredits grant to operate the bot
the fee could be waived for bot operators ( by Shareholders voting for certain public addresses, or by implementing some sort of authentication mechanism )
Or, what I proposed : 1) build solid datafeeds that track BTC/USD 2) B&C accepts a new type of order, where instead of specifying the price, you specify the URI of the datafeed. 3)the matching engine of the exchange needs to constantly fetch the price from the feed. We get optimal price tracking and no need for bot operators to enter new orders all the time. However I acknowledge that building a reliable data feed is non-trivial.
< your solution goes here>

thoughts?