-keypool=0 leads to permanent coin loss #445

issue dooglus opened this issue on August 1, 2011

dooglus commented at 8:18 AM on August 1, 2011: contributor

$ rm -f ~/.bitcoin/wallet.dat; ./bitcoind -daemon -keypool=0 bitcoin server starting $ ./bitcoind getaccountaddress foo 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E $ ./bitcoind getaccountaddress bar 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E $ pkill bitcoind $ rm -f ~/.bitcoin/wallet.dat; ./bitcoind -daemon -keypool=0 bitcoin server starting $ ./bitcoind getaccountaddress foo 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E $ ./bitcoind getaccountaddress bar 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E

I get the same address generated for multiple accounts in multiple wallets. There are over 60 BTC in the address already, apparently permanently lost. See https://bitcointalk.org/index.php?topic=8728.msg203511#msg203511

Perhaps I shouldn't be trying to use -keypool=0, but if so it shouldn't be allowed.
gavinandresen referenced this in commit e300f4a56c on Aug 12, 2011
gavinandresen referenced this in commit 2691c8bae8 on Aug 14, 2011
gavinandresen referenced this in commit 7db3b75b3e on Sep 1, 2011
gavinandresen closed this on Sep 8, 2011
coblee referenced this in commit 39098d1b7d on Jul 17, 2012
davispuh commented at 11:09 AM on February 19, 2014: none

Looks like there's also other implementations with same bug as that address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E is still receiving coins sent to it every now and then.
laanwj commented at 11:24 AM on February 19, 2014: member

Address '1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E' is 'b472a266d0bd89c13706a4132ccfb16f7c3b9fcb', or ripemd160(sha256("")). I suppose it's pretty easy to get there with a buggy implementation.

Looks like all the recent transactions to the address use 1ponziUjuCVdB167ZmTWH48AURW1vE64q, that may help narrowing down who has a broken client.

(appears to be some gambling site https://bitcointalk.org/index.php?topic=447831.0)
ghost commented at 10:27 PM on December 29, 2014: none

so i see the address has a ton of coin
dooglus commented at 6:20 AM on October 29, 2015: contributor

According to this thread, 1HT7xU... is still finding its way into wallets created long after this issue was closed.
gmaxwell commented at 6:28 AM on October 29, 2015: contributor

based on the comment I believe its from a wallet that was screwed up in the past. But I need to know if it's encrypted or not to diagnose further.
ptschip referenced this in commit b22d70e2dd on Apr 25, 2017
classesjack referenced this in commit 7e30c44a3c on Jan 2, 2018
kallewoof referenced this in commit 3d274183d2 on Oct 4, 2019
Losangelosgenetics referenced this in commit 91fd348be8 on Mar 12, 2020
MarcoFalke locked this on Sep 8, 2021

Contributors

Labels

Linked (view graph)

#467 Logic running with -keypool=0 was wrong (empty keys were being returned).