I expect a model generic enough that requires to be switched very few times a day, versus multiple time a second
Will the algorithm be reviewed here? I think an analysis and trade off study would be helpful.
You bet!
1 Like
@JordanLee This is btw the proposal I have made. [Passed] LPC grant request for supporting NBT/USD on CCEDK
At the present moment this has about 38% support. I believe I need to take the time to respond to a number reservations that have been expressed both here and privately. I will also say more about how it should be implemented, which I think will help people understand mirroring order books won’t be as technically difficult as some think right now. In fact it will greatly simplify multiple LPCs supporting the same pair. So, expect quite a bit more info about this in the coming week.
The plan expressed in this motion is the most important way we can increase NuBit adoption at this stage, in my opinion. I believe NuBits can replace both USD and BTC as intermediate currencies with the plan I have outlined above. What I mean by intermediate currencies is when I someone wants to trade their Blackcoin for Peercoin they cannot do so directly, so they use either USD or BTC as an intermediary: they trade Blackcoin for BTC and then use the BTC to buy Peercoin. In the future (when this motion is passed and implemented), people will want to use NuBits as the intermediate currency because it will offer superior liquidity. That NuBits are stable is another advantage over BTC, as people performing this kind of trade don’t have an interest in speculating on the value of BTC.
3 Likes
I am looking forward for the upcoming technical clarifications.
But before that, personally, I would also like to receive a clarification of what I wrote in post#46 . It basically boils down to :
Do we really want NuBits to be an intermediary coin? Why?
And can be expanded to several subquestions : Is being an intermediary coin part of our strategy to become widely adopted as a stable currency? Is there any sign that being used as an intermediary will drive adoption of NuBits in other contexts?
What are the benefits for shareholders?
Do we have clear signs from the market?
Should we update our whitepaper? Our marketing targets, slogans, and campaigns?
“The world first stable intermediary currency”
Should we change our description of “What can you do with nubits?” ?
I believe that this change - forgetting technical challenges - deserves more attention, and a proper discussion followed by a motion.
I will chip in what I think.
I have been concerned that Nubits is running on fractional reserve and there doesn’t seem to be an obvious or quick solution to it. I do realize that fractional reserve is an effcient way to use capital. The crux is where to draw the line between being so conservative that Nu economy is choked off and being so adventurous that we ended up having a catastrophic loss of the peg.
I don’t know where to draw the line yet but I think I see how to increase the safety margine, to broaden the line into a buffer zone. The trick is to create a demand for nubits such that its users don’t really care whether there is localized or short term doubt of the peg. Such use already exists. Bitcoin fluctuates greatly but people still consider it safe as a medium of exchange because it is often “good enough”. This utility of bitcoin creates a constant demand of it. People don’t rush to the exchanges to cash out bitcoin just because there is a couple of percent drop of BTC/USD. This fraction of bitcoin that is effectively permanently in users hand is what I consider safety margin.
Nubits could have this safety margin, just miles broader. The period of bitcoin’s being considered “good enough”, as mentioned above, is inversely proportional to how stable bitcoin is. If nubits is widely used as a intermediary currency in commerce, then I expect many users will hold onto it regardless where short term price might drift. I will go as far claiming people will use it even the peg will slowly drift away from at strict 1:1. This part of “nubits with velocity” is the coushion of fractional reserve. (I will post an brief review of a paper that discussed money with velocity)
Therefore I see pushing nubits to be an intermediary coin on cryptocurrecny exchanges to be of great strategic importance for Nu’s security.
3 Likes
I agree if it is being under control. The beauty with cryptos is that we are compelled to make everything transparent in order to keep the integrity and the trust into the trustless decentralized system.
So I think having a real time tool that lets shareholders and users know about the quantity of nubits in circulation, the quantity of nubits parked, the reserves and the buy liquidity on every NBT/* pair is very important so that we know to which extent Nu is “leveraged”.
I agree on that. I mean it is just a matter of trust. And the trust can absolutely exist under a fractional regime as long as the degree of the fractional aspect is “reasonable”, I believe.
Look at FIAT money. It is probably highly leveraged but still most people use it all the time.
We need to define and measure what is “reasonable” though.
2 Likes
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