[ANN] Critical vulnerability (denial-of-service attack)

[Qoheleth]

Can Qt version be made to look and function indistinguishable from wx?

Probably. Does wx have a consistent look? I thought it just wrapped GTK+ :p
As for function, it should be possible, though probably a lot of work.

wx wraps whatever your native window drawing library happens to be. So GTK+, or Aqua, or whatever the heck Windows uses...

[1713427721]

1713427721

[1713427721]

1713427721

[Luke-Jr]

Can Qt version be made to look and function indistinguishable from wx?

Probably. Does wx have a consistent look? I thought it just wrapped GTK+ :p
As for function, it should be possible, though probably a lot of work.

wx wraps whatever your native window drawing library happens to be. So GTK+, or Aqua, or whatever the heck Windows uses...

It doesn't wrap native here. I use a Qt-based system.

[ssaCEO]

Is there something about 0.6+ that refuses to read block chain files copied in from earlier versions? Just built it, but every time I run it, it ignores the blk*.dat files and deletes the __db.* files from the configuration directory. Then it tries to reload the whole block chain off the network. I wouldn't mind doing that on a spare machine, but now I'm worried if I do let it run, then when I copy the directory over to a hot machine it'll just start all over again.

Has anyone else run into this problem?

[bitlane]

Stupid question, although I think someone else was wondering the same...

How was that mass 'vulnerability' message sent and displayed within the affected Bitcoin GUIs/Clients ?

I saw that (in the lower left of my Bitcoin-QT Windows GUI) before I saw the forum warning....

I guess what I am most wondering is, what call was used on the client-side to retrieve that warning ? (getmininginfo.something ?)

I would like to be able to display future warnings etc in my Web Mining monitor, that I also display other BTC info in using API calls.

[Luke-Jr]

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

[bitlane]

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

Thanks.

Can I use getinfo()'errors' to display future message broadcasts in a web app ?

[Luke-Jr]

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

Thanks.

Can I use getinfo()'errors' to display future message broadcasts in a web app ?

Should be fine, though I'd advise against posting it publicly, just in case some attacker is googling for vulnerable services.

[bitlane]

Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.

Thanks.

Can I use getinfo()'errors' to display future message broadcasts in a web app ?

Should be fine, though I'd advise against posting it publicly, just in case some attacker is googling for vulnerable services.

Of course. It will just be on my local mining monitor app for CGMiner.
Thanks again.

[geek-trader]

The QT version won't run on my minimal linux machine.  I've been running 0.4.0 forever.  Where can I find this 0.4.6 backport you speak of?

[geek-trader]

The QT version won't run on my minimal linux machine.  I've been running 0.4.0 forever.  Where can I find this 0.4.6 backport you speak of?

Nevermind, I got it to run. 

[Luke-Jr]

The QT version won't run on my minimal linux machine.  I've been running 0.4.0 forever.  Where can I find this 0.4.6 backport you speak of?

https://bitcointalk.org/?topic=79651

[rav3n_pl]

Since update I see some lags caused by bicoind/bicoin-qt. From time to time (even every 10 sec) bitoin is eating full cpu for 0.5-1 second freezing my machine. Any1 noticed this?

[Luke-Jr]

I've put together a chart with the status of listening nodes.

[ineededausername]

I've put together a chart with the status of listening nodes.

      2 32300 ".ljr2" vulnerable

Is that you?

[Luke-Jr]

I've put together a chart with the status of listening nodes.

      2 32300 ".ljr2" vulnerable

Is that you?

No, that's an ancient version I made in early 2011.

[coga]

I wanted to add here that it is worrying, how much power here is vested in developers. And as much of a great job they do, they do make mistakes. Every time I have to upgrade, there is always a thought on the back of my mind - what if there is a vulnerability or exploit? Even worse is that even those of us who don't upgrade for that reason still depend on the 50% of other nodes to be not vulnerable

At this time most nodes upgraded to the new version, and it is behemoth. Satoshi's client was no fun, but compared to amount of code in the current version, it is nothing! It is simply impossible to tell that there is no hack/vulnerability/backdoor in all this code. Even if there is not any in the bitcoin code per se, there is no way to tell about all dependent libraries. So, at this time,  everybody runs this oversized, unreliable client, and why? Because there is bug, and nobody maintains original daemon, so the latest one is the one fixed.

I'd say, if bitcoin community ever gets to the times when network could run safe, robust, and reliable, it will be when a stable, simple client goes out, which does only what is needed, and nothing more, and the code gets frozen, except for security updates. GUI shouldn't be part of the client, especially when client already supports xml-rpc to perform the tasks. When there is an issue with the code, but GUI has the ways to go around it, that leads to the bugs, that never get fixed, that go unnoticed.

I beg developers: please focus on the core. Make it stable. Bring the daemon to the state, where it is usable by external GUIs, and let them have at it. There shouldn't be a way for dev to destroy bitcoin by mistake of developer.

[rjk]

The daemon is already useable by external GUIs, and is also much more stable when performing that task. Take for instance the Armory client which uses bitcoind in the backend. There are others as well.

You don't have to have the GUI to run the daemon; indeed you shouldn't even need to look at a single line of QT code at all.

[Luke-Jr]

At this time most nodes upgraded to the new version, and it is behemoth. Satoshi's client was no fun, but compared to amount of code in the current version, it is nothing!

Huh? Bitcoin-Qt is much lighter and abstracted in comparison to the old wxBitcoin...

It is simply impossible to tell that there is no hack/vulnerability/backdoor in all this code. Even if there is not any in the bitcoin code per se, there is no way to tell about all dependent libraries.

We (especially Gavin) have been working on unit tests to ensure changes don't affect behaviour of the client. This is a big step forward in being able to audit changes. Additionally, many developers (including myself) read every single commit (or at least most) - so anything fishy should get picked up.

So, at this time,  everybody runs this oversized, unreliable client, and why? Because there is bug, and nobody maintains original daemon, so the latest one is the one fixed.

Why do you say nobody maintains the original bitcoind? I've been maintaining it since 0.4 - the current version of which is 0.4.6 and has this vulnerability (as well as the others) fixed. The stable branches only get bugfixes and mandatory protocol updates.

Bring the daemon to the state, where it is usable by external GUIs, and let them have at it.

That's a goal, but it's unfortunately a far way off

The daemon is already useable by external GUIs, and is also much more stable when performing that task. Take for instance the Armory client which uses bitcoind in the backend. There are others as well.

I'm pretty sure Armory doesn't really use bitcoind, just the files bitcoind makes/maintains... Spesmilo does try to use bitcoind.

[rjk]

I'm pretty sure Armory doesn't really use bitcoind, just the files bitcoind makes/maintains... Spesmilo does try to use bitcoind.

From the bitcoinarmory.com website:

Also, Armory does not use independent-networking.  It can be thought of as an “add-on” to the regular Satoshi client (www.bitcoin.org), which needs to be running in order for Armory to work.  In the future, Armory may integrate networking components of the Satoshi client directly, so that all features are integrated into a single program.

Although I believe etotheipi is planning on changing that.

[casascius]

I wanted to add here that it is worrying, how much power here is vested in developers. And as much of a great job they do, they do make mistakes. Every time I have to upgrade, there is always a thought on the back of my mind - what if there is a vulnerability or exploit? Even worse is that even those of us who don't upgrade for that reason still depend on the 50% of other nodes to be not vulnerable

This doesn't bother me one bit as I keep most of my coin on paper wallets.  My exposure to a client bug is always limited to the amount of coin I have online at any given time.

I wish the idea of putting bitcoins on paper had more favor with the developers and was considered an important feature for the client.  "Click File, Print, Print Money.  Be your own bank."  Specifically, having the private key sweep/import feature exposed in the UI and for it to not need a full blockchain scan to execute would go a long way toward users ability to protect themselves from risks, including future client bugs.  The more this feature is offered by lightweight clients, the fewer full bitcoind nodes there are going to be on the network as people choose those other clients.