FYI : we are building it and it’s high priority. Front end is mostly complete
2 Likes
To say that we want NuBits to be an intermediary currency is probably a redundant statement. The word “currency” is misused quite a bit in our industry so I felt additional clarification was helpful. In reality, all currencies are intermediary currencies. Specifically, currencies are never bought to be used directly. Rather, they are instruments used to solve the coincidence of wants problem. For example, I’m a software developer that would like to sell my labor for food at the grocery. They can’t use my labor so I’m out of luck, unless I use an intermediary currency. I sell my labor for currency and the grocery is happy to take the currency. This is exactly what I am proposing when I say NuBits ought to be the thing people buy when they want to trade Dogecoin for Peercoin. It is an instrument that allows them to solve the problem that most people selling Peercoin don’t want to receive Dogecoin. We aren’t in a position to become a currency to the average grocer at this time. We must gain that position in the cryptoasset trading markets first. So, suggesting that NuBits become an intermediary currency is really just saying it should be a proper currency.
Yes. We have to create that role for NuBits in cryptoasset trading markets first, then we will have the liquidity and credibility we need to drive acceptance in other contexts.
Yes. Bitcoin is an example. Liquidity, infrastructure, services and trust must all be built to see wider adoption. Becoming the currency used in cryptoasset trading is the most practical way to do these things at this stage.
If we achieved the goal of becoming the currency used for cryptoasset trading, it would be difficult to imagine a scenario where the market cap of NuShares would be less than a billion NuBits.
US dollars and BTC are currently being used for this purpose, and it is a big market. It is clear there is a real chance NuBits can penetrate and dominate this market. The reason is that it is a much better currency than the US dollar or BTC. Ever try transferring 50,000 USD from Bitfinex to BTC-e? It takes a long time, funds are subject to freezing and it is expensive. Compared with BTC, we can provide deeper liquidity and stable value, which are valuable attributes in this scenario.
I don’t think so. It isn’t a shift in the vision of what NuBits will become, it is just additional details regarding how it will get there.
12 Likes
Thank you for taking the time to answering my questions. I will welcome the 2015 liquidity challenge with open arms.
4 Likes
As will I. Thank you Jordan for answering these questions. You have a grand vision for NuBits and taking the time to understand the path that lies ahead of us and setting clear achievable goals will only aid in giving us the motivation to carry out this vision.
Here is broad outline of how we can implement the proposed changes to NuBot:
First of all, if the motion passes desrever and I should hire an additional developer for NuBot. Woolly_Sammoth has little time available due to another full time job and other obligations, so I would like to have him continue to implement exchange APIs as he has been doing. Then we will have two other developers. One should work on implementing the transfer of funds between tier 1 and tier 2. The other can be begin working on order book matching code. After the funds flow between tier 1 and tier 2, the flow between tier 2 and tier 3 can be implemented, probably by the same developer that worked on tier 1 and 2.
I will say a little about how order book matching will work. Take the example of the Bter BTC/NBT market, which you will see will be far superior in liquidity to the Bter BTC/USD market. We will make the order books of as many exchanges as possible available on the BTC/NBT Bter market. For instance, Bitfinex, Bitstamp and BTC-e. The Bter BTC/NBT market mirrors the combined order books of Bitfinex, Bitstamp and BTC-e. The entire depth of the order books is not replicated, only the top portion. How big that portion is depends on how much of a risk the double fill exploit proves to be, where orders are simultaneously filled by a bot at Bter and say Bitstamp by someone who is not an LPC.Even if this is employed extensively, the cost can be kept quite small by using a small amount of tier 1 liquidity. Losses could be made up with custodial grants or widened spreads. The merged order book on Bter will have slightly worse pricing in one sense than Bitstamp, Bitfinex and BTC-e. This is because two transaction fees must be included in the spread, one for Bter and one for, say, Bitfinex. I expect we can negotiate fee discounts to minimize the adverse effect of this. There is even a real chance we can be transaction fee free because what we are doing will bring so much volume to exchanges we support. In another sense, our pricing will be better because you will get the best price offered at the three exchanges for the full depth of your order. Let’s look at an example. Say I want to buy 10 BTC. Here are the buy BTC order books, presuming a special, negotiated transaction fee of 0.1% on all exchanges for our LPCs:
Bitstamp
Price, USD, BTC
310, 620, 2
311, 933, 3
313, 1252, 4
315, 630, 2
Bitfinex
Price, USD, BTC
314, 942, 3
316, 632, 2
317, 317, 1
319, 1595, 5
BTC-e
Price, USD, BTC
308, 924, 3
310, 620, 2
312, 624, 2
313, 1252, 4
Bter
Price, NBT, BTC, Mirrored Exchange
308.62, 925.85, 3, BTC-e
310.62, 621.24, 2, Bitstamp
310.62, 621.24, 2, BTC-e
311.62, 934.87, 3, Bitstamp
312.62, 625.25, 2, BTC-e
313.63, 1254.50, 4, Bitstamp
313.63, 1254.50, 4, BTC-e
314.63, 943.88, 3, Bitfinex
315.63, 631.26, 2, Bitstamp
316.63, 633.26, 2, Bitfinex
317.63, 317.63, 1, Bitfinex
319.64, 1598.19, 5, Bitfinex
The cost to purchase 10 BTC at each exchange, including a 0.2% transaction fee the buyer pays is:
Bitstamp: 3126.24 USD
Bitfinex: 3173.33 USD
BTC-e: 3113.21 USD
Bter: 3109.41 NBT
So, you pay less for your cryptoassets if you buy them with NBT instead of USD. And, you don’t have to use Bter. Bitstamp, Bitfinex and BTC-e would each have their own blended BTC/NBT order books as well that offer similar pricing as Bter, if the exchange supports NBT and we support the exchange.
Let’s examine how this works from the liquidity provider custodian perspective. Dan is an LPC mirroring the BTC-e order book. He opens accounts at BTC-e and ideally, all other supported exchanges, which we will say are CCEDK and Bter. Dan deposits an equal amount of funds in BTC-e, Bter and CCEDK. In each case half the deposit is BTC with the other half being USD for BTC-e and NBT for CCEDK and Bter. NuBot places buy and sell walls on CCEDK and Bter to mirror the BTC-e walls on the BTC/USD pair. It updates the CCEDK and Bter walls as the BTC-e wall changes. When one of his orders on either CCEDK or Bter is filled, NuBot executes a comparable market order on BTC-e immediately. Just as is the case now, from time to time these accounts may need to be rebalanced. The question of whether that can be done without losing funds other than transaction fees is complex with many variables. The question should be answered empirically, by tracking the actual costs of rebalancing. Similar issues exist with rebalancing costs now, although some of the variables are different. It is possible that an offset value will need to be used (for example, perhaps the BTC-e account will be repeatedly drained of BTC and it cannot be replenished at cost, on average, so BTC-e liquidity is offered at other exchanges at a 1% higher price than normal). This means NuBot will need to track losses and gains, including for rebalancing. This type of tracking is needed regardless of whether order book mirroring is implemented.
Another LPC mirrors Bitfinex at CCEDK and Bter. He does not need to concern himself with Dan’s orders placed on CCEDK and Bter. Limited, or small, collisions will occur when the BTC sell price at Bitfinex is at or below the BTC-e buy BTC price. Only the top price in combined order book will collide. This is not a problem, and it is self correcting when mirrored orders are placed at BTC-e and Bitfinex. With this design, collisions are actually profitable trades in the sense that custodians get to trade at a price more favourable than the price of the market they are mirroring. This design does not require coordination of LPC walls to prevent collisions, offering significant simplification over the way NuBot currently operates.
Edit: While the above example uses BTC, I expect similar mirroring would be done with other coins, such as Litecoin, Dogecoin, Ripples, etc. While in the example above the goal is to compete against USD, an LTC/NBT market would compete against LTC/USD and LTC/BTC pairs simultaneously by mirroring both types of trading pairs.
4 Likes
Sounds like a kind of automated arbitrage without moving the coins. Given the amounts which are likely involved it requires very well tested and hardened bots. Mistakes or failures will be expensive. But I probably state the obvious. Can I assume we invest in a proper simulation/test environment or will it be small scale testing in production to mitigate these risks?
1 Like
Probably the most practical way to finalize testing will be on a small scale in production, as you suggest. The LPCs will be independent enough of one another that it will be practical to have them on different versions of NuBot.
If you run such bots on NBT/BTC and you see an arbitrage opportunity of BTC/USD between two of the exchanges where you have bots, do you do arbitrage between the two exchanges and level the prices in BTC/USD, or not?
If you don’t, and since you actively maintain the same order book of NBT/BTC on the two exchanges, will you attract arbitrageurs on each of the exchanges to run arbitrage between your NBT/BTC bot and BTC/USD locally, which is cheaper and low risk to do? Aren’t your bots used by these arbitrageurs to move funds between the exchanges for their profits? Won’t your multi-exchange bots end up becoming a multi-exchange price equalizer to all pairs among these exchanges? Since it costs to move funds around, aren’t you footing the bill for such non-trivial trades? Since you are paying for it anyway, won’t you run bots to do arbitrage between exchanges on pairs, such as BTC/USD above, that have a close “affinity” to your NBT/BTC, as well?
2 Likes
Thanks for your reply. Had the time to think a bit more about this and I like to share some concerns.
Having had exposure to high availability software and hardware environments in the distant past, I suggest that we ensure that developers and QA are aware of at least the strategies mentioned here: http://www.embedded.com/design/prototyping-and-development/4024434/Design-Patterns-for-High-Availability
Fault injection, tolerance scenarios, checkpoints and forward error recovery should be standard in their vocabulary.
I emphasize this as I like your proposal to move forward, but also see increased risks removing our software development focus from the blockchain to more classic areas (the bots) without these assurances. The assurances and protections the blockchain offers about logging and transactions are most likely not envisaged in the proposed development. We have already seen that a lot of effort is required to provide transparency and clarity on the current bots workings, reporting and logging. Blockchain technology would provide this natively. This potential weakness of the bots technology, if not addressed properly, might concern shareholders especially when the inevitable faults occur and cannot be played back to learn from.
I would like to see that the design of your proposal would support transparency in logging from day one, ideally based on blockchain technology. Transparency might not need to be real-time publication of transactions but the ability to access secure and irrefutable logs should be available with or without blockchain technology.
Please consider this post as positive feedback and engagement and possibly this has been already thought off and my concerns can be taken away. I see the hiring of another developer in this area as a potential recognition that these risks needs to be mitigated and require additional effort.
4 Likes
Thanks @JordanLee for taking the time to expand on the enhanced liquidity operation with some figures. It has cleared up most of the concerns I had around the reasons for doing so when such a large change to the technical workings of NuBot is required to achieve it.
My remaining concerns are less to do with NuBot itself although they do echo @Cybnate s concerns above.
When working with NuBot, and previously with personal trading bots, the weakest point has always been the APIs of the Exchanges. While they perform admirably 99% of the time, the 1% when they fail (or communication with them fails) is when the market has most movement, which is just when you need them most. I’m less concerned about NuBot instances not being highly available, more the APIs, which are, unfortunately, out of our hands.
Although knowing this to be the case puts us on a good footing, a lot of thought needs to be paid to the best ways of reacting to such an API failure when it could impact the mirroring and overall liquidity provision so badly.
The actual implementation of reading orders, doing a calculation and placing a similar order somewhere else should be fairly straight forward. It’ll take time but the code to interact with the exchanges in that way is already there in NuBot, it’s just the controlling logic that needs a tweak. I’d agree that an extra developer for NuBot would be a good thing. As mentioned, I don’t always have the spare time to devote as I would like due to other commitments.
I do think though that before that, there should be a wider discussion among shareholders around the controlling logic of NuBot and how to react to the various scenarios that have historically played out in the real world. I’m constantly astounded by the level of trading knowledge displayed on this forum and feel that it’s a hugely valuable resource that needs to be tapped for the Nu trading bot.
My other concern is around the number of Custodians we have versus the number of markets we will potentially have to mirror. I’m comfortable with the idea of a single custodian potentially handling the mirroring of an entire exchange on a second, with all the pairs that entails. I’m also comfortable with the idea of a single custodian potentially running multiple instances of NuBot to cope with that. There comes a point though where we hit a natural limit both in terms of what a single custodian should be expected to handle for the return they get and in what a single NuBot instance can handle with mirroring.
I’m not really expecting an answer to this as we will only find out what those limits are by trying out various combinations in the real world and seeing what happens. I write it here as a concern merely because that’s what I started thinking about when I read Jordan’s example. At least it’s now a known unknown!
In conclusion - I’m sold on this idea now. I think this is a logical evolution for liquidity provision to take and, now that my concerns around it have been allayed, I’m excited by the technical challenges it presents. I’m going to crack on with implementing as many APIs as I can find.
6 Likes
Could someone explain how we end up with “using NBT cheaper than using USD”?
I fail to understand the calculations.
In any case, it seems that in the overall vision of @JordanLee, besides monetary policies, developing and maintaining NuBot than can deal with multiple pairs over different exchanges is a crucial element for maintaining the peg, therefore for NuBit.
At the same time, it seems that NuBot would get more and more complex as well over time.
So I agree with @cybnate on the fact that providing max transparency of how NuBot works is of utter importance not only for shareholders but also for users.
It is easy to be tempted by the dark side of greed and try to take advantage of a centralized system that you have control over. Have a look at what has been found out with MtGox. It looks that Mark created fake trades all along, to build up more than 600k bitcoins in his own pocket.
The best way to make NuBot transparent is to put it somewhat on a blockckain-technology, I believe but is it realistically easy to implement? If the answer is yes, what would be the cost to shareholders?
Besides, if this motion passes, by when mirroring is intended to be implemented?
EDIT: I have understood now how the computations are made.
1 Like
I am analysing the proposed approach and taking some time to thinking this through.
We can definitely use an additional developer time for implementing the “move funds across tiers” part while I work on the mirroring part.
It is very interesting reading about all the different point of views and expertise in the community to form a more holistic vision.
This is why I am also interested in reading more about the concerns expressed by @mhps, and also listening to the opinions of more experienced traders ( including @Chronos and @pennybreaker 
) .
While we will do our best to incorporate collective wisdom into the bot, I have a strong feeling that one of the best way to achieve good results in this domain is empirically.
Once again I want to express a wish : while 3-4 persons, including myself, are working on this experiment, I would like to see the rest of the community trying to explore other domains where a digital 1$ currency comes to hand. In case our experiment fails, we should have many other open branches to work on. I invite everybody to read Jordan’s last post about vision and mentally replace “intermediate liquid currency” with some of the many spaces we could attack : crowdfunding, remittance, merchants, crypto-equity, betting … Sorry for sounding redundant .
1 Like
It is definitively one of the huge application domains of NBT, I guess once we have established a deep liquidity across exchanges.
I submitted some proposals to improve NuBot to the developers. I believe there is a lot of room for improvement it will be interesting to see how it evolves.
3 Likes
In the near future, i imagine users charging their NBT virtual wallets by just making an order with their credit cards, There will be also NBT prepaid cards…
I note that even if Nu cannot get a special discount and has only 0.2% instead, it is still cheaper overall to buy cryptoassets with NBT instead of USD.
My opinion is that we should not have liquidity at all in any other pair than NBT/USD. Not even NBT/BTC
Nubits works for USD because both NBT and USD can provide practically unlimited liquidity, and changes in USD price are so small that are more than enough to be covered by the conversion fee.
But when we create walls in a volatile currency like BTC we are exposing ourselves to that currency liquidity, which is, like its price, totally volatile. We are effectively injecting liquidity into other volatile currency, trusting that price is volatile but liquidity is not, which is a big misconception.
Sure, some may argue that bitcoin have, let say, 200k BTC (a ton) in liquidity at current prices at both sides, the bot can rely on that and place walls accordingly.
For example a bot with 1k BTC and 270k NBT: when someone dumps on it 1000 BTC and leave the bot with 2000 BTC / 0 NBT, we assume that we can sell the 1000 BTC back. But then we are relying on the bitcoin liquidity to remain the same. What if the 200k BTC liquidity have been consumed? Then the price moves and the bot lose money. This can happen in any currency without that practically unlimited liquidity. It is happening in PPC, could happen in BTC and any other crypto.
Sure, it works for now, but who wants to rely on something that can be exploited any moment?
So my vote would be to leave only NBT/USD.
But what happens then if someone wants to convert PPC to NBT? The answer is multiple conversion, hopefully operated by an exchange.
This works like this (like a single transaction on the exchange):
- User 1 have 10k PPC and wants nubits. PPC price is 1 USD.
- The exchange locks the user 10k PPC.
- The exchange look at PPC/BTC liquidity which is for example 12k ppc at 0.003. Ok, the exchange can put here 4k PPC and get 12 BTC but the exchange does nothing yet.
- The exchange look at PPC/USD liquidity which is for example 6k ppc at 1 USD. Ok, the exchange can get rid of 6k PPC and get 6k USD but the exchange does nothing yet.
- The exchange look at BTC/USD liquidity which is for example 20k USD at 300 USD. The 12 BTC that we could get on step 3 could be exchanged for 3600 USD.
- 6k USD of step 4 plus 2400 USD of step 5 sum 9600 USD
- The exchange lock orders at 3,4 and 5, execute the conversions, and get the 9600 USD
- 9600 USD go to the NBT/USD pair for 9600 NBT and the user gets 9600 NBT
This can be calculated by the exchange in real time, and show the user how many NBT it would get with his 10k PPC. Using REAL liquidity and getting the price accordingly with both the available prices and liquidity.
Also, NBT would be tradeable between any currency without any risk for any party.
Wait, but if 1 PPC is 1 USD (or 1 NBT) then 10k PPC would have to get 10k NBT. Why am I getting only 9600 NBT?
Because with the current price and liquidity of PPC the real price for selling 10k PPC is 0.96 each PPC! We can’t have a wall in NBT/PPC at 0.96 NBT/PPC because we do not control price and liquidity of the PPC market.
The price for NBT/PPC would completely change for someone selling 1k PPC and for other selling 50K PPC!
This would be adjusted by fees but I am sure you agree they would be insignificant. Also the exchange offering this service should not charge the fee in every step of the conversion, only in the final one, maybe a little higher because of the processing but also insignificant. There is not any risk for the exchange.
6 Likes