Wallet encryption bug found (IMPORTANT!)

[Bitsky]

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

Maybe a bounty system would work. Depending on the severity of the bug you earn a few BTC for reporting it.

[1714113487]

1714113487

[1714113487]

1714113487

[1714113487]

1714113487

[1714113487]

1714113487

[1714113487]

1714113487

[deepceleron]

It's too late for a lot of testing, you can't just fuzz test Bitcoin without setting up your own gapped network of nodes and doing lots of mining first. Lets say a bug was introduced where if you send an address starting with 11 over 2^40 base units, the transaction's output address gets messed up? Oops if you are the one to find that.

I guess hex searching your hard drive for private keys before and after a 0.4.0 upgrade with encryption would be the big test that wasn't done...

[jkminkov]

The only inconvinience is that the wallet password must be supplied every time when starting bitcoin client, not only when sending coins.

Which totally defeats the purpose of wallet encryption. If you're going to do it that way, you might as well just encrypt on backup only (which would be a very nice feature anyway...)

The encryption of only private keys are no solution either. Just wait until victim sends the coins to someone, then recover the password using keylogger. It can only protect against trivial attacks such as grabbing the wallet.dat file right away. There is no real way of securing the wallet.dat file on compromised computer. But if I use encryption, I would like the whole wallet.dat to be encrypted, so even if shit hits the fan and my wallet.dat is leaked, all my adresses are not disclosed to attacker.

put virtual keyboard in client, so user picks letters/symbols with a mouse and keyloggers defeated

[Luke-Jr]

IMO, You guys need to figure out an organized way to fund Gavin's work.

IIRC, Gavin is paid full time for Bitcoin development as well as some other guy for Bitcoin QA.

[kgo]

I know this doesn't solve the problem of lack of QA, but the only reason I know about this problem is because I decided to read some threads with people arguing that are always in the "Bitcoin Discussion" forum.

It'd be nice if this information was on the bitcoin.org homepage.

It would be really nice if there was a release/security-issue mailing list I could subscribe to.  (I know it's not much work, but if you need a volunteer I'll be happy to setup a moderated list on google groups or something like that.)

This would also make it more likely that I personally would run release candidates, betas, etc.

[kgo]

I know this doesn't solve the problem of lack of QA, but the only reason I know about this problem is because I decided to read some threads with people arguing that are always in the "Bitcoin Discussion" forum.

It'd be nice if this information was on the bitcoin.org homepage.

It would be really nice if there was a release/security-issue mailing list I could subscribe to.  (I know it's not much work, but if you need a volunteer I'll be happy to setup a moderated list on google groups or something like that.)

This would also make it more likely that I personally would run release candidates, betas, etc.

Well I guess it looks like such a list is already active on sourceforge, but it isn't documented anywhere, and doesn't have emails for RC's or security advisories.

[finway]

Lucky i don't leave a raw "encrypted" wallet .

[Gavin Andresen]

Features seem to be considered stable way too quickly. I'd like a version scheme like this:
- Add new features to 0.5.
- At some point, stop adding new features to 0.5 and call that the "unstable" release. Start adding new features to 0.6.
- 0.4 remains the "stable" release for at least 6 months, and it is recommend that newbies use this version. The unstable version is also available in binary form and can be easily used.
- Once 0.5 has been unstable for 6+ months, call that one stable.
- As many past 0.x releases as possible continue to get bugfixes for people who like to use really stable software.

I'm still using 0.3.19, and it works fine with only a few modifications. I avoided several bugs by doing this.

Once this problem is fixed, it would be a good idea to issue an alert for users of affected versions. Maybe not many users are affected, but it seems irresponsible to not notify these users when they can be notified.

Luke-Jr is planning on supporting 0.4-based releases (finding somebody to fix wxWidgets-related bugs is an issue, though).

The issue I have with calling any pre-1.0-release 'stable' is it implies a level of maturity that I don't think we're at yet. I can see 1-year develompment->unstable->stable release cycles once we're at a solid Bitcoin 1.0 release that I can actually feel comfortable recommending to my non-geek relatives.

My fear is that developers would happily code away and use the development branch, bugs would pile up against the unstable branch (and would get ignored because developers were happily coding away on dev, and nobody really wants to do bug fixing or QA testing), and unstable would never become stable enough to tag 'stable.' But I've never led an open source software project before, so I might very well be wrong (best way to convince me is to point to other small open source projects that we can emulate-- I don't think emulating big projects like Ubuntu will work).

I agree that when a fix has been tested and is available an alert to the affected versions is a good idea.

IMO, You guys need to figure out an organized way to fund Gavin's work.

IIRC, Gavin is paid full time for Bitcoin development as well as some other guy for Bitcoin QA.

Unfortunately, TruCoin ran into a funding crunch because an investor got cold feet and had to stop paying for anything besides directly-related-to-TruCoin work.

[michaelsuede]

Would it be possible to leverage the ability of major community stake holders (Mt. Gox, Pool Operators) to incentivize or encourage activity on the testnet for new builds?

I think something along these lines is a good way to ensure proper testing.

The use of a reward type system would be ideal.

For example, a set reward amount, to be awarded by private exchange or business owners, for discovering a bug.

If I were to test the code and get a reward from the community for each bug discovered, I would be much more motivated to do so.  The higher the reward, the higher the incentive for bug testing.

Another way of funding: Say in the client, put in an option to auto-contribute a tiny portion of each transaction to a bug testing reward pool that people may chose to opt into.

Something else to consider:  a bug testing reward tracking website that people could also contribute to?  Perhaps funded by auto-contributions from the client?

[Luke-Jr]

If anyone has unexpectedly leaked their wallet as a result of this, I am willing to offer 0-fee acceptance of a single transaction of any legit size via Eligius, under the following conditions:

• This offer expires 3 months after a fixed GUI (or bitcoind, whichever is later) client is released
• All inputs must be from transactions confirmed earlier than this post (exceptions might be made on a case-by-case basis)
• I must either already trust that you can be found reliably before making this post (ie, you're a regular who's been part of the community for a long time) or I will need some way to verify your full name and address.

I'm not happy entirely with the last requirement, but it's the only way I can think of to ensure thiefs can't abuse this offer. If you prove your identity to me, I promise not to share it except if subpoena'd (eg, by someone else who claims to own the coins and has already filed a lawsuit against you).

Please contact me directly if you have leaked your wallet and want to take advantage of this. Also note that I am not offering to help create the transaction for you (that's your responsibility), just accept it.

[molecular]

It is embarrassing and astonishing that this critical a bug was not caught before the 0.4 release; constructive suggestions on how to improve the testing and release processes that do not assume access to hundreds of thousands of dollars of funds to hire security consultants or QA teams are welcome. Getting sufficient testing of code BEFORE it is released has been a chronic problem for this project.

Don't know who would come up with the money for it, but it wouldn't be hundreds of thousands of dollars: Maybe offer BTC-bounties for bugs found in "official test releases". They probably wouldn't have to be high to motivate people in the bitcoin community to do better testing than is done now.

About coming up with the money: I've had quite some success (although not yet what I hoped for) with collecting donations for a common cause (https://bitcointalk.org/index.php?topic=51133.0). Maybe enough people would be willing to donate to "bitcoin testing", especially after things like the encryption bug or maybe even more serious stuff happen.

[niko]

Is there anything an average Windows user without much programming experience could do to help with testing? Do all you experts and "experts" realize how obscure things are?  I looked at the development subforum, hoping to see a stickie. Nothing. I looked at bitcoin.org. Nothing. I looked at sourceforge. No leads. Sure, from random posts on this forum I infer that there is something called testnet, but I have no idea if and how I could help running a client on it.

How can I help at this stage of bitcoin development?

[foo]

Sure, from random posts on this forum I infer that there is something called testnet, but I have no idea if and how I could help running a client on it.

You forgot to check the Wiki.

https://en.bitcoin.it/wiki/Testnet

[niko]

Sure, from random posts on this forum I infer that there is something called testnet, but I have no idea if and how I could help running a client on it.

You forgot to check the Wiki.

https://en.bitcoin.it/wiki/Testnet

I sure did forget, thanks! 

[bitcoinspot.nl]

So, if i understand it correctly:

1: the fix is still being worked upon ?
2: Gavin has troubles with funding the work on the client ?

Greetz.

[P4man]

Don't know who would come up with the money for it,

We all should. Why not include a donation option in the client? Make it optional, but set it by default so that 0.01% or whatever of each transaction is donated to a fund used to pay Gavin, other developpers and for bug bounties.  There was talk of a bitcoin foundation a while ago, not sure how thats going, but they could manage those funds.

In fact, even making such a donation mandatory wouldnt be such a bad thing, like a tobin tax, or like the transaction fees we already pay to miners. Although of course some people will just fork and use a client without the "tobin tax", if you set a hardcoded lower limit low enough, most people wouldnt mind I think.

[molecular]

Sure, from random posts on this forum I infer that there is something called testnet, but I have no idea if and how I could help running a client on it.

You forgot to check the Wiki.

https://en.bitcoin.it/wiki/Testnet

That indeed explains what testnet is. That's not the only thing that was asked for, I think.

I think niko was looking for a place where "normal users" would be able to obtain information on how they could help with testing. Such a place would include

• explanation about what "testnet" is
• information about the planned release milestones and testing timelines
• downloads of test releases
• information on how to submit bug reports and other test results.
• info about how to test
• info about what needs testing and maybe current status

I'm sure the information is out there, it's just not easy to get to it if you're not quite heavily involved on developer mailing-lists, github, #bitcoin-dev, etc...

In other words: the bitcoin developer circle is quite a hard place to get into for joe schmoe, am I right? So maybe it would be cool to somehow make it easier for the "normal user" to help.

[molecular]

Don't know who would come up with the money for it,

We all should. Why not include a donation option in the client? Make it optional, but set it by default so that 0.01% or whatever of each transaction is donated to a fund used to pay Gavin, other developpers and for bug bounties.  There was talk of a bitcoin foundation a while ago, not sure how thats going, but they could manage those funds.

I agree.

In fact, even making such a donation mandatory wouldnt be such a bad thing, like a tobin tax, or like the transaction fees we already pay to miners. Although of course some people will just fork and use a client without the "tobin tax", if you set a hardcoded lower limit low enough, most people wouldnt mind I think.

I don't agree. It'd be very bad from a marketing point of view to make such a mandatory "tax". I'm experiencing a lot of troubles marketing bitcoin to friends (key import/export is a big one, by the way, because I use casascius coins to get people started, they inevitably want to see proof that it's working (and it's a big "AHA", when it finally does). Fiddling with pywallet ("what? that's not even in ubuntu repository") and having the client "stuck on blockchain rescan" with no gui showing for minutes ("that pywallet screwed up bitcoin, now it doesn't start any more, glad I have a backup") doesn't help the cause. But that's a different matter).

Having a tobin tax would only add to the troubles I'm having "selling" bitcoin to people.

[P4man]

Its just the name you object to I think. There already is such a "tax"in the form of transaction fees. Now they benefit miners, I dont see why we could not redirect part of it to a bitcoin foundation.

[molecular]

Its just the name you object to I think. There already is such a "tax"in the form of transaction fees. Now they benefit miners, I dont see why we could not redirect part of it to a bitcoin foundation.

The difference between "bitcoin foundation" and "miners" is (lack of) decentralization, one of bitcoins main selling points.

I'm not against "bitcoin foundation" at all. But they shouldn't get to put "developer fee" code into the client (to avoid the evil "tax" word here). I probably wouldn't mind myself, but explain that to someone you just explained the coolness of decentralization and "basically free" transactions. It's hard enough to explain the tx fees, but it usually works out with a nice AHA-effect in the end when you explain mining incentive after block reward drops to close to nothing.