|
Well, I'll be damned. I actually linked both the Win64 and Windows_all versions to the Windows_all download link. That explains a lot!
I think, for now, I will only post the Windows_all version, and link users to the 64-bit version if they have difficulties.
OH! I bet this is the reinstall problem so many people had! Armory can't start after a fresh install: because they thought they had the 64-bit version installed previously, and installed the new 64-bit version. But they actually had the 32-bit version installed. It doesn't change the fact that the installer should do a full overwrite anyway, but it does make more sense, now.
|
|
|
|
I just tried it and unfortunately it never finnishes the inital scanning process (I left it open for 4 hours).
I'm on a brand new iMac with SSD, so I guess it should be done by now.
I'm running bitcoin-qt version 0.7.2 because I already had database problems when using 0.8.1 and had to do a rescan.
Could that be related to the armory problem?
Anyway, thanks so much for getting this started for OS X, really looking forward to a working version!
Can you send me a log file? And 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. 0.7.1 should work. But I'll wait to say any more until I see a log file (etotheipi gmail com) It sounds like 0.88 has to come with a caveat ... flip a coin ... if it's heads, it won't work on your OSX machine... gah! |
|
|
|
Question!Has anyone ever noticed a difference between the Win64 and Windows_all versions of Armory, on 64-bit Windows? I just noticed on my googlecode download page that 99.9% of downloads are for the win32 version. And I know more than 0.1% of users are using 64-bit! I ask, because it's kind of a pain to keep producing both 32-bit and 64-bit versions of the software. If I could reduce it to just one Windows version, that would dramatically reduce the amount of work I have to do for a release! Perhaps this proves that the 32-bit version is interchangeable with the 64-bit version and I can ditch it... Thoughts/experiences?
|
|
|
|
Claimed by jackjack!Original message:
I was going to do this myself, but it should be fairly straightforward to implement and I have some other priorities right now. But there has been demand for it, so I'll let someone else take a shot it for me. The string manipulations should be trivial in python. Goals: - (1) Create a new message signing algorithm that I can easily wrap with a nice GUI
- (2) It should have three modes:
-
- (a) Bare signatures, compatible with signatures from Bitcoin-Qt/bitcoind
- (b) RFC2440-compatible, ASCII-armored signature blocks (Base64), with the CRC-24
- (c) RFC2440-compatible, ASCII-armored signature blocks (Clearsign)
- (3) It would be neat if the clear-signed messages were somehow compatible with bare signatures: i.e. you could copy the text into Bitcoin-Qt and signature into Bitcoin-Qt and it would verify properly. But I highly doubt that's possible... maybe for simple messages
- (4) Unit-tests that demonstrate dash-escaping, newline behavior, and unicode support
- (5) Be willing to release the copyright of your solution to public domain
The reason I think (3) is not possible is that Sections 6 and 7 of RFC2440 indicate changing newlines (\n) to Windows newlines (\r\n). And dash-escaping the clear-signed text, but using the original text for signing. I haven't looked too deeply into it, but what I've seen is that it won't be too complicated, just requires some attention to detail. Such as getting CRC-24 coded correctly (also looks simple). For Base64 encoding: go figure, python has it built-in: "import base64; base64.b64encode(msg), and base64.b64decode(sigBlock)" This doesn't need to be integrated into the GUI at all. Just have it operate on raw strings, and I will integrate it into the GUI. The GUI would probably have radio buttons that say "Version 0 (Bare Signature/Bitcoin-Qt)", "Version 1 (Base64)", "Version 1 (Clearsign)", and the appropriate signature would be produced for the text that is in the text box (which may include newlines, dashes, and unicode). Anyone up for the task? [/list][/list]
|
|
|
|
Hey, I think you should fix that!. Where I placed the red circle/ellipse thingy, I think the text should be fully centered (to allow seeing the decimals without wasting the space) instead of starting on the middle like it is currently. What do you think?
Yeh, I guess I could bring it in a little bit. The goal is to make sure the decimal place is lined up for all rows, so that 112.5 doesn't "look the same" as 1.125. For that, I need to reserve some space on the left side. But I agree, there's probably too much there. |
|
|
|
|
Do you have a way to check whether anything really changed? I mean, I tried uninstalling everything, but there's a chance that it didn't do it right. I was thinking of restoring a fresh OSX install to try it, but I forgot to save the fresh-install state. I figured what I did was enough...
|
|
|
|
Unfortunately, I don't have a system to test on that doesn't work, so the best I can do is try your suggestion, and post the results. I uninstalled all the brew dependencies, cleaned all the build directories, added --env=std, and then rebuilt everything. For some reason, the result is 300 kB smaller... not sure why. But I did it, so you can try it. I have updated the original post here. |
|
|
|
Some people might have heard about Stroncoin's security leak, which caused some people's Bitcoins to be stolen. When I discovered this, I went to take all of my Bitcoins out and transfer them to another address. To my surprise, I was not able to do so, since the website is having some sort of issue. I emailed the support email address, got a couple of replies which were simply questions, but have not been replied to since answering the questions. That was almost a week ago, so I am trying desperately to find a way to get my coins so I can stop having to deal with Strongcoin. Anyway, I have my Strongcoin paper backup, and am trying to use it using the Import/Sweep Private Keys function. I entered the private key into the box, selected "single key", and can only select "Import These Keys" since "Sweep" is greyed out. I hit OK, and nothing happens at all. The OK button looks like it's being pressed, but nothing else happens. Is there something I am doing wrong?
I found an error in the error-handling code, which causes that "Ok" button to do nothing when you enter invalid data. So it should've notified you that the data was invalid, but it doesn't change the fact it was invalid! I'm not familiar with the data format that Strongcoin produces. Do you think you could give me a sample that doesn't have any money attached to it? Then I can see what it's expecting. But is it only a single private key? Does strongcoin only use one address for your account? |
|
|
|
Thanks for fixing the problem. However, why would you want to reduce the timeout from 0.01s to 0.001s? Would there be any noticeable difference?
That check happens in the main thread, which means it blocks until it's done. That means the GUI will be unresponsive for up to 0.01s on each call. If this function was called every 0.1 seconds, the interface would be jittery and laggy. It's not called that often, but in the future I might want to... So, I want the value as low as possible unless I want to go through the hassle of somehow multithreading it. Since it's localhost, I figured 0.001s was more than enough time anyway. And I was right... for all systems except Windows Server 2008, apparently... Oh well. I reverted it back to 0.01s, which isn't a problem when it's called at most once-per-second, and I'm sure it will have minimal impact. I just have to be careful if I want to increase that frequency. |
|
|
|
My system is pretty new iCore7 (8 cores) and it has 16Gbs of RAM, sata3 drive, etc, and i have the same problem, take ages (4 to 6 hours) each time to start working online.
That is clearly unreasonable with that kind of RAM available. I have 8GB and an SSD, it takes 3 minutes. I would expect 4-5 with sata3 at most. There's clearly something that is going wrong on some systems. Even my OSX, Win7 and Ubuntu VMs, which are on old-school platter HDDs and 4GB of RAM take 4-6 minutes. I don't mean to discount the necessity of the upcoming upgrades to avoid the scanning entirely ... that's in the works, regardless. But there is something wrong if it takes that long. Can you try the new version and tell me if really takes that long consistently through the scanning (because there's no a progress bar), or if it goes through scanning and then hangs for that long? Also, if you want to keep using Armory and you can't resolve this, you might consider deleting the Bitcoin-Qt datadir, and letting it redownload... which should take about 4-6 hours! So you wouldn't really be losing any time...  |
|
|
|
|
Whoops! I accidentally changed the makefile, and the Linux installers didn't work on systems with python2.7. I have repackaged them and posted them to the top post.
|
|
|
|
|
Maybe someone with more lower-level tracing experience than me can help out: can we trace the dependencies used by the .app I created? It's supposed to be completely self-contained, but it sounds like there's still some system libraries being accessed, some of which are not compatible with the ones in my VM.
|
|
|
|
A minor buglet:
The time estimate when loading the block chain is completely off. It takes 2-3 min to load, most of the time it estimates the remaining time to 18 min. This is undoubtedly because it only uses the number of block files read to make the estimate, but since I upgraded the Satoshi client from 0.7 to 0.8 I have three huge files, and around 15 small ones after that one.
Worse is full-blockchain-download estimator. Those things are tough to do right! I had to cap it at 8 hours to avoid it saying "187 years" when the download pauses. I have all these ideas to improve it, but I have also spent an unfortunate amount of time dealing with it already. The 0.7 thing will go away over time, especially with forced upgrades to 0.8.1. I won't stress too much about it. Though I suppose it wouldn't be too hard to actually look at the size of those blockfiles... But even that will become irrelevant when I get the persistent blockchain stuff (coming soon!) |
|
|
|
I checked the Mac app on my Mountain Lion 10.8.3 MacBook Pro.
Unfortunately, it is highly unstable. The app crashes almost no matter what I try to do. For example, I have a testing wallet with no encryption. Clicking on Make Paper Backup cause a crash, also if bitcoin-qt is not running.
I tried to build from source, that version works, but it is clearly a different version. The app is 0.87.98, the one I build from source is 0.87.3. Probably I am building from the wrong branch, which branch should I build to test this? I was planning to test if it is the build or the armory version that is unstable by building myself (all previous versions that I have built from source have been rock stable). If it is the app only, I could also modify the makefile to build with debugging enabled, and attach a debugger (although debugging a multhithreaded program is new for me).
In any case I am busy at work, so my progress may be slow.
Ack. Not good! It seems to be random, when it works and when it doesn't (not by OSX version). If you want to do further testing, use the "testing" branch. Only the blockdata access stuff is multi-threaded...everything else runs in a single thread. I don't think it should be too bad. |
|
|
|
Does it follow then, that if I create another, new, armory wallet, alongside the first armory wallet, and transfer the contents of the first wallet into the second, (maybe even delete the empty first wallet) that only the backup of the second wallet is relevant, and the backup of the first wallet is of no security value to anyone?
tia
When you say "transfer the contents", I assume you mean "send the coins" from one wallet to the other...? In that case, yes. If a wallet has no coins left, and you are not expecting anyone else to send any coins to any of the addresses in that wallet, then you can safely discard that wallet. |
|
|
|
Hey,
is it possible to use amory without a GUI? I'm thinking about installing it on my server and using my laptop for signing. But my server has no GUI and i've no intention to install it.
thanks for the info,
spoc
Look in the "extras" directory, there is a script called "cli_sign_txdp.py". You provde it a wallet file, and an unsigned transaction. It will prompt you for verification, then ask you to type your unlock password. It will produce a signed transaction. There is also armoryd.py, but it's in its infancy and not exactly stable. But it will be expanded (and stabilized) at some point, hopefully in the near future! |
|
|
|
Hello, thanks for this public OS X release but I get a segfault $ open /Applications/Armory.app/Contents/MacOS/Armory
/Applications/Armory.app/Contents/MacOS/Armory ; exit;
new-host:~ me$ /Applications/Armory.app/Contents/MacOS/Armory ; exit;
/Applications/Armory.app/Contents/MacOS/Armory: line 5: 61800 Segmentation fault: 11 bin/python armorybuild/ArmoryQt.pyc
logout
[Opération terminée] I'm using Mac OS 10.7.5 with a Macbook Air $ python -V
Python 2.7.3 -- EPD 7.3-2 (64-bit) Can you try running it with " --offline" at the end, to see if it loads without any blockchain stuff? Was there a log file created by Armory in your ~/Library/Application Support/Armory directory? Unfortunately, I hope someone with more OSX experience will be able to investigate these problems. It looks like you're using a French OS, which makes me realize I never tested unicode support on OSX... I guess I should take a shot at that... |
|
|
|
Ok so I'll add Armory and Tor on the next release.
What about bookmarks ?
I'm sure there are many important links I missed
If you tell me what distro it is based on, I'll make an offline bundle for you -- making it absolutely trivial to install it in your live environment. It'll just be a zip file containing all the .deb files needed to run it without an internet connection. Or maybe the build instructions I put there are sufficient for building the live CD (sorry, not all that familiar with how it works). |
|
|
|
Armory: - Printable paper backups
- Only-one-time-ever-needed backups (deterministic wallets)
- Multiple wallet interface
- Offline wallets with watching-only wallets for the online computer.
- GPU-resistant wallet encryption
- Key import & export
- Key sweeping
- Coin control
- Custom Change addresses
- Transaction history export to .csv
- Payment request blocks (to be copied into emails or webpages with URLs)
I'm sure that's not even all of it. There's been a lot of demand for a live CD with Armory on it, because thousands of people rely on the offline wallets feature, but it's not trivial to setup offline in Linux and I'm not good with live distributions (though I distribute an offline bundle for Ubuntu 10.04-32bit for that reason). |
|
|
|
|
Ack, I forgot to mention (and it will be at the top of the release notes):
Windows users must uninstall the previous version before installing this new one. If you've already installed the new version, reinstall/repair it.
|
|
|
|
|
Show Posts
