|
At the moment, none of the upgrades are critical. You should/need to be upgrading Bitcoin-Qt/bitcoind, because you risk forking yourself off the main chain after May 15. But the Armory upgrades are usability and feature upgrades, not security upgrades.
You should receive notifications about new versions through the app, when you restart. It will show you what has changed, and you can decide whether or not you want to upgrade. If the upgrade is important, I'll make it the first item in the list of changes: i.e. "Security-Critical Update. Please upgrade immediately!". So far, I've never had to do that...
The next major update, will be the one that dramatically reduces RAM usage and startup time. That is an important upgrade for many users. But it's still just a usability thing... For now, you should be fine with any version past 0.86.3, which included some upgraded code for dealing with new blockchain format in the latest Bitcoin-Qt.
|
|
|
|
So my Armory install is broke? I was the OP of the error that was coming up. I'm not really sure what I'm suppose to do. I didn't do any upgrades or make any changes. And I still have bitcoin in my Armory wallet. I don't know what you mean when you say run it with this argument or whatever. Can you be a bit more detailed?
Just uninstall your current Armory and install the new version, 0.88.1. That error you originally reported has been fixed. https://bitcoinarmory.com/get-armory/ |
|
|
|
Will do shortly sir. I was reluctant to uninstall the BTC client for 2 reasons. Both due to ignorance. One I didn't want to have to download the blockchain again, of course. Two I was not sure if I could opt to not use the default install location with the Armory install option. I do not want it on my root drive for multiple reasons.
Quick side question maybe someone can answer. Is there anyway to move the blockchain data from its default location of the users directory?
You can move your Bitcoin home directory anywhere you want, just make sure you start Bitcoin-Qt/bitcoind with the -datadir=PATH option to make sure it's pointing in the right place. If you're letting Armory manage it for you, go into the settings and put the new path into the second box "Bitcoin-Qt home directory". Armory will start bitcoind with the -datadir option for you, and then set itself to look there, too. Reinstalling Bitcoin-Qt or Armory will not cause any issues. These programs are designed to touch only C:\Program Files\ on installation/removal, and only touch C:\Users\username\AppData\Roaming\ when running (which is where the blockchain data and wallets are stored). I need to make it more clear to users that their wallets will remain untouched. Upgrading/reinstalling, literally just changes the code that is running. |
|
|
|
Is this the "offical" 0.88 version?
The "official" one was yesterday. But I missed these show-stopper bugs, so I decided to go through the whole thing again today. It was annoying, but I really couldn't leave it in an usuable state for so many. I updated the webpage, but didn't re-trigger notifications. I didn't want to spam people who already upgraded. They'll probably find the upgrade themselves if they were affected by any of those bugs. |
|
|
|
Bugfix version 0.88.1, now available(Windows users, please fully reinstall again... this reinstallation stuff will hopefully be going away, soon) Well, I found three hardcore bugs in v0.88. Not security-related bugs, but the kind of bugs that prevent users from using the software. At all. These should've been caught during testing! Please help test. Especially in Linux, if you are running from the git repo, just keep yourself on the testing branch and pull occasionally. I promise only to update the testing branch after a lot of internal testing. Fixes:- Unicode issues in settings window: I missed a unicode fix which prevented some users from opening the settings dialog at all. This meant that you couldn't set Bitcoin-Qt installation or home directories
- "rpcport" in bitcoin.conf: Users who specified any rpcport argument in their bitcoin.conf file, would result in failed loading with auto-bitcoind. There really was no workaround for this
- Importing addresses: Another major Armory feature that was botched with a recent upgrade. You simply could not import addresses into an encrypted wallet. At all. Unencrypted wallets imported fine.
- Clean shutdown on Linux: It turns out I accidentally used functions in the python-psutil module that do not exist natively in older versions. This caused the auto-bitcoind management to leave bitcoind open even after Armory was closed, in older Linux versions. Granted, that might be good for some users... but it's not intended behavior (this is part of my goal to keep Armory dependency-version-less: making it easy to compile on just about any system)
So, I spent a couple hours creating scripts to streamline the release process, and it definitely made it a lot easier. The offline computer now signs the .debs, and also repackages the offline bundle, and automatically produces the *.sha256sum.asc file and signs it (after I manually verify hashes between all my computers/VMs). So, this process hopefully won't be so painful in the future, and the offline bundle will be reproduced automatically on every release. But it's still not pleasant. So, I just posted the updated installers to the Download page. I re-linked them at the bottom of this post, because my script automatically emits the BBCode for me, and so it just one copy&paste.
All the signed installers: Version 0.88.1-beta for Ubuntu/Debian 64-bitVersion 0.88.1-beta for Ubuntu/Debian 32-bitVersion 0.88.1-beta for Windows 64-bitVersion 0.88.1-beta for Windows 32- and 64-bitVersion 0.88.1-beta for Mac/OSX 10.8Version 0.88.1-beta SHA256 hashes of installersVersion 0.88.1-beta Offline Bundle for Ubuntu 10.04-32bitVersion 0.88.1-beta Offline Bundle for Ubuntu 10.04-64bit
|
|
|
|
OK upgraded to new 88 version on a 64bit Win7 box. Got the alert that my bitcoin client was running and I should shut it down. I did this hit the retry button, no joy. I figured out I needed to manually point it to where I installed the BTC client. I did that as I have don't have it on the root drive. Left the working dir path blank as it seemed correct. Still no joy.
I then filled out the working path since this is also not truly on the root drive but linked to another drive. Still no luck. I then had to set it back to the old method and restart Armory and we were rolling again.
Just thought you should know. i am not much more help than this but will do what I can to help figure this out if it wasn't just me doing something wrong.
As always: can you try it again and then send me a log file? |
|
|
|
.88 seemed to work for me but actually crashes every time when trying to encrypt a new wallet or decrypt an existing one. Repeatable Steps: Click Create new wallet enter password 3 times wallet created unlock wallet enter password crash or Click Create Paper Backup Prompt for password enter password crash OS X 10.8.3 Mac Pro 4,1 Process: python [70016] Path: /Applications/Armory.app/Contents/MacOS/Armory Identifier: com.armory.armory Version:  Code Type: X86-64 (Native) Parent Process: bash [70015] User ID: 501 Date/Time: 2013-04-19 11:18:10.814 -0700 OS Version: Mac OS X 10.8.3 (12D78) Report Version: 10 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Can you try restart Armory and do it with a new wallet? Can you decrypt other wallets? I've seen an error like this when the wallet was corrupted. Perhaps it was corrupted immediately, somehow? It will fail on any operation that requires unlocking. Also, please send me a log file. If the error is what I think it is, it'll have a "Stored public key does not match private key!" error (or something like that). Thanks for the report. |
|
|
|
Since Mike laid out the advantages of moving to DNSSEC for the PKI as soon as possible (in the other thread), an SSL "hack" may just be what we need for know, rather than designing anything "serious" based on SSL which is then later discarded. I like this hack and don't see any problem with it. Bitcoin pubkeys can be encoded case-insensitive in base32. And the merchant can decide if the security benefit is worth it for him or not. Small merchants won't have that kind of monitoring.
I'm liking the hack the more I think about it, too. Encoding a compressed public key (257 bits) in base32 would be 52 characters, which is comfortably less than the 63-character domain name limit. Anybody buying a multi-domain (not wildcard) certificate sometime soon? I'm curious to find out if CA's blink if you ask them to issue a certificate valid for something like BTC8df4rfkbmeopl49vvfgkjgtimb84k9gtredsxfr9fekspclen493.mydomain.com I was thinking about this hack last night, and I think it's not as bad as it sounds -- perhaps not really a hack, but just a simple extension of the existing systems. It's because the string in the subdomain doesn't have to be the full address, it just has to be identifiable. -- My business creates a super-secure offline wallet. The wallet root private key has the address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv. -- I create a subdomain of bitcoinarmory.com: 1armoryxcfq7tncsuza9fqjrywj4bkrkfv.bitcoinarmory.com -- I get a cert for that domain (all lowercase) verifying that I actually control that domain. When I send out a payment request, I include: -- A cert verifying that 1armoryxcfq7tncsuza9fqjrywj4bkrkfv.bitcoinarmory.com is verified -- The actual root public key (but not chaincode) -- The "InvoiceID" which will be used to multiply that public key -- The amount to send (and all the other stuff that needs to be included) Then user's software can verify that 1armoryxcfq7tncsuza9fqjrywj4bkrkfv.bitcoinarmory.com belongs to me, and that hash160(publickey).lower() matches the subdomain. Then they mulitply the verified public key by the "InvoiceID" and pay that address. This works, because the address is 160 bits. Throwing out the casing removes at most one bit of that information. Even if my address is all letters (like the one in my signature), you still have at least (160-33)=127 bits of "entropy", which is more than enough to be collision resistant. And I haven't actually added anything here: you have to send them the public key anyway. I'm just pointing out that the signed data in the subdomain doesn't have to to be be a full address, just a "fingerprint" of such an address. This has been on my mind recently, because I'm enjoying potential simplicity of this solution, and think it would be technically usable right now... besides the availability of a standardized, compatible wallet format (but BIP 32 will work). A company only has to get another subdomain included on their cert each time they change their wallet. Or the solution could be extended so that they can actually use the verified address, to ECDSA-sign other addresses/wallets to be used to collect funds for the company. |
|
|
|
|
Yep, another bug! Another something-simple that shouldn't have slipped by me. I tested sweeping in encrypted wallets, and importing in unencrypted wallets. But the bug is only for importing in encrypted wallets.
For now, it should work to import your single key using the mulit-key version. Let me know if not.
Looks like I'll be making a v0.88.1 release soon. I'll just silently release it with these little bug fixes and re-link the download page, but not trigger notifications. Things like key importing are quite important. And most of these fixes are just one-line/5-character updates.
|
|
|
|
If thinking like this starts creeping in than we are on a slippery slope. Why not reverse a 1-Conf transaction, if the pay is good? I think we should try to nip it in the bud. Encourage good behavior by orphaning transaction reversal blocks.
Reversing 1-confirmation transaction is almost always economically unfavorable. You don't need to discourage that, because miners are bleeding money for every second they aren't mining off the top block. And as I said ... you can encourage, wish, complain, etc, all you want, but if it goes against their bottom line, it's not going to make a bit of difference if they're acting within the prescribed rules of the system (which is that there is no economic incentive not to do this) So it will be done. On the other hand, if we implement something that makes it economically infeasible, then that's a different story. But you can't regulate this problem away. You have to adjust the rules of the system and let it reach equilibrium, which hopefully doesn't include that behavior. But I'm not sure if this is something we can achieve. EDIT: about your "orphaning transasction reversal blocks": there's no way to do that with zero-confirmation transactions. For 1-conf, it would be possible, and if you hit a critical mass of miners willing to reduce their effective hash rate, they might be willing to do it. But again, all miners have the incentive to mine off the top block. if they are not mining the top block, they are losing money. (enter caveats about extreme circumstances like someone putting a 200 BTC fee on a tx to try to out-spend that economic motive). |
|
|
|
|
Like jdillon, I believe that in the long term, many miners will allow paid replacements of transactions and zero-conf transactions will become as useless as what we're afraid of. You can talk about ethics, and what's in the "best interest of miners", but that is just wishful thinking that in a completely-decentralized system everyone will have the same ethics and motives. I'd rather just see it happen and let the ecosystem adjust to the loss of remaining zero-conf security/sanity, instead of naively hope that everyone will follow the same guidelines that are not bound to follow. Especially when there is economic incentive to breaking these guidelines. Not all miners are dependent on the security of zero-conf transactions. Many of them will just do what's best for their bottom line.
I've seen the phrase "allow" when referring to miners replacing zero-conf transactions. Above, im3w1l mentioned "setting a precedent". This is meaningless, because no one has control over all the miners, and they don't need to seek anyone's permission to do something that is entirely within the rules of the system. The best we can do is "recommend" guidelines by making it part of the default client, but that's it. It's part of the blessing&curse of being decentralized. Sure, a lot of miners won't do it. But some will, and you only need any to do it, in order for it to dramatically degrade this system.
Therefore, we are adapting ourselves (and letting others adapt) to a false reality by designing systems with an assumption that there is some security in zero-conf transactions. I'd much rather just write it off completely, and let businesses and users adapt to the idea that zero-conf transactions are basically useless for exchanges between untrusted parties. Forget it. If you don't trust the person, don't mess with zero-confirmation transactions. Period.
|
|
|
|
No need to post twice on the same question. I'll answer it in one of the places. See my answer here: https://bitcointalk.org/index.php?topic=56424.msg1881413#msg1881413Also, when reporting on a problem, please also try it in offline mode, to help me figure out if the networking/blockchain stuff is part of the problem. In windows, a shortcut to "Armory (Offline)" is added to your menu next to the regular Armory. |
|
|
|
I run Windows 8. Every time I try to run Armory, I get this: Traceback (most recent call last):
File "ArmoryQt.py", line 4804, in <module>
File "ArmoryQt.py", line 466, in __init__
File "ArmoryQt.py", line 3867, in setDashboardDetails
File "armoryengine.pyc", line 10777, in getSDMState
File "armoryengine.pyc", line 10809, in getSDMStateLogic
File "armoryengine.pyc", line 10942, in getTopBlockInfo
File "armoryengine.pyc", line 10934, in updateTopBlockInfo
File "armoryengine.pyc", line 10867, in createProxy
TypeError: %d format: a number is required, not str
Argh! Just found that there is a real bug here, not user error. The issue is that i'm not casting the "rpcport" in the bitcoin.conf file to an integer, so it's failing to produce the correct URL when you have any rpcport argument in the bitcoin.conf file. And for Windows users, there's not a convenient way around this bug. I can't believe no testers ran into this! Man, I need more testers... The only solution I know for working around this with 0.88-beta is to remove rpcport from your bitcoin.conf file, and run bitcoin-qt/bitcoind with the -rpcport command-line argument. Then run Armory with the -satoshi-port argument that matches. I hate releasing a bugfix version right after a regular release and triggering notifications again (effectively spamming users). I guess, I could accumulate these bugs into a v0.88.1-beta version, and silently update it, without triggering notifications. But still change all the links to point to the new version. I guess that works... |
|
|
|
My Armory just stopped working. It crashes when trying to sync up. Before I start messing around with things, I would like which direction to go in? I do have bitcoin in my wallet. Please advise.
Faulting application name: Armory.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: MSVCR90.dll, version: 9.0.30729.6871, time stamp: 0x4fee6073
Exception code: 0x40000015
Fault offset: 0x0005beae
Faulting process id: 0x1f84
Faulting application start time: 0x01ce3cad710e53a1
Faulting application path: C:\Program Files (x86)\Armory\Armory Bitcoin Client\Armory.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6871_none_50944e7cbcb706e5\MSVCR90.dll
Report Id: 0edbb14d-a8a1-11e2-be93-180373e36d96
Faulting package full name:
Faulting package-relative application ID:
Did you uninstall the previous version before installing the new one? At least, you can rerun the installer and choose "Repair Installation". |
|
|
|
When importing a private key in 0.88 I get stuck in a confirmation loop, selecting OK after entering the private key, selecting Yes to verify the associated address, back to the key entry where I press OK, which then asks to verify the address, etc. This was not an issue in 0.87, where it would ask for the wallet password after verifying the address.
Weird! Can you send me a log file? The key data is never written out (I was careful about logging in that section). But you should review it anyway before sending it. I literally just imported a key, myself, and it worked. 10 minutes ago. I was glad to see that, I thought, the feature was still working! What's the key format you're using? Casascius mini-private key? |
|
|
|
etotheipi, just for you to know, latest v0.88-beta from github still has issue with unicode when trying to enter settings UnicodeEncodeError: 'ascii' codec can't encode characters in position 228-229: ordinal not in range(128)
Traceback (most recent call last):
File "/opt/BitcoinArmory/ArmoryQt.py", line 716, in openSettings
dlgSettings = DlgSettings(self, self)
File "/opt/BitcoinArmory/qtdialogs.py", line 10215, in __init__
'specified format.' % exampleStr )
File "/opt/BitcoinArmory/qtdefines.py", line 212, in __init__
self.setText(txt, **kwargs)
File "/opt/BitcoinArmory/qtdefines.py", line 215, in setText
text = str(text)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 228-229: ordinal not in range(128) Gah! I missed something! I fixed the unicode path names, but not if your default datetime format has unicode characters. That's unfortunate. You can manually modify qtdefines.py:215 to say "unicode(text)" instead of "str(text)". I know that doesn't solve it for everyone else... That's also what happens when I don't have a lot of people testing. I have conceded that certain bugs will only be found after major releases, and that there will be a v0.XX.1 that will have to happen 1-2 weeks later. Oh well, there's no real way around it (I don't blame people for being hesitant about testing new versions with their primary wallet). |
|
|
|
I run Windows 8. Every time I try to run Armory, I get this: Traceback (most recent call last):
File "ArmoryQt.py", line 4804, in <module>
File "ArmoryQt.py", line 466, in __init__
File "ArmoryQt.py", line 3867, in setDashboardDetails
File "armoryengine.pyc", line 10777, in getSDMState
File "armoryengine.pyc", line 10809, in getSDMStateLogic
File "armoryengine.pyc", line 10942, in getTopBlockInfo
File "armoryengine.pyc", line 10934, in updateTopBlockInfo
File "armoryengine.pyc", line 10867, in createProxy
TypeError: %d format: a number is required, not str
Apparently you have a non-numeric port number in your bitcoin.conf file? Did you create that file yourself? What's the port number? |
|
|
|
Can you send me a log file?
Here's the log from a recent start: http://snippi.com/s/so03ak4And to clarify, it finishes "synchronizing" (the first one), but doesn't finish scanning the blockchain (the second one)? Are you using a non-standard datadir? I ask because I just found a bug that will be fixed when I release 0.88 soon.
It's stuck at the "Scanning Transaction History" process and won't ever get over 75%. Datadir is the default directory in ~/Library/Application Support/Bitcoin/ This is becoming all-too-common now. And I just started on my persistent-blockchain updates -- I will no longer be touching blk*.dat files at all! This will solve so many bugs like this (though, probably introduce more...) Until then, you get the same advice I give everyone else. It looks like there's a glitch in your blk*.dat files which Armory is tripping over. Redownload the blockchain. It takes a long time, but it seems to work. (1) I can't replicate this problem, so I don't know how to fix it (2) It is purely an artifact of a design decision that is completely going away... I don't know if it's worth trying to fix it if it will be obsolete in a couple weeks. |
|
|
|
Just tried to import into Blockchain.info and it did not recognize the key. So that won't work  It's because that key is not in a standard format. Somehow it has to be converted to a standard format that is recognized by other apps. I'm not sure what format it's in... but I'm sure you can do some searches for StrongCoin private keys and figure out what format it's in, and how to convert it. |
|
|
|
|
Show Posts
