Bitcoin Forum
December 04, 2023, 05:47:14 AM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 »
1  Bitcoin / Armory / Re: Serious usability problems and bugs with armory on: September 17, 2015, 12:58:51 PM
OP: Why did you remove the oh-so-clever memes that were up late last night, showing skeletons representing the bodies of people who never finished syncing? Perhaps the time you spent getting the bile & rage going in your system would've been better served reading earlier posts. If you had, you'd have noticed you're not the only person who has had this issue. (Granted, I admit we could do a better job of explaining certain issues in a more public manner.) Oh well. The pics are here and here in case anybody wants to check them out.

As goatpig said, the Core corruption is beyond our control. We used LevelDB in 0.90-0.92 and migrated to LMDB (a much saner DB) in 0.93. We're working on improving our response to Core corruption. There's only so much we can do, especially on Windows, where LevelDB is a total disaster. Also, while firing off your vague set of specs last night, one thing you forgot to mention was whether or not you're using an HD or SSD. The latter will handle Core and Armory much more gracefully. (Again, this is something that I admit should be explained in public more clearly.)

I'm sorry you're having issues. I also don't know what to tell you, especially if I'm just going to be carpet bombed with profanities in the reply.
2  Bitcoin / Armory / Re: Has an Armory wallet ever been hacked and how can it be protected against if yes on: September 04, 2015, 05:15:58 PM
I'm unaware of any successful hacking attempts made against Armory. The only possibility I can think of would be one where somebody has an unencrypted wallet that gets copied when somebody has physical or remote access to the computer. The solution in that case is quite simple: Encrypt your wallets with a passphrase. Smiley You should never have an unencrypted wallet without very specific reasons, and an unencrypted wallet should never hold more coins that whatever you're willing to lose.

Or, as the last poster said, I suppose a keylogger could steal your passphrase. Not much we can do there, unfortunately. It'd be cool to add some code that understood one's typing cadence and such, and could tell if somebody wasn't you. I'm not going to write that code! (Hell, short of hiring a real expert in that particular field to write it, I'd object to such code being in Armory, period.)
3  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 29, 2015, 07:20:42 PM
Suggestion (possibly devs already thought this):

Create a package that isn't "armory" for the testing releases (armory-testing?).

Rationale: the majority of users still use a monolithic OS; only one instance of a package can be installed on such a machine. There are alot of people out there who might benefit from using this upcoming test release instead of the main release, and the process would benefit from as wide a potential testing base as can be. A separate package would allow those who run release Armory to see whether 0.94, for instance, alleviates their issues or not, without having to contemplate uninstalling "armory-testing" and re-installing Armory main release.

Interesting idea. Admittedly, I'm not entirely sold on the idea of a separate package. There's too great a chance that people will be lazy and leave two copies on their system, potentially leading to weirdness down the road. For example, if somebody had 0.93-testing and tried to go back to 0.92, the Armory DB would keep getting nuked and lead to constant rebuilds.

Unfortunately, I don't think "But only people who know what they're doing will install it!" is correct. It wouldn't be hard for us to miss posts on, say, Reddit, and end up with somebody suggesting people try a test version that fixes one problem but introduces another.

(Just FYI, Reddit was just an example. Some of us do check Reddit on occasion. We typically prefer this forum, though.)

That said, it's something to keep in mind moving forward. Pros and cons, as always.
4  Bitcoin / Armory / Re: stuck or good? on: August 29, 2015, 02:51:01 AM
Oke, using bitcoinqt worked. Took ages but it worked. Started armory and after a while it worked, however...

Sometimes closing armory fails, I need to start bitcoinqt en try to close again.

Latest thing I'm having now: I start Armory and it seems suddenly stuck at organizing blockchain ?!

goatpig can correct me if I'm wrong but my understanding of this is that your blockchain is corrupt. Long story short, Bitcoin uses LevelDB to organize the blockchain, and LevelDB is a massive pile of junk. (Armory also used LevelDB from 0.90-0.92. 0.93 uses LMDB, which is much saner. Anyway....) LevelDB can be easily corrupted, especially on Windows. So, you may have to download the blockchain again and hope for the best. Sad Again, goatpig can correct me if I'm wrong, and give you more specific advice.
5  Bitcoin / Armory / Re: Failed to verify deb package signature on linux mint on: August 26, 2015, 08:04:34 PM
There were some issues with the release scripts that have been fixed. It needs to be discussed internally but I don't see why these changes can't be added to the next release.
6  Bitcoin / Armory / Re: Armory i18n (internationalisation) on: August 20, 2015, 09:55:56 PM
All right... I'll probably be around when a transition happens Cheesy I bet that there are many users who would be willing to help on translations for several languages...

Thanks. I'm sure we'll get the word out once we're ready to handle translations. Smiley
7  Bitcoin / Armory / Re: Offline bundle for newer Ubuntus? on: August 19, 2015, 08:14:43 PM
I didn't have success in setting up clang, so I will be running the provided 0.92.3 offline bundle with Ubuntu 12.04 on my cold storage machine. Thank you to anyone who have helped out in this thread. I am very grateful for that.

I think the later 92.x releases use the newest transaction file format, Armory devs will know the full details on that sort of thing. So you're not missing much in the difference between 0.92.3 and 93.2 (no deterministic signing, for instance).

For offline machines, yes, this is basically correct. There is a bug (fixed in 0.93.2, IIRC) that does affect signatures and has a 1-in-256 chance of being triggered. That could be a problem depending on luck and how often transactions will be signed. (Then again, the bug may have been introduced in 0.93! I forget exactly where all the code was introduced.)
8  Bitcoin / Armory / Re: Offline bundle for newer Ubuntus? on: August 19, 2015, 02:58:45 PM
To make the .deb, try this script:

I'm not all that familiar with it but this is what etotheipi used to build 0.92 at least.

That script also requires some extra attention if you want to create an offline bundle. This link (WARNING: Massive amounts of techno-babble) and some follow-up posts roughly describe the process for building offline bundles.
9  Bitcoin / Armory / Re: Armory i18n (internationalisation) on: August 19, 2015, 02:53:12 PM
The work isn't finished. Long story short, the ideal solution is to upgrade the Armory codebase to Python 3, which has much better internationalization/Unicode support. It's far more difficult under Python 2, and prone to weird bugs too. IIRC, we had one translation (Icelandic?) we tried sticking in. We found that it broke a lot of our code and had to abandon it.

The aforementioned Python 3 upgrade is something that must come sooner or later. The question is when exactly we will make the jump. It definitely won't be in time for 0.94. Honestly, I'd be surprised if anything is released before the year's out, but that's just a personal opinion, not official policy. I've been surprised before. Smiley
10  Bitcoin / Armory / Re: Armory - Discussion Thread on: August 16, 2015, 11:22:32 PM
It is thread 5:

Thread 5 Crashed:
0              0x0000000104e3a3c6 StoredHeadHgtList::unserializeDBValue(BinaryRefReader&) + 470
1              0x0000000104e3a694 StoredHeadHgtList::unserializeDBValue(BinaryDataRef) + 52
2              0x0000000104e157b3 LMDBBlockDatabase::getStoredHeadHgtList(StoredHeadHgtList&, unsigned int) + 179
3              0x0000000104e1494e LMDBBlockDatabase::putBareHeader(StoredHeader&, bool) + 302
4              0x0000000104e94e25 Blockchain::putNewBareHeaders(LMDBBlockDatabase*) + 309
5              0x0000000104e4e131 BlockDataManager_LevelDB::loadDiskState(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool) + 2945
6              0x0000000104ea5af2 BlockDataManagerThread::run() + 578
7              0x0000000104ea57f9 BlockDataManagerThread::thrun(void*) + 9
8   libsystem_pthread.dylib        0x00007fff91c5305a _pthread_body + 131
9   libsystem_pthread.dylib        0x00007fff91c52fd7 _pthread_start + 176
10  libsystem_pthread.dylib        0x00007fff91c503ed thread_start + 13

Ah ha. That is definitely Armory code.
11  Bitcoin / Armory / Re: Bitcoin Core / Bitcoin XT on: August 16, 2015, 06:43:30 PM
AFAIK, XT hasn't changed the names of any of the binaries. You may need to use command line args like "satoshi-datadir" to point to particular directories, and maybe turn off auto-management and run bitcoind manually. (I don't remember offhand if you can tell Armory where to find bitcoind. I think you can.) That should be it.
12  Bitcoin / Armory / Re: Bitcoin Core / Bitcoin XT on: August 16, 2015, 02:41:34 AM
As I understand things, Armory shouldn't have any problems if it encounters bigger blocks. If there are bugs, fixing them should be pretty trivial. Core/XT does the actual block validation. Armory then runs with the ball and is more concerned with the block's transactions, which aren't affected by the blocksize debate.

(If I'm wrong about any of this, I'm sure other developers will correct me. Smiley )

are you saying Armory does not actually validate blocks? or can you elaborate this more pls? (i think you're saying we can switch bitcoin core with XT no problem as Armory just rely on them....)

But i still hope Armory team make a thread to clarify all this.


Okay. Here's my understanding. Core already does a lot of heavy lifting. It validates blocks, does a lot of work to validate the transactions, etc. It wouldn't make sense for us to turn around and say, "Well, we need to do our own block verification scheme." Instead, we trust whatever comes out of Core, although we obviously need to have some processing logic in order to read the blocks and transactions, along with writing transactions.

In addition, when creating a Tx, we don't actually fire it onto the Bitcoin network ourselves. We form something that should be valid and feed it to Core, letting Core once again do the heavy lifting. If the Tx goes through, cool. If not, we try to give info to the user explaining what might have gone wrong.

Like I said, I could be wrong about some of the details. I'm pretty sure this is correct, though. It just doesn't make sense to, say, take several hours to download the blockchain (including time to verify the blocks) and then take several more re-validating everything. We trust that Core will provide us with good data. This has led to certain issues, like when the blockchain isn't complete. (Core apparently validates a block and then attempts to write it to a file. If the write fails, Core won't care. Obviously, this leads to weirdness with Armory.)
13  Bitcoin / Armory / Re: Bitcoin Core / Bitcoin XT on: August 15, 2015, 11:33:52 PM
I haven't tested it personally. I think a user tried it with a pre-0.11A version and said it worked fine.
14  Bitcoin / Armory / Re: Bitcoin Core / Bitcoin XT on: August 15, 2015, 10:10:35 PM
As I understand things, Armory shouldn't have any problems if it encounters bigger blocks. If there are bugs, fixing them should be pretty trivial. Core/XT does the actual block validation. Armory then runs with the ball and is more concerned with the block's transactions, which aren't affected by the blocksize debate.

(If I'm wrong about any of this, I'm sure other developers will correct me. Smiley )
15  Bitcoin / Armory / Re: Offline bundle for newer Ubuntus? on: August 12, 2015, 09:17:22 PM
I'm not aware of any such plans at the moment. That said, we are working on a setup that should make it easier to support multiple offline bundles. No promises but hopefully the stuff we're working on will make bundle support much easier.
16  Bitcoin / Armory / Re: Run Bitcoin Core and Armory on separate computers. on: August 12, 2015, 03:10:26 PM
AFAIK, this wouldn't work, at least not with the way Armory's set up. You could store and/or read the data on a networked drive but that's it.
17  Bitcoin / Armory / Re: Armory - Discussion Thread on: August 12, 2015, 01:42:50 AM
Hello. Is thread 0 the one that actually crashed? It could be a different one. The crash report will always say which one it is.
18  Bitcoin / Armory / Re: Can I update my offline wallet without losing bitcoins on: August 05, 2015, 11:08:29 PM
IIRC, all pre-0.90 versions didn't use a DB. Instead, they tried to load the entire blockchain into memory. So, 0.87.2 is going to try to load something like 50 GB of data into RAM. I'd imagine this isn't feasible on your system.

AFAIK, you're best off just upgrading to the latest Armory (0.93.2) on both your online and offline systems. You shouldn't have any problems loading your wallets, although the online system will need some time to build the DB. No matter what, be sure to back up your wallets, either in paper or digital form.
19  Bitcoin / Armory / Re: What disk space is needed with 0.93.2 ?? on: August 05, 2015, 06:08:03 PM
Yeah, you'll be fine. Also, if you upgrade to 0.94 when it comes out, the amount of space will be cut by about half. My pre-release, fully synced Armory 0.94 DB is ~175 MB, with ~46 GB worth of blocks and another 1 GB worth of "chainstate" data under BC Core.

I don't want to eat up expensive SSD space, so I think there is a way you can point to use another drive for the database. I didn't spend bookoo money on an Intel 750 SSD for an 100GB blockchain DB.

One of these days the DB will just be too large for local machines. Unless developers figure something out I guess.

There are two command line options. Use the "--datadir" option to change the Armory home directory (not that big a deal once 0.94 is released), and the "--satoshi-datadir" option to change the Bitcoin home directory (much more important since you'll still need a full blockchain).
20  Bitcoin / Armory / Re: Armory - Discussion Thread on: August 03, 2015, 02:14:28 AM
My armory breaks down every time I start it. Or better: as soon as it is connected to BitcoinQT (while organziing blockchain). I have the latest version of BitcoinQT and Armory. It was everything ok for weeks. But today it happend EVERY time (I tired at least 10 times, reboot, ...) I have a mac.

Any hint what I should do? Rebuilt blockchain? Reinstall Armory?

I use Armory on my Mac often and very rarely see crashes. I've heard some people are still having performance issues. My theory is that Qt (an underlying library) just doesn't play nice with some Macs due to threading issues. I've been trying to make some noise and get this investigated. If anybody would like to help me out, please upvote this bug. The patch I posted there doesn't fix everything but it does fix a lot of issues. Maybe drawing more attention to it will lead to more long-term fixes.

*jumps off soapbox* Anyway, regarding this crash, if it happens again, look for the following bits of info.

Crashed Thread:        8


Thread 0:: Dispatch queue:
0   libdispatch.dylib                0x00007fff8b59f7f8 _dispatch_queue_wakeup_with_qos_slow + 1075
1                 0x00007fff8d155bed PerformBlockWithThemeRegistry + 102
2                 0x00007fff8d155e7e _LookupThemeProvider + 232
3                 0x00007fff8d1391e1 -[CUIThemeFacet _approximateRenditionForRenditionKey:] + 109
4                 0x00007fff8d13e706 -[CUIThemeFacet imageSize] + 83

The crashed thread will test you which trace to post, which is the gobbledygook at the bottom of my quote. I'm guessing it'll be a Qt issue but I could be wrong.

Also, just curious, do you put your Mac to sleep often? I do get the odd crash on Yosemite after I've put my Mac to sleep something like 12-15 times, along with other odd behavior. Some of it might be Armory - I'm investigating right now - and some of it is almost certainly Qt (or Yosemite causing Qt to freak out).
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!