Rampion, can you file a support ticket and include both your logs (armorylog.txt and armorycpplog.txt) and the stack trace that comes up when the code crashes? In the meantime, can you try something for me? Can you create a directory called "ArmorySatoshiTest" and then run Armory from the command line? Use the following steps, with the assumption that the directory is on the desktop. 1)Open the terminal. 2)cd *Armory location*/Armory.app/Contents/MacOS 3)./Armory --satoshi-datadir="/Users/*your username*/Desktop/ArmorySatoshiTest" This will cause the blockchain to be downloaded again. Sorry! We definitely need this step to troubleshoot what's going on, unfortunately. Thanks! Sorry for the late reply - I've been away from my computer in the last two weeks. I already sent some logs on 20/2 - I have since then reverted to 0.92.3 (and still using BC 0.10.0) and for now everything is working OK. |
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times  How did you delete the old DB? Within Armory? Or manually deleted the folder? I just realized we probably haven't had much testing of the wipe-old-databases-and-rebuild process. A log file through our support channel would be great. @doug_armory: can you test this in OSX? Based on another report from earlier, this might be OSX-specific. I deleted within armory - it asked me if i was not going to downgrade, i said no, so it deleted the db. |
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times Force the dbdir to something else how do i do that? |
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times |
|
|
|
That's not to say it couldn't be done on Linux or Mac ... but simply those weren't the target platforms. And this is literally the most advanced malware on the planet, so we can hope that there's a high barrier to entry to replicate this on the other OS (as I write this, I realize there's no guarantee that they haven't already...)
The only "good" thing there is to say about this in connection with Armory is that these guys are professionals with huge budgets. They are not going to expose themselves by stealing our meagre bitcoin stashes. That gives us a short respite, at least until this malware leaks into the hands of the common criminals. Who will probably mainly go after the home banking password.  Today's NSA malware is tomorrow's bitcoin thieves malware. That's a fact. We must be prepared for the worst (firmware level malware). |
|
|
|
Don't see 0.92.99.7-testing, it says last update retrieved 4 months ago, maybe because I have my system set up to run through Tor?
EDIT: I managed to reactivate secure download by tweaking the "privacy setting", but i see 0.92.99.7 only on Windows - I'm a mac user.
Oh, the navigation system for that is a mess, and I've been meaning to rework it. Select an earlier version of OSX than the latest. You should then see it. Yep, I see it if I select as an OSX version 10.9.4 or lower... If I select 10.10 only 0.91.2 appears (?) |
|
|
|
|
Don't see 0.92.99.7-testing, it says last update retrieved 4 months ago, maybe because I have my system set up to run through Tor?
EDIT: I managed to reactivate secure download by tweaking the "privacy setting", but i see 0.92.99.7 only on Windows - I'm a mac user.
|
|
|
|
Oops, I just updated to Bitcoin Core 0.10.0 and fired up Armory 0.92.3, it looks stuck on "building databases"... Did I screw up?
Use the secure downloader to grab 0.92.99.7-testing. It's a release candidate and should be officially renamed to 0.93 tomorrow (or latest Monday). You'll wipe the DBs, but the rebuild is super fast! Thank goatpig for that OK, will do that... BTW, Armory 0.92.3 finally built the database and displayed the correct balance, so I guess is somewhat compatible with BC 0.10.0 |
|
|
|
|
Oops, I just updated to Bitcoin Core 0.10.0 and fired up Armory 0.92.3, it looks stuck on "building databases"... Did I screw up?
|
|
|
|
|
Yo simply cannot hack a cold wallet, therefore:
a) it wasn't a cold wallet
b) somebody who had physical access to the wallet stole the coins.
There are other options (wallet created with compromised software; RNG/entropy problem) but those are extremely unlikely. You can put all your money on either a) or b).
|
|
|
|
At the end what do you think? Will the Greece get out from the Europe this year or not ?
As I wrote earlier: no because Greece location's is too important for NATO. Greece is one of the most important ports in the Mediterranean Sea. The Greek islands are full of NATO military bases. NATO wouldn't want Greece to get closer to China/Iran/Russia, which you can bet they would do if they get kicked out from the Euro. |
|
|
|
Quick question: how are Bitstamp's fiat withdrawals working lately? I always had no problem with them, but after the hack I never requested any withdrawal, and I may need to request a bigger one in the next couple of months.
Any experiences with that? Withdrawals as smooth as usual?
I need to know that too! anyone ? I guess no news is good news? Anyhow this silence is quite unsettling  |
|
|
|
|
Quick question: how are Bitstamp's fiat withdrawals working lately? I always had no problem with them, but after the hack I never requested any withdrawal, and I may need to request a bigger one in the next couple of months.
Any experiences with that? Withdrawals as smooth as usual?
|
|
|
|
nobody wants to have to hard fork every year
That's stupid, because that's not what the guy was suggesting. His idea can be implemented in a single hard-fork implementing a *rule* not yet another hardcoded magic number. Exactly. I just think that rule should be very well thought. If it is not done right just doubling the block size limit once the current limit is approached is just like not having a block size limit at all. Some spam-prevention mechanism should be in place to avoid blocks growing non-stop because of some sort of spam attack. Maybe it would be enough to have a rule that says that the block size limit should be approached for long enough to make such an attack economically unfeasible. |
|
|
|
|
Why don't we just double the block size limit when we approach it? We could do it every time the limit is approached.
That seems more sensible than just making it x20 in one go.
|
|
|
|
|
Greece is too importante geopolitically to exit the Euro. That would automatically mean Greece getting closer to Russia/Iran/China, which NATO wouldn't like at all.
Greece is one of the most important ports in the Mediterranean sea, imagine how happy would Obama be if the NATO bases in Greek islands are replaced by Russian military bases.
|
|
|
|
|
Raspberry PI is perfect, but so it is any old computer you have lying around and that you would otherwise throw away.
I'd just recommend Ubuntu or any other Linux flavour, especially for the online instance.
|
|
|
|
|
Ridiculously obvious scam.
|
|
|
|
collapsing hashrate
Collapsing hashrate? The hash-rate at the last difficulty re-target (12/01) was 314,761,417 GH/s - the higher hashrate we ever had. Please point out some hard numbers (taking into account variance) that supports your "collapsing hashrate" theory. 12 minute blocks today reported by https://blockchain.info/de/stats not 10 minute blocks LOL at 11.43 minutes blocks meaning a "collapse" in the hashrate. Look at the chart below. Hashrate already "collapsed" a few times in the past. Mid 2009, end of 2011, end of 2012. So what? Bitcoin died?  |
|
|
|
collapsing hashrate
Collapsing hashrate? The hash-rate at the last difficulty re-target (12/01) was 314,761,417 GH/s - the higher hashrate we ever had. Please point out some hard numbers (taking into account variance) that supports your "collapsing hashrate" theory. |
|
|
|
|
Show Posts
