Hi, new small (non-mandatory) client update:
- fixes a bug where not more than 0.5 NBT got placed on a market side
- server message integration
2 Likes
I noticed dividends are sent from different addresses, one of them being BNUpooLx* .
I am not sure if this is on purpose but, here is my thought. If we want to protect pseudonymity, then we should use a different sending address for every TX. Alternatively, if we donât care much, I suggest the same address gets used for transparency, making it easy to reckon TX coming from the pool.
What are your thoughts?
BNupool holding the current funds and thus being the input address is indeed on purpose so we can recognize transactions faster if we do manual payouts, which were needed a couple of times because of server restarts.
Every transaction coming from a different address would mean, that we would have to pay transaction fees for every single outgoing transaction, which is many times more expensive as the current sendmany solution with inputs coming from BNuPool.
Iâm struggling to see how moving the funds from BNuPool to another address would increase pseudonymity as we wouldnât launder the coins and the inputs would be clearly traceable on the blockchain?
In fact it is the addresses other the BNUpooL* that are the error. We didnât enable avatar mode to begin with so after the first payment the change got sent to a change address. That is the other address you see.
1 Like
As woolly already said we actually want everything to come from our custodian address and I think it was always me with my manual emergency payouts who messed this up.
In general I honestly never gave much thought to that. It is extremely easy (and therefore robust and certainly bug free) in python to generate a sendmany call, since you really just create a dict and dump it to json. But making each transaction as a sendtoaddress would be just as easy.
Of course, as willy mentioned, if someone is curious then it wonât be any problem to find out the addresses of other pool participants. Not sure if and how mining pools obfuscate those things (maybe they just spend out of the generated blocks).
1 Like
Small client update:
https://github.com/creon-nu/nu-pool/releases/tag/0.94
The update includes a performance tweak discovered together with @Cybnate. If you are experiencing a low efficiency because of missings, then this update should help a lot.
Hi,
I assume many of you saw an error like this in the past hours: THROTTLED_10_SECOND It is still not 100% clear what it means, but what is sure is that it notifies us that the client is too spammy in those cases. I wrote a little workaround to overcome this issue, and if you have this error then I would recommend to update:
1 Like
I did get the error THROTTLED_10_SECOND.
Upgraded to 0.95. It seems to have been fixed.
Tks!
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.
https://twitter.com/BittrexExchange/status/590272678633738240
â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â?
1 Like
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.
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.
2 Likes
That explains why buy side liquidity has decreased by more than 20k.
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:
Please find the final release of the TLLP software with the updated disclaimer here:
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.
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!
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
5 Likes
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.
5 Likes
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.
2 Likes
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?
- 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
- 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
- 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.
1 Like