NuBits v5.2.0 Release

The Plaza
#1

I released version 5.2.0 to help on exchange issues.

Windows: https://bitbucket.org/JordanLeePeershares/nubit/downloads/nu-5.2.0-win-gitian.zip
Linux: https://bitbucket.org/JordanLeePeershares/nubit/downloads/nu-5.2.0-linux-gitian.zip

The changes are:

When a generated transaction is too big the error message is now explicit.

Added -multitx option. When this option is activated the sendtoaddress and sendmany RPCs will generate multiple transactions if the operation doesn’t fit in a single transaction. In this case the RPCs will return a string with all transaction hashes separated by newlines.

Added the splitshareoutputs RPC to change the way shares are split without restarting the client.

The default value for splitshareoutputs is now 0, so that shares are not split by default anymore. Share splitting should only be activated on nodes that intend to mint for a long period. To activate it on your minting node you can add this to your config file: splitshareoutputs=10000. If you do that it is advised to disable splitting before you send funds to someone else, especially for large amounts, to avoid the extra fees and the problems with transactions being too large.

Added a mergeoutputs RPC. It should be used by users who transact large amounts of NSR that may have been split and would generate too large transactions. The command takes all the unspent outputs of an address and sends them to the same address in a single output. If the transaction is too large it generates multiple transactions (and one output per transaction). If no address is provided to the RPC this process is done for all the addresses that have at least 2 unspent outputs. This RPC may take some time to proceed. Exchanges should run this command on a regular basis.

Added a -stakegen option to enable or disable minting (enabled by default). This is useful for nodes that do not want to mint (full nodes, exchanges, etc.). Without this option turned off the node may use CPU to generate blocks even when it doesn’t have any shares. Put stakegen=0 in your config file to disable minting.

So exchanges should probably use these options:

multitx=1
stakegen=0
splitshareoutputs=0
avatar=0

Minting nodes should use this option:

splitshareoutputs=10000

Nodes without shares should use this option:

stakegen=0

The code changes are here: https://bitbucket.org/JordanLeePeershares/nubit/pull-requests/273/52-stable/commits

sha256sum:

57f1d900e9620bc5f434ac091c80fec639a6275ac825c1a3f4d7e39e1cdf59cb  nu-5.2.0-win-gitian.zip
eeec33f07ea32e34697774faf9f637499562ba6f97858950d3ad56400bde878d  nu-5.2.0-linux-gitian.zip
bc97f13a3d76a2963833d61a1622b74b1886dafc2900fe3f80c61035cb70e5b6  64/Nu-5.2.0-win-setup.exe
e9f36252285a41f4ddb2fe288d380ca2a5731be33d92e9ac32328896e1d2e0ee  64/nu.exe
7949750f5744c354c25946d485169528e8f44ca696d6435d535fe52b67220f88  64/nud.exe
76c5939bdb08ad8c8686d6d8f3dfb57181f658cf7df889fd867decdc4ce668b1  bin/32/nu
a08dd12e6a25ac021162c459abe3e750d78ddb051420f46a9c61896c394c71f4  bin/32/nud
64c729e308d7bc2dd4d2fd94b9bef12c0719978b0f71c01e370aee64e8cdd91c  bin/64/nu
63438bc0ca3a78987ddb83124e5806ebd2296f435c7efcd6d7b9d049a9d81d88  bin/64/nud
6 Likes
Cryptopia delisting NuBits (USNBT) and NuShares (NSR)
Cryptopia delisting NuBits (USNBT) and NuShares (NSR)
Alcurex withdrawals/deposits (working as of Dec 8)
Poloniex withdrawal discussion for NuShares (NSR)
#2

Thank you for this release, @sigmike! I have instructed Alcurex to upgrade, use the four recommended options, add extra nodes, and consider using the mergeoutputs RPC.

2 Likes
#3

macOS build available!

https://nubits.com/wallet
https://github.com/jooize/Nu-macOS/releases/download/v5.2.0/NuBits-5.2.0.dmg

shasum -a 256 NuBits-5.2.0.dmg
487a8c2fd3fde5aab9d472bc943511d87ef5b37e4ad4e7e34b966d92232b963e  NuBits-5.2.0.dmg
1 Like
#4
#5

We should have this added to docs.nubits.com

1 Like
#6

This version still not super stable and still crashes after while.

#7

Just have been shared an experience using the 32-bit version over the 64-bit version. It uses less memory. Maybe making it more stable in the same process. I will give that a go shortly.

3 Likes
#8

Can confirm this works for a node. Save 0.5Gb of memory (from 2.3Gb back to 1.8Gb) If you have a Ubuntu/Debian distro you will need to install mutli-arch to run 32-bits binaries (https://wiki.debian.org/Multiarch/HOWTO). Have fun.

1 Like
#9

Am i on the correct chain?

getblockhash 1563676


093ae2bd2bfb00f99d0d07619d3268cb16dab4db896454cde422efdffd4631a1

#10

Can confirm that with my wallet:
21:38:19 093ae2bd2bfb00f99d0d07619d3268cb16dab4db896454cde422efdffd4631a1

1 Like
#11

tks.

#12

Can someone upload the full blockchain?

#13

We are seeding a recent one here:
magnet:?xt=urn:btih:THYEHOULGZRIO5KHIQD4NHXMXOO5YP2L&dn=Nu.blockchain

#14

Thanks, but that’s not the latest full chain.

#15

It also seems the wallet still have memory leak issues

#17

Tested v5.2 with 16GB of ram with Win7, 8, 10 and the wallet crashes in every instance. Wallet needs fixing badly. Otherwise, the new listing on exchanges will be very short lived like Cryptopia .Again…

#18

I assume this is just an issue with the Windows executable of the v5.2 wallet. The 64 bit Linux binary has been successfully running for me since it’s release (it is the daemon that powers https://nu.crypto-daio.co.uk).
@bitmaster1 have you tested with the Linux wallet at all (I assume you run virtual machines to test with all the Windows versions). If not, do you have some extracts of the debug log to see what the wallet is doing when it crashes?

1 Like
#19

Here’s the exeption: nu-crash-exception

1 Like
#20

EnvShutdown exception: DbEnv::close: Invalid argument (22)

1 Like
#21

I’ve left 5.2.0 running (and minting) for a few days on a 64 bits Windows 7 VM with 8 GB of RAM and it hasn’t crashed yet. The process uses about 3.3 GB (according to the task manager). So it doesn’t look like it’s a windows specific issue because it works fine in this VM.

There must be something else on your setup. How much memory does the process take when it’s loaded? Does it grow significantly? What’s the percentage of physical memory used (visible in the task manager)? Are you running a 64 bits Windows? Do you have other processes taking a lot of memory? What do you usually do with the client? (nothing? minting? sending transactions?)

I don’t think exchanges reported crashes recently.

This “bad alloc” error means it failed to reserve memory. The most common reason is the system is running out of memory. Either because Nu took it all, or something else did. Reporting the memory amounts would help. It may also be because the system restricts processes memory usage in some ways, but I guess you don’t have such a configuration. It may also be because the system is running out of address space (running a 32 bits version on a 64 bits system would limit the process to 4 GB of memory use, and running a 32 bits Windows would limit the whole system to 3.4 GB).

This error could suggest there’s something wrong with your block database or another database. But it’s most likely just a consequence of an earlier memory error.

1 Like