I’m also fine with the advertising and continue to pay for that for a while until adoption has some critical mass. When it has its mass the trading with other cryptos doesn’t need to be supported by Shareholders. For now it is just finding the right balance.
I am OK with Nu running NBT/BTC as a convenience for NBT distribution, with limited availability. The custodian is free to pull the wall. NBT/USD should be always available.
Ask yourself this seemingly strange question: Why does no one have to lose money to defend the BTC/USD pair on BTC-e, even “BTC-e USD” is $1 like NBT? The answer is that people can buy and sell BTC-e USD from many places other than BTC-e for $1. You don’t need BTC/USD to prove BTC-e USD is $1.
Vote for the PEGs motion that is coming 
4 Likes
Sorry for the confusion.
Obviously NBT/BTC will be one of the most important trading pairs on B&C for some time.
I was not talking about about removing NBT/crypto pairs.
To be a bit more specific I was thinking about supporting these pairs with liquidity provided by Nu directly or indirectly.
Those pairs will have liquidity provided by traders.
Phasing out NBT/crypto pairs with Nu sponsored liquidity providing will happen due to monetary incentives.
If you (as a liquidity provider) want to provide liquidity on such a pair you have to take the volatility as a financial risk into calculation.
So NBT/crypto will require higher interest rates or the liquidity providers will shift to stable and less risky NBT/fiat pairs.
Ultimately the Nu shareholders decide when and how to phase out NBT/crypto pairs by the grants they will approve. Moving the interest rate of NBT/crypto pairs more and more to the interest rate of NBT/fiat pairs does the trick
2 Likes
This should be probably in another thread but basically I see supporting nbt/btc as a cost of acquisition of users. I do not feel that liquidity provision on this pair is predictably profitable as i tried to explain in the following thread: On the profitability of liquidity provision, unless we accept to increase drastically the lpc commissions.
However this would be in direct contradiction with the vision of jordan lee on b & c since he foresees a drastic reduction of liquidity provision costs enabled by its decentralized aspects.
1 Like
What’s the parametric order book?
Is B&C able to accept fiat pairs?
Would it be profitable for LPC to provide liquidity on B&C? We know that’s far from a given on Nubits pools
It’s an intermediate step toward the order book mirroring Jordan wants. Just read desrever’s posts in that thread.
1 Like
Only 169 nbt in buy side in: {“credits”: 33588, “users”: 11, “validations”: 403064, “liquidity”: [169.49416758000004, 10068.318210430001], “sampling”: 12} …
There should be a mechanism that incentivizes lpcs to transfer their fund onto the buy side.
I really like the maturing order model for this. You have ask side offer a flat rate, like we have now. However, for bid side you make it so the rate builds up over time, eventually reaching a maximum that is higher than the ask side. This gives incentive to find ways to turn your nbt back into bid side without going through the very market you’re trying to support.
There are other tricks we could try, but ultimately automated burning is the only real way to solve this issue.
Does connecting to the TLLP server use secure (https) connection and if not, is a secure connection needed?
If a hacker breaks into a TLLP server, what information can be collected? Liquidity providers’ IP, liquidity provision history, anything else?
Not yet. Could always be a plus… but given the fact, that only your public key is transmitted, I don’t think we are in a rush here.
I can only speak for NuPool here: Due to the design of our server, the IP address is recorded for a short period of time but is not connected to a specific user account. Standard tllp shouldn’t log any IP information afaik.
A log file usually looks like this: pub key, credit (thus: balance), exchange, timestamp. Maybe sampling/missing problems (client->server connection) can be found deeply in the debug logs.
Thanks @willy. So high value IPs can be obtained if someone gains access to the server. It’s not too bad.
Can you elaborate on that?
I don’t want to go into to much detail about our structure, but I will talk to @woolly_sammoth if we still need to keep IP addresses after all.
We do have a server log that has ip addresses but it isn’t generated by the pool software and so can only be tied to an Api public address and payout nbt address by matching timestamps in the server log.
It is worth a thought that we don’t really get any value from this log so it will likely be disabled in future pool runs.
The architecture of the server has had thought put towards security. Each process is run by a standard user and ssh access is only possible with an appropriate private key. All unused ports are blocked and fail2ban monitors for brute force attacks and automatically blocks offending ip addresses.
It’s not fort knox but the attack surface of the server is quite small. An attacker would have to put quite a lot of effort into getting the information off the server and even then, could only associate three prices of pseudo-anonymous information: ip, nbt address and api public key.
If the client sends pub key to the server then the IP can be tied to the pub key. It is possible to find out the balance from payout.
I guess if the hacker takes over the server (or a rogue pool owner for that matter) he could do something easier than breaking the client’s computer behind the IP. For example in the NBT/BTC market when the peg walls are dominating liquidity, the hacker could just removes all buy side BTC and direct all sell side NBT to be placed at 0.000001 BTC where he has a buy order, then direct all buy side BTC to buy NBT at 1BTC where he also has an order. Virtually all clients’ value will be transfered to the hacker’s account. The client software could do sanity check to avoid such drastic scenario but the hacker could still sabotage, e.g. by inserting code to front run the client and steal most coins from the client pretty quickly.
In this sense TLLP isn’t totally trustless unless the client can check the prices independently. (for the NBT/USD market the price could be hardwired)
edit to add: It seems that both the server and the client get the prices independently from third parties. So the server can’t influence the order placing on the client side.
The server is never given the API secret. The client is the one that puts up buy and sell orders.
The only invasive API call by the server is asking for their orders, I think. To really get someone to place arbitrary orders, you’d have to hack the github and get people to pull a tainted copy and run it without reading it.
This is what we mean by ‘trustless’. The pool operator could be completely corrupt, and the user would not feel the pain, only Nu. The client does check the prices independently, from yahoo or coindesk or bitfinex or what have you, dependent on the currency.
I meant the API public key. It is used to identify client on the server side, right?
Oh I thought the client gets the price from the server.
Identify, yes. Control, no.
Then the server knows which pub key is tied to which IP (and identify high value IPs) ?
Sam and Willy would know that better than I.
I’ve just pushed an update to the nu-pool software that should fix the 1 NBT order bug. The issue was that the orders weren’t being cancelled before the new orders were being placed (they were when the limit was being decreased but not when increased). This may cause a slight delay in liquidity being present on the exchange under such conditions, but will mean that the pyBot places one large order using available funds rather than many 1 NBT orders.
Thanks to @masterOfDisaster for providing logs of a bot that was displaying this behavious and apologies that it took so long for me to identify and fix this issue. I have been working hard with external partners on a concpet that could lead to a much greater demand for NuBits (more on that when the time is right). I have some time now to bump the TLLP software up my priority list.
My pseudo-roadmap for the software looks a bit like this:
- Improve the price feed code (EUR feeds have been causing an issue on @Cybnate s pool. It could do with some extra feeds being added as backups)
- Pull all the changes that have been made on the three pools into one repository to allow users to more easily keep track of such changes and only require one peice of software (I will need to co-ordinate with @Nagalim on this to understand what has been done with the NuPond client and how best to integrate it).
- Investigate porting the pool software to payout in NSR rather than NBT in preparation for the NSR grants available in Nu 2.0
- Investigate whether the client can report Tier 2 liquidity available on exchange but not on order to the server.
- Look at the tweaks that are needed in NuBot to integrate more fully with the TLLP software.
Currently the server does have logs detailing the pubkey and the contirbution of thhat account. In a speerate log there are details of the ip addresses used to connect to the server. If a server was compromised, and the attacker was able to gain super user rights, they could tie together which ips are contributing which amounts to the pool. They could then attack the ips and atttempt to gain the api private key which could give them access to the user funds on the exchange. Both Bittrex and Poloniex require that an API key pair is given permission to withdraw funds so, in most cases, the attacker would only be able to place detrimental orders with the funds.
As mentioned, I will look at disabling the logging that logs IP addresses in future pool runs so this small risk will be mitigated further.
6 Likes