Trust-less liquidity pool

[masterOfDisaster]

Do you imply that ultimately Nu would need to get rid of NBT/BTC ?

I can only speak for myself, but as it has been identified to pose a (financial) risk for liquidity providers to offer NBT/BTC trading pairs, Nu has a financial incentive to phase them out.
With the liquidity providing becoming decentralized and not being provided by shareholders the financial risk is being delegated to the new decentralized liquidity providers.

But indirectly this still poses a financial risk for Nu, there’s just a layer in between. I think so because the liquidity providers either need compensation for the risk (which needs to be paid by a grant) or they will pull walls in case of highly fluctuating markets, bringing the peg in danger.

So it’s in the best interest of Nu to discontinue other pairs than NBT/fiat.
NBT/BTC is still available as long as fiat/BTC is available next to NBT/fiat.
But those who want to trade NBT/BTC then need to take the extra step on own risk.

I can only recommend to stop NBT/BTC as soon as possible.
Currently it’s still needed due to lacking NBT adoption.
Paying for the higher price of offering NBT/BTC (higher compared to NBT/fiat) is paying for advertizing NBT.

[Sentinelrv]

I don’t think @JordanLee sees it this way according to his recent post in the B&C thread…

NuBot will be critical to the success of B&C Exchange, as it will be the method for establishing liquidity on it. The parametric order book feature that is the most important NuBot road map item is extremely important for providing liquidity on B&C Exchange to pairs other than BTC/NBT, such as LTC/NBT, Dogecoin/NBT, NSR/NBT, etc. Also, NuBot will need to be modified to work with B&C Exchange.

He still wants NuBits to be the intermediary currency for crypto. That would imply not removing these types of trading pairs, unless going to fiat only is temporary only until the parametric order book feature is finished by @desrever.

[Cybnate]

Paying for the higher price of offering NBT/BTC (higher compared to NBT/fiat) is paying for advertizing NBT.

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.

[mhps]

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

[masterOfDisaster]

That would imply not removing these types of trading pairs

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

[cryptog]

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.

[crypto_coiner]

The parametric order book feature that is the most important NuBot road map item is extremely important for providing liquidity on B&C Exchange to pairs other than BTC/NBT, such as LTC/NBT, Dogecoin/NBT, NSR/NBT, etc.

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

[Sentinelrv]

What’s the parametric order book?

Modelling a parametric order book

Currently NuBot puts all the available liquidity in a vertical wall, according to the initial design outlined in the whitepaper. The above model worked out to well to prove Nu's capabilities of pegging, but now it is time to move forward. Many new hypothesis emerged around the next direction, and here I am, trying to make a synthesis and put them together into something more concrete. If you haven't done yet, I invite you to read past (long) discussions : one - two - three . The option th…

It’s an intermediate step toward the order book mirroring Jordan wants. Just read desrever’s posts in that thread.

[cryptog]

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.

[Nagalim]

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.

[mhps]

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?

[willy]

Does connecting to the TLLP server use secure (https) connection and if not, is a secure connection needed?

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.

If a hacker breaks into a TLLP server, what information can be collected? Liquidity providers’ IP, liquidity provision history, anything else?

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.

[mhps]

Thanks @willy. So high value IPs can be obtained if someone gains access to the server. It’s not too bad.

[willy]

high value IPs

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.

[woolly_sammoth]

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.

[mhps]

Can you elaborate on that?

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.

[Nagalim]

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.

[mhps]

The server is never given the API secret. The client is the one that puts up buy and sell orders.

I meant the API public key. It is used to identify client on the server side, right?

The client does check the prices independently

Oh I thought the client gets the price from the server.

[Nagalim]

Identify, yes. Control, no.

[mhps]

Identify, yes. Control, no.

Then the server knows which pub key is tied to which IP (and identify high value IPs) ?