Bitcoin.conf File Discussion

[Rspigler]

Taken from discussions I had on the Slack, fleshed out a bit, in order to keep track and for others not on the Slack:

Validation:

assumevalid=0 I imagine our customers, since they are already seeking out the most secure storage system (IMO :) ) would want to validate the chain in the most secure way. By default, Core users skip script verification for many blocks. By setting this argument, our users will validate everything. However, this increases IBD time.

higher dbcache: Setting a higher dbcache will help with this. This value is set in megabytes. Machines sync faster with a larger cache, and it is recommended setting this as high as possible based upon the machine's available RAM. The default setting is 450 I believe. Since in our setup, our users are only using the computer for Yeti (this should probably be written in BOLD and red in the docs somewhere, as it is very important for security), and not running on things like raspberrypi, the dbcache most likely can be raised.

checkpoints=0? This is an interesting one. Checkpoints are still used in Bitcoin Core, although they are no longer added with the use of assumevalid. The latest one is in 2014. Having a checkpoint enabled would prevent a reorg to prior April 2014, and it also helps with a targeted attack where during IBD a node can be flooded with low difficulty block headers. IMO, if a reorg this large can happen, the game theory behind bitcoin has failed anyway. Also, in this incredibly rare case (and hopefully /never/ case), Yeti users would be out of consensus with Core users. Because of this, I argue against disabling these checkpoints. However, this is an agreement I think we should all come to, as there are definitely philosophical and security arguments to be made here.

Privacy:

avoidpartialspends=1 This improves privacy, but increases fees. Groups outputs by address, selecting all or none. See https://github.com/bitcoin/bitcoin/pull/12257

addresstype=bech32 changetype=bech32

Other:

txindex? Thought I'd list it here, can't really think of any use case where our users would need a full transaction index. Would people building a blockchain explorer want Yeti? Would our users ever want to look up full details for transactions other than their own? I don't know

For networking:

proxy=127.0.0.1:9050 listen=1 bind=127.0.0.1?

Online, the -bind command is recommended in some tutorials. I don't quite understand the difference between setting the proxy with or without the bind. Does anyone have info on this? -proxy Connects through SOCKS5 proxy, while -bind command Binds to given address and always listens on it. So I don't see any downside from it?

Core defaults to 8 outbound connections to receive blocks and transaction info. Setting the correct proxy info puts this behind Tor. However, this disables listening; if you want to help the network you need incoming connections. This usually requires forwarding port 8333. Having incoming connections via a Hidden Service does not require this, since Tor bypasses this.

Since Tor version 0.2.7.1 and Core 0.12.0, Core can create and destroy ephemeral hidden services programmaticaly (rather than having one HS set permanently). Tor must be downloaded (which Yeti does and verifies).

This needs to be added to your torrc at /etc/tor/torrc

ControlPort 9051 CookieAuthentication 1 CookieAuthFileGroupReadable 1

Then, figure out what group tor is using:

ps -eo user,group,comm |egrep 'tor' |awk '{print "tor group: " $2}'

Figure out what user is using Bitcoin

ps -eo user,group,comm |egrep 'bitcoind|bitcoin-qt' |awk '{print "Bitcoin user: " $1}'

Run the following as root, which adds the Bitcoin user to the tor group. Replace above information in below following appropriate places:

sudo usermod -a -G TOR_GROUP BITCOIN_USER

Restart tor and Core

Now, all outbound connections will be via Tor, and all inbound connections will be via your ephemeral HS

Can the above networking process be automated in any way? Either way, docs should be added to explain all of our decisions.

Notes:

Someone asked about 'onlynet'. onlynet=onion isn't recommended. Doing so will make it so that Core only connects out to Tor hidden services, which hypothetically could make the node more secure, but if large amounts of people did this, it could partition the chain, which is very dangerous. If you are concerned about putting your connections behind Tor, setting the -proxy commmand will do this (which Yeti does currently)

gaetawoo brought up 'walletbroadcast=0'. I believe this turns off the ability to broadcast transactions from your own wallet. So maybe no harm in adding this to the offline wallets, but we wouldn't want this on the online wallet.

[Rspigler]

Umm, don't know what I was thinking here.

I understand the desire to help the network, but listen should be set to 0. Disabling incoming connections is a great way to reduce attack surface. Therefore, no reason to set up HS either, and great way to reduce confusing setup/documentation on our end.

[willweatherman]

We cannot set listen to 0 or we would not be able to download the blockchain. Mabey we could change it after we disconnect the network but It would only be redundant. And we cannot disable broadcast because yeti 2.0 uses the wallet broadcast features.

[Rspigler]

This isn't correct but we can discuss on Slack.