Topic: [ANN] Critical vulnerability (denial-of-service attack) (Read 25839 times)

Interesting!!!! I didn't realize that actually have already happened once. So, I guess, that illustrates my point very nicely, how much the whole community depends on a small number of developers. It is very good to know that they already handled such situation appropriately, kudos to devs.

Yet, it also confirms that there ARE reasons to be concerned. We are all humans, and there are organizations out there, which wield significant power, and can put enormous pressure on a person. There would be significantly more certainty if there was a client, code of which never gets touched.

Bitcoin has had to rolled back up to 53 blocks before (CVE-2010-5139), so I wouldn't say it's impossible. Integrity of the currency comes before miners' income.

And this is what you don't realize, and many people don't either. With too-widespread software flaw, you can lose bitcoin EVEN if nobody picks your private key, or hacks into your PC. The bitcoin network is only as good as the software. If there is a critical bug introduced, and too many people use the client that has this bug, you could push through any transaction you want. Those would technically be invalid transactions, and clients not affected by bug would reject them, but if too many clients will accept, it will become de-facto a new block. And once a bunch of blocks are stacked over invalid block, it will be practically impossible to rollback. So, your paper money would lose the balance and you wouldn't even know.

This is why, to my mind, it is so important to have the most basic, the most minimal client possible.

Command line daemon could have been it, but unfortunately there are known, 100% reproducible bugs in it, such as this one, that have been there for years, and nobody would put a permanent fix. I realize, I'm jumping from a critical bug scenario to the one of real low priority, but bugs like that are the reason not too many UIs exist for a daemon

"WARNING: Displayed transactions may not be correct!  You may need to
upgrade, or other nodes may need to upgrade."

  I had that message! I then tried to upgrade and nearly lost my wallet!

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.

From the bitcoinarmory.com website:


Although I believe etotheipi is planning on changing that.

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

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.

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.

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

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

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.

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.

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

      2 32300 ".ljr2" vulnerable

Is that you?

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

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?

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

Nevermind, I got it to run. 

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?

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

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

Thanks.

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

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