[ANN] Armory 0.93.1 Official Release

[sflicht]

sflicht:

You either let Armory manage bitcoind for you, or you start BitcoinQt manually and let it sync fully before you start Armory. Instead, you are starting BitcoinQt and letting Armory run on top of a blocks folder that Core is still indexing through milestones hashes, which guarantees you'll run into missing block data. Let BitcoinQt do its thing then start Armory.

First, the OS X version does not support Armory management of bitcoind, so I'm stuck with the BitcoinQt approach.

Second, I guess I can just wait till the blockchain downloads, and then have Armory build its db afterwards. But is there some reason in principle that Armory cannot recognize incomplete blocks? During normal operation (i.e. after most of the blockchain is downloaded), Bitcoin-Qt is periodically getting new blocks, so there is a short window every 10 minutes when the situation is similar. Also during normal operation, I assume Armory periodically scans for new blocks (after Bitcoin-Qt tells it a new one has arrived), to extend its own database and display fresh data to the user. When it does this, there are probably no new partial blocks yet (because the next one wouldn't come for at least 10 minutes). But there is a small chance that two blocks are found almost simultaneously, right? In which case, right after Bitcoin-Qt tells armory it's ok to update its db, it might start downloading other partial blocks from random peers. So why couldn't the same "missing block data" cause crashes even after the initial bootstrap? Or are there certain state guarantees about ~/.bitcoin/blocks that are satisfied *except* during the initial bootstrap?

Apologies if these are dumb questions, just curious.

Regardless, the documentation (for all versions, but especially OS X since there's no choice) should probably be clarified to inform the user who is manually running bitcoin-qt that they must not run Armory until the blockchain is "fully" downloaded. I did see this on a non-official website about armory, but I assumed it was probably wrong and just a waste of time.

[1713495241]

1713495241

[1713495241]

1713495241

[1713495241]

1713495241

[goatpig]

First, the OS X version does not support Armory management of bitcoind, so I'm stuck with the BitcoinQt approach.

I'm aware of that but non Mac users read these threads too so I use platform agnostic statements whenever possible.

Second, I guess I can just wait till the blockchain downloads, and then have Armory build its db afterwards. But is there some reason in principle that Armory cannot recognize incomplete blocks? During normal operation (i.e. after most of the blockchain is downloaded), Bitcoin-Qt is periodically getting new blocks, so there is a short window every 10 minutes when the situation is similar. Also during normal operation, I assume Armory periodically scans for new blocks (after Bitcoin-Qt tells it a new one has arrived), to extend its own database and display fresh data to the user. When it does this, there are probably no new partial blocks yet (because the next one wouldn't come for at least 10 minutes). But there is a small chance that two blocks are found almost simultaneously, right? In which case, right after Bitcoin-Qt tells armory it's ok to update its db, it might start downloading other partial blocks from random peers. So why couldn't the same "missing block data" cause crashes even after the initial bootstrap? Or are there certain state guarantees about ~/.bitcoin/blocks that are satisfied *except* during the initial bootstrap?

Core behaves differently when it verifies blocks through milestones hashes as opposed to checking each transaction sig. The usual behavior is checking the sigs, which is slow and doesn't trigger empty block data. Milestone hash checking is a lot more aggressive with disk writes and will resort to the headers first approach as much as possible. Also, you don't want to be heavily reading and writing the same data concurrently.

Regardless, the documentation (for all versions, but especially OS X since there's no choice) should probably be clarified to inform the user who is manually running bitcoin-qt that they must not run Armory until the blockchain is "fully" downloaded.

Too much has changed in this release so I don't expect most documentation to be up to date yet. Headers first changed some significant things under the hood for us and we might be more and more motivated to resort to blocks over P2P.

As for letting BitcoinQt run its course before starting Armory, it wasn't a requirement up until Core 0.10, but rather a good practice. Better let the first finish before moving on to the second.

[Searinox]

Found a quirk in 0.93.70.

OS: Windows 7 x64 SP1
Browser: Firefox

Not sure if it has to be the same address, but when I click on my bitcoin address link in my signature and it opens the send bitcoins window, if I then cancel the window, the comment of my first address disappears.

Steps to repro:

-make a new wallet, generate your first address for that wallet, and give that address a comment
-make a html page with a bitcoin: link to that first address you generated
-open the html page in a browser and click the link
-when the armory window to send bitcoins to that address pops up, cancel to close it
-check your wallet and notice the comment you left on your address is erased

Also, it is quite frequently using 12-25% cpu(1 core) when idle.

[goatpig]

Does the comment reappear on the next start?

[Searinox]

Nope, the bug edits right into the wallet comment label and removes it! The comment does not return upon restarting Armory.

[MegaFall]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

[etotheipi]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

[MegaFall]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

Seems to have solved my issue of needing to dump and reload the entire blockchain every time I loaded Armory. Updated, opened it, and within 10 seconds was back up and running.

My only complaint is an aesthetic one, the text in the bottom right corner (the "Offline" and "Connected (Number of Blocks)") seems to have been pushed down and to the right a little. It's barely just staying on my screen.

[goatpig]

Seems to have solved my issue of needing to dump and reload the entire blockchain every time I loaded Armory. Updated, opened it, and within 10 seconds was back up and running.

My only complaint is an aesthetic one, the text in the bottom right corner (the "Offline" and "Connected (Number of Blocks)") seems to have been pushed down and to the right a little. It's barely just staying on my screen.

OS?

[MegaFall]

Seems to have solved my issue of needing to dump and reload the entire blockchain every time I loaded Armory. Updated, opened it, and within 10 seconds was back up and running.

My only complaint is an aesthetic one, the text in the bottom right corner (the "Offline" and "Connected (Number of Blocks)") seems to have been pushed down and to the right a little. It's barely just staying on my screen.

OS?

My OS? Windows 7 Ultimate 64-bit.

[goatpig]

My OS? Windows 7 Ultimate 64-bit.

I was hoping for OSX. I'll look into it.

[cypherdoc]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

has the dependency fix for Ubuntu 12.04, 32 bit been implemented?

[doug_armory]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

has the dependency fix for Ubuntu 12.04, 32 bit been implemented?

I don't think so. A more permanent fix is about to enter the testing phase. Until then, a workaround is discussed here if you want to give it a try. It worked for me when I gave it a try a few days ago.

[cypherdoc]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

has the dependency fix for Ubuntu 12.04, 32 bit been implemented?

I don't think so. A more permanent fix is about to enter the testing phase. Until then, a workaround is discussed here if you want to give it a try. It worked for me when I gave it a try a few days ago.

it's actually the online version that is giving me the dependency error.

[doug_armory]

Just got a pop-up in Armory for 0.93.1... so are the issues fixed?

I was just about to post a message about this.

We believe we've resolved a bulk of the issues.  It's not perfect, but most of the issues were related to a database issue that has been resolved.  Please try it and let us know.

has the dependency fix for Ubuntu 12.04, 32 bit been implemented?

I don't think so. A more permanent fix is about to enter the testing phase. Until then, a workaround is discussed here if you want to give it a try. It worked for me when I gave it a try a few days ago.

it's actually the online version that is giving me the dependency error.

It should work for both versions.

EDIT: Derrrrrrrrp. Was conflating two issues. Sorry about that. Online 32-bit is still busted no matter which OS you use. What I posted should work for 32-bit offline and 64-bit online setups.

[etotheipi]

Armory 0.93.1  --  Fixes most BDM issues and the Fragmented backup UI issues.

As usual, please use Help->Update Software within the app to use the secure downloader, if possible. 

  Armory 0.93.1 for Windows XP, Vista, 7, 8+ (64-bit)
  Armory 0.93.1 for MacOSX 10.7+ (64bit)
  Armory 0.93.1 for Ubuntu 12.04+ (32bit)
  Armory 0.93.1 for Ubuntu 12.04+ (64bit)
  Armory 0.93.1 for RaspberryPi  (armhf)


  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.93.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.93.1: Signed hashes of all installers

NOTE: As of 0.93, we broke compatibility with both Ubuntu 12.04 (32 and 64) and Windows 32 bit.  The next major release (hopefully soon) will actually remove the bulky Armory databases (except in supernode, of course), and thus make it compatible with 32-bit again.

[Newar]

All good using Lubuntu 14.04

Good work!

[cypherdoc]

Armory 0.93.1  --  Fixes most BDM issues and the Fragmented backup UI issues.

As usual, please use Help->Update Software within the app to use the secure downloader, if possible. 

  Armory 0.93.1 for Windows XP, Vista, 7, 8+ (64-bit)
  Armory 0.93.1 for MacOSX 10.7+ (64bit)
  Armory 0.93.1 for Ubuntu 12.04+ (32bit)
  Armory 0.93.1 for Ubuntu 12.04+ (64bit)
  Armory 0.93.1 for RaspberryPi  (armhf)


  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (32bit)
  Armory 0.93.1 Offline Bundle for Ubuntu 12.04 exact (64bit)
  Armory 0.93.1 Offline Bundle for RaspberryPi  (armhf)

  Armory 0.93.1: Signed hashes of all installers

NOTE: As of 0.93, we broke compatibility with both Ubuntu 12.04 (32 and 64) and Windows 32 bit.  The next major release (hopefully soon) will actually remove the bulky Armory databases (except in supernode, of course), and thus make it compatible with 32-bit again.

so those of us on Ubuntu 12.04, 32 bit are not to bother with the above 0.93.1 release?

[cypherdoc]

yep, answered my own question:  Dependency is not satisfiable:  libstdc++6(>4.7)

[doug_armory]

yep, answered my own question:  Dependency is not satisfiable:  libstdc++6(>4.7)

Did you try the GCC 4.7 workaround I posted? It works for me, at least on the 64-bit build. Should work for 32-bit too. In any event, we are working on a permanent fix.