Topic: Should we just remove the wallet function of Bitcoin Core (Read 3468 times)
Better to keep the wallet part of the bitcoin core client. If you prefer not to have a wallet, just use a separate daughter client.
removing the wallet function will lead to more spammers stealing from you. a wallet is necessary to store your bitcoins and give a security to your earnings. it is risky to use online wallets as hackers are prone to hack them easily.
its recommended to use wallet applications in your devices to have good security.
its recommended to use wallet applications in your devices to have good security.
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
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
At some point yahoo mail had a "seal", some words and color you personally set and it's displayed.
That was imho a great way to prevent n00bs to get scammed / lose account.
Maybe this would be needed?
However giving up a great service just because some users are not smart enough or at least not careful enough is not OK.
Now a question, maybe not related: I always see Armory and Electrum as first choices after Core. Is MultiBit bad or flawed? Am I missing something obvious?
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?
You just forgot one thing: Sheeple dont want to think for them self. 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?
Imho, we shouldn't prevent users to do anything. If they want to put themselves at risk, they should be able to.
But a warning reminding the risk seems a really useful feature for new users. It might be something like the warnings implemented in web browsers.
But a warning reminding the risk seems a really useful feature for new users. It might be something like the warnings implemented in web browsers.
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.
User interaction is only possible in the qt variant, on the server side it'd just stop working?
An example of good key handling practices?
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.
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.
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.
bitcoin.PL contains.
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: $!";
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:[email protected]:8332/'
);
( $wallet, $wallet->api );
my $wallet = Finance::Bitcoin::Wallet->new(
'http://bitcoinrpc:[email protected]: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.
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?
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?
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.
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.
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.
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.
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.
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.
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.
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.
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]?
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.
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.
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.
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
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.
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.
Would be kinda stupid to remove the function maybe to limit or disable yourself or some options but not to totally remove the function.
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. Jump to: