Enable settings defaults for multi-valued object settings.

[evoskuil]

No description provided.

[digitsu]

Hi, thanks for answering by issues so far. Looks like I’m up and running with full chain now.

One funny non-critical error is that when I Ctrl-C to end the server it seems to take a very long time to shutdown. So long that I normally just give up and kill the process. Is this expected? Also I am running on a 8gb mem machine, it seems to use up quite a bit of mem, what is the recommended setup for running this server?

On Jul 29, 2015, at 08:50, Eric Voskuil notifications@github.com wrote:

Merged #109 #109.

—
Reply to this email directly or view it on GitHub #109 (comment).

[digitsu]

Sorry to ask so many questions, if there is a better forum for these, please let me know, I will be happy to use.

Can I know what is the main purpose for the libbitcoin-server? At first I thought it was for the use of bx tool, but it seems that bx looks to work fine without the server running. What queries or features of bx require libbitcoin-server node to be running in the background?

Great node btw. I love the sx tools, and just started playing around with bx.

Thanks!

On Jul 29, 2015, at 08:50, Eric Voskuil notifications@github.com wrote:

Merged #109 #109.

—
Reply to this email directly or view it on GitHub #109 (comment).

[evoskuil]

@digitsu It's best to start a new issue for a question unless the question relates to the topic of an existing issue. You can also ask questions on the freenode #libbitcoin IRC channel, or the libbitcoin mailing list

libbitcoin-node is a full p2p node, which is designed to maintian the blockchain and memory pool. libbitcoin-server is a layer over libbitcoin-node which provides fast query access to the blockchain via client-server protocol. libbitcoin-explorer (and the bx command line tool) speaks both Bitcoin (P2P) and Libbitcoin (via libbitcoin-client) protocols.

8GB is sufficient RAM for server. An SSD dramatically improves shutdown time. If you are hitting a memory stall shutdown time will be a function of the amount of message backlogging, which can be significant. If you see physical RAM shootting up past 1-2GB you should shut down (cleanly) and restart, preferably with different configuration (see below).

In recent builds config has been greatly expanded, and other improvements have been made, to improve the sync process. I'll eventually write up a tutorial on the wiki with best practices for sync, but I've got a couple of remaining issues to deal with before v2.2 release.

But if you set a recent checkpoint in the config file it will bypass full validation and other activity until that point. This speed improvement can prevent the memory stall altogether. Additionally you can reduce the number of outgoing connections as the default (8) is too much for sync. It will cause out-of-order blocks to create long reorg chains, which can easily result in a memory stall. Once you are past the checkpoint you would want to increase the connections so that you are seeing a larger part of the network. Once you are sync'd the stall is a non-issue.

If you liked sx I think you'll really like bx.