09

[subSTRATA]

ug

[CIYAM]

AFAIA the "datadir" can only be used as a program argument (at least this is what the Wiki currently states).

Has something changed regarding this recently?

(in either case I do agree that "datadir" should be able to be provided in bitcoin.conf and it would be nice to have the option to provide this during installation)

[CIYAM]

It seems so. I've tried to change datadir via configuration file, as suggested by many and listed on wiki page, but it does not work.

Although maybe not perfectly clear (due to the need to scroll down a bit) I think the Wiki page does specifically points out that "datadir" (and one other option) are "program argument only" options whereas others can be set in "bitcoin.conf" but then "overridden" by "program argument".

[gmaxwell]

it happens many times that client just stops downloading data and seemingly goes
to idle mode. Mentioned situation happens even if many other nodes are connected. I've found somewhere that it can be a sign of DDoS.

Whoever was telling you this was mistaken.  This is an expected behavior during the initial block download currently. It will begin pulling again when there is a new block on the network.

[Stephen Gornick]

4. Wallet encryption should be mandatory.

If I had to bet, I would gamble on the likelihood of more coins lost over the years because people don't remember their passphrase (or lose the piece of paper where it was recorded) than would have been lost to hacks if there was no passphrase encryption.

That being said, I have passphrase encryption on my wallet, and the passphrase secured on paper along with other important documents.

[CIYAM]

4. Wallet encryption should be mandatory.

Why leave increased safety of wallet to user decision? It's written somewhere that wallet should be encrypted before any transaction
takes place, so why not simply ask for passphrase before blocks download even starts? Or even better, why not encrypt wallet upon
1st ever client start without even asking user about it? Just use some easy to remember passphrase like "wallet" and inform user (s)he
should change it afterwards, when client finishes with update. Than on exit check if (s)he did so or not = if not, warn him or her.

Using a standard encryption phrase is absolutely no better than using none (just as you can very easily log in to non-secured routers by using "standard" passwords like "admin" or "master").

The problem with the pass phrase is that it needs to have enough entropy to be useful (so something easily remembered will be of little use) but if it is forgotten then the user loses all their bitcoin.

As a user will start with zero bitcoins (and then perhaps get some very small amounts from faucets or the like) there is really no need to pressure the user into trying to come up with a strong pass phrase (which they might easily forget later). It is something they can perhaps work on over a period of weeks before deciding to encrypt their wallet (my pass phrase is over 40 characters and includes numbers and special characters but it was not something I could have supplied "on the spot" and still be able to remember months or especially years later).

[gmaxwell]

Than why not simply add what you typed, or condensed version, to pop-up which triggers once stated condition(s) occur? I mean,
8+ hours installation is highly unusual this days. There's plenty of time for user to conclude something is not right and just deinstall
client, than turn to some other solution, in worst case those trustless online wallets.

Because the software doesn't know it isn't done, otherwise it would continue.  It happens now when the peer you were pulling from goes aware or becomes unresponsive. One of the things about making a secure zero trust client is that you just can't count on 'servers'  to tell you what you need to know, there is a lot of complicated interlocking behavior which can have unexpected outcomes.  Improving this aspect of the IDB processis planned, but software isn't written through wishes.

If you'd like to contribute please test and write procedures for testing and report bugs, or chip in on fixing some of these things.  Posting ideas here is only of modest assistance (most of the time such recommendations are already known but aren't handled yet because no one has had a chance, or because they're tricky).