etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
February 21, 2015, 04:56:03 PM Last edit: March 18, 2015, 11:53:03 PM by etotheipi |
|
Armory 0.93.1 is Now Available!Download links below Signed tag "v0.93" in https://github.com/etotheipi/BitcoinArmoryUpgrade with Secure Downloader in existing Armory is preferred (Help->Update Software) The website has not been updated. Sorry! We changed the website a couple months ago and forgot that we don't have the scripts worked out for it yet. Our updates only hit the secure downloader, not the website! Will have a manual update to the website soon. (as a workaround, you can always get the version from the website and use the secure downloader to immediately upgrade) I'm pleased to announce the final release of Armory v0.93. This release is especially relevant to the D&TD forum, as it implements a database mode we call "supernode" which does arbitrary blockchain lookups/slicing (instant importing & sweeping of any arbitrary address/script/wallet). Along with it comes a more-robust Armory daemon (armoryd.py) which can be used remotely via JSON-RPC or modified in-place with your code to power your web service, exchange, etc. Using armoryd.py along with the --supernode flag gives you a full-featured Bitcoin management platform on which to build your service with no external dependencies (such as blockchain.info for arbitrary balance lookup). Your service can now integrate hot wallets, cold wallets, watch-only wallets, message signing, unsigned tx creation, and all multi-signature lockbox features. NOTE: If you already use Armory, always get the latest version from the "Secure Downloader" (Help->Update Software). The links below are only for those who do not yet have a trusted version of Armory (or running a version so old it doesn't have the secure downloader). If you use the download links below, please check the GPG signatures of the last link and confirm hashes! 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 CHANGELOG: VERSION 0.93 Released Feb 21, 2015
- Compatible with Bitcoin Core 0.10 and "headers-first" The most recent version of Bitcoin Core includes a parallel network synchronization feature called "headers-first" which is incompatible with previous versions of Armory. This version is required to use Bitcoin Core 0.10 and newer. Torrent-based bootstrapping will be removed in the next version of Armory.
- New Scalable Blockchain Engine This version of Armory will look very similar to previous versions, but actually has a completely new, scalable database engine (using LMDB instead of LevelDB). The engine can now handle wallets with millions of addresses and transactions!
- Rebuild Required (but much faster!) The new database engine requires rebuilding and rescanning. You will be prompted as soon as you start up 0.93 the first time. However, due to the new blockchain engine, this process is considerably faster than before. Generally less than 45 min! NOTE: This is NOT redownloading the blockchain. It is only rebuilding the local databases that Armory creates for itself. - Improved Threading and Reliability With the new backend comes overhauled inter-thread messaging. This resolves a whole class of reliability issues that Armory has had in the past, especially with large wallets and transaction histories.
- Address and Wallet Importing in Background Importing wallets and addresses now induces background scans which do not disable the interface (previously forced you into offline mode for the duration of the scan). - Supernode Mode Use the "--supernode" flag before creating the databases to create a supernode database that enables instant address & wallet import. This is an enabling feature for high-volume, consumer facing apps and services to be built on Armory, such as exchanges and block- explorers. NOTE: Running with --supernode will result in an Armory database approximately double the size of the blockchain! - Improved armoryd.py The daemon version of armory, armoryd.py, has been fully updated and tested with the new database engine. Also includes a new "webshop" sample application that demonstrates basic usage of armoryd.py to collect & verify payments, generate unsigned transactions, etc.
- RFC6979 Deteministic Signing (via CLI args) Armory now has a deterministic signing mode based on RFC6979. The code passes all test vectors, but disabled by default pending more rigorous review. It can be enabled using the --detsign command-line flag.
Thanks to everyone on the Armory team for their hard work in developing, tweaking, testing, and more testing of the code in this release. And especially goatpig, who was instrumental in upgrading the database engine and responding extremely quickly (and effectively) to the variety of issues you would expect to pop up when overhauling such a large part of the code base. He's even got more tricks up his sleeve, for 0.93.1. Stay tuned!
|
|
|
|
|
|
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
teste
|
|
February 21, 2015, 05:12:11 PM |
|
Thanks. I love Armory wallet.
|
|
|
|
teukon
Legendary
Offline
Activity: 1246
Merit: 1002
|
|
February 21, 2015, 07:11:25 PM |
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious.
|
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4158
Merit: 8382
|
|
February 21, 2015, 08:46:15 PM |
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious. Personally I wouldn't implement it, I consider it a ill-advised and harmful feature. Keep in mind, there can be a BIP for anything that someone wants to use, having a BIP is not a mark of quality.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
February 22, 2015, 04:06:18 AM |
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious. No, we already had someone offering to pay us to implement something equivalent as a plugin and we turned him down
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
February 22, 2015, 04:16:23 AM |
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious. No, we already had someone offering to pay us to implement something equivalent as a plugin and we turned him down I think two things are getting conflated here. There's two parts to BIP39: one is encoding the wallet seed as a set of words (instead of Armory's "EasyType16" paper backups), and the other is the option to encrypt it with a password. I'm not thoroughly opposed to the word list encoding, it the encryption of the seed data will not be supported (which leads users to create, effectively, brainwallets), and seed sentences short enough to be memorized (which leads to actual brainwallets). However, do I like BIP39 for the fact that handwriting the seed data--instead of printing it--becomes much more reliable. Bad handwriting is much easier to overcome when human words are involved. You can have a few indistinguishable characters and it can still be readable. Users have asked us about brainwallets before (and as goatpig said, some have offered us money). We want nothing to do with brainwallets, or encrypted backup data (encrypting it defeats the purpose of having a backup!). However, as a mechanism for helping users reliably write down their seed data, I like it. I just don't know if there's a way to use it without encouraging memorization. For that reason I haven't made BIP39 a priority.
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3071
|
|
February 22, 2015, 09:08:44 AM |
|
Big congratulations, really pleased with this project and where it's heading right now.
One small question: when can we expect more info on the safety of enabling deterministic signing?
|
Vires in numeris
|
|
|
Joe4782
Member
Offline
Activity: 83
Merit: 10
|
|
February 22, 2015, 10:20:05 AM |
|
Updated Armory yesterday, and bitcoind to 0.10 last week. Does anybody else now have a problem of incompatibility? When I start up the latest Armory, after a few seconds my Win7 64bit machine pops up a dialog titled 'bitcoind.exe' and the message 'bitcoind.exe has stopped working'? Bitcoind 0.10 seems to have no problem running on its own.
I hadn't run Armory for a couple of months before I ran it yesterday (don't think that's relevant). I've rebooted my machine, but still no luck. My wife also updated both on her Win 7 64bit machine yesterday and also had a similar problem - although this seems to have been fixed by a reboot.
I'll admit to being a bit more paranoid about what I usually let run on my PC, so is it possible there should be a background service running or something?
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 11:00:40 AM |
|
Updated Armory yesterday, and bitcoind to 0.10 last week. Does anybody else now have a problem of incompatibility? When I start up the latest Armory, after a few seconds my Win7 64bit machine pops up a dialog titled 'bitcoind.exe' and the message 'bitcoind.exe has stopped working'? Bitcoind 0.10 seems to have no problem running on its own.
I hadn't run Armory for a couple of months before I ran it yesterday (don't think that's relevant). I've rebooted my machine, but still no luck. My wife also updated both on her Win 7 64bit machine yesterday and also had a similar problem - although this seems to have been fixed by a reboot.
I'll admit to being a bit more paranoid about what I usually let run on my PC, so is it possible there should be a background service running or something?
Mine's perfect, delete all the data and start fresh
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 11:02:16 AM |
|
Congrats! Just thinking a few years ago you got laid off and began Armory and here we are, the #1 wallet!
|
|
|
|
Joe4782
Member
Offline
Activity: 83
Merit: 10
|
|
February 22, 2015, 11:11:55 AM |
|
<- snip ->
Mine's perfect, delete all the data and start fresh 'Mine's perfect' - that comment doesn't really help me - my wife's is also now running, but we didn't learn much from that either. I'm running bitcoind independantly - and seem to be getting on better - currently scanning transaction history whereas before Armory 'locked up' almost as soon as bitcoind failed.
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 11:36:51 AM |
|
<- snip ->
Mine's perfect, delete all the data and start fresh 'Mine's perfect' - that comment doesn't really help me - my wife's is also now running, but we didn't learn much from that either. I'm running bitcoind independantly - and seem to be getting on better - currently scanning transaction history whereas before Armory 'locked up' almost as soon as bitcoind failed. You did ask Does anybody else now have a problem of incompatibility? Try deleting everything from Bitcoin and armory except wallets. Fully sync Bitcoin before starting armory. Actually Bitcoind shouldn't be running afaik, armory starts qt not d I think, I run it manually though You might have an old version running somehow or another program running it for you Or armory is starting the daemon and you're starting qt which kills the daemon
|
|
|
|
Joe4782
Member
Offline
Activity: 83
Merit: 10
|
|
February 22, 2015, 11:45:14 AM |
|
<- snip ->
You did ask Does anybody else now have a problem of incompatibility?
Try deleting everything from Bitcoin and armory except wallets. Fully sync Bitcoin before starting armory.
Actually Bitcoind shouldn't be running afaik, armory starts qt not d I think, I run it manually though
You might have an old version running somehow or another program running it for you
Thanks for your help. You are right - I did ask that, although it was more of a rhetorical question - I was already assuming that the new version was working ok for a lot of people, otherwise I guess it wouldn't have been released yet! Anyway, I've got Armory up and running now - I just have to run Bitcoin core/q/d on it's own.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
February 22, 2015, 12:42:51 PM |
|
Where can I find more info on supernode?
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
February 22, 2015, 12:59:00 PM |
|
Where can I find more info on supernode?
I am also curious about this supernode functionality, in depth documentation would be useful
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 01:02:53 PM |
|
Where can I find more info on supernode?
I am also curious about this supernode functionality, in depth documentation would be useful That offering might be more for business with paid support
|
|
|
|
neuronics
Newbie
Offline
Activity: 39
Merit: 0
|
|
February 22, 2015, 01:26:48 PM |
|
Thank you for the efforts, keep up the good work !
|
|
|
|
oakpacific
|
|
February 22, 2015, 01:48:42 PM |
|
Great, can I reuse an old blockchain copy?
|
|
|
|
mitus-2
|
|
February 22, 2015, 01:55:50 PM |
|
thank you very much!
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 01:57:45 PM |
|
Great, can I reuse an old blockchain copy?
Yes
|
|
|
|
AussieHash
|
|
February 22, 2015, 02:15:50 PM |
|
I've successfully installed armory_0.92.3_rpi_bundle.tar.gz on Pi B / Pi B+ / Pi 2 (raspbian wheezy) and BBB (debian wheezy + ubuntu 14.04).
However on ODROID C1 (Ubuntu 14.04, Feb 10th ISO) there is an error ImportError: No module names qt4reactor.
For some reason qt4reactor.py is allocated view = owner only / change = owner only / execute = nobody.
sudo chmod +755 /usr/lib/armory/qt4reactor.py fixes the problem, and 0.92.3 works.
In order to get armory_0.93_raspbian-armf.tar.gz working (Secure Downloaded and verified within armory), I copied the 0.92.3 offline bundle's Install_DblClick_RunInTerminal.py, ran
sudo python Install_DblClick_RunInTerminal.py in the same folder as the 0.93 tar.gz and ran once again
sudo chmod +755 /usr/lib/armory/qt4reactor.py
Success !
|
|
|
|
doug_armory
|
|
February 22, 2015, 03:22:40 PM |
|
Big congratulations, really pleased with this project and where it's heading right now.
One small question: when can we expect more info on the safety of enabling deterministic signing?
Thanks, and good question. The long and short of it is that Alan & I are figuring out the best way forward. My personal opinion is that the code is safe to use. I closely followed the path that Crypto++ uses whenever data is signed. (No small feat considering the ugliness of the Crypto++ codebase.) I use the appropriate test suites from RFC 6979 and from the Trezor codebase, and plan to add the libsecp256k1 test vectors sooner or later. I considered the codebase to be safe enough that I conducted several significant mainnet transactions using det signing. (Gotta eat your own dogfood, right?) Everything worked fine, and I didn't lose any coins. Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3071
|
|
February 22, 2015, 03:58:39 PM |
|
One small question: when can we expect more info on the safety of enabling deterministic signing?
[...] Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go. Sounds like a good enough reason to justify the disabling by default, you need at least 10 opinions . But I I know, you mean opinions from people who make it their business to know cryptography from all the theory based angles who can spot signatures leaking information in some way no-one's thought of, etc. I might wait just a while to use it, but it sounds like a good thing in principle (it makes address re-use safer/safe IIRC)
|
Vires in numeris
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 04:00:44 PM |
|
Big congratulations, really pleased with this project and where it's heading right now.
One small question: when can we expect more info on the safety of enabling deterministic signing?
[...]Of course, personal opinions don't mean squat. There could be some weird thing I missed. So, for now, Alan's going to take a close look once he has a little free time, and we'll decide from there where to go. Sounds like a good enough reason to justify the disabling by default, you need at least 10 opinions . But I I know, you mean opinions from people who make it their business to know cryptography from all the theory based angles who can spot signatures leaking information in some way no-one's thought of, etc. I might wait just a while to use it, but it sounds like a good thing in principle (it makes address re-use safer/safe IIRC) What do you mean by deterministic signing?
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3071
|
|
February 22, 2015, 04:04:55 PM |
|
What do you mean by deterministic signing?
It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93
|
Vires in numeris
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 04:21:57 PM |
|
What do you mean by deterministic signing?
It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93 Oh so instead of random it uses a rolling nonce Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know. If it adds a random number, it sounds very good.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
February 22, 2015, 04:32:23 PM |
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
February 22, 2015, 04:50:30 PM |
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
conceptually, the Trezor is a mini-HSM, right? from a security standpoint, would you consider it "as secure" as an HSM despite the fact it uses deterministic signing?
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
February 22, 2015, 05:03:33 PM |
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
conceptually, the Trezor is a mini-HSM, right? from a security standpoint, would you consider it "as secure" as an HSM despite the fact it uses deterministic signing? I think HSMs are frequently overkill in their protection capabilities, but in the enterprise market (monster companies, banks, financial institutions... our target market ), using FIPS-certified HSMs is a requirement, not a bonus. Trezor is a solid low-cost version of an HSM that doesn't come with any such certifications or protections (such as self-destruction upon tampering), but it doesn't need it for its target market. It's still a very strong HW model (as far as I can tell). I also believe that in the context of multisig wallets, the quorum of devices needed to sign can replace much of need for super-hardcore security of each individual device. However, in the banking & government world, they don't really care. Use an HSM or you're wasting their time. It's what they understand, and "overkill" is much preferable to risking "under-protected." In this context, I believe Trezor will suit the needs of most users and organizations that don't have such requirements. And for them, it's important to have deterministic signing as you need a way to audit the firmware that comes with the Trezor. Without deterministic signing, you have no way to know whether there's a backdoor in the signing algo. Gmaxwell has enumerated some pretty brilliant attacks in the past that can be performed if you compromise the RNG for signing, even if you upload your own seed entropy ... the wallet can be compromised with a few signatures, in a way that only the person that planted the backdoor can detect, and only from watching the blockchain. In the enterprise/gov't world, these devices hold the most important keys in the world and both the hardware and software are heavily scrutinized by NIST, etc. Trezor is not. P.S. - If you couldn't tell, Armory has shifted a lot of focus recently into the "enterprise" market -- banks, financial institutions, etc. This is where we see Armory having the biggest impact -- they don't want to have BitGo or Xapo protecting their funds, they want to do it themselves! See my recent article on more enterprise security concepts: https://bitcoinmagazine.com/19234/key-ceremony-auditable-private-key-security-practices/
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 05:13:54 PM |
|
I wish people would stop referring to "you are at risk if you don't use RFC6979". We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses. However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard. RFC6979 is exactly what it says "Request for Comments". It's not a standard, never been approved by any organization. I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.
For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack. If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device. This would mean our HSMs would immediately be unsuitable for any government use. This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.
This doesn't mean that I don't think RFC6979 is useful. It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability. While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).
My attitude on all this is: I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing. But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms. For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
February 22, 2015, 05:18:19 PM |
|
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
To be clear, it's not "incrementing". It's a hash that changes if the private key or message changes. In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979. It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus.
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 22, 2015, 05:20:17 PM |
|
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
To be clear, it's not "incrementing". It's a hash that changes if the private key or message changes. In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979. It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus. Oh ok that makes sense. What's protecting an identical transaction?
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
February 22, 2015, 05:49:05 PM |
|
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
To be clear, it's not "incrementing". It's a hash that changes if the private key or message changes. In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979. It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus. Oh ok that makes sense. What's protecting an identical transaction? nothing prevents an identical tx. but only the first will be accepted by the network, so there's no use in duplicating. edit: this is also what allows the "auditing" or "determinism" that eto was referring to.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
February 22, 2015, 05:59:25 PM |
|
Good I don't think I like it. There's no way I trust incrementing vs rng. I'd rather get support for usb rng plus mouse movements.
To be clear, it's not "incrementing". It's a hash that changes if the private key or message changes. In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979. It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus.we all want Armory to prosper as it benefits all of our security. this is a very reasonable approach.
|
|
|
|
adam3us
|
|
February 23, 2015, 08:12:31 AM |
|
What do you mean by deterministic signing?
It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93 Oh so instead of random it uses a rolling nonce Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know. If it adds a random number, it sounds very good. No thats not how it works. Deterministic DSA is to use k=H(d,m) as the nonce. In that way if you sign the same message m=H(transaction), you'll get the same signature. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
adam3us
|
|
February 23, 2015, 08:31:02 AM |
|
What do you mean by deterministic signing?
It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93 Oh so instead of random it uses a rolling nonce Idk, personally I think a bad write can make you reuse an increment and boom you're done. But what do I know. If it adds a random number, it sounds very good. No thats not how it works. Deterministic DSA is to use k=H(d,m) as the nonce. In that way if you sign the same message m=H(transaction), you'll get the same signature, so its also stateless. And this is important because if you reuse k with different messages you reveal a simultaneous equation allowing the private key to be computed. private key is d, public key is Q=dG, address is a=H(Q), signature is (s,r) where s=(h(m)+rd)/k, r=[kG].x, n is the order of the curve. s=(h(m)+rd)/k mod n s2=(h(m2)+rd)/k mod n => sk = h(m)+rd, s2k = h(m2)+rd => (s-s2)k = h(m)-h(m2) => k=(h(m)-h(m2))/(s-s2). now we know k and substituting: sk=h(m)+rd => d=(sk-h(m))/r There are worse attacks where even knowing a bias of a few bits eg http://www.irisa.fr/celtique/zapalowicz/papers/asiacrypt2014.pdf can result in d being recovered over a modest number of signatures, or that the NIST original DSA standard was partly broken due to a small bias in k generation algorithm by Bleichenbacher, see section 2.2 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.3190&rep=rep1&type=pdfAvoiding reuse of k is also tricky because that implies log transactional storage in the RNG state. What if the RNG is in a VM, and the VM snapshotted and rolled back? What if the RNG is poorly seeded (eg in a server environment). The lesson for bitcoin is dont reuse addresses but as there are usability difficulties with that also dont have biases in k, and dont rely on transactional, non-rollbackable storage: hence deterministic DSA. Adam
|
hashcash, committed transactions, homomorphic values, blind kdf; researching decentralization, scalability and fungibility/anonymity
|
|
|
picobit
|
|
February 23, 2015, 03:10:01 PM |
|
Avoiding reuse of k is also tricky because that implies log transactional storage in the RNG state. What if the RNG is in a VM, and the VM snapshotted and rolled back? What if the RNG is poorly seeded (eg in a server environment). Is this a real risk with Armory? Or does it have a sufficient alternate source of entropy / does not store the RNG state between sessions / does something else smart to prevent this attack vector. The reason that I ask is that my daily usage wallet is an Armory wallet with the offline computer being a VM (I know, a real offline computer is better, and I use that for the main offline storage). And I do roll it back after each use, from a (probably mistaken) idea that this increases security marginally by wiping whatever any malware may have stored before it somehow magically breaks out of the VM :-) Is doing this a huge mistake, and have I been saved by so far not having reused addresses?
|
|
|
|
solitude
|
|
February 23, 2015, 09:38:26 PM |
|
Is anyone else getting this error right after "Initializing Bitcoin Engine" completes? Of course I've done the "Rebuild and Rescan" numerous times to no avail Any ideas?
|
Hardly anyone speaks English on this forum.
|
|
|
kylerwk
Newbie
Offline
Activity: 1
Merit: 0
|
|
February 24, 2015, 12:19:47 AM |
|
Just upgrade to Armory 0.93 and Bitcoin Core 0.10. Things seem to be going well until my system get to the Organizing blocks stage. Then Armory just gets stuck and won't move on to the next step. I've tried to rebuild and rescan to no avail. No errors happen, it just won't move on.
Any other ideas?
Thanks
|
|
|
|
solitude
|
|
February 24, 2015, 12:33:44 AM |
|
Just upgrade to Armory 0.93 and Bitcoin Core 0.10. Things seem to be going well until my system get to the Organizing blocks stage. Then Armory just gets stuck and won't move on to the next step. I've tried to rebuild and rescan to no avail. No errors happen, it just won't move on.
Any other ideas?
Thanks
I have the same issue in the post above. Glad to know I'm not the only one.
|
Hardly anyone speaks English on this forum.
|
|
|
SlidingAndSlamming
Newbie
Offline
Activity: 21
Merit: 0
|
|
February 24, 2015, 04:29:12 AM |
|
FWIW, twice I've gotten the BDM error shown above, I reran Armory, doing the rebuild&rescan and it finished OK. I'm on Armory 0.93 and Bitcoin Core 0.10.
|
|
|
|
solitude
|
|
February 24, 2015, 05:47:29 AM |
|
Can we get an Armory Dev to confirm the BDM error is common and if a fix is in the works?
|
Hardly anyone speaks English on this forum.
|
|
|
matsumoto_iyo
Newbie
Offline
Activity: 1
Merit: 0
|
|
February 24, 2015, 07:42:53 AM |
|
Can you please provide the previous version of Armory?
I have installed a fresh copy of Ubuntu 14.04.2 LTS without it ever touching the internet and attempted to transfer the new armory_0.93_offline_ubuntu_12.04-64.tar.gz bundle via usb key and begin the installation as instructed but its just giving me these countless errors.
It doesn't work.
Errors were encountered while processing: dpkg-sig libqt4-designer:amd64 libqt4-help:amd64 libqt4-scripttools:amd64 python-qt4 python-twisted armory
I mean, how can you update all these dependencies if your cold machine can't touch the net??
If I get a copy of the previous Armory releases, maybe these dependency errors won't show up.
|
|
|
|
|
solitude
|
|
February 24, 2015, 10:42:47 PM Last edit: February 24, 2015, 11:11:14 PM by solitude |
|
This release is total fucking bug-filled trash. The devs have shifted their focus from the common bitcoiner to the corporate "enterprise" cocksuckers. They know where the money is. I can't even get this piece of shit to synchronize. bitcoind.exe crashing, BDM errors, what a pile of shit. The "devs" in the forum tell you to create tickets on their site but the tickets just go ignored, and I'm assuming your email address gets collected and sold. RIP in Peace Armory, it's time to move on to other Bitcoin clients. Quote from Alan Reiner, owner/creator of Armory: We have shifted much of our focus temporarily to the enterprise software and services where we’ve seen demand soaring, primarily due to a lack of enterprise options. And Armory is uniquely positioned to satisfy that demand — which also comes with revenue which is always good for sustaining a business! source: http://bitcoinsinireland.com/an-interview-with-armory-technologies-ceo-alan-reiner/In other words they couldn't give a fuck about the average joe who just wants a secure bitcoin solution. They'd rather have some unscrupulous shit-eating company give them tons of money, before claiming they've been hacked and running off with everyones coins.
|
Hardly anyone speaks English on this forum.
|
|
|
AussieHash
|
|
February 24, 2015, 11:00:18 PM |
|
The devs have shifted their focus from the common bitcoiner to the corporate "enterprise" cocksuckers. They know where the money is.
You mean there's more money to be made from paying enterprise cocksuckers than there is to be made from freeloaders ? Bitcoin core is free and in beta, armory is free and in beta - roll back to 0.92 and chill. Armory 0.93 beta is far more stable than electrum 2.03beta (which is due for RTM release this week)
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
February 24, 2015, 11:17:28 PM |
|
This release is total fucking bug-filled trash. The devs have shifted their focus from the common bitcoiner to the corporate "enterprise" cocksuckers. They know where the money is.
I can't even get this piece of shit to synchronize. bitcoind.exe crashing, BDM errors, what a pile of shit.
The "devs" in the forum tell you to create tickets on their site but the tickets just go ignored, and I'm assuming your email address gets collected and sold.
RIP in Peace Armory, it's time to move on to other Bitcoin clients.
1) Stop posting in 3 different threads. Pick one, or make one and stick to it. Stop spreading yourself so thin, I can't track posts all over the place and I'm not motivated to keep trying for very long. 2) We don't care for your email one second. Make a throw away account for this very purpose if you are afraid we would sell your address. This is how little we care for it. 3) Get me log files. I don't care how you do it. I always suggest using the dedicated support channel because there is some information in the logs that a few people don't feel comfortable sharing on a public forum. I don't care about your particular circumstances more than the next user. Edit the private info if you want, or don't, post it on pastebin, or copy paste it here, or make a ticket, whatever works. If you don't get me log files, I can't help you. 4) This is your last chance. Give me the information I need or don't expect to get any support from us anymore. That's what you get for throwing a tantrum instead of actually giving me log files. P.S: bitcoind.exe failing is usually a sign of a damaged Core DB. Start BitcoinQt manually, it will probably ask you to reindex blocks. Once that is done, try a rescan and rebuild in Armory again.
|
|
|
|
doug_armory
|
|
February 25, 2015, 12:02:49 AM |
|
This release is total fucking bug-filled trash. The devs have shifted their focus from the common bitcoiner to the corporate "enterprise" cocksuckers. They know where the money is. I can't even get this piece of shit to synchronize. bitcoind.exe crashing, BDM errors, what a pile of shit. The "devs" in the forum tell you to create tickets on their site but the tickets just go ignored, and I'm assuming your email address gets collected and sold. RIP in Peace Armory, it's time to move on to other Bitcoin clients. Quote from Alan Reiner, owner/creator of Armory: We have shifted much of our focus temporarily to the enterprise software and services where we’ve seen demand soaring, primarily due to a lack of enterprise options. And Armory is uniquely positioned to satisfy that demand — which also comes with revenue which is always good for sustaining a business! source: http://bitcoinsinireland.com/an-interview-with-armory-technologies-ceo-alan-reiner/In other words they couldn't give a fuck about the average joe who just wants a secure bitcoin solution. They'd rather have some unscrupulous shit-eating company give them tons of money, before claiming they've been hacked and running off with everyones coins. While I wouldn't necessarily phrase things quite like goatpig, I basically agree with him. We do care about our users, no matter who they are. We also need proper information in order to investigate reported issues. If users cooperate, we'll do our best. We have a lot of things to balance and may occasionally need a reminder, yes, but we do care. FYI, we transitioned our support software recently. Maybe something somehow slipped through the cracks. Maybe somebody just hasn't gotten a chance to look at it yet. I don't know, as I haven't touched the new system yet. I do know that you're not being intentionally ignored. We're trying our best to play the long game, which means making people happy and doing our best to create solid software. (Ignoring huge bugs and selling email addresses for peanuts to Nigerian scammers isn't exactly the best way to build a reputation.) It also means we're juggling a lot of tasks, some of which are, arguably, not even tasks we should be taking on, like providing support for free software. As for working with enterprise customers, well, what exactly is the reasonable alternative? Keep asking people for donations and hope that enough come in? This is no longer a project Alan's working on in his free time, and we can't just ask deep-pocketed early adopters to give us money out of the kindness of their hearts. It would be nice, yes, but it's not a viable long-term solution. The enterprise pivot doesn't mean free users are second-tier chumps. For various reasons, I'm confident that a free version of Armory will always be around and will be supported on one level or another. Will I guarantee it on the souls of my forefathers? No, as Armory is not my business to run. However, there are loads of reasons why a free, up-to-date version makes sense. We may occasionally pivot, as Alan said. That doesn't mean free users will still be stuck on 0.93 in 2018 while we're sitting on our stacks of 100s and polishing 4.0 for our enterprise customers. Respect is a two-way street. If users cooperate and get us the information we need, I promise we'll do our best to help them out, even if it sometimes seems like we're ignoring them. If users want to throw rage-filled tantrums over free software, well, there's not much we can do for them.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 25, 2015, 07:01:14 AM |
|
I'm glad armory might be getting paid business. Armory #1
Armory has been absolutely solid
|
|
|
|
RoadStress
Legendary
Offline
Activity: 1904
Merit: 1007
|
|
February 25, 2015, 06:42:16 PM |
|
I'm glad armory might be getting paid business. Armory #1
Armory has been absolutely solid
I agree with you. I love and support Armory!
|
|
|
|
senoirdean
Newbie
Offline
Activity: 3
Merit: 0
|
|
February 25, 2015, 11:29:28 PM |
|
BDM Error here also. Rebuilding DB. Im guessing Id have to uninstall Armory to roll it back then import backup? Man this sucks I was really glad to see how much faster Armory started up with new version.
|
|
|
|
rszibele
Newbie
Offline
Activity: 14
Merit: 0
|
|
February 27, 2015, 11:17:59 AM |
|
Armory 0.93 does not work for me, I though it was due to Armory being on a fuse NTFS partition on Debian ( thread), but even on an ext4 partition it fails to sync and also fails at building the database . This is the only error that seems relevant: 2015-02-26 09:46 (ERROR) -- Traceback (most recent call last): File "/media/disk0/Armory/ArmoryQt.py", line 7038, in method_signal method() File "/media/disk0/Armory/ArmoryQt.py", line 2473, in proceedOnceBitcoindIsReady self.loadBlockchainIfNecessary() File "/media/disk0/Armory/ArmoryQt.py", line 2525, in loadBlockchainIfNecessary TheBDM.goOnline() File "/media/disk0/Armory/armoryengine/BDM.py", line 148, in inner return func(*newArgs, **kwargs) File "/media/disk0/Armory/armoryengine/BDM.py", line 251, in goOnline self.bdmThread.setConfig(self.bdmConfig()) File "/media/disk0/Armory/armoryengine/BDM.py", line 148, in inner return func(*newArgs, **kwargs) File "/media/disk0/Armory/armoryengine/BDM.py", line 339, in bdmConfig bdmConfig.blkFileLocation = blockdir File "/media/disk0/Armory/CppBlockUtils.py", line 2067, in <lambda> __setattr__ = lambda self, name, value: _swig_setattr(self, BlockDataManagerConfig, name, value) File "/media/disk0/Armory/CppBlockUtils.py", line 45, in _swig_setattr return _swig_setattr_nondynamic(self,class_type,name,value,0) File "/media/disk0/Armory/CppBlockUtils.py", line 38, in _swig_setattr_nondynamic if method: return method(self,value) TypeError: in method 'BlockDataManagerConfig_blkFileLocation_set', argument 2 of type 'string const &' I tried Armory 0.93 with the latest Bitcoin-core and also the previous Bitcoin-core, and it fails to sync and build the database with both of them. As others have suggested, I will try the old Armory 0.92.3 with the previous Bitcoin-core.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
February 27, 2015, 02:45:42 PM |
|
Armory 0.93 does not work for me, I though it was due to Armory being on a fuse NTFS partition on Debian ( thread), but even on an ext4 partition it fails to sync and also fails at building the database . Force your bitcoin folder with --satoshi-datadir, the path auto detect is failing somehow.
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 27, 2015, 03:21:53 PM |
|
Regarding the BDM errors, I've seen them happen a few time now, and the pattern is they occur when starting up Armory after it hasn't been running for ~1 week, with bitcoind running constantly in the background (not under Armory's control).
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 27, 2015, 03:28:25 PM |
|
Also your master branch as of 25248a752364afa91b4701f5b28b203ecd8364f2 doesn't build: make -C cppForSwig make[1]: Entering directory 'redacted/src/BitcoinArmory/cppForSwig' g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c UniversalTimer.cpp g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BinaryData.cpp g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c lmdb_wrapper.cpp g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c StoredBlockObj.cpp g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BtcUtils.cpp lmdb_wrapper.cpp: In member function ‘bool LMDBBlockDatabase::getStoredTx_byHash(BinaryDataRef, StoredTx*, BinaryData*) const’: lmdb_wrapper.cpp:2627:54: error: invalid initialization of non-const reference of type ‘BinaryData&’ from an rvalue of type ‘BinaryData’ BinaryData& gettxhash = getTxHashForLdbKey(hint); ^ g++ -Icryptopp -Imdb -DUSE_CRYPTOPP -D__STDC_LIMIT_MACROS -I/usr/include/python2.7 -I/usr/include/python2.7 -std=c++11 -O2 -pipe -fPIC -c BlockObj.cpp Makefile:87: recipe for target 'lmdb_wrapper.o' failed make[1]: *** [lmdb_wrapper.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory 'redacted/src/BitcoinArmory/cppForSwig' Makefile:9: recipe for target 'all' failed make: *** [all] Error 2
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 27, 2015, 04:08:58 PM |
|
I just noticed all the transaction inputs are the same multisig address for all my transactions
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
February 27, 2015, 04:21:53 PM |
|
Also your master branch as of 25248a752364afa91b4701f5b28b203ecd8364f2 doesn't build:
This commit is in dev, and dev is unstable currently. I was stopped halfway through a big change to go after the BDM error issue.
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
February 27, 2015, 04:35:19 PM |
|
Thanks I thought everyone magically switched to multisig but wondered why their change wasn't
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1009
|
|
February 27, 2015, 05:43:50 PM |
|
This commit is in dev, and dev is unstable currently. Oops - somehow my local repo ended up with confusing upstream tracking branches.
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
March 02, 2015, 04:16:42 PM |
|
Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 02, 2015, 05:19:31 PM |
|
Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?
You are using a 32bit OS?
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
March 02, 2015, 05:48:59 PM |
|
Tried installing 0.93 on Ubuntu 14.04 and it errored out saying it couldn't install python-gtk2:i386 and Ubuntu Software Center disappeared from my system, along with many apps (VirtualBox, Dropbox, Okular...), what am I missing?
You are using a 32bit OS? Yes, I am
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 02, 2015, 07:40:02 PM |
|
Yes, I am
Are you trying to use Armory on this machine as an offline signer or to get online?
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
March 02, 2015, 08:32:35 PM |
|
Yes, I am
Are you trying to use Armory on this machine as an offline signer or to get online? It's an online machine, and I used the Armory Installer
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 02, 2015, 09:58:32 PM |
|
It's an online machine, and I used the Armory Installer
No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
March 03, 2015, 11:27:42 AM |
|
It's an online machine, and I used the Armory Installer
No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86 Odd, your website lists 0.93 for Ubuntu 12.04+ (32bit), I thought your binaries would be compatible... I guess I'll just install it on my 64 bit machine
|
|
|
|
achow101_alt
|
|
March 03, 2015, 08:50:29 PM |
|
Will Bitcoin Core 0.10 be available through the secure downloader?
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 03, 2015, 10:54:19 PM |
|
It's an online machine, and I used the Armory Installer
No x86 online for 0.93. Go back to 0.92.3 and wait for the next release for x86 Odd, your website lists 0.93 for Ubuntu 12.04+ (32bit), I thought your binaries would be compatible... I guess I'll just install it on my 64 bit machine Yeah we forgot to rename all that stuff, sorry about that =(
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
March 04, 2015, 02:04:20 AM |
|
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
|
March 04, 2015, 02:38:37 AM |
|
Works for me but I didn't have problems
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 09:21:44 AM Last edit: March 04, 2015, 12:40:25 PM by Searinox |
|
Deleted Armory's DB and upgraded to this version. The progress on the UI appears not to freeze anymore and I can actually see Armory building the DB. Will edit this post or make a new one if it actually makes it beyond 19-20GB or completes building.
|
|
|
|
sflicht
Newbie
Offline
Activity: 19
Merit: 0
|
|
March 04, 2015, 12:39:31 PM |
|
For anyone having issues with 0.93 BDM errors, I just pushed goatpig's fix into 0.93.0.70. Yeah weird version number. This will be 0.93.1 after we've confirmed it does what it's supposed to.
As usual, get it from the secure downloader within Armory (help->update software). ashes of all installers [/url]
Secure downloader shows only 0.91 for OS X.
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 12:40:40 PM Last edit: March 04, 2015, 01:03:22 PM by Searinox |
|
Done rebuilding. For the first time, this version of Armory 0.93 successfully completes building the DB without progress unresponsiveness or non-specific hangups.
I must however make a note about memory usage. While I do understand from other threads that Armory doesn't actually gobble up all the memory and merely softly asks the OS to pre-commit space for it and release it at any moment if another program needs it, I still find it untennable to constantly run a program in the background that makes my gauging of free RAM unreliable. I don't want to have to use my PC in a manner where task manager is continually showing 99% RAM being used up, preventing me from actually seeing when a program does indeed get out of hand. Since I've seen no other program ever do this, I'd find it reasonable that Armory could scale down the practice too since I really don't see it needing to commit so much RAM in the first place.
EDIT: Upon a 2nd startup it seems to only do this RAM thing when it first builds the Armory DB, or at least, because the DB isn't that far behind it does it to a significantly less extent on future startups. It's still weird and, if Armory does think it's nice to have this type of DB lookup convenience, I don't think it should do it in a manner that's visible to the user(task manager).
Btw Armory's startup scanning and reach of full functionality is significantly faster than before. Cheers!
|
|
|
|
sflicht
Newbie
Offline
Activity: 19
Merit: 0
|
|
March 04, 2015, 01:06:55 PM Last edit: March 04, 2015, 01:52:50 PM by sflicht |
|
FWIW the 0.93.0.7 patch seems *more* unstable on OS X: instead of popups about BDM errors, it just crashes outright. I've included the OS error traceback and the ERROR part of my armory log below. Process: Python [55136] Path: /Users/USER/Downloads/Armory 2.app/Contents/MacOS/Python Identifier: com.armory.armory Version: ??? Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: Python [55136] User ID: 501
Date/Time: 2015-03-04 07:52:28.384 -0500 OS Version: Mac OS X 10.10.2 (14C109) Report Version: 11 Anonymous UUID: 5A98AC76-3157-7B75-505C-CA45B9237DF7
Sleep/Wake UUID: 6CFCD9AF-1AC6-4A02-BC77-B35669F33722
Time Awake Since Boot: 1200000 seconds Time Since Wake: 8800 seconds
Crashed Thread: 5
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000011bb00000
VM Regions Near 0x11bb00000: mapped file 000000011ab00000-000000011bb00000 [ 16.0M] r--/r-x SM=PRV /Users/USER/Library/Application Support/Bitcoin/*/*.dat --> MALLOC_LARGE 0000000122afc000-0000000122bf0000 [ 976K] rw-/rwx SM=PRV
Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296 5 com.apple.HIToolbox 0x00007fff8f7ebaef RunCurrentEventLoopInMode + 235 6 com.apple.HIToolbox 0x00007fff8f7eb86a ReceiveNextEventCommon + 431 7 com.apple.HIToolbox 0x00007fff8f7eb6ab _BlockUntilNextEventMatchingListInModeWithFilter + 71 8 com.apple.AppKit 0x00007fff87d8ff81 _DPSNextEvent + 964 9 com.apple.AppKit 0x00007fff87d8f730 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 194 10 com.apple.AppKit 0x00007fff87d83593 -[NSApplication run] + 594 11 QtGui 0x0000000105b9387a QEventDispatcherMac::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 538 12 QtCore 0x0000000105127cad QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 477 13 QtCore 0x000000010512aec7 QCoreApplication::exec() + 199 14 QtGui.so 0x0000000105392610 meth_QApplication_exec_(_object*, _object*) + 80 15 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486 16 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725 17 org.python.python 0x00000001000aaec6 PyEval_EvalCode + 54 18 org.python.python 0x00000001000d43e4 PyRun_FileExFlags + 164 19 org.python.python 0x00000001000d3f61 PyRun_SimpleFileExFlags + 769 20 org.python.python 0x00000001000eafd7 Py_Main + 3063 21 Python 0x0000000100000e55 0x100000000 + 3669 22 Python 0x0000000100000d71 0x100000000 + 3441
Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff8c923232 kevent64 + 10 1 libdispatch.dylib 0x00007fff8bc61a6a _dispatch_mgr_thread + 52
Thread 2:: com.apple.CFSocket.private 0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10 1 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131 2 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176 3 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 3: 0 libsystem_kernel.dylib 0x00007fff8c91d4de mach_msg_trap + 10 1 libsystem_kernel.dylib 0x00007fff8c91c64f mach_msg + 55 2 com.apple.CoreFoundation 0x00007fff86a09b34 __CFRunLoopServiceMachPort + 212 3 com.apple.CoreFoundation 0x00007fff86a08ffb __CFRunLoopRun + 1371 4 com.apple.CoreFoundation 0x00007fff86a08858 CFRunLoopRunSpecific + 296 5 com.apple.AppKit 0x00007fff87ef333b _NSEventThread + 137 6 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131 7 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176 8 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 4: 0 libsystem_kernel.dylib 0x00007fff8c9223fa __select + 10 1 org.python.python 0x00000001000b0806 PyEval_EvalFrameEx + 20486 2 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725 3 org.python.python 0x000000010003658c function_call + 364 4 org.python.python 0x0000000100010d53 PyObject_Call + 99 5 org.python.python 0x00000001000aeccd PyEval_EvalFrameEx + 13517 6 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725 7 org.python.python 0x00000001000b3139 fast_function + 297 8 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709 9 org.python.python 0x00000001000b30d2 fast_function + 194 10 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709 11 org.python.python 0x00000001000b30d2 fast_function + 194 12 org.python.python 0x00000001000ae9a5 PyEval_EvalFrameEx + 12709 13 org.python.python 0x00000001000ab58d PyEval_EvalCodeEx + 1725 14 org.python.python 0x000000010003658c function_call + 364 15 org.python.python 0x0000000100010d53 PyObject_Call + 99 16 org.python.python 0x000000010001dec6 instancemethod_call + 166 17 org.python.python 0x0000000100010d53 PyObject_Call + 99 18 org.python.python 0x00000001000b289d PyEval_CallObjectWithKeywords + 93 19 org.python.python 0x00000001000ed1a6 t_bootstrap + 70 20 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131 21 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176 22 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 Crashed: 0 libsystem_platform.dylib 0x00007fff8ae51fc9 _platform_memmove$VARIANT$Unknown + 41 1 _CppBlockUtils.so 0x0000000107205fce BinaryData::BinaryData(BinaryDataRef const&) + 78 2 _CppBlockUtils.so 0x0000000107257408 BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocksFromFile(BlockDataManager_LevelDB::BitcoinQtBlockFiles::BlkFile const&, unsigned long long, unsigned long long, std::__1::function<void (BinaryData const&, std::__1::pair<unsigned long, unsigned long long> const&, unsigned int)> const&) + 1144 3 _CppBlockUtils.so 0x0000000107254ead BlockDataManager_LevelDB::BitcoinQtBlockFiles::readRawBlocks(std::__1::pair<unsigned long, unsigned long long>, std::__1::pair<unsigned long, unsigned long long>, std::__1::function<void (BinaryData const&, std::__1::pair<unsigned long, unsigned long long> const&, unsigned int)> const&) + 189 4 _CppBlockUtils.so 0x0000000107250883 BlockDataManager_LevelDB::loadBlockData(ProgressReporter&, std::__1::pair<unsigned long, unsigned long long> const&, bool) + 419 5 _CppBlockUtils.so 0x000000010724dfe9 BlockDataManager_LevelDB::loadDiskState(std::__1::function<void (BDMPhase, double, unsigned int, unsigned int)> const&, bool) + 3081 6 _CppBlockUtils.so 0x00000001072a529e BlockDataManagerThread::run() + 462 7 _CppBlockUtils.so 0x00000001072a5019 BlockDataManagerThread::thrun(void*) + 9 8 libsystem_pthread.dylib 0x00007fff88973268 _pthread_body + 131 9 libsystem_pthread.dylib 0x00007fff889731e5 _pthread_start + 176 10 libsystem_pthread.dylib 0x00007fff8897141d thread_start + 13
Thread 5 crashed with X86 Thread State (64-bit): rax: 0x0000000115d80000 rbx: 0x0000000107f00428 rcx: 0x000000000002902f rdx: 0x0000000000083a5c rdi: 0x0000000115ddaa2d rsi: 0x000000011bb00000 rbp: 0x0000000107f00380 rsp: 0x0000000107f00380 r8: 0x0000000000000000 r9: 0x000000000000000b r10: 0x000000000000000d r11: 0xfffffffffa2daa2d r12: 0x0000000000fa55cf r13: 0x0000000101b5a210 r14: 0x000000011baa55d3 r15: 0x0000000000083a5c rip: 0x00007fff8ae51fc9 rfl: 0x0000000000010206 cr2: 0x000000011bb00000 Logical CPU: 2 Error Code: 0x00000004 Trap Number: 14
Binary Images: .... Log file opened at 1425473672: /Users/sflicht/Library/Application Support/Armory/armorycpplog.txt -INFO - 1425473685: (BlockUtils.cpp:861) blkfile dir: /Users/sflicht/Library/Application Support/Bitcoin/blocks -INFO - 1425473685: (BlockUtils.cpp:862) lmdb dir: /Users/sflicht/Library/Application Support/Armory/databases -INFO - 1425473685: (lmdb_wrapper.cpp:478) Opening databases... -INFO - 1425473685: (BlockUtils.cpp:1193) Executing: doInitialSyncOnLoad_Rescan -INFO - 1425473685: (BlockUtils.cpp:1255) Total number of blk*.dat files: 78 -INFO - 1425473685: (BlockUtils.cpp:1256) Total blockchain bytes: 10,461,603,124 -INFO - 1425473685: (BlockUtils.cpp:1597) Reading headers from db -INFO - 1425473686: (BlockUtils.cpp:1623) Found 254495 headers in db -DEBUG - 1425473686: (Blockchain.cpp:211) Organizing chain w/ rebuild -WARN - 1425473686: (BlockUtils.cpp:1285) --- Fetching SSH summaries for 1000 registered addresses -INFO - 1425473686: (BlockUtils.cpp:1298) Left off at file 77, offset 106193333 -INFO - 1425473686: (BlockUtils.cpp:1301) Reading headers and building chain... -INFO - 1425473686: (BlockUtils.cpp:1302) Starting at block file 77 offset 106193333 -INFO - 1425473686: (BlockUtils.cpp:1304) Block height 254435 -DEBUG - 1425473687: (Blockchain.cpp:211) Organizing chain w/ rebuild -INFO - 1425473687: (BlockUtils.cpp:1339) Looking for first unrecognized block -INFO - 1425473687: (BlockUtils.cpp:1488) Loading block data... file 77 offset 98453429 -ERROR - 1425473687: (BlockUtils.cpp:536) Next block header found at offset 98453437 -INFO - 1425473687: (BlockUtils.cpp:564) Reading raw blocks finished at file 77 offset 121385335 -INFO - 1425473687: (BlockUtils.cpp:1356) Wrote blocks to DB in 0.266411s -ERROR - 1425473687: (lmdb_wrapper.cpp:1517) Block height exceeds DupID lookup table -ERROR - 1425473687: (BlockUtils.cpp:1395) missing 58 block headers -ERROR - 1425473687: (BDM_mainthread.cpp:427) BDM thread failed: Missing headers! This blockchain copy is corruptbeyond repair, time for a factory reset!
EDIT: Eventually managed to build the database and scan the tx history. Keeping my fingers crossed. EDIT2: Still unstable. Bitcoin-QT is still slowly catching up, but Armory didn't seem to be communicating with it (~30 minutes without Armory getting the new blocks bitcoin downloaded). Restarting armory led to "Missing headers: factory reset required" errors. After a couple of "light" resets (no db rebuild) it seems to have resolved itself and is rescanning the tx history. I have no technical expertise on these matters, but I wonder if partially-downloaded blocks are causing issues?
|
|
|
|
doug_armory
|
|
March 04, 2015, 02:29:16 PM |
|
FWIW the 0.93.0.7 patch seems *more* unstable on OS X: instead of popups about BDM errors, it just crashes outright.
I'm glad the crash went away. The crash actually looked exactly like a last-minute bug that was fixed right before 0.93 came out. Anyway, for various reasons, Armory remains unstable on some systems. On my system, Armory is stable. (That said, I haven't run the official 0.93.0.70 build yet.) On others, it's wonky. My suspicion is that it's due to Qt, a library we rely on. We are working on a possible solution in the background. It probably won't be ready for awhile yet but I do have hope that, after patiently waiting for so long, a reasonably stable OS X build will finally be out soon.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 04, 2015, 03:06:08 PM |
|
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.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 04, 2015, 03:07:35 PM |
|
Done rebuilding. For the first time, this version of Armory 0.93 successfully completes building the DB without progress unresponsiveness or non-specific hangups.
I must however make a note about memory usage. While I do understand from other threads that Armory doesn't actually gobble up all the memory and merely softly asks the OS to pre-commit space for it and release it at any moment if another program needs it, I still find it untennable to constantly run a program in the background that makes my gauging of free RAM unreliable. I don't want to have to use my PC in a manner where task manager is continually showing 99% RAM being used up, preventing me from actually seeing when a program does indeed get out of hand. Since I've seen no other program ever do this, I'd find it reasonable that Armory could scale down the practice too since I really don't see it needing to commit so much RAM in the first place.
EDIT: Upon a 2nd startup it seems to only do this RAM thing when it first builds the Armory DB, or at least, because the DB isn't that far behind it does it to a significantly less extent on future startups. It's still weird and, if Armory does think it's nice to have this type of DB lookup convenience, I don't think it should do it in a manner that's visible to the user(task manager).
Btw Armory's startup scanning and reach of full functionality is significantly faster than before. Cheers!
Next version will take it easier on the RAM front. For now I'm more interested in stability.
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 04, 2015, 03:25:21 PM |
|
Understandable. And in that, Armory works, and better than ever. Significant improvements in speed can be felt in steps 2 and 3. There is nothing that can be done about bitcoind's slow startup is there? It's a problem with bitcoind not Armory.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 04, 2015, 03:42:01 PM |
|
Understandable. And in that, Armory works, and better than ever. Significant improvements in speed can be felt in steps 2 and 3. There is nothing that can be done about bitcoind's slow startup is there? It's a problem with bitcoind not Armory.
Something can and will be done in the next version. It won't make it instant but it should prevent it from redownloading the last few blocks over and over.
|
|
|
|
sflicht
Newbie
Offline
Activity: 19
Merit: 0
|
|
March 04, 2015, 08:27:31 PM |
|
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.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 04, 2015, 10:17:55 PM |
|
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
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 05, 2015, 09:30:59 AM Last edit: March 05, 2015, 10:05:04 AM by 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
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 05, 2015, 03:31:30 PM |
|
Does the comment reappear on the next start?
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 05, 2015, 03:41:42 PM |
|
Nope, the bug edits right into the wallet comment label and removes it! The comment does not return upon restarting Armory.
|
|
|
|
MegaFall
Jr. Member
Offline
Activity: 56
Merit: 1
|
|
March 18, 2015, 07:57:03 PM |
|
Just got a pop-up in Armory for 0.93.1... so are the issues fixed?
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
March 18, 2015, 07:58:38 PM |
|
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
Jr. Member
Offline
Activity: 56
Merit: 1
|
|
March 18, 2015, 08:08:34 PM |
|
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
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 18, 2015, 08:09:17 PM |
|
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
Jr. Member
Offline
Activity: 56
Merit: 1
|
|
March 18, 2015, 08:12:04 PM |
|
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
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 18, 2015, 08:13:19 PM |
|
My OS? Windows 7 Ultimate 64-bit.
I was hoping for OSX. I'll look into it.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 18, 2015, 08:24:43 PM |
|
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
|
|
March 18, 2015, 08:40:34 PM |
|
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.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 18, 2015, 08:52:18 PM |
|
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
|
|
March 18, 2015, 09:17:23 PM Last edit: March 19, 2015, 12:38:42 AM by 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.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
March 18, 2015, 11:53:26 PM |
|
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
Legendary
Offline
Activity: 1358
Merit: 1000
https://gliph.me/hUF
|
|
March 19, 2015, 07:07:21 AM |
|
All good using Lubuntu 14.04
Good work!
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 19, 2015, 03:52:18 PM |
|
so those of us on Ubuntu 12.04, 32 bit are not to bother with the above 0.93.1 release?
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 19, 2015, 03:56:56 PM |
|
yep, answered my own question: Dependency is not satisfiable: libstdc++6(>4.7)
|
|
|
|
doug_armory
|
|
March 19, 2015, 04:07:41 PM |
|
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.
|
Senior Developer - Armory Technologies, Inc.
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 19, 2015, 04:22:53 PM |
|
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. i'll wait. no rush.
|
|
|
|
blindminer
|
|
March 23, 2015, 03:49:37 AM |
|
Windows 32bit
|
|
|
|
Searinox
Full Member
Offline
Activity: 147
Merit: 100
Do you like fire? I'm full of it.
|
|
March 26, 2015, 07:15:41 PM |
|
This issue continues to exist.
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 27, 2015, 03:13:26 AM |
|
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. ok, getting frustrated now. my online 0.92.3 online totally stopped working on 12.04, 32 bit. when are we going to get that dependency required i've been asking about?
|
|
|
|
etotheipi (OP)
Legendary
Offline
Activity: 1428
Merit: 1093
Core Armory Developer
|
|
March 27, 2015, 03:16:51 AM |
|
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. ok, getting frustrated now. my online 0.92.3 online totally stopped working on 12.04, 32 bit. when are we going to get that dependency required i've been asking about? 12.04 and 32-bit are both broken (for different reasons) in 0.93+. You will have no choice but to use 0.92.3. We should have a testing version of 0.94 soon which will work on 32-bit (Linux and Windows), but 12.04 still won't work yet. Unfortunately, it's more than "a missing dependency". We're working on a solution, but it's requiring a reworking of the build and packaging system
|
|
|
|
cypherdoc
Legendary
Offline
Activity: 1764
Merit: 1002
|
|
March 27, 2015, 04:45:39 AM |
|
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. ok, getting frustrated now. my online 0.92.3 online totally stopped working on 12.04, 32 bit. when are we going to get that dependency required i've been asking about? 12.04 and 32-bit are both broken (for different reasons) in 0.93+. You will have no choice but to use 0.92.3. We should have a testing version of 0.94 soon which will work on 32-bit (Linux and Windows), but 12.04 still won't work yet. Unfortunately, it's more than "a missing dependency". We're working on a solution, but it's requiring a reworking of the build and packaging system i'm getting this in the Armory Dashboard: There was an error starting the underlying Bitcoin engine. This should not normally happen. Usually it occurs when you have been using Bitcoin-Qt prior to using Armory, especially if you have upgraded or downgraded Bitcoin-Qt recently. Output from bitcoind: StdErr: bitcoind: ./db/dbformat.h:99: leveldb::Slice leveldb::ExtractUserKey(const leveldb::Slice&): Assertion `internal_key.size() >= 8' failed.
|
|
|
|
goatpig
Moderator
Legendary
Offline
Activity: 3668
Merit: 1345
Armory Developer
|
|
March 27, 2015, 05:20:57 PM |
|
i'm getting this in the Armory Dashboard:
There was an error starting the underlying Bitcoin engine. This should not normally happen. Usually it occurs when you have been using Bitcoin-Qt prior to using Armory, especially if you have upgraded or downgraded Bitcoin-Qt recently. Output from bitcoind: StdErr:
bitcoind: ./db/dbformat.h:99: leveldb::Slice leveldb::ExtractUserKey(const leveldb::Slice&): Assertion `internal_key.size() >= 8' failed.
Start BitcoinQt manually and see what it has to say for itself. Most likely it's DB is corrupt and it will ask to reindex the blockchain.
|
|
|
|
themann00
Newbie
Offline
Activity: 10
Merit: 0
|
|
April 22, 2016, 01:44:18 PM |
|
Missing BTC? Unconfirmed? Sweeping my keys? A while back (2013 apparently) I setup an Armory offline wallet setup. It was pretty slick. Had a netbook that had never been online, yadda yadda yadda. Well, I ended up hating it, because Armory always takes 19 years to sync back up if you don't run it constantly, so it was not convenient to move stuff in and out of. I messed with electrum a little- was going to go that route, and then decided to go with one of the commercial hardware wallet solutions. Before I did that, and got things moved, Armory did some kind of update, I couldn't get my online and offline versions to play nicely together, and I ended up having to recover my wallet to my online PC to access my funds. The recovery worked- and I had everything there I was expecting. In early March of this year, a friend who owns an IT company had a client that needed help with one of the cryptolocker viruses. We sent 3 bitcoins to the company, and the files unlocked. But this is where I'm confused about my balance. It's 3 bitcoin short. This is my entire recovered wallet-- it was at 16.77ish bitcoins at the begining of March. Then I sent 3.0001 bitcoins. The incoming .35ish is probably change from an address? The transaction itself is not confirmed for some reason, and my balance (also not confirmed) is off by 3 bitcoins from what I think it should be. It's showing about 10.77. Should be 13.77BTC. http://imgur.com/5vCVr9I So when I get my hardware device today- what is the BEST method to sweep my keys or whatever I need to do to ensure I've got each and every bitcoin I'm expecting, especially the missing 3BTC. Thanks for your help.
|
|
|
|
unamis76
Legendary
Offline
Activity: 1512
Merit: 1005
|
|
April 22, 2016, 07:18:20 PM |
|
Recovering your Armory backup gets all of your coins back. Maybe you had coins on two different wallets? If you want you can dump all private keys, but that will take too much time and do pretty much the same thing... BTW, this version of Armory can be considered obsolete. Next time create a new thread
|
|
|
|
|