Trust-less liquidity pool

[cryptog]

I did get the error THROTTLED_10_SECOND.
Upgraded to 0.95. It seems to have been fixed.
Tks!

[cryptog]

I have bee getting a lot of THROTTLED_10_SECOND showing up even after 0.95 upgrade unfortunately.
Pulled the last update. Still THROTTLED_10_SECOND errors showing up.

[GreatScott]

Bittrex (BittrexExchange)

"We adjusted the throttling on some of the APIs. If your bot was affected, please contact us for developer support."

Can we call this the “NuBits Effect”?

[creon]

Very interesting, I am in contact with the developer support if you want to call it like that but didn’t hear back so far. I assume it is either the getbalance call or the market depth call which gets trottled. They now changed their error message, so it showed up again in our clients. Here is a more generic fix:

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

It also makes the trading bot less aggressive (i.e. it doesn’t check every 15 seconds if an action is required, but every 30 seconds now). This shouldn’t harm you and is nice for Bittrex. The current throttling error won’t show up anymore.

[creon]

Hi, the CCEDK API is down and since I was still initializing them at the start the client it probably happens that you won’t be able to connect to our current server anymore (although its Bittrex). Sorry for that, I bundled all recent tweaks together into a new release which also fixes this and only initializes the selected exchanges:

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

And thanks to @CoinGame for reporting. Please don’t hesitate to PM me when something like this happens, I just didn’t notice it on my own and it was easily fixable.

[cryptog]

Hi, the CCEDK API is down

That explains why buy side liquidity has decreased by more than 20k.

[creon]

Shareholders,

From this day on I will not be attached to any Nu related LPC operation anymore, including TLLP operations.

The code repository will remain available under:

verc/nu-pool

Please find the final release of the TLLP software with the updated disclaimer here:

verc/nu-pool

As stated in the repository I am not responsible for any outcome of future LPC operations that are using my software. You are free to use the software under these conditions. I will make all previous releases unavailable soon. If @willy and @woolly_sammoth want to discontinue the current operation at this point, then I can support them in burning the remaining amount.

Thank you for your understanding.

[masterOfDisaster]

I have to admit that I don’t understand…
I understand what you are saying, but I don’t understand the reasons behind it.

Anyway - thank you for having created nupool!
It’s an impressive piece of software that is running like a charm on my RaspberryPi!

[woolly_sammoth]

I for one would like to continue operation for this run and beyond to supporting multiple exchanges and many more times the liquidity. (I believe @willy feels the same way). I feel that allowing small liquidity providers to join in LPC operations is a massively important step in the development of Nu and the TLLP is a fantastic tool to do just that.

@creon. I understand your concerns around the potential future of Nu, especially around the ability of Nu to function and develop when the attention of the development team is elsewhere. I must admit that I don’t share the concerns to quite the same level and think that we need to be offereing services like the TLLP in order to make Nu as robust as it can be.

I’d like to thank you personally for providing this software and for allowing it to remain open. Its been really great working with you on this project and I’m sorry that your feelings around the current direction of Nu have led you to this decision. I really hope we don’t loose you from Nu entirely. You’d always said that you weren’t really interested in continuing TLLP services indefinitely so I was prepared for this day to come, but to loose your ideas and work from the entire community would be a massive blow.

Thanks

[creon]

I’d like to state that the reasons are because of my personal belief about the outcome of the current events for Nu. I am a developer looking for productive environments, not an investment adviser, so please take this into consideration. I sincerely hope that everything will turn out great for Nu and wish you all the best.

[Cybnate]

At this stage my intention is also to continue with Liquidbits.net as I think @creon left a legacy with his software which is too good to let go to waste. And for that I also like to thank Creon for his contributions to this community. It was always great working with you. I can tell others that I spend many (for Creon mostly nightly) hours testing and discussing the software. I’m sure he did the same with the NuPool team on the early developments.

Regarding your concerns with the direction of Nu I’m in the same boat as WoollySammoth mentions above, I share some of your concerns but not to the same extend. I understand your position and your rational analyses of the situation. Let me say this, many people in this world are not always rational and rely on trusts and believes and want to be guided more or less. It is one of the reasons people play Lotto (against all odds) and belief in Leaders which not necessarily are of benefit or disbenefit for them, but fit in their culture, their beliefs or have proven to be good in the past. Not saying this is good or bad, it is a human factor you have to calculate in.

Going against a community’s beliefs and the trust they have requires a lot of energy. It is not always worth to do so when the outcomes of going either way would not necessarily differ that much, which is my opinion. Apparently you are feeling much stronger about this and therefore I think you made the right decision for yourself. I hope we don’t loose you entirely for Nu as I do think we need contributions from smart rational thinkers going forward to keep the balance healthy.

Anyway wishing you the best and let’s celebrate the legacy Creon left behind by keeping it alive going forward by using the software for the greater benefit of Nu.

[mhps]

Sorry to see you go @creon It was nice working with you. May I ask what you could suggest to the Nu communty on software development?

[creon]

May I ask what you could suggest to the Nu communty on software development?

1. Find someone who can read a PPC codebase (anyone will suffice, since it is better than nobody), pay these persons in NSR and only in NSR, no single NuBit must be printed for that
2. Use the gained centralized development capacity to implement a plugin system into the client, including libraries and wrappers that allow it so easily and independently develop interfaces for centralized custodian services
3. Develop a motion with payment processor interfaces or other plugins as suggested by you in your post. Assign a minimal and maximal value of NBT to each of these interface proposals and vote for it to pass. When the motion passes everyone can submit a code solution to the plugin at any time by applying for the corresponding NBT grant, where the promised compensation rises weekly from the minimal up to the maximal value to increase the incentive.

This would have been one possible transition to a decentralized development effort that is Nu focused. But all this will not happen, since shareholders would neither be willing to create more NSR, nor to find a suitable developer who can do the first step. It furthermore requires continuous attention from the shareholders on this specific project and not to another project.

But this is what I would suggest as development road map for a stable unit. And no, I am certainly not done with the concept, too much efforts have I put into this. Many ideas are floating around, from which several are inspired by Nu and which totally focus on the stable currency / money transmitter aspect.

[Cybnate]

Find someone who can read a PPC codebase (anyone will suffice, since it is better than nobody), pay these persons in NSR and only in NSR, no single NuBit must be printed for that

Practically we should pay them with NBT (in its function as a stable currency) I think, but we should burn an equal amount of NSR at the same time or soon afterwards. I think with the new burning functionality soon to be released this is not an issue. Custodians can take care of that as part of the motion/grant.

Just an off-topic side note on an interesting suggestion.

[creon]

Contractors of the main code repository should have never been paid in money, but only in shares, so its in their own interest that the project succeeds. I see this different with the plugins where people from outside who don’t want to have anything to do with Nu but getting their bounty are still very welcome.

Of course these NBT have to be burned at some point, to make a zero sum. This won’t change until people stay with their money within the Nu ecosystem. You will (in my opinion) see soon that Nu started too early to make use of sell side LPCs when many long hold NBT will be used in the auction.

No more such liabilities! A strict money management on the cost of the shareholders directly (through NSR), not on the pegged unit, and an active participation to realize all this without getting totally ignored will be required. If the current shareholders are willing to suffer, then I think that Nu has all ingredients to provide non-existing tools that are useful today, and not in some potential future.

[JordanLee]

Contractors of the main code repository should have never been paid in money, but only in shares

Nearly all contributors have had equity in the project. However, the problem with paying only in NuShares is that contributors need to pay bills, so they would be forced to sell NSR. Given the current thin trading volume, this would cause the NuShare price to decline considerably. It is better to have investors who intend to hold NuShares provide funds to pay contributors in NuBits.

[creon]

If they need to pay bills, then they also need to sell their NuBits. If they sell their Nubits, then they sell into a custodian. The custodian then at some point needs to pay bills and sells to the next custodian.

Without any natural growth, as right now, this has to end in an NSR grant to burn these NBT again, so there is absolutely no difference. We just shift the same liability into the future.

EDIT: In fact, and I wanted to suggest this for some longer time, I think it could be a useful design property if shares are non-spendable. Shares can only be created through grants or burned for NBT if shareholders offer this possibility. But somehow I think that exchanges would vote against this motion

[mhps]

Find someone who can read a PPC codebase (anyone will suffice, since it is better than nobody), pay these persons in NSR and only in NSR, no single NuBit must be printed for that

Peercoin community members such as mably and kac- have certainly read PPC code. Mably even are trying to re-write the wallet in Go.

Use the gained centralized development capacity to implement a plugin system into the client, including libraries and wrappers that allow it so easily and independently develop interfaces for centralized custodian services

This has been suggested to Peercoin but has gained no traction. Currently anyone who wants to do peripheral development has to read the code. This is great obstacle to Peercoin/Peershares/Nu growth.

Develop a motion with payment processor interfaces or other plugins as suggested by you in your post. Assign a minimal and maximal value of NBT to each of these interface proposals and vote for it to pass. When the motion passes everyone can submit a code solution to the plugin at any time by applying for the corresponding NBT grant, where the promised compensation rises weekly from the minimal up to the maximal value to increase the incentive.

This would have been one possible transition to a decentralized development effort that is Nu focused. But all this will not happen, since shareholders would neither be willing to create more NSR, nor to find a suitable developer who can do the first step. It furthermore requires continuous attention from the shareholders on this specific project and not to another project.

I was secretly hoping you could come up with some running code during your coffee break . As Jordan suggested Nu could buy such code. So I just posted a plan to kick start and cultivate adoption of Nubits among payment processors and exchange gateways.

[Cybnate]

This has been suggested to Peercoin but has gained no traction. Currently anyone who wants to do peripheral development has to read the code. This is great obstacle to Peercoin/Peershares/Nu growth.

We do have Peercoinj and Nubitsj library thanks to Matthew which allows for maintaining a wallet and send/transfer actions. https://github.com/Cybnate/NuBitsj

I think more can be done, but I for one wouldn’t have a clue what is needed in the plugin system besides the already existing libraries and RPC calls in the current wallet.

[mhps]

Peercoinj and Nubitsj library

You are right. “no traction” is not accurate. Very little traction.