Trust-less liquidity pool

GLock 2015-03-30 03:23:29 UTC #222

I tried again with a fresh clone and the error still there

I have also tried with older versions, just to check that didn’t have to do with my configuration, and I don’t get the bitcoincoid error.

creon 2015-03-30 03:29:29 UTC #223

Yup my fault, I accidentally replaced the method. Please try again. Thanks!

GLock 2015-03-30 03:44:25 UTC #224

fixed! thank you

creon 2015-03-30 03:49:07 UTC #225

Nice! Here the new release for the others: https://github.com/creon-nu/nu-pool/releases/tag/0.37

cryptog 2015-03-30 09:35:17 UTC #226

Right. Tks for the clarification. That makes sense now.
So now - Increasing your minimal interest will never increase your payout, - is verified all the time.

So when I want to decide to participate into the pool, I need to ask myself how much I am willing to expose for what reward.
Let us imagine that I have 1000 NBT.
Depending on the circumstances I would need 5% (average exchange) of minimal reward in order for me to expose them.
Under other circumstances just 1% (a decentralized exchange) might be enough.
Under others (a risky exchange) 30% could be a minimum.

Speaking of my own experience, I find it risky to provide 5000NBT of buy side liquidity on an exchange even for 10% reward.
But I might be willing to provide such a liquidity for say 30% interest rate.
However if I reduce that liquidity to 500NBT, 5% could be fine
100NBT at 2% sounds totally acceptable. Even less.
Right now I get 0.65% on 20NBT or so. I feel it is acceptable.

But then 100NBT is just a portion of my 5000NBT.
That is where comes the pool.
If there are now 50 participants, we get the original 5000NBT.

I am planning to increase my fund to 100NBT when the trustless liquidity pool bot is stable.

I sincerely hope that plenty of users will follow and will be willing to contribute some of their funds.

@creon Once you feel the bot is stable, you should ask for a custodian fund in order to create a Web service with a nice interface.
I believe it would be the catalyst of the highly needed liquidity.

My feeling is that the vast majority of the liquidity will be provided by pools.
Furthermore I feel the trustless version will attract many more contributors than the centralized version for you are allowed to contribute smaller amounts of fund.

creon 2015-03-30 11:34:45 UTC #227

Are you referring to these numbers as daily or monthly interest rates? In the pool all these percentages are daily interest rates, so the 0.65% you are currently getting would actually correspond to about 195% monthly interest rate. I don’t think that shareholders would be willing to pay so much for liquidity, although you could argue that they don’t have much of a choice right now.

cryptog 2015-03-30 12:13:57 UTC #228

The rates I quoted were monthly rates.
I did not realize consciously that the rates produced by the trustless pool were daily rates. 195% montly rate is huge!
Of course right now your pool limits the liquidity size to 50NBT but do you envision a pool that could possibly accept up to say 10k NBT and reward 195% as a monthly rate?

creon 2015-03-30 12:21:52 UTC #229

Of course not, its only to promote it right now. I think shareholders will be ok with about 7.5% - 10% monthly interest rate.

cryptog 2015-03-31 01:46:26 UTC #230

Right

GLock 2015-03-31 03:28:16 UTC #231

hi creon! any plans to increase the 50NBT limit soon?
I know we still in BETA but getting pretty excited about the full potential of your project.

It would be nice if we could start to provide more liquidity to Bitcoin.co.id using your NuPool! they are doing very well and they started to have stellar volumes!

cryptog 2015-03-31 03:34:43 UTC #232

Indeed
–>
Bitcoin Indonesia NBT/BTC $ 11,355 $ 1.00 57.80 %
Poloniex NBT/BTC $ 6,552

Any particular reason for that?

GLock 2015-03-31 03:45:57 UTC #233

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 2015-03-31 09:47:41 UTC #234

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.

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

cryptog 2015-04-01 00:31:12 UTC #235

I see.

[Passed] Trustless Liquidity Pool operation on Bittrex

creon 2015-04-02 01:01:52 UTC #236

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:

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 2015-04-02 05:42:16 UTC #237

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 2015-04-02 22:34:19 UTC #238

Ask and ye shall receive

JordanLee 2015-04-02 23:39:39 UTC #239

@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 2015-04-03 00:19:12 UTC #241

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.

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.

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 2015-04-03 00:46:23 UTC #242

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?