Questions About Running a Node

21 replies 296 views
Posts: 55 · Reputation: 19
#1Jun 10, 2019, 12:00 PM
Hey, I got a question about running a node. Didn’t want to clutter the challenge thread... So, while my Bitcoin core wallet is syncing, I see blocks downloading as.dat files, just like my Electrum wallet. Can someone break down for me what this format is and how it differs from wallet files? If I have the block files, why is my node still checking current blocks?
4 Reply Quote Share
gang2015Member
Posts: 682 · Reputation: 62
#2Jun 10, 2019, 05:19 PM
Those files might share the same.dat extension, but they’re different formats. Most of the time, Electrum saves wallets without any extension. You should check out Bitcoin Core's wallet.dat specifically, that one's also.dat. Also, when syncing, remember you need to copy the whole folder, which includes other important stuff like the chainstate folder.
2 Reply Quote Share
RogueCipherFull Member
Posts: 39 · Reputation: 453
#3Jun 11, 2019, 01:30 PM
Yeah, privacy is key here. With more nodes, we decentralize the network. Just like mining, every extra node helps keep your mempool safe and keeps that blockchain info immovable.
2 Reply Quote Share
Posts: 55 · Reputation: 19
#4Jun 12, 2019, 11:46 PM
Totally agree with that. I back up everything in Bitcoin Core’s directory. After reinstalling, I copied all the files over, but it’s still syncing super slowly. Feels like headers just won’t budge anymore, so I might have to start over.
0 Reply Quote Share
gang2015Member
Posts: 682 · Reputation: 62
#5Jun 13, 2019, 05:49 AM
If it’s stuck on syncing headers, that could just be your internet. No need to restart you don’t have to redownload everything.
3 Reply Quote Share
0xNodeMember
Posts: 671 · Reputation: 80
#6Jun 15, 2019, 05:22 PM
When syncing, nodes put together the entire UTXO set. This is basically the unspent outputs for every Bitcoin address. They gotta read blocks in order, no skipping, to check for invalid transactions. Even if you saved blocks, it checks them again after loading.
6 Reply Quote Share
dave.forkMember
Posts: 375 · Reputation: 185
#7Jun 15, 2019, 10:57 PM
Yeah, verification takes the most time. Download speeds are usually fine everywhere, but verifying can take ages. A day to download, but checking it all can take a week, depending on your computer.
2 Reply Quote Share
Posts: 16 · Reputation: 34
#8Jun 16, 2019, 03:51 AM
Right? You don't need anyone else to track your Bitcoin. Plus, it’s a boost to your privacy, since you’re not giving anyone else a peek.
3 Reply Quote Share
Posts: 55 · Reputation: 19
#9Jun 16, 2019, 06:55 AM
File extension doesn't matter that much. Could be.txt or anything. What’s important is the data inside. The blk.dat has block data, transactions mined, while wallet.dat has your wallet info. Each block is intertwined with the previous one, so your node needs to verify that everything’s legit going all the way back to the genesis block.
5 Reply Quote Share
Posts: 16 · Reputation: 34
#10Jun 17, 2019, 12:46 PM
Thanks for all the info. This is new to me. @NotATether, I want to use this thread to ask about my syncing issue. Bitcoin Core slows down crazy at 15% while the Bitcoind syncs fine. Not sure what’s up since my RAM and CPU are fine with the prune command you suggested.
0 Reply Quote Share
Posts: 55 · Reputation: 19
#11Jun 17, 2019, 03:37 PM
That’s normal, syncing can slow down. Your node has to check each block’s validity. Since your node's only synced up to 2016, and those blocks weren’t as popular, they had fewer transactions to verify.
2 Reply Quote Share
mr_apeNewbie
Posts: 401 · Reputation: 35
#12Jun 17, 2019, 04:47 PM
Totally get it. It was syncing fast at first, hit 15%, and then slowed way down. I guess the blocks post-2016 are just heavier files. Is there a way to speed things up with leftover RAM and CPU?
3 Reply Quote Share
0xLynxMember
Posts: 113 · Reputation: 205
#13Jun 17, 2019, 09:28 PM
For sure, you can up your cache size. Just set your dbcache in bitcoin.conf to about 8GB since you have 16GB RAM.
1 Reply Quote Share
gang2015Member
Posts: 682 · Reputation: 62
#14Jun 17, 2019, 10:22 PM
Set blocksonly=1 in your bitcoin.conf too. It can cut your bandwidth usage by a huge margin. After the initial sync, you can switch it back.
4 Reply Quote Share
0xLynxMember
Posts: 113 · Reputation: 205
#15Jun 17, 2019, 10:32 PM
Good to know. That 88% was from older versions; now Bitcoin Core uses compact blocks that speed up propagation without sending all transactions.
3 Reply Quote Share
Posts: 55 · Reputation: 19
#16Jun 18, 2019, 12:17 AM
Yeah, even if it’s not 88% now, going blocksonly helps a lot. I tried it on my last node and saw some real benefits.
6 Reply Quote Share
0xLynxMember
Posts: 113 · Reputation: 205
#17Jun 18, 2019, 03:47 AM
How do I know if the dbcache setup is working? Bitcoind processes so much data quick that the initial summary is hard to read when I open it. Also, why doesn’t my command have a # in front like others do?
2 Reply Quote Share
Ba5edGuruFull Member
Posts: 92 · Reputation: 349
#18Jun 18, 2019, 04:12 AM
The # is just for comments. It hides that line from being read by the code. As for dbcache, usually, it’s 1/4 of your RAM, so for 16GB, aim for dbcache=4096.
2 Reply Quote Share
Posts: 55 · Reputation: 19
#19Jun 20, 2019, 07:55 AM
Make sure your bitcoin.conf is saved as.conf, not.txt. When you're set, you should see those changes. The # just comments out, so it’s easier to read and helps clarify what each command is.
4 Reply Quote Share
Posts: 185 · Reputation: 37
#20Jun 20, 2019, 10:10 AM
Quick follow-up: why did blocks from 2016 sync slower when 2017 and later had more transactions? Now that I finished 2016, my sync is at 85%, but it crawled before.
2 Reply Quote Share

Related topics