Bitcoin Forum

Bitcoin version 0.4.0 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/

The main feature in this release is wallet private key encryption;
you can set a passphrase that must be entered before sending coins.
See below for more information; if you decide to encrypt your wallet,
WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you
forget or lose your wallet passphrase, you lose your bitcoins.
Previous versions of bitcoin are unable to read encrypted wallets,
and will crash on startup if the wallet is encrypted.

Also note: bitcoin version 0.4 uses a newer version of Berkeley DB
(bdb version 4.8) than previous versions (bdb 4.7). If you upgrade
to version 0.4 and then revert back to an earlier version of bitcoin
the it may be unable to start because bdb 4.7 cannot read bdb 4.8
"log" files.

Notable bug fixes from version 0.3.24:
--------------------------------------

Fix several bitcoin-becomes-unresponsive bugs due to multithreading
deadlocks.

Optimize database writes for large (lots of inputs) transactions
(fixes a potential denial-of-service attack)



Wallet Encryption
-----------------
Bitcoin supports native wallet encryption so that people who steal your
wallet file don't automatically get access to all of your Bitcoins.
In order to enable this feature, choose "Encrypt Wallet" from the
Options menu.  You will be prompted to enter a passphrase, which
will be used as the key to encrypt your wallet and will be needed
every time you wish to send Bitcoins.  If you lose this passphrase,
you will lose access to spend all of the bitcoins in your wallet,
no one, not even the Bitcoin developers can recover your Bitcoins.
This means you are responsible for your own security, store your
passphrase in a secure location and do not forget it.

Remember that the encryption built into bitcoin only encrypts the
actual keys which are required to send your bitcoins, not the full
wallet.  This means that someone who steals your wallet file will
be able to see all the addresses which belong to you, as well as the
relevant transactions, you are only protected from someone spending
your coins.

It is recommended that you backup your wallet file before you
encrypt your wallet.  To do this, close the Bitcoin client and
copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user
name)/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/
on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on
Windows Vista and 7 and /Documents and Settings/(user name)/Application
Data/Bitcoin on Windows XP).  Once you have copied that file to a
safe location, reopen the Bitcoin client and Encrypt your wallet.
If everything goes fine, delete the backup and enjoy your encrypted
wallet.  Note that once you encrypt your wallet, you will never be
able to go back to a version of the Bitcoin client older than 0.4.

Keep in mind that you are always responsible for your own security.
All it takes is a slightly more advanced wallet-stealing trojan which
installs a keylogger to steal your wallet passphrase as you enter it
in addition to your wallet file and you have lost all your Bitcoins.
Wallet encryption cannot keep you safe if you do not practice
good security, such as running up-to-date antivirus software, only
entering your wallet passphrase in the Bitcoin client and using the
same passphrase only as your wallet passphrase.

See the doc/README file in the bitcoin source for technical details
of wallet encryption.

Signed SHA1 checksums of the binary release files:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

25c3ec9683d62235afea24d4a147d4616d8a884f  bitcoin-0.4.0-linux.tar.gz
a800d9fa4aa61527e598708f4ace7f855c22a46b  bitcoin-0.4.0-macosx.dmg
1d2c8d82ede5e8aa9f83b59da07e443de89c5c8f  bitcoin-0.4.0-src.tar.gz
ecf1304ff467bd30dc668b3dadff3044c3c86df1  bitcoin-0.4.0-win32-setup.exe
6034efe23e4bd76b0860f633e81710cd66d499db  bitcoin-0.4.0-win32.zip
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAk58n20ACgkQdYgkL74406ibEACgzyZj86lsQORi5HTs/N3ABCes
Pg8AoKFXU1vxiZI9qZOQ5ZET60ewcynW
=sY+Q
-----END PGP SIGNATURE-----


Full changelog ("git shortlog --no-merges v0.3.24..")
-----------------------------------------
Abraham Jewowich (1):
      Fix bug with accessing vchData[0] when vchData is empty.     Fix typo in CBase58Data::CompareTo

Alex B (2):
      Romanian translation added
      Spanish translation update

Alex Waters (1):
      Updated readme file

Daniel Folkinshteyn (1):
      Update the list of seednodes.

Dawid Spiechowicz (1):
      added polish wallet encryption messages

Dean Lee (1):
      Update to the Chinese Simp translation

Dev Random (4):
      Linux gitian config with separate wxWidgets build
      Mingw gitian with separate wxWidgets and boost
      Mingw gitian build with deterministic bitcoin.exe by use of faketime
      Add Gitian Build descriptors for Boost and wxWidgets.

Doug Huff (1):
      Make mlock() and munlock() portable to systems that require the address to be on a page boundary.

Dylan Noblesmith (1):
      mlock() all private keys in memory

Eric Hosmer (1):
      Added crypter to makefile.vc.

Fabian H jr. (1):
      Updated checkpoints, maybe Tx fee should be reduced to 0.0001 from 0.0005 and maximum minimum tx should be 0.0010.

Gavin Andresen (24):
      Do-nothing MapPort() ifndef USE_UPNP.  fixes #450
      Don't std::advance past beginning of transactions array.  Fixes #465
      Remove unused ScanMessageStart function
      Compile with DEBUG_LOCKORDER to detect inconsistent lock orderings that can cause deadlocks
      CHECKMULTISIG unit tests.
      Highlight mis-matching locks
      Fix rpc-hanging deadlocks
      Fixed potential deadlocks in GUI code.     Also changed semantics of CWalletTx::GetTxTime(); now always returns the time the transaction was received by this node, not the average block time.     And added information about -DDEBUG_LOCKORDER to coding.txt.
      Fix typo ("you own security")
      SetCrypted() obtains keystore lock, to be safe.
      Logic running with -keypool=0 was wrong (empty keys were being returned). Fixes #445
      Fix RPC call name in error message.
      obtain cs_wallet mutex to protect vchDefaultKey
      Fixed regression I introduced: wallets with lots of transactions were unusable in GUI.
      Fix bad merge: getaccountaddress was broken for new accounts
      Give hard-coded seed nodes a random last-seen time, to randomize order they're tried.
      Do not try to download blockchain from 0.3.23 nodes
      If compiled -DDEBUG_LOCKORDER and run with -debug, print out every mutex lock/unlock (helpful for debugging something-is-holding-a-mutex-too-long problems)
      Stay connected to seed nodes; disconnecting causes problems if you are trying to make the initial blockchain download.
      Versions 0.3.20 THROUGH 0.3.23 have trouble with blockchain downloads; avoid them
      Bumped version numbers to 0.4.0rc1
      Optimize database writes for transactions with lots of TxIns.     Patch from ArtForz, who discovered the problem.
      Fix AddAddress cs_mapaddresses/db transaction deadlock
      Fix QA email address

Giel van Schijndel (15):
      fix warning on 64bit systems: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      fix warnings: expression result unused [-Wunused-value]
      fix warnings: using the result of an assignment as a condition without parentheses [-Wparentheses]
      fix warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
      fix warning: X enumeration values not handled in switch [-Wswitch-enum]
      fix warning: unused variable 'X' [-Wunused-variable]
      fix warning: unused function 'SigIllHandlerSSE2' [-Wunused-function]
      fix warning: variable ‘nMinDepth’ set but not used [-Wunused-but-set-variable]
      fix warning: control reaches end of non-void function [-Wreturn-type]
      Make some global variables less-global (static)
      Cleanup makefiles such that diffs to them are smaller
      Move func 'REF' from util.h to serialize.h
      Start moving protocol-specific code to protocol.[ch]pp
      Move CAddress to protocol.[ch]pp
      Move CInv to protocol.[ch]pp

Han Lin Yap (2):
      Comment "deprecated"
      Add a note to only include .po file

Jay Weisskopf (4):
      Add logos/branding currently found on bitcoin.org into NSIS installer.
      Set default compression for NSIS installer to LZMA.
      Remove NSIS branding from bottom divider.
      Increase resolution of Windows icon.

Jeff Garzik (8):
      Update CWallet::LoadWallet for proper return type.
      Bump version to 0.3.25
      doc/README: word wrap into something readable
      CAddrDB::LoadAddresses: properly initialize CAddress
      src/makefile.unix: remove -DFOURWAYSSE2
      Add reference python miner, in contrib/pyminer/
      README.md: word wrap text file
      Revert "Define MSG_NOSIGNAL to 0 on platforms where it is unavailable."

Jeroenz0r (1):
      Translation from "Open Bitcoin" to "Verstuur Bitcoins"

JoelKatz (1):
      Fix UNIX-specific thread handle leak.

Johannes Henninger (1):
      Identify as "Bitcoin + version number" when mapping UPnP port

Luke Dashjr (7):
      Update nTime after nExtraNonce to avoid potential race     (extraNonce being reset due to just-occurred time change after nTime is set)
      Reset extraNonce only every 15 seconds, just in case some miner is updating time himself and stuff
      Reset extraNonce only when prevBlock changes, so miners can continue updating the time on their work until it's stale
      Support for boost filesystem version 3
      ignore stuff
      Save coinbase, not just extraNonce
      Bugfix: Use timestamp in coinbase rather than "bits", needed to ensure coinbase txn is unique even if address is the same

Matt Corallo (35):
      Add minversion to wallet.
      Add wallet privkey encryption.
      Set the number of SHA512 rounds based on the speed of the computer.
      Push unlocked_until in getinfo.
      Dynamically remove/insert the Options for encryption in the menus.
      Add the walletlock RPC method to lock the wallet manually.
      Add Wallet Encryption section to README
      Use DB Transactions when encrypting wallet.     This speeds up the encryption process significantly.
      Make an invalid addrIncoming so that old clients crash.
      Update makefile.linux-mingw to work with crypter and UPnP fix.
      Fix makefile.linux-mingw
      Fix crashes when a wallet is locked and GetReservedKey() is called
      Generate Warning when using default key.
      Fix Build in GetReservedKey() in wallet.cpp
      Fix bad return values in LoadWallet.
      Actually use mapAlreadyAskedFor.
      Fix EncryptKeys crash introduced by a9ba4710, identified by TD.
      Check for duplicate txins in CheckTransaction.
      Make it clear that setting proxy requires restart to fully apply.
      Don't listen if on TOR (resolves #441).
      Add missing include to serialize.h
      Add file for transaction tests.
      Cleanup test suite output to be more useful.
      Unify copyright notices.
      Missed a 'password' should be 'passphrase'.
      Fix incorrect RPC error messages
      Add specific wallet encryption details to doc/README
      Upgrade dependancies and tweak build process.
      Update binary mos to latest translations.
      Fix build process to actually work.
      Add binary mo for new translation.
      Update gitian build descriptors to produce proper builds.
      Update bitcoin icon to make nsis setup exe deterministic.
      Update binary mo to match latest po translation.
      Restructure gitian files and add download config files.

Michael Bemmerl (4):
      Basically some grammatical fixes of the German translation.
      Added German wallet encryption messages translation.
      Changed Russian translation according to comment in issue 395
      Updated German translation

Michal Zima (1):
      Updated czech translation

Nils Schneider (2):
      log low-level network messages only when fDebug is set
      missed printf in AbortMessage(); merged printfs in EndMessage

Patrick Varilly (1):
      Single DB transaction for all addresses in a message

Pieter Wuille (11):
      Prepare codebase for Encrypted Keys.
      Do not use obsolete CPrivKey for passing keys around
      Bugfix: add autogenerated addresses to address book
      get rid of mapPubKeys
      Use CBitcoinAddress instead of string/uint160
      split off CBase58Data from CBitcoinAddress
      Fix for small change outputs
      Bugfix: don't overuse limited ExtractAddress
      avoid strAddress + validity checks
      SocketHandler thread can be detached
      Updated dutch translation

Stéphane Gimenez (1):
      Single DB transaction for addresses from DNS seeds

Vegard Nossum (6):
      Add missing includes to key.h
      Add missing include to script.h
      Add missing includes to net.h
      Fix testing setup
      Add prototype for EvalScript() to script.h
      Add a file for script tests

Venkatesh Srinivas (4):
      Test for SO_NOSIGPIPE rather than assuming all BSDs support it.
      Qualify make_tuple with boost:: namespace.
      Use 'unsigned char' rather than 'char' for pchMessageStart.
      Define MSG_NOSIGNAL to 0 on platforms where it is unavailable.

Wladimir J. van der Laan (2):
      remove magic number: change threshold for nLockTime to constant
      make SetHash160 return a value (as specified in the function signature)

cjdelisle (1):
      wxWidgets needs to be at least version 2.9.1 because wallet crypto uses ToStdString() which is not in 2.9.0

ovdeathiam (1):
      Edited locale/pl/LC_MESSAGES/bitcoin.po via GitHub

Oh, forgot to add:  Thanks to everybody who helped out!

+1 

This latest release with wallet encryption may very well be what's needed to fuel more-widespread adoption of Bitcoin.  We owe a debt of gratitude to the devs.

Thank you for making bitcoins a reality.

Keep up the good work.

Woohoo!

Great work!

+1 This might well be something that would make Mr and Mrs "Smith" feel secure about using bitcoins.


Great work ;D

This deserves a round of applause for Gavin and everyone who contributed.

Thanks to everyone who contributed and thank you for the post Gavin. Everyone should read it before using encryption.

Thanks to all the devs for their dedication and hard work. This is a big step forward.  :)

Many thanks to the developers team, which is the main asset of bitcoin, who made this release possible.

+1

Good work guys.

Thank you,

I suggest we (bitcoiners) offer something in return to developers.

I offer to help their personal requests related to my geographical location,
Croatia.
Basically, I offer my time, remote assistance and available info...

I do not promise 100%, but around 90% :)

Thank you devs!!!!

Good work!

L.

Sadly still not working on W2k  :'(

Thanks guys! ++1

Switch to Linux.  Surely W2K will have enough unpatched security holes that any bitcoins you own will surely get stolen.

Maybe it's his workplace machine. I can't imagine a bitcoiner using W2K by choice in the year 2011.

Thanks Dev team!

Thanks for the hard work.  This should help a lot of people.

Are you from the past?

Also, thanks devs!

Thank you very much to all of the devs.

this is a Big Day for Bitcoin!  thank you!

Please help test, no matter what platform (linux/windows/mac) you are using!

Wow .. the Mac version actually came out at the same time as the others this time.  This must be a first.  Thanks developers!

https://i.imgur.com/oJXAH.png

this image is public domain.

It's a server in my home network and already behind a Linux gateway. It's never been compromised and has been running fine needing no attention. I know W2k is old, but this one just works and I don't intend to replace it just because of this update while the old client still works. Especially since the fix should be pretty simple (I already provided details in another thread).

And don't get me started by implying "Linux is safe by default"; for the sake of a civilized discussion, I'll assume you were trolling.

I had some minor troubles after the upgrade, but things seem to be ok now. Just in case someone else runs into the same issue: At first, the 64-bit linux client failed to download any new blocks. The first thing I tried was to start with a new .bitcoin directory; this worked, but I didn't want to re-download the entire chain. Then I tried the new 32-bit client with the original .bitcoin directory, and to my surprise, this worked as well. After downloading a few blocks, I started the 64-bit client again, which continued to download the remaining blocks.

Congratulations on the new release, especially the wallet encryption. Just one feature request (which has been voiced many times, I think): Could you please give some indication of the block chain download status, e.g. a progress indicator? Thanks.

thats already in the qt-gui, so you get it with v0.5 if you dont want to compile that one yourself.

Thanks Guys! People, dont forget to donate bitcoins to developers team ;)

Thanks for the update! I was a bit worried to see the "are you sure you want to encrypt" before the passphrase verification though.

first off: congrats and thanks for the hard work to the devs.

A question:
How does using rpc call "sendtoaddress" work with an encrypted wallet?

Many thanks to all the bitcoin developers, you have solved the immediate problems facing users.

Now on to 0.5 and a pretty GUI! :D

And perhaps sipa's mod can make it into the next release so we can all stop using pywallet? No offense to jackjack, it's an excellent tool, but frankly it's a tool that shouldn't exist considering there's been a pull request that duplicates its functionality for quite some time now.

From the point of RPC, the wallet is either in "locked" or "unlocked" state. You can use the "walletpassphrase" RPC call to unlock it for a limited time. Sendtoaddress and some other commands will fail if the wallet is locked.

Nice, that's a good solution. Thanks for the info, sipa.

+1  :)

I'll be interested in two things, and I'll make some of my own estimates for the fun of it:

1)  Ratio of BTC lost due to forgotten passphrase vs. those to stolen wallet.dat's:
1e) 10/1

2)  First post here from someone needing to know how to get their coins from an encrypted wallet due to forgetting their passphrase:
2e) 3 days

Don't get me wrong...I think this is good an necessary work and I thank the dev team for it and all the other work.  But I do anticipate the encryption contributing to the 'deflationary' nature of the currency :)

You guys are great, thank you for this further step.
Is there a donation adress for the whole developer team or something similar?

Thanks guys. Built-in encryption is great.

Thanks the hard work of the development team!

Thanks guys! Keep up the good work :)

Yeah certainly not when XP is still available.

And Microsoft will give you a current version of Windows for free.

Thanks devs.  Keep up the fantastic work!

Super Excellent!

What is the encryption method/algorithm used?

Since the DB format has been updated how will that affect blockchain archives? Will there have to be two versions or will downloading an older version still work fine? I guess it auto-converts if it sees an older version DB?

OFF-TOPIC: Where can I signup for that free windows version?

dynamic iterated SHA512 hashing to derive a password key, AES256-CBC using the password key to encrypt a master key, AES256-CBC using the master key to encrypt the wallet keys.


The wallet format changed to support encrypted keys, the blockchain database format didn't.

The binary is linked using bdb4.8 instead of bdb4.7 though, which will upgrade the database logs well, in a backward-incompatible way.

More details are in the doc/README file in the tree:
  https://github.com/bitcoin/bitcoin/blob/master/doc/README#L70

There is not a donation address for the whole development team; if there was, somebody would have to be in charge of keeping track of the bitcoins, deciding what they should be spent on, etc.

I don't want to be that somebody....

If you like the wallet encryption feature, send bitcoins to:
  Matt Corallo (https://bitcointalk.org/index.php?action=profile;u=4528) :  1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
and Jeff Garzik (https://bitcointalk.org/index.php?action=profile;u=541) : 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj

Matt (aka "BlueMatt" in IRC) did the hard work of making wallet encryption happen, and deserves a ton of credit for being persistent and reworking his Jeff's initial implementation a few times based on feedback and suggestions.

Gregory Maxwell ('gmaxwell') also deserves credit and donations, he gave a lot of feedback and did a lot of testing:
  gmaxwell (https://bitcointalk.org/index.php?action=profile;u=11425) : 1LjPAUKf23kDBy9sLJbiLfsvjde3ZdHcbJ

(corrected to give Jeff credit for the initial implementation-- sorry Jeff!)

i have a question.  i want to use an very long complex password that i've memorized.  however, i stopped the encryption when i saw just a single password entry window that hides the password itself.  reason being is that if i mis type one character and proceed to ok the encryption i'm screwed, correct?  if correct, why wasn't a "re-type password" window used?

Just did this myself and it does prompt a second time to re-enter the password before creating the new wallet.

thanks.  didn't want to press ok until someone told me exactly what was going to happen next.

http://www.websitespark.com/

Is it a notification or a real crash?

Are you joking? windows 2000 in 2011? Ehi i have a copy of windows 3.1 somewhere, are you interested in it?  ::)

The fact that the client doesn't work with w2k is a GOOD THING.

Would someone mind uploading the block chain somewhere for me those on expensive inet connections. Cheers!

There has only been one reliable release from Microsoft since 2000.

Seriously - if you pretend that everything between Windows 2000 and Windows 7 never happened, then Microsoft actually look like a badass company with solid products.

A real crash.

In a perfect world, Bitcoin version 0.1 would have included code that looked for a "Bitcoin version X or later required to read this wallet.dat file" setting, and notify the user and exit cleanly if X is greater than the version you're running.

We don't live in a perfect world.

So the second-best solution was to have version 0.4 and later do the "Bitcoin version X or later required to read this wallet.dat file" thing.  And write a value into the wallet that causes previous versions of bitcoin to crash on startup.

If previous versions didn't crash when given an encrypted wallet, they'd just ignore the encrypted keys, generate a bunch of new, unencrypted keys, and give people heart attacks when they ran the old version of bitcoin and told them they had a 0 bitcoin balance.

Well, for the record, I wrote the initial implementation (which BlueMatt then reworked):

     https://github.com/jgarzik/bitcoin/tree/crypter

Actually, I do have WfW on floppies. Also DOS.

But seriously, why should I replace a perfectly running system that's working as a server? I'd need to buy new hardware, a new Windows, install and configure it along with all the tweaks and services running on top of it. Just to run the client of an experimental currency? Yeah, like that will happen.

As I said before, I provided a solution already and hope that the Devs will add it.

Hmm, how many files does bitcoin read? I might be able to help sanitize the input - display "invalid file: dsdsd, bitcoin will now exit" etc, like how "can't read blkindex.dat" works for the rest of the files that crash bitcoin. I would get a heart attack if any financial software crashed due to a cosmic ray.

Link for Mac users?   ::)

 ;D

You're running anything serious on an antique like that?! My phone is more powerful than computers that were contemporaneous with Windows 2000. There has to be a lower bound of support somewhere, and your old Studebaker is below it.

That's not to say that your simple change couldn't be added; the problem is it can't be tested and verified because the rest of us can't lay hands on Windows 2000 without significant time or expense.

As said, it does all its work perfectly fine. Leave the imaginative problems which you assume I'm having to me and play with your phone.

Again, as said, Matt worked on that for v0.3.24 and I successfully tested the fixed binary. It's an official MS fix and the only problem was compiler-related.

http://eu1.bitcoincharts.com/blockchain/ (http://eu1.bitcoincharts.com/blockchain/)

If Windows: you may use 7-Zip (http://www.7-zip.org/) to untar it. :)

Instead of this method, couldn't you have just changed the default filename to something like xwallet.dat?

Then the old client would ignore the file and generate a new empty wallet.dat, leaving xwallet.dat untouched.

Is there some way to import a new key into an encrypted wallet?
I used to use pywallet but I'd expect that it can no longer support "--importprivkey" now.
Is there an json-rpc for importing a key? How would that be done?

That still results in the same scenario: you roll back a version, and see "Balance: 0.00" and panic.

What the hell does this crap mean? XP (SP2+) had better security (and compatibility) than Windows 2000, and Windows Vista's security was light-years ahead of 2000 or XP.

Its very common for people to forget their secure passwords and as Bitcoins becomes more mainstream it will happen quite a few times.

Is there any way to have a optional "password hint".

Why aren't these people using a password safe? Try Keepassx, PasswordSafe or similar. Given how many web sites, accounts, keys and other things people use now it's plain idiotic to be trying to remember passwords or even worse repeat them on multiple sites/accounts.

I've been using Keepassx for years. Make backups of the pwd db file. I have hundreds of strong passwords in mine and about a half dozen copies in various safe places. It's way more convenient and safer than trying to remember passwords. There only needs to be ONE password in your head.

There will be soon, most likely.

https://www.grc.com/offthegrid.htm

Incidentally, there is a service called PieTrust being built specifically for that scenario -- a system to let a community produce a reputation score for recognizing contributions to a team effort, everyone from programmers, graphics, documentation ... and for those providing support to the community even.  Using that score allocating of donated funds is one potential use of the service.  That service's founder is a participant in the Bitcoin community and Bitcoin is expected to be used as a compensation method though compensation portions are essentially only an add-on/module fo PieTrust.
  - http://www.pietrust.com

Today I upgraded to v0.4 with passphrase encryption but believe I am subject to having a false sense of security.  I still have bitcoins kept in addresses from my wallet that previously was unencrypted and I still have backups of that wallet.dat from before I encrypted.  

I posed a question regarding this on the Bitcoin StackExchange Q&A:
 - http://bitcoin.stackexchange.com/questions/1243/can-i-force-my-wallet-to-only-have-news-keys-post-encryption

Some sort of lost bitcoin recycling protocol could be implemented in the future to alleviate all of that. Something along the lines of requiring bitcoins to either be transferred at least once over some very extended amount of time (say 2 years), or the bitcoins will be flagged as lost and re-mined. In terms of usability, the client could simply tell the user the time remaining for the oldest bitcoin in their wallet to expire, informing them that they need to make a simple transfer of their coins by then to retain ownership of them.

Some people had pointed that out when the release candidate came out, but I guess it wasn't fixed.

Surely the client can just detect when an address may expire and transfer it to a new address automatically since the client doesn't even show what addresses contain what portion of the balance.

The real problem is when users don't use their wallet for a long period of time and then one day open it expecting their bitcoins to still have value. I'm not sure you can demand that users use the client to maintain their wallet value.

man, not that btc recycling again, you seem to have serious issues grasping a decentralized store of value economy.
After being born, educated and lived almost a whole life in a system like we have today, we try to desperately to put concepts and existent ideas into every new system that already works by it's rules only to avoid having to learn from scratch.
Educate yourself a little more

Yeah, I definitely don't have a philosophical problem with that idea. The trick is that it wouldn't work for encrypted wallets, because by definition, the client couldn't have it automatically send the coins out if he doesn't know the password.  Furthermore, any automated transfer every so often might theoretically be a security hole that could be exploited.


Yeah, I agree with that sentiment, but I don't think that that expectation is necessarily a fundamental principle that can't be breached. The use of bitcoin is a choice, and its foundational principles are going to be based on what the majority will download as their client. I don't think it would be unreasonable proposition to the people who want to be a part of the system to agree to a protocol that simply maintains the currency's count in circulation. If someone loses their wallet.dat, or someone sends their bitcoins to a bad address, this wouldn't hurt them, as they've already lost their coins, but it would solve the problem that they are lost to everyone else forever. The only argument I can think of against it might be for someone who forgot their wallet password, and wanted it to stay within their right to brute force their password over a longer period of time than the transfer deadline (the example was two years). I'm not sure whether or not it would break these physical bitcoin concepts that are out there.



I'm just bringing it up as a consideration -- I'm not set on it or anything. I think you're making an unnecessary judgement on my grasp on the concept of decentralized stores of value, instead of simply making your point.

Come on, do you really think I'm doing this? I'm very persuaded by anarcho-capitalist perspectives, which of course isn't anywhere near the majority perspective I've grown up around, so I don't think I'm very motivated to do what you're suggesting. Anyway, coming up with a reasonable way to maintain bitcoin's count in circulation could be argued as being contrary to any system any of us have grown up with, because, in contrast, our current governments do nothing of the sort.

Lost coins are only a problem to the sucker who lost them. His moral right to brute force them back into existence are dwarfed by thieves' motivation, superior mathematics and processing power. Cryptographic rights trump legal and moral.

Aren't they also an unnecessary cause of deflation, given the concept of being able to re-mine them?


Are lost coins somehow more vulnerable to thieves? I'm not understanding what you're suggesting here.

It's like whack-a-mole   :(

Seriously - even 20 years is too short a time for this sort of thing. Consider people jailed for political reasons; they should damn well have their bitcoins when they get out.
I sure as hell don't want to have to destroy my bitbills or casascius coins in a few years, and I might want to put them in a vault for 10 years or more.

For a currency which purports to give *personal* control over your money - this idea is a bad joke.

There's no need to recycle old coins.   If concern about large savings (previously thought lost) suddenly coming onto a market with fewer total bitcoins is an issue in oh.. about 100 years from now; they can deal with that by transitioning to another blockchain entirely over a period of many decades.

Besides, you would never, never ever get any agreement on the issue because the loss of coins naturally raises the value of those remaining, even if by a small amount.

The correct path is to put a small amount of serious effort into making sure your wallet isn't lost.

If you lose your US$ cash no one would seriously suggest they should be re-imbursed (unless you have paid for insurance). Perhaps people worried about this need to start a bitcoin insurance company. Sounds like a new business idea but I have no idea how you would prove the loss of bitcoins.

btc recycling is a bad idea.

It's simpler to make a proxy-currency (with a new block chain and slightly altered economic rules) that can be used for daily transactions which are exchangeable with floating rates to bitcoins which would be used for longer term storage.

Hey Gavin and co., great job man !! I really appreciate and value the hard work that your team and yourself have contributed to the viability of the bitcoin project...keep up the good work. Without your client, I would not have any bitcoins. Thanks again.

I could see a value in recycling bitdust (small transactions that are of very low value, like 0.00004) when their storage cost on the network vastly exceeds their value... but not for any economic theory, just practicality.  I don't want half my hard drive devoted to a collection of gigabytes/terabytes of transactions whose total sum is 1.00 BTC.

Updated.  Thanks Gavin.

Where is best to submit bugs?

git?

Launching bitcoin in Linux takes about 10 minutes for the actual window to show up. Not sure what the deal is here, it's not using a lot of CPU power.
What can I do to debug this?

EDIT: Attaching with gdb prints this output:


Is a bitcoin client with debug symbols available somewhere?

Submit bugs here: https://github.com/bitcoin/bitcoin/issues
Although all of the GUI code is being replaced in the next version, so don't bother submitting UI bugs.

RE: debugging what bitcoin is doing in the 10 minutes it takes for the window to come up:
  tail -f ~/.bitcoin/debug.log
... should tell you what it is busy doing.  Probably loading the block chain and reading the wallet (do you have a very large wallet.dat?)

I have one sending address and three receiving addresses, seems pretty small to me. The following is added to debug.log while bitcoin is waiting to appear:


I'm reporting a bug.