Trust-less liquidity pool

[mhps]

mhps
any coin sent to the deposite address will be used in the pool

This sounds more like a more public version of the Nu Lagoon, since the pool operator has the private keys and could run away with the coins.

I don’t quite understand. The fund is in client users’ accounts. How can the server operator take it? Do you mean by manipulating the orders and transfer users’ fund to the operator’s exchange account?

[creon]

Can you make a website that has 1) a newly generated deposit address, 2) an input box for an nubits address, and 3) a button. If one provides a receiving address to the input box and press the button, any coin sent to the deposite address will be used in the pool to support peg, for a month, and after a month the funds will come back to the reveiving address plus reward.

This thread got long, it was about this idea, right? Maybe I am understanding this wrong, but the users would send coins to an address which is owned by the pool and then used for liquidity, is that right?

[creon]

I ve tried Nubot instead of none (=Pybot) but it did not place any orders.

Almost didn’t read this. Yes, @mhps pointed me already to this problem and it seems to be fixed, along many many other things, so big thanks to @mhps. I will monitor his client a little bit more and if everything works fine then I’ll make a new release with all these fixes. If you’re using the github then you can just pull.

EDIT: release 0.13 on github, which contains all above mentioned fixes

[mhps]

to an address which is owned by the pool and then used for liquidity, is that right?

Right. Have to think about it. multisig address maybe? Actually even the user has contol to the keys the pool op can still dump users fund to self’s account by manipulating orders (e.g. selling all users nbt to self for 1 PPC when nbt/ppc liquidity is low). So fundamentally sending the coins to the pool’s address isn’t much worse than trusting any liquidity pool at all. (unless the pool can only excute pre-set valid trading).
Maybe this should go to anther thread.

[creon]

Well of course an extremely simplified version of the liquidity pool would be to provide the pool operator with BOTH API keys (i.e. key AND secret), and let him operator the bot on the pool. On most exchanges the bot operator would not be able to withdraw coins with these keys, but place arbitrary orders (not necessarily in Nu markets). This would allow for exactly would you say:

e.g. selling all users nbt to self for 1 PPC when nbt/ppc liquidity is low

So it is certainly not trust-less. Also, from the other perspective, the honest pool operator will have a hard time to explain to the customers why the bot placed which order at a particular time, creating a loss in the user’s total funds. Not even talking about the possible legal consequences.

So I would personally prefer making a deal with an (unknown) pool operator using this given pool method, since I am in full control of my funds and the only thing that may happen is that I won’t get a payout (which can also happen in the semi-trusted way). Note that you don’t even have to trust the trading bot - set the bot to none and place your orders by hand in the correct price range and you will get your reward.

[mhps]

Note that you don’t even have to trust the trading bot - set the bot to none and place your orders by hand in the correct price range and you will get your reward.

The original idea was to provide an extremely simple interface to let everyone contribute to liquidity provision, so letting them run a bot or adjust order is out of the question. There will be risk. I think if trying is simple and the risk is less than the reward people will do it.

[Joe]

I finally had free time to set up the pool. It went so smooth I thought I must have done something wrong!. Very impressive work.

[Joe]

I got a few errors but it seems to have recovered.

[cryptog]

No! Cryptography allows the user proof to the server that the orders are placed without giving it access to the funds. The data sent to the server only allows to view the current order status.

My understanding is that the private key is used to sign the orders requests by the client.
Then the server gets those requests and verify that they are produced by the client that claims to have sent them by using its public key.
If this is correct, that implies that the server is not able to see the private key part in users.data?
But how do you prove that?

[woolly_sammoth]

You’re right that in this pool implementation, the server never gets to see the “secret” api key for an exchange. That means that only the client can sign the requests to place orders or move funds. The server just verifies that the submitted order placement came from the claiming client.
Proving that is a different matter. It’s in the code for the client and server but ideally there will be a way of proving the knowledge of the server without having to code review each release. One to think about certainly.

@creon mentioned previously that I’ve been creating a graphical interface for the client software. That work is still ongoing as i’d like to display the updating server/account statistics as the client runs.
The configuration and running of the client works well though (although only on the same machine as the UI code currently.)
If anyone wants to take a look, the repository is here: https://github.com/inuitwallet/plunge
It needs a few things to be installed to work properly. Once it’s a bit more ready, I’ll get it packaged as a standalone executable.

[Joe]

If you ever feel inspired it would be cool to see a chart with the number of users + luiquidiy info over time.

[creon]

I finally had free time to set up the pool.

Thank you so much. the server doesn’t seem to be as responsive from your location. But in general it is looking quite good.

If this is correct, that implies that the server is not able to see the private key part in users.data?

Right it is the same technology that you are using in your data feed to prove that you own the address attached to it.

But how do you prove that?

The continuous development over the last weeks made proving this harder than it should because in my client implementation people would need to reed about 500 lines of code in order to verify that at no point the private key is revealed to the server.

However, writing “a working client” (that is able to connect to the server), which only contains the very basic functionality, would require less than 100 lines of codes to verify.

If you ever feel inspired it would be cool to see a chart with the number of users + luiquidiy info over time.

I’ll preparing some visual data from the beta data and of course I will publish it.

[Joe]

I still get quite a few errors after observing overnight.

ERROR: liquidity: socket error (111), retrying in 15 seconds …
ERROR: submit: socket error (111)
ERROR: unable to receive balance for unit nbt on exchange poloniex: exception caught: urlopen error [Errno 111] Connection refused
ERROR: /price/btc: socket error (111), retrying in 15 seconds …
ERROR: /E4ZX1-3R7CS-2JEC3-HBRK: socket error (111), retrying in 15 seconds …
ERROR: unable to receive statistics for user EXZX1-3RNAS-2J173-HBR2VK: socket error (111)
ERROR: /DF4055-AB2-4E1-7CE-89763986A: socket error (111), retrying in 15 seconds …
ERROR: unable to receive statistics for user DF4955-A92-4E1-97E-897686A: socket error (111)

It eventually stopped working at some point. I suspect my internet may be the cause but any insight from @creon will certainly help

[creon]

I made a little server upgrade which should help to avoid the issue some people have that a single reject appears quite late in the epoch. This is achieved by using a higher sampling on client side than on server side, and to use those multiple incoming requests per validation in chronological order. This provides the server with more candidates and increases the likelihood of making a successful validation.

The old client is compatible, but I still strongly advice to update to the most recent client version to benefit from the performance tweaks.

Of course I had to restart the server to let the update take effect, so all balances were reset to 0.0. I sent 0.3 NBT as redemption to every payout address found in the log file - except to the two people who registered with a BTC address, because this wouldn’t work anyway. Regarding this point it is worth mentioning that the pool operators are free to pay the participants in any currency or good they want - at least the system doesn’t force them to use NuBits. It is just a logical consequence since the grant will also be paid in NBT and my pool will of course pay in NuBits

[creon]

Yes, I made a server upgrade. It wasn’t necessary but I think it was a good idea for user efficiency reasons.

It should automatically reconnect after a while, but it would be nice if you could use the time to update the client, you will probably benefit from the update. The updates also includes a more aggressive behavior if the server is down, such that short down times won’t let the clients wait so long.

Did you receive some NBT? I hope you’re not one of the users who registered with a Bitcoin address.

[Joe]

It’s possible :o I was super tired when I set it up

edit: yep had a btc address derp. (lets just keep this on the dl)

[creon]

Oh please make sure that this is not the case, payout won’t work otherwise. But thank you, this could have lead to a non-functional payout system, so its good that I saw it now

However, if you change the address now, I’m afraid you will also need to make new API keys. The reason is that the server rejects any attempt to overwrite an address, since otherwise people could steal your credits if they know your public key.

[Joe]

very smooth security feature. I’ll generate new keys now

[creon]

Thanks for your effort @assistant tip 1 @Joe

[assistant]

Hi @Joe

You were just sent a tip of 1 NBT by creon

Please send a Private Message to @assistant with the first word ‘register’ to receive the tip and view your details