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.
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.
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?
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?
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?
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.
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?
I think so since it all depends on the amount at a certain point in time.
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.
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.
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?
Has anyone compiled a r-pi 2 version of the gui less bcexchanged yet? Itās stake time
Nope. Had trouble trying it, but so far no help fixing the issues.
In my spare time (of which there isnāt much at the moment) Iāve been experimenting with using Docker to create an ARM build environment that can be run on a normal (x64) computer.
I have this so far https://github.com/inuitwallet/Docker-ARM-NuBits-client-build
It starts the build process but normally fails a part way through so needs a bit more work. Itās just for the NuBits client currently but could easily be ported to B&C once itās working.
If anyone knows Docker and wants to take a look, feel free. I think itās just missing a dependency but Iām not sure which. Iāll run it again in a bit and get the actual error message the make
fails with
Sorted by views, the [ANN] thread at the bitcointalk.org āProject Developmentā board is in the top 25 (current place: 23) of all ever announced/discussed projects (more than 7,000 in this board):
Total number of views: 50,050
Total number of posts: 487
(bitcointalk.org time: July 29, 2015, 12:16:46 PM)
Thatās impressive!
For those who want to generate their own set of B&C keys, I base58 decoded a set in advance:
private key prefix: 0x99
public key prefix: 0x12
After initial problems to build a bcexchanged on my RaPi2 I tried again.
Hereās a dcoumentation of my steps:
sudo apt-get update
sudo apt-get install libcurl4-openssl-dev #libcurl is required to build from the source, although not stated in doc/build.txt; make sure to have all other dependencies installed
mkdir ~/bce
cd ~/bce
wget https://bitbucket.org/JordanLeePeershares/bcexchange/get/e472f471107c.zip
unzip e472f471107c.zip
cd ~/bce/JordanLeePeershares-bcexchange-e472f471107c/src
sed -i 's/USE_UPNP:=0/USE_UPNP:=-/' makefile.unix #disables UPNP; I don't have the dependencies installed and don't need UPNP
make -f makefile.unix
Et voila, bcexchanged ready after some time (thanks to the RaPi2 being fast as hell compared to the RaPi1 )
Tried starting it and it worked
bcexchanged --daemon
B&C Exchange server starting
Error: To use the "-daemon" option, you must set a rpcpassword in the configuration file:
/home/pi/.bcexchange/bcexchange.conf
It is recommended you use the following random password:
rpcuser=nurpc
rpcpassword=bVCSDYtSZyo9SNIw31O10bRa47Y9c8qO8mJT4N0cJSQf
Still some Nu left - but hooray, itās working
??
Thatās the output which is generated if you start bcexchanged with the āādaemonā flag
Can someone remind me of the current minting stats?
Minimum coinage?
Minting reward?