Join and earn Bitcoin Cash for participation

Bitcoin ABC vs Bitcoin Unlimited

31 1331
Avatar for Geri
Written by   23
5 months ago (Last updated: 3 months ago)

edit: PLEASE NOTE

Informations in this article became obsolete.
WE RECOMMEND YOU TO RUN BITCOIN UNLIMITED!!!
Bitcoin ABC supports block-tax, however, Bitcoin Unlimited supports the original conception of Bitcoin Cash.

Read the original (obsolete) article:

At christmas, i had some free-time, and i was bored. I ended up testing Bitcoin ABC and Bitcoin Unlimited Cash, to see which node is better. Originally, i decided to continue working on my node software. To be able to do this, i had to download the blockchain, and thats why i had to test a few node software to do so. My node software is basically a program i wrote in C, its not yet able to connect to other nodes, and not able to create transactions. Currently, it can read the files of a full wallet, lists and browses all the blocks, all the transaction inputs and outputs, and it can observe and display some of the content uploaded to the blockchain.

This is the software in action: https://streamable.com/n7ahr

This article, however, is not about my node software. Its not even good for anything yet, there would be no point in shilling it. Basically, the story is: to test my node software, i had to install the official node software of various coins. These official full wallet softwares, which downloaded the blockchain, were required, so i was able to test my software on those files.

First i have tested my node software on the Dogecoin blockchain, and then i have decided to feed the Bitcoin Cash blockchain into it as well. The most two major Bitcoin Cash implementation is the Bitcoin Cash ABC software, and the Bitcoin Cash Unlimited (BUCASH) software.

The configuration of my computer

The computer i used to carry out this experiment, is more than 10 years old. The CPU is a 4 core Athlon2 X4 from 2009 for the Socket AM3 platform. I have 8 GBytes of DDR3 RAM, and an 1,5 TB SATA HDD. The computer has a 64 bit Linux operating system. Probably everything in this computer is at least 10 years old, and in total, it probably worths less than $200. This is a typical desktop PC of nowdays, althrough most people nowdays use i3 chips instead (which is not that much faster than this, so it would no point in updating this computer).

The internet speed is a 30MBit connection with about 2 MBit upload and unlimited traffic. I enabled port forwarding to have inbound connections for the wallet as well.

Experiences with Bitcoin Cash ABC (v0.20.9)

I have never used a Bitcoin Cash node before. I had bad experiences with the Bitcoin Core node in 2017, when syncing the coin was slower than receiving the new blocks, which resulted a growing lag with the network, even if the software was running all the time. Bitcoin Cash ABC was however, syncing very quickly. Just within 48 hours, the software was able to sync the blockchain. On the disk, it consumed about 152 GByte of free space after syncing.

The software worked very well, it (usually) eats betwen half to 1.5 GByte of RAM. It didnt slowed the computer down too much. After the sync was done, my first visit was to the debug panels. Even after allowing the wallet to idle for another extra day, there was no geniune incoming connections. There was incoming connections, such as blockchain explorers, node explorers, a few service running from .cash domains. There was however no incoming connection from other wallet software, such as no ABC or BUCASH was connected to my computer through an inbound connection at all. As these blockchain explorer services were connecting to my computer, its safe to assume that the ip address of my computer was broadcasted through the network, but for some reason, nodes wont try to make an incoming connection, and only use the major nodes.

This is maybe not just an issue with ABC, this is more likely a wide issue of the algorithm that decides how the nodes will connect to each other as a whole. This makes the network vulnerable in the case of a major DDoS attack against the most frequently used nodes, as once they are out, the nodes on the network will not try to connect to actual nodes. This behaviour of the Bitcoin Cash network is different from the behaviour of other cryptocurrency. Such as on the Dogecoin network, after a few days, you have 4-5 incoming connection from other nodes, and if you run the node for several weeks, you will have hundreds of incoming connections from nodes who have learned your IP address.

Stopping and starting the software was quick. Bitcoin Cash ABC needs maybe 10 seconds to start, which is a record short time i have seen among the node softwares so far. After this, i went to play with the wallet, to see if i can find any interesting things. And well, yeah, i found some very intriguing and worrisome.

Bitcoin Cash ABC and deprecated functions

After checking out the commands, i have noticed that they started to remove the sendmany and sendfrom commands. When trying to use these commands, a message appears, warning you for the fact of deprecation. You have to start the wallet in a special mode to be able to use these commands. The nodes usually supported a feature called accounts. This was used by online services. For example, if a webpage had a tipping system, each user ID had its own account in the wallet, and accounts was able to have one or multiple addresses, belonging to that account. This feature is used by various tipbots, and ABC decided to remove it in last month alltogether. Sendfrom, a command that allowed to spend from an account, is gone. Sendmany, that is similar to this in functionality, and allows to spend from accounts and manually selected bitcoin cash addresses, is also partially being deprecated. It is possible to replace sendfrom with sendmany, so this isnt a big problem. Thinking on it, account management should have nothing to do in a core wallet to begin with, but it will need a lot of extra work from the service providers to rewrite the service, if they already used it.

Bitcoin Unlimited Cash 1.7.0 (BUCASH)

Bitcoin Unlimited Cash didnt wasted the time to create a logo, they just qucikly mspainted a splash screen with the Bitcoin Cash logo and some texts, which already indicates that this isnt the software of the decade. After starting to play with the settings, it gave a positive impression: a lot of settings to throttle your output bandwidth, limit the maximum block size (if you are a miner), a lot of extra info in the debug panel, and an additional graph for the network. However, they have also removed certain panels. I tought they even have removed the panel to set the number of verification threads, but they just hid it - in ABC thats the first that appears if you click on options, but in BUCASH, a different menu comes up, and then you must go back to the main settings to find this. You can see various options are removed from the menu.

Left: ABC, right: BUCASH

After syncing a bit, i decided to limit my send bandwith to 128 kbyte per second, and restarted the software. At this point, everything was a downhill. The software, if its already downloaded the blocks, will take almost 5 minute on this computer to start (compared to the 10 second of ABC). When i have restarted the software, i noticed that there is no incoming bandwidth at all, the software stopped syncing, there was only one peer i was able to connect to. I quickly googled a few node IP addresses, and added them to the node list. The software refused to even try connecting to them, after a few minutes, the software stopped syncing.

I deleted every file of BUCASH, decompressed it again, limited the outbound bandwith to 128 kbyte sec, started it, and... one block, and the connection stalled. I have restarted the software again, this time it stalled after 22000 blocks, and refused to restart again, losing all the connection to nodes.

After i have disabled the bandwidth limitation, and restarted the software, it came alive. Basically, the developers totally messed up the code with the bandwidth limitation, probably they have never actually tested it. The send bandwidth limitation limited not just the incoming but outgoing data too, and not just on a per-second manner: once it reached the 128 kbyte, it stopped all network communications FOREVER.

After this, the node started syncing. Even after an hour, it only had 3 connections to the network alltogether (despite of adding loads of node IP addresses). I was checking to the settings to see what is going on. Bitcoin Unlimited Cash has additional panels to observe the network activity, but the another graph was dead, there was no outpot on it whatsoever. They have removed the field which indicates the received and sent bytes on a per-ip basis, so you cant know which peer doing what.

None of the Bitcoin Unlimited Cash special features work

After closely observing, none of the features the BUCASH team has added to the wallet, was working. The bandwith limitation was dead, the graphs and extra output functionality they added were showing only zero and not changing ever. At this point i became less and less excited to run this node on my computer, the software is obviously full of bugs and its a question how this is even made into the public.

Colossal bugs in Bitcoin Unlimited Cash during syncing

After this, i continued the synchronisation aniway, to check what happens. After waiting a few hours, i have noticed my computer locking up, and the HDD were working like crazy. First i toughts its due to reaching larger blocks, which probably put a lot of stress on the disk drive, but then my browser just froze and it didnt became responsible even after a minute. I have pressed control-alt-delete to see whats going on, but the process explorer never came up as well. Shit.

I used the linux quirk for quick console access, which was able to come up after a half minute. I was able to find out using the top command, that Bitcoin Unilimted Cash ate all of the RAM in the system, and it currently tried to swap in and out gigabytes of data to the disk in every second. I tried to close other applications to free up more RAM, but it had no use, i had to quit BUCASH which miraculously was able to close gently.

At this point i decided to restart the computer. After that was done, i restarted BUCASH and continued syncing. After a few minutes, it already ate more than 2 GByte of RAM. After running for another hour, it ate more than 3 GByte of RAM, and after anther half hour, it consumed about 4 GB of RAM, and the responsibility of my system started to dramatically decrease again.

Bitcoin Unlimited Cash will potentionally damage your hardware

Imagine doing the thing above on a machine with an SSD. SSD-s are only capable to have a limited number of write cycles. A typical SSD can only handle a couple TByte of disk writes, and then the cells dying on it. Bitcoin Unlimited Cash can kill your SSD very easily, doing multiple hundred dollars of hardware damage for you just by running it on your computer. And then, maybe even your data is becoming unaccessable forever. I dont really understand why people are running this node for they business. OH wait, i can: it still fully supports the sendfrom command. Despite this, i recommend to avoid using BUCASH, this is the worst node software i ever seen. This node is notorious for crashing at the critical moment of the 2018 november hardfork. These bugs should be present for very long time, probably there was no notable testing for this project for years. Imagine, if the code quality is so bad, what vulnerabilities could be still present in this code?

To sum up

Bitcoin Cash ABC is the only realible Bitcoin Cash implementation. It is fast, consumes betwen half and 2 gbyte of memory (and it will not leak the memory like BUCASH). It runs fine even on an old trashpicked computer, and does not uses a lot of CPU power. Bitcoin Unlimited has serious bugs and risks the integrity of your system. Other node implementations are not yet tested, based on this test, i recommend running the ABC node.

2
$ 18.51
$ 5.00 from @molecular
$ 2.00 from @Read.Cash
+ 12
Avatar for Geri
Written by   23
5 months ago (Last updated: 3 months ago)
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

My gratitude goes to Mr Satoshi for bringing bit coin to existence. It really good and it is a good platform to be.

$ 0.00
4 weeks ago

Would love a review of bchd =)

$ 0.10
3 months ago

Thanks @Geri for taking the time to test Bitcoin Unlimited.

I'm glad you write this post because it let us to trace the issue you had down to a GUI problem in the traffic shaping feature, where if you put in a max bandwidth but leave average blank it assumes the average is zero. We are going to fix it.

If you are still interested to test Bitcoin Unlimited I recommend to use the BU issue page on github (https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc), this is where we look to discover about problems encountered by nodes operators while using BU.

One last point on the traffic shaping issue, in the article you speculate that "[T]he send bandwidth limitation limited not just the incoming but outgoing data too, and not just on a per-second manner: once it reached the 128 kbyte, it stopped all network communications FOREVER". I just want to point out this is not the case and the real issue is due to the fact if "average" upstream is set to 0 you won't be able to send any packets out, not even the one used to request for blocks. This is why you don't see any traffic after awhile, not because you hit the 128KB limit.

In your review you mention "graphs and extra output functionality they added were showing only zero and not changing ever". I guess that in this case you are referring to transaction per second graph that during IBD is always zero because you don't accept txs in the mempool during IBD (see https://imgur.com/a/DmleOY8)

On the other hand you could have a visual idea of the bandwidth used (both upstrean and downstream) by looking at the "network traffic" tab, e.g. https://imgur.com/a/Lpj71oF

On the ram consumption, like @ptschip said already, BU on linux during IBD allocated as much as half your available memory the it set it back to 500MB once your client finished the sync process. If you want it to use less memory you need to set up the amount of RAM you want to allocate for the in-memory UTXO set by using the dbcache parameter.

I've also tried to reproduce the "hang" problem you describe on a low-end machine of mine (old core i3, 8GB ram) by mimicking as best as I could the various thing you have described in this article, unfortunately I wasn't able to have BU hang during IBD. It is still syncing (around July 2016 currently), will report back once/if it finishes. I will be interested in any additional data points on this matter so that I could investigate further.

One last minor point I wonder where you find out the "BU" logo used in this article cause thi s is not the one we use for the splash screen. if you want you can update with the official one you can find here: https://github.com/BitcoinUnlimited/BitcoinUnlimited/blob/release/share/pixmaps/bitcoin256.png

$ 1.55
5 months ago

Thankyou for the response, i am glad that the bandwidth limitation bug will be removed. I will update the logo in the article. When i was syncing, multiple software was also open, as i used my computer, such as a few tabs in chromium, eating about 2.2 gbytes of RAM, and other applications such as libreoffice, pcmanfm and kwrite were also running with documents inside. The total free ram left for the node was about 4 GB of RAM, and the rest was used different applications, as i used my computer.

$ 0.00
5 months ago

Nice to see a quick response from BU

$ 0.00
5 months ago

I'm wondering how much of the BU experience is due to poor compiler optimizations and how much of this is to due to poor OS settings. The famous disk-thrashing issue of swamp memory on linux is something that I quickly learnt to deal with by disabling swap, and when re-enabling for the very few usecases that actually needs it, pair it with a suitable swappiness of 10.

My experience with BU is nothing like yours, but I compile from source and have a much beefier computer than in this writup. I also have had no need to limit the bandwidth.

I do agree with you one one thing though: BU does start slow.

Our of curiousity, did you also try to limit the ABC bandwidth? did it behave differently?

$ 0.00
5 months ago

Thankyou for sharing your experience. ABC does not have bandwith limiting. The only way to limit the bandwith of ABC would be using iptables. (which is a linux kernel level feature, so it would work both for abc and bu).

Also, the swapping: you are totally right, swapping in Linux didnt works properly, and people disabling swap partitions alltogether because the developers refuse to fix this issue. I also have disabled swap, HOWEVER, in the recent years they changed the behaviour a bit, and depending what priviliges your app is running, Linux will STILL use some sort swapping to your system partition, even if you dont have swap partition or swap files, it will just secretly create one for itself if it runs out from the RAM, and use it aniway (similar to windows which creates a swap file to your c:). Back then, it just simply kicked out the process, now it will just swap out even your desktop environment so it will take minutes to bring up the sartmenu if you are lucky :D

$ 0.00
5 months ago

This is a great review, can't believe nobody has done this comparison before. Thanks!

$ 0.00
5 months ago

Thankyou.

$ 0.00
5 months ago

I can't verify your experience. My BU node runs well without problems and starts quickly both on the PC and on Raspberry Pi. The synchronization only took 22 hours.

$ 0.50
5 months ago

Here is my detailed configuration if you are interested to reproduce the results:

uname -ra

Linux debian 4.9.0-7-amd64 #1 SMP Debian 4.9.110-3+deb9u2 (2018-08-13) x86_64 GNU/Linux

lspci

00:00.0 RAM memory: NVIDIA Corporation MCP61 Host Bridge (rev a1)

00:01.0 ISA bridge: NVIDIA Corporation MCP61 LPC Bridge (rev a2)

00:01.1 SMBus: NVIDIA Corporation MCP61 SMBus (rev a2)

00:01.2 RAM memory: NVIDIA Corporation MCP61 Memory Controller (rev a2)

00:02.0 USB controller: NVIDIA Corporation MCP61 USB 1.1 Controller (rev a3)

00:02.1 USB controller: NVIDIA Corporation MCP61 USB 2.0 Controller (rev a3)

00:04.0 PCI bridge: NVIDIA Corporation MCP61 PCI bridge (rev a1)

00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2)

00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)

00:08.0 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)

00:08.1 IDE interface: NVIDIA Corporation MCP61 SATA Controller (rev a2)

00:09.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)

00:0b.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)

00:0c.0 PCI bridge: NVIDIA Corporation MCP61 PCI Express bridge (rev a2)

00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration

00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map

00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller

00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control

00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control

01:08.0 Mass storage controller: HighPoint Technologies, Inc. HPT366/368/370/370A/372/372N (rev 01)

01:08.1 Mass storage controller: HighPoint Technologies, Inc. HPT366/368/370/370A/372/372N (rev 01)

01:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)

01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)

$ 0.00
5 months ago

Great article.

I gave you $5 so you can upgrade to a 3.5 inch floppy drive.

$ 0.00
5 months ago

Lol, thanks. I kept the 5.25 drive as a decoration in that case. Since the picture is created, i have moved the 5.25 drive alongside with a 3.5 drive to a new (quite of similar) tower case, to a retro 6x86 machine which i actively using for developing programs and testing then under low-spec environment.

$ 0.00
5 months ago

I am sorry that you had a negative experience with BU. According to https://cashnodes.io/ we currently have 637 in-consensus nodes running on BCH, which is the most nodes of ANY client. Given this data, its clear that your experience is somehow abnormal. So I would have hoped that you would have contacted us before writing this, especially since I do not think that many people are running 10+ year old hardware.

But I have a old 4 core laptop though with similar specs, except that I did swap the drive for an SSD, and am running a modern release of Ubuntu. Based this post, I wiped out my .bitcoin directory and used the GUI to configure 128KB/sec avg and 256KB/sec max upstream bandwidth using the GUI (It is "odd" that you specified only a single number in this post when configuration requires both an average and a maximum value) . It is having no issues and has processed 145000 blocks in a few minutes (the early blocks are mostly empty).

I hope that you will work with us to figure out what's incompatible about your system, and perhaps revise this post when we get you going. Please keep in mind that using BU's bandwidth limiting feature will, well, limit the bandwidth. So doing so and then comparing the sync time would be disingenuous.

$ 0.05
5 months ago

Thankyou for your comment. Sure, i have posted my lspci and system information in a comment above, alongside with the kernel and debian version i use. I have also posted a screenshot with abnormally high memory usage in the article resulting after a few hours. If you need more information, i am glad to dig it up.

Right now, by comparison, i am resyncing the ABC node from zero, and this is what can be observed: https://i.imgur.com/bo18SPw.png As you can see, ABC works totally fine (its currenty 3 years behind) and only eats about 1.8 gb of RAM.

$ 0.00
5 months ago

As someone else pointed out already in the comments, the amount of RAM allocated by BU is automatic unless you override, and allocating half (or even more) of your available memory is nothing bad, it just makes for more efficient caching during the sync.

If you want it to use less, you can configure appropriately - nearly every "how do i set up a full node" tutorial has the instructions on those parameters.

FWIW, I've not had the same bad experience as you have in using BU, but I don't use the graphical interface anyway, I doubt most users do.

You should also check out BCHD.

$ 0.00
User's avatar btcfork
This user is who they claim to be.
We have manually verified this user via some other channel.
5 months ago

I dont think its a good idea for any software to assume that there is no other programs will be present and it can take half of the ram of a computer by default, i didnt seen any other program that was made like this, this seems more like a design flaw than a feature.

If really this is the case, then i think it would be more professional if by default, it would monitor the quantity of free ram, and throttle back and forth the ram usage dynamically.

$ 0.00
5 months ago

It only takes assumes half your memory (on windows it's dynamic and uses up to 80%) during the IBD process when memory usage is needed most. It was designed this way to give fast IBD for new users who don't know enough about the importance of the coins cache to set the -dbcache size properly. In BU once IBD is complete, and you haven't set -dbcache, it returns to the default 500Mb of cache size. But what you should have done when testing IBD is to set the -dbcache size for both ABC and BU to give a real apples to apples comparison.

Also you noted a few other items which are a bit strange. You said that the number of script threads where missing from BU's config. I think you must be looking in the wrong place , it is clearly in the Options dialog but you were probably looking in the Unlimited options dialog?

Another thing you did with BU is it sounds like you didn't set both the max and avg values for rate limiting but you rather did only one or the other and then saved causing the avg to be zero. Rate limiting works fine but you need to set both those settings!

Another item is that you said the output was not showing up in one of the debug screens. The Transactions per second screen will not show anything until IBD is competed because transactions are not allowed into the mempool until sync is finished. Futhermore if you had set the above rate limiting to zero then you for sure won't get connections or any network activity of any kind.

$ 0.05
5 months ago

Its very interesting to hear, if you set the rate for bandwidth limiting, it really didnt affects the other very obscurely explained slidebar value, and according to your comment, it should, so thats another bug that maybe explains why the network stalls if you set the bandwidth limitation and maybe would be an easy bugfix for the team.

Expecting users to dig up hidden command line parameters in manuals to be able to figure out why the software eating all of the ram by default, should not be normal, but maybe it will fix the problem for practicular users, not fixing however the fact that the wallet eats all the ram by default, which should not be allowed under any circumistances.

You are right about the verification thread settings, i searched them on the wrong place, as in ABC, when you click to options, a different panel comes up compared to BU, and in ABC thats the default panel to choose from.

https://i.imgur.com/kNLt8Am.png

I have modified the article accordingly, by inserting this screenshot into the article.

$ 0.00
5 months ago

It's a damned if you do , damned if you don't scenario with the memory. In the past we would always get a lot of new users complaining about slow IBD which typically was caused because they never set the -dbcache setting properly. So we went with a dynamic usage if the user didn't set -dbcache. Since we did that we haven't had any complaints anymore about IBD from new users until now from you - lol. But I think it's been better for BU this way because we spend way less time trying to get new users up to speed. IBD is a time consuming process so using the dynamic sizing can make IBD take just a few hours rather than a few days so it's been a big plus for the newbies and for the devs in having to do less communicating every time there's a complaint about slow IBD.

As for the bandwidth settings, sure we could fix that. It's an old feature which gets very limited usage so we don't spend a lot of time it development wise but it's good feedback from you and we'll discuss it internally as to what kind of fix we should put in there.

$ 0.05
5 months ago

I did not have any issues with inbound connections on a Bitcoin ABC node with open port, but my experience is quite dated.

I don't think either of the logos can be properly MSPainted, haha. (ABC, BU)

It's near-certain that BU has higher system requirements than ABC, presumably due to higher parallelism (with a possible flip side of higher throughput capacity). For example, I can sync the BSV blockchain on my computer using Bitcoin SV (derived from Bitcoin ABC) but not using Bitcoin Unlimited. BU runs out of memory and crashes on large blocks. Ironically, due to BU's Emergent Consensus it is also impossible to ignore large blocks, thanks to the rejection of BUIP054, so you have to invalidateblock every large block manually to stop your node from crashing.

BU's network transaction rate graph (in debug window) worked fine for me.

$ 0.00
5 months ago

WRT BU syncing SV blockchain: current version does not support SV what version did you use?

$ 0.05
5 months ago

Probably the last version of BU with SV support. This happened during the Quasar upgrade (which only changed the block size limit, so that BU version should still be able to track it) in July this year. I had 8 GB RAM. There was a non-upgraded minority chain but I could not configure Emergent Consensus settings to stop downloading and crashing on the large blocks of the majority chain (only invalidateblock stopped the crashes).

$ 0.00
5 months ago

So basically you experience the same issue, it allocates all the memory of universe and then crashes. Basically without seriously tweaking this wallet, there is a chance it will not work properly on a regular pc. In your case, SV blocks can be 128 MB, so if it uses multiple threads - and each thread allocates hundreds of mbytes of ram, then who knows how many ram it will eat, and how many it will just leak.

$ 0.00
5 months ago

Did you delete the blockchain data before attempting BU on the same machine? ABC uses the same data folders, but has a slightly different database structure.

$ 0.00
5 months ago

I use -datadir.

For curiousity, i have checked if BU can work with the synced blockchain of ABC, it did started and it claimed it is synced. After that, however, i deleted those folders alltogether.

In the experiment, i have specified newly created, blank directories as datadirs, so there was no chance for them to interfer with each others blockchain (i dont just specified new datadir, i also had deleted the old blockchains alltogether).

$ 0.00
5 months ago

OK cool.

With regards to RAM usage, if you don't specify how much memory you're willing to use, BU will attempt to guess an appropriate number. With more memory usage, you'll get better performance. With an 8GB system, it's not weird that it ate up 4GB.

If you were comparing performance, why did you start to mess with bandwith limiting? Did you try a clean install where you haven't messed with that feature?

$ 0.05
5 months ago

I compared the two wallet as a whole, on the practicular computer, the newest releases. I havent compared the speed of syncing the blockchain as that factor alone, because i think if the difference is lesser than a magnitude, then this factor is not very relevant. I dont know if ABC or BUCASH would win such a test, if the point of this test would be that. I wanted the wallet up and running, but i also used the computer, thats why i fired up bandwith limiting initially, which resulted a disaster alone. When i have finally realized to disable the bandwidth limitation, i didnt deleted the files and messed with a clean install, as after disabling the bandwidth limitation, the wallet started to sync. After that, i quit the software and restarted it, to see, if really this was the issue, and yes, from that point, it was syncing.

$ 0.00
5 months ago

Pretty cool!

$ 0.00
5 months ago

Thankyou... i think i lost some hair till i finished tho :D

$ 0.00
5 months ago

I can imagine :)

$ 0.00
5 months ago