Trust-less liquidity pool

[GLock]

Not sure, but Oscar Darmawan and his team promote very well NuBits around the indonesian community, so that could be a factor
<img src="/uploads/default/638/e7b43b424d8f2ae4.jpg" “150” height=“200”>

[creon]

I have to be careful that the payouts don’t explode of course, so I picked a very high interest rate and a very low target. The alternative would be to set a very low interest rate (of around 0.1%) but a much larger target of around 1,000 NBT. I can set this up in a couple of hours.

Any particular reason for that?

I am using a much smaller spread on bitcoin.co.id than whoever is on Poloniex, so I guess this is the reason.

[cryptog]

am using a much smaller spread on bitcoin.co.id than whoever is on Poloniex, so I guess this is the reason.

I see.

[creon]

I made another server update which should provide the clients with a much more stable representation of the current payout. The client also has some final tweaks and if you want you can download it here:

verc/nu-pool

This version is considered as the first release (which is not a pre-release) and all features that were originally announced are implemented on both the client and the server side.

---

I decided to stop the beta at this point. At some days up to 19 keys were connected, and in total about 6 payout addresses were delivered. Up to 470 NBT liquidity per minute was provided on four different exchanges. It was an interesting experiment.

Unfortunately the beta was never really perceived outside the Nu community and the data surely doesn’t serve to make any forecast about public interest. I tried my best to answer every question via PM, email, reddit, and here in the post which already took a lot of effort and a large scale operation will surely only require even more attention from me on this.

Thanks everyone here who participated and who provided feedback and bug reports! The server will stay up, but only pays 0.1% for up to 500 NBT target on each side until the server has no NBT anymore, so if you have fun running the client then feel free to continue.

[cryptog]

The server will stay up, but only pays 0.1% for up to 500 NBT target on each side until the server has no NBT anymore,

I think you should further expand the size of this trust-less liquidity pool.
I think trust-less liquidity pool will be very important for maintaining the peg.
Why don’t you make a custodial grant vote?

PS: typo

[woolly_sammoth]

Ask and ye shall receive

[Passed] Trustless Liquidity Pool operation on Bittrex

We are happy to announce the first full outing of the Trustless Liquidity Pool. After a successful Beta period, during which many iterations were tested, the pool software is ready to provide liquidity for the Nu network. The full proposal can be viewed below. We would like to have the proposal passed before the point at which liquidity provision is started. The main points of the proposal are as follows: Intention to provide 20,000 NBT liquidity on Bittrex 30 day operation Maximum compensat…

[JordanLee]

Unfortunately the beta was never really perceived outside the Nu community and the data surely doesn’t serve to make any forecast about public interest. I tried my best to answer every question via PM, email, reddit, and here in the post which already took a lot of effort and a large scale operation will surely only require even more attention from me on this.

@creon could clarify what factors are causing you to hesitate to expand operations to larger scale production quantities funded by custodial grant? While I only viewed the beta from a distance and may not be aware of some details of how it functioned, I have been eager to see it move forward to production use. Are you hesitating to do that because you are concerned there won’t be enough participation? I think 19 daily participants for the beta is a very strong showing for our small community. You seemed to have expected participation to come from outside the Nu community, but that probably isn’t realistic at this point, nor is it necessary for the pool to be a success. Are you concerned that shareholders might not pass a custodial grant to fund your operation? I would enthusiastically support such a custodial grant and I’m under the impression most other shareholders would too. My guess is the maximum compensation shareholders would give right now is somewhere between 7.5% and 10% per month. You could take whatever proportion of that percent you like, but I think between 25% and 50% would be considered reasonable by most shareholders. Are you concerned that level of compensation would be insufficient for the effort you would need to expend?

Moving this pool forward will bring a lot of value to NuShares, so I’d like to do whatever I can to facilitate that.

Edit: Just after posting this, I noticed this custodial grant to start trustless pool operations. That means my post wasn’t really relevant anymore, so I deleted. I’ve brought it back because of the responses to it.

[creon]

@creon could clarify what factors are causing you to hesitate to expand operations to larger scale production quantities funded by custodial grant?

This is a pilot run. I see many possible points of failure:

• Not enough user participation
• Scalability (see below)
• A critical flaw which I did not see. I guess the only one who tried to trick the system in any way so far was me.
• A bug in the trading bot that will lead to a loss

I am not very much concerned that shareholders will pass a larger grant, but in this operation I want to have a clear exit point - even if something critical happens after one week, we can still burn our grant, and I can go back to development without producing too much damage.

I think 19 daily participants for the beta is a very strong showing for our small community.

19 connected keys, 6 payout addresses including mine, so maximal 5 users. There is no real world data available how much the server is able to handle - just some load balance experiments @willy and I performed but it would be foolish to take this as safe measure.

This is why this grant is designed very carefully. The 10% limit you mentioned was also our threshold and the variable interest concept implemented in the pool furthermore will allow us to determine how much users are willing to get and therefore to have the required data to make a better estimate for the maximal interest in upcoming grants. It is this what this concept is about, finding the real price for liquidity by transforming the custodian competition into user competition.

And I honestly don’t care about any personal profit from this, it was just the (hopefully) right idea in the right situation and I was able to build it so I built it - when Nu is open source then this should be a basic rule for everyone who can develop. Custodial grants are great, but 99% of the software we are using in this field was just developed because it was the right idea in the right situation and someone could do it, Nu itself is no exception.

Moving this pool forward will bring a lot of value to NuShares, so I’d like to do whatever I can to facilitate that.

It hopefully will. Thanks for your support, I think this is very important for the project.

EDIT: Where is your post? Should I delete mine? I’m a bit puzzled. willy saw it too, so I am probably not crazy …

[cryptog]

It seems that jordan lee deleted his post.
I guess he just saw the propopal from @woolly_sammoth that introduces a much greater scale, which is what @JordanLee was talking about in the deleted post.

So it seems that you have delegated the responsibility of the first big pool to @woolly_sammoth but my understanding is that the risks you mentionned remain the same, such as bugs, scalability issues etc… because the source code is the same. Am i right?

[creon]

So it seems that you have delegated the responsibility of the first big pool to @woolly_sammoth

The reason for this is simply that the legal framework in my home country would make it difficult and very expensive to allow me to run such an operation. This would also be true for a bitcoin mining pool for example. @woolly_sammoth is a person where I feel very comfortable to let him run the operation and he doesn’t have these problems. The software is just the same and I will be part of the team.

Note however that neither @woolly_sammoth nor me will be responsible for any damage that will occur. The only part of the software which actually could lead to a loss if it contains a bug is the trading bot. If you look at the NuBot for example, then you will see that it contains a similar disclaimer and you cannot demand anything from the developers when it didn’t do what you wanted. This is common practice in open source projects.

Also note that you are free to disable the trading bot and to place the orders manually or to use any other trading bot implementation you like. If you do that then it is impossible that my software will make you lose money at any time.

EDIT: I should mention that the risk for the shareholders is by design small. Shareholders pay for the amount of liquidity provided, not more and not less. If the pool fails after 3 days and does not provide liquidity anymore, then the remaining NBT of the grant will be burned.

[cryptog]

the legal framework

Wo. I was assuming that you would not need a legal framework but if we want to build a network of Nu liquidity provision operators around the world as Humanity has with regards to bitcoin and its mining, it seems that having a legal status is the right direction to go.

Also note that you are free to disable the trading bot and to place the orders manually or to use any other trading bot implementation you like.

Could you let me know how I can do that? I am not saying that I would want to use something different than PyBot or NuBot but I am just curious.

Generally speaking, that would be great to have some sort of documentation attached to nu-pool code source so that anybody that can run a python script can contribute to the liquidity provision easily.

[creon]

Could you let me know how I can do that?

Run the client with none instead of pybot or nubot in the users.dat and it will just not run a trading bot, but only send order requests.

Without any bot you could open http://104.245.36.10:3333/price/btc in a browser, check the btc price, and then go on the exchange and place an order at this price ± 0.5%. Your client then should provide exactly the same output as if the bot would have placed the order … as long as the price is in the correct range.

Generally speaking, that would be great to have some sort of documentation attached to nu-pool code source so that anybody that can run a python script can contribute to the liquidity provision easily.

Absolutely, I neglected this quite a bit during development. This will be improved.

[cryptog]

Tks a lot for the details.

[cryptog]

By the way, I have not understood yet how the algorithm behaves if I specify no minimal rate…(which is what I am doing right now.)
Would it set my fund always first compared to the other funds?

Furthermore, I suppose that if 2 contributors come up with the same minimal rate, the one that would see its fund put into orders first is the one with the earliest timestamp. Correct?

[mhps]

Just a data point - I haven’t been able to connect to or have the client.py script to work (it just produces no output) for about 10 days for unknown reason. I have tried to run from ISP in China, the US, and France. It is possible a problem from my laptop. But the laptop has had no other internet acccess pproblems.

[creon]

If you remember that ugly post where I introduced the most recent system you remember that there were always two important interest rate levels which are determined based on the liquidity provided and which interest rates were given by the user. From these two interest rate levels, one is larger (high) and one is smaller (low).

Liquidity up to the target will compensated, partly at the high interest rate and partly at the low. Every participant whos interest rate is smaller than high will be compensated according to his or her contribution. Every participant with an interest rate < low will additionally compensated at the lower interest rate according to the contribution.

EDIT: To answer your question more directly: If you provide no interest rates at all, then it takes the pool’s maximum which will then be compensated according to the rule above.

Furthermore, I suppose that if 2 contributors come up with the same minimal rate, the one that would see its fund put into orders first is the one with the earliest timestamp. Correct?

This all is not the case anymore. If the target is 50 and both contributors provide 30 at the exact same interest rate, then each of them will get 30/(30+30) x 50 = 25 NBT compensated.

I haven’t been able to connect to or have the client.py script to work (it just produces no output)

Very interesting. The current server is located in San Francisco, California. Are you able to access the json API via browser? e.g. http://104.245.36.10:3333/status

Otherwise I would appreciate if you could send me your log file. It does not contain your api secret, ideally check for it of course. The client doesn’t print those messages to the terminal anymore for some releases.

EDIT: @mhps, if you can not access the json API link above, can you try to access just http://104.245.36.10/ ? It should show some Apache2 Ubuntu default page. If you can see this, but not the json API link, then this might be a port issue. The final operation will probably run on port 80, such that this problem would be avoided.

[creon]

Hi,

a small update:

• server: reimplementation of credit system
• client: payout per minute in output-
• bitcoincoid: nonce search improved
• many additional small tweaks

I recommend clients to upgrade to the newest version:

https://github.com/creon-nu/nu-pool/releases/tag/0.5

The next step will be integrating Bittrex compatibility. Their API allows for some interesting features which theoretically would allow users to get paid without even being connected to the server.

[cryptog]

If you remember that ugly post where I introduced the most recent system you remember th

You must be talking about: Trust-less liquidity pool

EDIT: To answer your question more directly: If you provide no interest rates at all, then it takes the pool’s maximum which will then be compensated according to the rule above.

So putting no min interest makes you the latest one to be served?
Let us say that the pool offers sell liquidity up to 100NBT at 5% daily interest

A) offers 50NBT at 3% min
B) offers 25NBT at 2% min
C) offers 25NBT at 1% min
D) offers 50NBT with not min.

In that setting, C) will get 2% on 25NBT, B) will get 3% on 25NBT, A) will get 5% on 50NBT and D) will get 0% on 50NBT or is it the other way around, that is to say D) will get 1% on 50NBT ?

[creon]

In total there are 150 NBT with a target of 100 NBT, so 50 of these 100 NBT will be compensated at 5% and 50 will be compensated at 3%. The higher payout level will be served first. Since everyone’s min interest rate is below 5%, also everyone is in the higher payout level, and each one will get:

5% * 50 * x / (50+25+25+50) where x is the offering. So nobody will be served “first”, they all get served at the same time according to their contribution.

The second payout level is 3%. B and C have a intrest rate which is strictly smaller than 3%. Therefore the remaining 50 NBT will be compensated to them at 3%:

3% * 50 * x / (25+25)

So there is no ordering of the users beyond the minimal interest rate ranking. You are getting paid for the fraction of the total liquidity that you are providing.

[cryptog]

Getting this kind of error:

2015/04/07-10:07:48 ERROR: submit: user not found: xxx

2015/04/07-10:08:35 ERROR: unable to receive statistics for user xxx: server response invalid

Sell order successfully placed though.

CTRL + C does not suspend the process any more.