Topic: [ANN] Armory 0.93.1 Official Release - page 4. (Read 16724 times)

I'm glad armory might be getting paid business. Armory #1

Armory has been absolutely solid

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.

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.

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)

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:


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. 

An approach using Synaptic: https://bitcointalksearch.org/topic/how-to-get-the-needed-packages-on-your-offline-computer-synaptic-pm-777625

I'm unsure if it is included in a standard Ubuntu 14.04.2, though. You might to have to get it (and maybe dependencies) on your own.

http://packages.ubuntu.com/trusty/synaptic

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.

Can we get an Armory Dev to confirm the BDM error is common and if a fix is in the works?

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.

I have the same issue in the post above.  Glad to know I'm not the only one.

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

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?

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?

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=pdf

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).

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

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

we all want Armory to prosper as it benefits all of our security.

this is a very reasonable approach.

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.

Oh ok that makes sense. What's protecting an identical transaction?

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.