Should we just remove the wallet function of Bitcoin Core

[jl2012]

Just see another victim of the 100-address trap in the Chinese subforum. 10BTC lost. Comments in the thread say the best option for noobs is to use a centralized bitcoin bank. I just feel speechless and don't want to argue with them

Should we just remove the wallet function of Bitcoin Core if HD is not (read: will never be) implemented? If people want to be a full node, they can use Armory. Otherwise, they can use Electrum.

Actually, wallets without deterministic backup (e.g. Bitcoin Core) should not be recommended in bitcoin.org

[TierNolan]

Actually, wallets without deterministic backup (e.g. Bitcoin Core) should not be recommended in bitcoin.org

Agreed.

Some kind of wallet is needed, even if only to create addresses for getblocktemplate.  A watching only wallet HD key could be used for that though.

[tspacepilot]

Just see another victim of the 100-address trap in the Chinese subforum. 10BTC lost. Comments in the thread say the best option for noobs is to use a centralized bitcoin bank. I just feel speechless and don't want to argue with them

Should we just remove the wallet function of Bitcoin Core if HD is not (read: will never be) implemented? If people want to be a full node, they can use Armory. Otherwise, they can use Electrum.

Actually, wallets without deterministic backup (e.g. Bitcoin Core) should not be recommended in bitcoin.org

What's the argument against moving Bitcoin Core to HD?  Are the principle developers against it for some reason?

[btchris]

It seems to be a work in progress: https://github.com/bitcoin/bitcoin/issues/5761

[unamis76]

100-address trap? I'm not aware of such things, is it an exploit of some sorts? Private key extraction through social engineering?

I don't thibk the wallet functionality should be removed... I think the key is develop it further, having it deterministic maybe, as it was referred

[Abdussamad]

100-address trap? I'm not aware of such things, is it an exploit of some sorts? Private key extraction through social engineering?

It's not an exploit. It means that backups are only good for 100 transactions from the time of backup. After that bitcoin core generates new private keys that are not in the backup you made so you must make a fresh backup. If you fail to do that and the wallet file on your hard drive is corrupted you lose money.

What's the argument against moving Bitcoin Core to HD?  Are the principle developers against it for some reason?

One of the principle developers invented the concept of HD wallets so they can't be more in favour of it.

[unamis76]

100-address trap? I'm not aware of such things, is it an exploit of some sorts? Private key extraction through social engineering?

It's not an exploit. It means that backups are only good for 100 transactions from the time of backup. After that bitcoin core generates new private keys that are not in the backup you made so you must make a fresh backup. If you fail to do that and the wallet file on your hard drive is corrupted you lose money.

Ah, I see, I didn't remember that when I read the OP Thank you.

[crazyearner]

Would be kinda stupid to remove the function maybe to limit or disable yourself or some options but not to totally remove the function.

[tspacepilot]

Would be kinda stupid to remove the function maybe to limit or disable yourself or some options but not to totally remove the function.

The thread btchris linked to above contains some useful discussion about how/whether to modularize the catch-all which is bitcoin-core.  I, personally, could see some use in dividing the project into mining-node vs. wallet vs. hd-wallet, etc.  Perhaps an installer would ask you which components you wanted to build and run or something like that.

[gmaxwell]

Just see another victim of the 100-address trap in the Chinese subforum. 10BTC lost. Comments in the thread say the best option for noobs is to use a centralized bitcoin bank. I just feel speechless and don't want to argue with them

Should we just remove the wallet function of Bitcoin Core if HD is not (read: will never be) implemented? If people want to be a full node, they can use Armory. Otherwise, they can use Electrum.

Actually, wallets without deterministic backup (e.g. Bitcoin Core) should not be recommended in bitcoin.org

jl2012-- Your thread title and premise is needlessly antagonistic; and came close to just being ignored by me completely.

Lets be clear about this.  In 2011 I proposed deterministic wallets. Other contributors in Bitcoin Core vigorously opposed them because they make backups a liability and undermine good key management practices,

Subsequently, I came up with the homomorpic public derivation, Pieter later formalized it in (and the non-publicly generatable scheme as well) in BIP32.  However, we believed that the the cryptography was too new and conjectural to rush out and deploy. Other wallets have done so, and some have done so in ways (e.g. only supporting the public derivation, and always using it; while simultaneously supporting key export) which has resulted in funds loss too.  Conservationism here is justified especially so in that one can simply set the key-pool to an arbitrarily high value and obtain most of the values of the fancier schemes; without many of of their costs.

Today the people opposed to it have been convinced or at least worn down. There is an implementation of BIP32 in the Bitcoin Core codebase.  Everyone active on the project has been working primarily just keeping the system afloat; there are very few substantial contributors, and I have no lately seen any work from you on this.    Suggesting removing a huge swath of useful, widely used, and generally reliable software because some functionality is not (yet!) incorporated is an insult.

[jl2012]

I know I sound rude and I'm sorry if anyone feel offended. I am really pissed off when I learn someone lose bitcoin again due to this problem. This is so 2011. It simply should not happen in 2015 because most wallets now have deterministic backup

Fixing Bitcoin Core is like fixing the International Space Station on the orbit. I know most devs are not paid and they have different priority. Improving the Core wallet is probably not the highest priority, which I agree, since we already have so many alternative wallets. But since the security level of Core wallet has not improved for years, it is not up to the 2015 standard. I mean native cold storage support (I know one can do it with some ugly hack) and deterministic backup.

For lay users, however, many of them still start with Bitcoin Core. They believe the Core wallet is the best one just because it is the reference client. They simply don't understand the risk of the lack of deterministic backup, until they lose money.

Actually I think we should still keep the wallet in Core, but disable it by default. Only advanced users, who really understand what they are doing, should use the Core wallet. Lay users should be directed to something else like Armory or Electrum.

[TierNolan]

Conservationism here is justified especially so in that one can simply set the key-pool to an arbitrarily high value and obtain most of the values of the fancier schemes; without many of of their costs.

I think a reasonable compromise would be to have wallets refuse to use new keys without explicit authorization.  If you backup the wallet.dat file, you are safe unless you hit "Yes" on the dialog box confirming that you have backed up.

The client could still generate the keys and add them to the wallet in advance of running out of old keys.

The sequence could be something like.

- When keys low, generate new keys and inform user that the wallet needs to be backed up
- When keys expire, ask user if they have backed up their new wallet.dat file

The user might hit ok, remembering a backup 2 times previously, so it isn't fully secure.

[btchris]

Conservationism here is justified especially so in that one can simply set the key-pool to an arbitrarily high value and obtain most of the values of the fancier schemes; without many of of their costs.

I think a reasonable compromise would be to have wallets refuse to use new keys without explicit authorization.

Do you mean as a stop-gap prior to implementing an HD wallet (specifically in Bitcoin Core), or in lieu of implementing it [HD]?

[laurentmt]

I think a reasonable compromise would be to have wallets refuse to use new keys without explicit authorization.  If you backup the wallet.dat file, you are safe unless you hit "Yes" on the dialog box confirming that you have backed up.
 might hit ok, remembering a backup 2 times previously, so it isn't fully secure.

+1000
Users may get bored by these alerts but that's perfect because it will encourage them to backup the wallet.

IMHO, the alert should disappear if the user has explicitly done the backup from the wallet (menu, ...).
If you just ask the user to confirm that backup has been done, it's likely that people will answer yes, just because they want to get rid of the alert.
An option might allow most advanced users to get rid of the alert with a simple confirmation but that shouldn't be the default behavior.

[shorena]

I think a reasonable compromise would be to have wallets refuse to use new keys without explicit authorization.  If you backup the wallet.dat file, you are safe unless you hit "Yes" on the dialog box confirming that you have backed up.
 might hit ok, remembering a backup 2 times previously, so it isn't fully secure.

+1000
Users may get bored by these alerts but that's perfect because it will encourage them to backup the wallet.

IMHO, the alert should disappear if the user has explicitly done the backup from the wallet (menu, ...).
If you just ask the user to confirm that backup has been done, it's likely that people will answer yes, just because they want to get rid of the alert.
An option might allow most advanced users to get rid of the alert with a simple confirmation but that shouldn't be the default behavior.

I dont think its a good idea to force security with error messages. If you are in the process of sending and the wallet forces you to create a backup for the change address you might just dump a backup somewhere in order to continue what you are trying to do. The code has enforced the rule, but did not solve anything. The user might not even remember that they still have to create a proper backup and just forget about it. The wallet would remind me anyway, so whats the big deal.

[MonkeyCoin11]

I think people who want to use Bitcoin should (must) at least understand how it is working.
Then, they should be intelligent enough to understand that without backup they could have big problem.
If people don't give any interest how new technology work, they should leave bitcoin for ever, it is not made for them.

But that's my opinion, now new generation think it's easy and think they are geek because they are lvl 600 in candy crunch on their iPhone.

[laurentmt]

I dont think its a good idea to force security with error messages. If you are in the process of sending and the wallet forces you to create a backup for the change address you might just dump a backup somewhere in order to continue what you are trying to do. The code has enforced the rule, but did not solve anything. The user might not even remember that they still have to create a proper backup and just forget about it. The wallet would remind me anyway, so whats the big deal.

Indeed. Having a blocking alert in the middle of another operation isn't a good solution.
Better solutions: a message displayed in all screens of your wallet or a popup when you open the wallet.

[TierNolan]

A simplier option is to just prevent sending at all.  The pop-up could be "The number of keys in your wallet has expired" and a warning if you click "generate more keys" that they will not be in any backups. 

[person]

Education is better than enforcement. Or placing fake limits.

If 1000 people use Bitcoin Core without an incident every day, let's educate the 1 or 10 that need to avoid the problem.

HD wallets are good, easy to use, have a purpose. I'd say that Non-HD also have its place. Let people learn about both and choose.

Or the next suggestion will be to have a "master-key" to revert transactions because a victim in China sent 10BTC to a scammer, and we need to "protect" them right?

[cheako]

An example of good key handling practices?

After looking at a few of the backups, I've decided that bitcoind needs a keypoolrefill prior to making the backup.

The default value is 100, but I feel that the code could auto-scale up for large sites if it recorded the number of records that were dumped each time.

Replace the two occurrences of YOUREMAIL.

Code:

#!/usr/bin/env perl

use common::sense;

use Fcntl qw(O_RDONLY O_NONBLOCK);
use POSIX qw(mkfifo);
use File::Temp qw(mktemp);
use File::Copy qw(copy);

my ( undef, $api ) = do '/home/btc/.bitcoin/bitcoin.PL';

my @fh;
my $unopened_file = mktemp("/home/btc/.backup${$}XXXXX");
$SIG{INT} = sub { die };
END { unlink $unopened_file }

mkfifo( $unopened_file, 0600 ) || die "mkfifo $unopened_file failed: $!";

sysopen( $fh[0], $unopened_file, O_RDONLY | O_NONBLOCK )
  || die "open $unopened_file failed: $!";

open( $fh[1],
'|gpg --batch --trust-model always -e -a -r "YOUREMAIL"|mail -s Bitcoin_Backup YOUREMAIL'
) || die "|gpg|mail failed: $!";

$api->call( 'dumpwallet', "$unopened_file" );

copy($fh[0],$fh[1]) || die "copy $unopened_file |gpg|mail failed: $!";

bitcoin.PL contains.

Code:

use Finance::Bitcoin;
my $wallet = Finance::Bitcoin::Wallet->new(
'http://bitcoinrpc:blahblahblah@127.0.0.1:8332/'
);
( $wallet, $wallet->api );

Actually, this doesn't work with the new 0.10.  I had to switch out using a regular file, less secure, instead of the FIFO this code uses and worked with previous versions.