Qoheleth
Legendary
Offline
Activity: 960
Merit: 1028
Spurn wild goose chases. Seek that which endures.
|
|
May 17, 2012, 04:18:27 PM |
|
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...
|
If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the prevalence of users convinced that BTC is a magic box that will turn them into millionaires, and of the con-artists who have followed them here to devour them.
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 17, 2012, 06:54:28 PM |
|
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
|
|
May 18, 2012, 11:39:58 AM |
|
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
Internet detective
Sr. Member
Offline
Activity: 462
Merit: 250
I heart thebaron
|
|
May 18, 2012, 12:50:08 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 18, 2012, 01:52:13 PM |
|
Should be in the getinfo "errors" key. It uses a hardcoded private key to relay across the p2p network.
|
|
|
|
bitlane
Internet detective
Sr. Member
Offline
Activity: 462
Merit: 250
I heart thebaron
|
|
May 18, 2012, 03:10:07 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 18, 2012, 03:18:13 PM |
|
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
Internet detective
Sr. Member
Offline
Activity: 462
Merit: 250
I heart thebaron
|
|
May 18, 2012, 05:23:18 PM |
|
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
|
|
May 19, 2012, 06:01:15 PM |
|
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
|
|
May 19, 2012, 06:12:44 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 19, 2012, 06:52:35 PM |
|
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
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
|
May 24, 2012, 06:31:06 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 29, 2012, 08:05:26 PM |
|
I've put together a chart with the status of listening nodes.
|
|
|
|
ineededausername
|
|
June 04, 2012, 01:54:58 AM |
|
I've put together a chart with the status of listening nodes. 2 32300 ".ljr2" vulnerable Is that you?
|
(BFL)^2 < 0
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 04, 2012, 02:05:50 AM |
|
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
Full Member
Offline
Activity: 222
Merit: 100
www.btcbuy.info
|
|
June 06, 2012, 02:20:21 AM |
|
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.
|
GPG key: 6F8E305690A05365B58C50A
|
|
|
rjk
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
June 06, 2012, 02:22:59 AM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
June 06, 2012, 03:08:15 AM |
|
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
Sr. Member
Offline
Activity: 448
Merit: 250
1ngldh
|
|
June 06, 2012, 03:14:09 AM |
|
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
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
June 08, 2012, 08:56:59 PM |
|
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.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
|