Thanks goatpig, that worked. Saw on website that 0.93.2 also says it has a 32 bit version and will run on XP. But when I checked on secure downloader and filtered out 32 bit versions 0.93.2 didn't show up. So I installed 0.92.3 to play it safe.
That's a mess up on our part, 0.93 only comes in x64 on Windows. |
|
|
|
|
You can offline sign with 0.92 and broadcast with 0.93.3
|
|
|
|
I actually didn't know about the entry guard attack. My point is that not all clearnet traffic is encrypted: to inject data into a non encrypted clearnet packet
Rather simple to setup this broad, undiscriminated attack on the Tor network, the kind de-anonymising parties would resort to I expect. did some very complicate traffic correlations attacks that only a gov. agency is able to do
If it's a credible attack vector, it should be accounted for, regardless of the resources implied. This is why I consider Tor to clearnet traffic to be unsafe. Same goes with SSL, for obvious reasons. There are 300+ CAs out there, and it only takes compromising one. |
|
|
|
|
I've read several times that the weakest point in Tor is the exit relay since it is essentially positioned as a MITM. I'm no network security specialist but it seems rather benign for an adversarial exit relay to inject data into a non encrypted clearnet packet to try and reveal meta data about the requesting party, or monitor said packet size.
|
|
|
|
Electrum is included on Tails OS though. Wouldn't Tails compansate sufficiently for the loss of privacy in Electrum?
You will still be uploading your wallet's addresses to Electrum to fetch your history. As for the IP, if the Electrum server is a hidden service, you'll be fine. If it's on the clearnet, you'll be using an exit relay which may or may not reveal your IP. |
|
|
|
|
You lose privacy with SPV/lite clients. Armory has a harder and longer than average setup but won't jeopardize your privacy in return. That choice is for you to make.
Regarding security, as long as the wallet software doesn't do anything ridiculous, the security of your coins depends on the security of your stack + backups. In other words, the main factor is you and how well you understand the mechanics of cold storage.
I can't tell you much of anything about Electrum's security, I don't use it. I'm in no position to evaluate that part of the software.
|
|
|
|
The offline packages are for Ubuntu, some of the .deb in there won't install on Tails (which is based on Debian Wheezy). I'm not sure what you are trying to achieve. If you are using this machine as an offline signer, you will need to build up the list of necessary packages to install Armory. If you start with one of the Ubuntu packages, you will most likely run into dependency issues with python-twisted, python-openssl and libqt4. You will want to browse to the offline package folder from the terminal and run: sudo dpkg -i ./*.deb You will get a bunch of errors, these will be from packages that are either missing or not suited for Debian Wheezy. Go to Debian's repo ( https://www.debian.org/distrib/packages) and search for these packages by name. Download the Wheezy i386 version for each package (I'm fairly sure Tails is x86), unless it says all, in which case get that. Copy the downloaded packages into the offline bundle folder, and run that one command again. On top of my head, the packages you will be missing are: libqt4-designer libqt4-help libqt4-scripttools libqt4-test python-crypto python-openssl python-twisted-bin python-twisted-core python-twisted-names python-twisted-web and whatever else I forgot about. Once you finally get the message that Armory has been installed (kinda hard to miss), you should be able to run it just by typing armory in the terminal. ------------------------ If you are using Tails for online Armory, follow these instructions: https://bitcoinarmory.com/building-from-source/You'll have to build Core from source too most likely. |
|
|
|
Happy to report though that after a long Core download from scratch followed by an Armory rebuild/rescan, things appear to be working again! Hopefully I'll never have to do that again :-O
Backup your Core data folder to ease the pain next time. |
|
|
|
|
I'm not familiar with Core's code but I expect it was due to Core. Armory only ever reads those files and doesn't attempt to lock out other processes so it doesn't interfere with Core flushes either.
|
|
|
|
EDIT: To be clear, I did the lightest option factory reset. I guess a heavier version is also an option.
You dont have much of a choice in the matter. Usually I'd recommend deleting the blkXXXXX.dat files up to the missing blocks, but at height ~200000k you're barely 5GB into the blockchain, simpler to just nuke it all. |
|
|
|
Thanks for the quick response! So to be clear, I can do the factory reset and once it's complete, have full functionality back with my existing wallets?
Factory reset nukes your DB, Core's blocks and defaults your settings. It doesn't touch wallets nor lockboxes. Any idea what would have caused this?
Core is either missing a block in one of its blkXXXXX.dat or the block got mangled and the valid one was written after it. Core does not delete mangled blocks nor overwrites them. Armory is chocking on the mangled block (it's probably not mangled enough for Armory to just skip it). The upcoming version handles these kind of cases properly. |
|
|
|
I have a similar issue, but possibly not the same one.
I'm running Armory 0.93.3 and Bitcoin Core 0.11.2.
I normally run both Bitcoin Core and Armory 24/7. Bitcoin Core is up to to date and always current (i.e. receiving blocks without issue). Armory one day crashed and said I needed to factory reset (no idea why). I restarted with a rebuild and rescan figuring it might fix things. It didn't. Armory always stops at block 191534. I tried a few times and every time I rescan or rebuild/rescan, it always come up and appears ready at block 191534. Meanwhile, Bitcoin Core chugs along normally (currently at block 386938).
A few questions:
Is Armory compatible with Bitcoin Core 0.11.2?
Do I need to do the factory reset to resolve this?
Does a factory reset remove all wallets and require that they be re-imported?
1) Yes 2) Yes 3) No |
|
|
|
More out of curiosity than anything else, but is the secure downloader actually working at the moment? For me, it complains that it hasn't seen an update in months, and won't show me anything recent. But I self-built, so maybe something broke.
I don't think it is. Sometimes when I make a tx and get change back in the same wallet the change appears as separate tx between the transactions. Not a real problem ofcourse, however the change is also not subtracted from the address so it shows as double. This prevents to make further transactions until the tx are confirmed. In those cases the change address is the same as the output address.
Armory won't let you spend incoming ZC, only ZC change. I'm aware of the ZC parsing bug (where it sometimes fail to figure out an output is actually change) and I have fixed that in the soon to come release, so you'll have to be patient. |
|
|
|
|
You don't need to delete everything, you can simply get rid of the last 1-2 blkXXXXX.dat files in your case.
|
|
|
|
Is 0.93.3 going to be put up on the website? Currently the downloads link still seems to point to 0.93.2.
roy
Not sure about that, I'll ask around. |
|
|
|
Is this the fix for the URI bug?
No In jsonrpc_listaddrunspent() the identical code is used at line 556.
Should that line be patched in the same way as line 462 ?
No |
|
|
|
Hey goatpig what about BIP65 support/UI? Is that on the to-do list?
It has to be, at least to identify received locked outputs. At that point adding support for CLTV spends is trivial. Is it hard to do it?
Not hard per se. GUI modifications are always a pain though. |
|
|
|
|
Show Posts
