So we wait for the next proper working version of Armory ?
The current one works fine - if you have 8 GB of RAM. So if you are impatient, that is an option ...  |
|
|
|
I performed testing, and could not reproduce this vulnerability. Password reset does not touch the 2FA settings.
Stephen, could you check and let me know exact steps to reproduce? Maybe I missed something. Thank you!
Just to clarify, what I'm asserting is that if my e-mail account is compromised an attacker can reset my password and withdraw my funds. Steps: From a browser instance after clearing cache, cookies, etc: Step 1: Confirm 2FA is active (Attempt to login to account in which 2FA is activated, using just username and password). Response: "Your code isn't valid." Step 2: Click "Request new password" button. Step 3: Login using single use login sent via e-mail Step 4: Once authenticated, click GA_Login tab [Edit: and click "Create code" button.] "Google Authenticator is enabled for your account. If you want to create a new key - please click on the button below. The old key will be dropped." Step 5: Add TOTP secret to Google Authenticator, mark "I have successfully scanned the current code" checkbox, and click "Code scanned" button. Step 6: Withdraw funds using new TOTP secret from Google Authenticator Of course the really difficult thing is to stop vulnerabilities like this, and still have a recovery path in case somebody loose their GA secret. I just to my horror realized that on an iPhone the GA secrets are backed up in a way that they can only be restored on the same device. Secure, but troublesome if I loose the device. |
|
|
|
I notice that simply doing a password reset through e-mail can successfully bypass two-factor authentication (2FA) protection as I can withdraw funds without 2FA after resetting the password.
Shouldn't the 2FA code be required to request a password reset (when 2FA is enabled)?
This is serious. That means that 2FA protection for withdrawal is nonexistent. I hope this bug get fixed soon, password reset should not reset 2FA, forgetting the password and loosing access to your phone are two different problems. |
|
|
|
|
It would certainly be sufficient for an offline machine - I use a Raspberry Pi for that! No need for SSDs or anything fancy for that use. And don't use the machine for anything that will touch the Internet.
SSDs may be less likely to crash, but they can still fail. And your machine may fail in many other ways, including getting stolen. Do not rely on your offline machine being indestructible, instead keep a number of backups including at least one paper backup.
|
|
|
|
|
Are you sure you have installed a 64 bit version of armory? The 32 bit version has reportedly stopped working because some of the data cannot be addresses in 32-bit mode. It must be one of the very few real-world applications needing 64 bit!
If everything else fails, start Armory in offline mode and export the private keys. You should be able to import them in another client, or on blockchain.info or similar.
|
|
|
|
Same problem here. And I'm running 32 bit windows on my laptop. Can I solve the issue by creating a bootable USB running ubuntu (64 bit), and installing QT + armory?
Probably And will I be able to transfer the blockchain across rather than having to wait for QT to sync (which would probably take a week)?
Yes, you should be able to copy everything from the directory where Bitcoin-Qt stores its blockchain to the similar directory under Linux (.bitcoin/blocks - be aware that .bitcoin starts with a dot making it a hidden directory). You should definetely copy all blk*.dat files, and probably also the index and rev*.dat files. Good luck! |
|
|
|
Since Armory wallets are deterministic it doesn't matter if you made the backup when you first created the wallet. All of the information will still be there when you restore the wallet to a new machine and no need to copy any files.
Any notes you have added after taking the backup will be lost. But no BTC will be lost. You may actually want to copy over both the full Armory data directory, and the whole Bitcoin-Qt data directory. The latter will save you a 1-2 day synchonization of the block chain. Unfortunately, I never use bitcoin under Windows, so I have no clue where the data is hidden. |
|
|
|
Could you link to the bitfunder spec/trading page regarding the difficulty futures? I can't find it.
Search for iDiff, that is part of the name. They settle significantly sooner than September, so it is not a useful indication of what the price at icbit should be  |
|
|
|
Good news everyone! We just launched Bitcoin difficulty futures, DIFF-9.13It's going to be an interesting financial instrument, happy trading! Questions are welcome, of course. OK, so that is a new one, and not seen in other markets. But is it a financial instrument, or just betting?? |
|
|
|
I haven't opened armory for a while because I use bitcoin qt for day to day use. Now I was going to transfer funds to my qt wallet, but I can't connect armory up to the blockchain. It scans the chain for 5-10 minutes, then I get a runtime error from windows, and it shuts down. Anyone have a clue what might be the problem?
Probably you have been hit by some of the data structures used to represent the block chain are now to big to be addressed in a 32-bit application. You suddently need a 64 bit version of Armory. That is very unfortunate, and unfortunately only one of many problems caused by the exploding size of the block chain. |
|
|
|
piuk,
I'm trying to transfer BTC from my blockchain.info wallet and I get the error message: "ReferenceError: Can't find variable: precisionFromBTC". Any idea what is causing this?
Thanks
In case puik does not answer: Have you tried clearing your browser cache, it often solves this kind of problems. |
|
|
|
So if I open an order with a leverage of 1, I'm still charged interest, even though I'm not "borrowing" any BTC to place the order?
But you are borrowing as many BTC as you have placed in your margin account. That is why you can win on the price going up. If you were not borrowing, you would just have been moving your BTC from your own wallet to 1Brokers. If you place one BTC as margin and go long at leverage 1:1, then you borrow and additional BTC and can win or lose depending on what happens to the price. If you were posting USD as margin and going long at 1:1, then you would not be borrowing but just buying. Leverage where you post margin in the same currency as you trade is a bit strange, essentially the leverage is one higher than normal when going long, and one less than normal when going short. |
|
|
|
For the BTCUSD CFD on 1Broker I think I have good news is the near future How near is the near future? :-) |
|
|
|
|
AMD64 = AMDs 64-bit processors
EM64T = Intels 64-bit processors
|
|
|
|
i386 = 32-bit systems (alternately, anything that is not a 64-bit AMD system. I have an intel 64-bit CPU and I use this i386)
amd64 = only for 64-bit AMD systems
To be honest, I do not know how debian does it, but in most other Linux distributions amd64 means 64-bit AMD or Intel. AMD were first with the 64 bit extensions to the i686 architecture, hence the name. Intel wisely chose to be compatible, but by then the name amd64 had stuck for that architecture, although some chose to change the name to x86_64. |
|
|
|
Ahh. You know I never used easy_install, but I just tried it. That really is easy!
At least until you want to uninstall again. No luck. Which is why pip is preferred over easy_install, and preferably in a virtual_env. Care to explain? I never heard anything about that unlike real packaging systems, easy_install drops everything in the main Python directory structure. There is no central database of what was installed by which package, and no way to uninstall the stuff again. This can make it kind of hard to return to a clean installation, or to get rid of unnecessary packages. |
|
|
|
At least the paper will survive through water,
Unless you use an inkjet printer. heating below 451 F, With all respect for Bradbury, I doubt that this temperature is particularly significant :-) |
|
|
|
It seems to me that my only risk with this system is that my flash drive gets corrupted and I lose the private keys. Assuming that doesn't happens, ..... Why would you assume that doesn't happen? Flash drives are notoriously unreliable, even if you don't loose them or wash them with the laundry (which, btw, they often survive). A few years back, I almost lost my GPG key. I only had four backups, and the first three failed (mostly due to age, one of them was a 3.5 inch floppy!) |
|
|
|
Ahh. You know I never used easy_install, but I just tried it. That really is easy!
At least until you want to uninstall again. No luck. Which is why pip is preferred over easy_install, and preferably in a virtual_env. |
|
|
|
Is there anything protection against the following attack?
Say I'm using an offline wallet, and I want to send some funds to an address. My offline wallet contains 1000 BTC at a single address, and I want to send 10 BTC to an address.
My online computer is infected. The Armory running here has been replaced with a malicious version. The malicious version of Armory creates a transaction that, correctly, sends the 10 BTC to my desired destination, but returns the 990 BTC change to an attacker's wallet.
Can the offline Armory version tell if an output is a change address, and thus deduce whether it's sending change back to an address owned by itself or to an attacker?
I can see when I make large transactions that online Armory hides the change address. If the attacker makes the online Armory version hide the change address (which belongs to the attacker), and the offline Armory doesn't know whether it's sending 10 BTC with 990 BTC change, or 10 BTC to one foreign address and 990 BTC to another foreign address, then it's very difficult for me to see in offline Armory what's really happening, since I don't know my own change address.
Is it possible to mark change addresses with some specific color in offline Armory, so I can see that a specific address is indeed a change address, or is this already done?
Thanks!
Yes, the offline computer can see that. Remember *always* to check the transaction on the offline computer, the change address will be marked with the label of the wallet. If neither address is labeled, you are in trouble. This is why Armory always tells you to double-check the transaction on the offline computer. Recently, I did something like that myself. I was combining a payment with moving some funds. I made a payment using a single input (coin control), and two outputs, one was my payment the other an address in my blockchain.info wallet. So no change address. Armory issued a warning that I could be falling victim to the attack you describe. I cannot remember if it was the online or offline Armory that warned me. Looks like etotheipi has thought about this vector |
|
|
|
|
Show Posts
