|
Also, if you haven't upgraded to Bitcoin-Qt 0.8, then you should do so. The older versions sometimes took like 24 hours to sync the blockchain. Version 0.8 takes only 5-6 hours (at least on Linux). I'm going to work on getting by VM back up so I can test this!
By the way, does it have the Armory icon in the task tray (or whatever it's called)? Do you know if there's a way to do that?
Also, does anyone have experience with digitally signing .app's? You said .dmgs are shinier... well I don't mind a little shiny, if it doesn't come with drawbacks (beside a little more up front cost of setting it up). I'm still mostly going mostly by your guys' judgment on what's appropriate...
Sorry picobit... I appreciate you trying, but it looks like higuys just left all the competitors in the dust!
|
|
|
|
Alright guys, the script is done. I've tested it a few times and the .app it produces appears to work fine. None of the problems people have had before are present (afaik). I still can't test making transfers or anything like that, but I don't think the wrapper would affect it. How long is syncing the blockchain supposed to take for the first time? Once again, download the buildarmory.sh file from https://gist.github.com/bsmt/5130568 and run it. You'll have to input your password a few times (unless you run it as root) and say "yes" to one license agreement. The dependencies it needs to run are xcode, brew, and pip. Aside from that, it will install cryptopp, swig, qt, pyqt and wget on your machine. It takes a while to build because it does everything from scratch and pyqt takes a looooooong time to make. There are some optimizations that could be made, but I'm going to hold off until I get feedback from etotheipi and everyone else. It might be a good idea to integrate this into the Armory makefile, too, provided this is what etotheipi wants. Fantastic. The only problem is that I upgraded my OS recently and borked my OSX virtual machine. I'm going to have to find another way to test this myself. But as far as I can tell this is what I was looking for. I assume I can setup this environment once, and hold the git repo inside it. Then I can just pull the updates from my development machine and rebuild it and re-run the script to package it up...? There's already a Darwin branch in the makefile... I can just expand it as necessary. By the way, how big is the final .app file? Compressed and uncompressed? Is it normal to distribute apps as zip files? If so, I guess the uncompressed size doesn't matter... |
|
|
|
Just received another PM from "higuys" who is still stuck in the newbies forum. He just sent me this gist: https://gist.github.com/bsmt/5130568"It still needs a few minor changes, and it hasn't been tested, but it should give everyone an idea on how to do this." |
|
|
|
My apologies. I misread that thread the first time, and assumed that my planned fix would... fix it. It's strange to me that Fedora would install those packages, and not put a symlink in a standard location to find them. You really shouldn't be linking directly to "package.so.X.Y", it should be linking to "package.so" which is a symlink to the latest one, which in your case happens to be .X.Y. Perhaps the details don't matter to you -- the point being that I don't think that's a long-term solution, exactly. I'll still post it on the webpage, since it obviously works for at least one person (you!), and I'm sure other Fedora users will benefit. But that's likely to break when the system is updated... so I'll have to work on something more robust. |
|
|
|
I'll donate if you'll just put the instructions I offered on the install page under the ubuntu instructions.
Can you link me? |
|
|
|
I really like the bounty idea. Any chance of you doing that for the rest of Armory development? I mean, I'd really like to see a Bitcoin Armory rpm for fedora users. Slap up a bounty and I'll donate to it, eventually there's bound to be enough fedora users that would like to have that. It was a real workaround for me to figure out how to get Bitcoin Armory to work for me on Fedora.
I'll offer a bounty to fix the makefile. Seriously, all I need is the simplest of checks in the make file, and Armory compiles super-cleanly on all these *nix distributions. Once the makefile goes looking for the .so instead of .a, having any versions of the dependencies should be sufficient. But yes, there will probably be more bounties in the future, to help with related things. As long as they are well-contained, easily-verifiable problems, I am for bounties... |
|
|
|
|
Actually, wouldn't it more directly be related to the number of signatures? And if so, isn't the ratio of blockchain bytes to signature bytes fairly constant? In other words, wouldn't it be even more accurate to measure/predict the number of TxIn's? Or probably just total blockchain bytes...
Also, sipa just pointed out that verification is diabled for the initial download up to about blk 216,000. This is because there's a hard-coded checkpoint there, so verification isn't necessary. This would explain why it all slows down pretty dramatically at the very end.
I guess it is just coincidence that it fits the N8 curve pretty cleanly...
|
|
|
|
The download time is linear in the number of transactions ...
Imagine that... |
|
|
|
Why is it not on Github?
I'm not sure what you mean. All the code is on github. But we can't have regular users installing Xcode, Python, Qt4, etc, and compiling from source. Unfortunately, to make a standalone installer, all that needs to be included somehow. Actually, I just got a PM from someone who claims to have done something like this already! He's stuck in the Newbies forum, but will post here soon. He said was able to jam everything into a .app and it works. But it's 232 MB. I suspect that most of it can be pruned out. For reference, the Windows installer (*.msi) has everything and is less than 20 MB. Question: is *.app what I want? Is that a sign-able container? Is it easily converted to a .dmg? Or pkg? What do I want? (I don't even know, myself) EDIT: upon reviewing what he said, I suspect that 180 MB is instantly removable: the entire cppForSwig directory and the .git directory. If so, this may already be in a usable state. Anyone have comments about the idea of bulk including a python installation, PyQt4, etc? It would require me updating them when necessary, but on the other hand, it reduces the number of libraries that are system-dependent (and thus, probably also increases security a bit). |
|
|
|
Okay, well I just did an experiment with Bitcoin-Qt 0.8, and what I found is kind of scary... Plotting percentage-of-blocks-downloaded vs percentage-of-total-download-time yielded a rather extreme relationship:  It can be linearized by plotting (% of blocks) 8 vs (% of total time). The linearity of the result is surprisingly... good.  This is scary because I would like to think that no part of Bitcoin has an order of growth of O(N 8). Of course, that was probably the trajectory of the relationship before we hit the [artificial] block-size limits. The moral of this story is that if you predict the current top block you are synchronizing to (say from asking peers, or just projecting out at 10min/blk from your last estimate), then you can create a fairly accurate "Percent Complete: ..." meter by simply computing (currentBlock/maxBlock) 8. This seems to be accurate for at least the first 225k blocks... |
|
|
|
If you publish this donation address somewhere on your web site we could use the blockchain.info tag feature to mark it.
I just added it to the webpage under the OSX section: http://bitcoinarmory.com/get-armory/ |
|
|
|
|
Haha, whoops. I should've created a new wallet for this. All the donations are showing up in my donation wallet along with my other donations. They are, of course, intended for the bounty, but I just want to mention that I may accidentally "spend it". I will try to remember to use coin control to avoid doing so, but if I forget, the coins may end up moving...
For that reason, I will be going by total BTC received by that address, not how much is still in it when the bounty is to be paid. Just wanted to clarify that.
|
|
|
|
It is strange that you didn't see the confirmations. Do you use a non-standard Bitcoin-Qt installation? Unfortunately, the scanning is part of the startup, which used to only take a couple minutes. Armory will be switching over to a much quicker/better model, but it's no trivial amount of work. But it's my top priority. Maybe you will try it again after it's done and easier to use  Don't worry, not everyone can have a good experience with Armory. Thanks for trying! I'm glad you were able to get your coins out. |
|
|
|
0.87.3 shouldn't behave any different in this regard, compared to 0.87. So wait, you did restore it? Your wording was awkward... If you restored from paper backup and it still has unlocking problems... I'll have to think about that one... You could also try going to Help-->Revert All Settings. I doubt that would do it, but who knows. Also, make sure the wallet is removed from your .armory directory before you restore from paper backup. So I put a tail on the log and the only issue that it took like 2 hours after importing the paper wallet to read the blockchain and I just sent 1 btc to your bounty for the Mac OSX with no issues, guess the wallet was corrupted. Ugh! Have you used a lot of addresses in that wallet? I forgot that I recently added an "extended" search for restored wallets, to guarantee that it searches out far enough in your address list. If you have used a lot of addresses, I could see it doing quite a few scans.... Glad it works now, though... |
|
|
|
|
Wow, excellent! Already at about $1,000 USD. Given the nature of this task, and the amount collected so far, I bet this will be a very effective bounty campaign!
|
|
|
|
0.87.3 shouldn't behave any different in this regard, compared to 0.87. So wait, you did restore it? Your wording was awkward... If you restored from paper backup and it still has unlocking problems... I'll have to think about that one... You could also try going to Help-->Revert All Settings. I doubt that would do it, but who knows. Also, make sure the wallet is removed from your .armory directory before you restore from paper backup. |
|
|
|
So when I am sending coins from any one of my wallets, Sometimes I have to keep hitting the unlock password button until it will actually send the coins. Then I looked in the error log and saw this 2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (INFO) -- qtdialogs.py:5379 - Change address behavior: Feedback
2013-03-09 18:29 (INFO) -- qtdialogs.py:5379 - Change address behavior: Feedback
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
My version 2013-03-09 18:15 (INFO) -- armoryengine.py:571 - Armory Version : 0.87
2013-03-09 18:15 (INFO) -- armoryengine.py:572 - PyBtcWallet Version : 1.35
2013-03-09 18:15 (INFO) -- armoryengine.py:573 - Detected Operating system: Mac/OSX
Ack! That looks like a corrupted wallet! The only time I remember seeing that is when I was messing with a wallet file and destroyed some data. Unfortunately, the error doesn't lead to a very agreeable way for me to investigate further (unless you want to send me your private keys and wallet file so I can check on it...). Perhaps it got corrupted somehow on the way to being encrypted. I have the app restore from the parallel backup when it detects an error in the wallet file, but that error cannot be detected until you try to unlock your wallet, which happens after the check Do you have a paper or digital backup? Can you try backing up the wallet manually (from your home directory), then remove it from Armory and restore from backup? Then try again signing again. Was there anything special about this wallet? Was it originally restored from a paper backup? From the new fragmented backup? Do you know what version created it, or when you created it approximately? It was created in 0.85 and I can send funds from the wallet, but I have keep click unlock until it takes sends the transaction, I do have a paper back, it all works fine. Should I do a digital back up, and try and restore from that? Should I create a new Wallet? Wait... so it's not deterministic whether it accepts the passphrase? How many attempts does it take? I'm not sure why it would work ever, if it doesn't work the first time. Perhaps only some of the keys are corrupted and it needs to be clicked once for each of them. I recommend upgrading to the latest version (probably 0.87.3) and then restore from paper backup. You can restore it directly to an encrypted file in the latest version. After it rescans with the restored backup, try sending again. |
|
|
|
|
First order of business: I strongly believe that Red Emerald should receive 5-10% of this bounty regardless of any further contributions by him. Without his help, there might not have been any OSX support for Armory, at all. And I'm sure his brew installation will be extremelyt useful in figuring out what dependencies are needed, etc.
Discuss! (and donate!)
|
|
|
|
Total Bounty Accumulated: 24.75 BTC (last updated, Mar 10, 1:10am EST) ( Donation address on blockchain.info) User "higuys" has claimed the bounty! More information here. You can get the first unofficial release of the OSX build from this thread!
Original Message:The number of users offering bounties for a native OSX package for Armory has reached critical mass. Red Emerald has done a phenomenal job making it available through some brew commands at the terminal, but it's not a long-term solution. Eventually, Armory needs to be accessible to the audience of users that have never seen a terminal. So, I'm announcing a official bounty for anyone who gives me a solid "recipe" for distributing Armory on OSX:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The following address is owned by Alan Reiner (Core Armory
Developer) and will be used to collect donations to be given
as a bounty for the successful packaging of Armory for OSX.
All donations will be maintained by Alan Reiner, and
distributed at his sole discretion.
1Armory1HBqc8dNEvHDuT9AYWPWf98aCzJ
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJRO9osAAoJEEqxauqYgyIjzWAP/AubsJ/zQb3/jFbLV5CcK8tR
wF+8JzjVQyOWFH2nPQL3LNQ2pgyUgghBHGzm1FVslHeJ3Ahf+4D3o+W73ntqXKKx
SLjyy6ZQVJLgCazWVlKcKEoE+lwNJs1oj3Zl3BdO3jwpxy6J3LqtufZkPhdawXD2
ul5ECfGFQDcONVLA4RbzgNmrgEbGNvCJdlVeQ/gZ5uMAv5vsbGaIywK55t/lEzrl
2eg3YPjRf0txYQ0/hyqfmc8ZkS0i2OnWR9c+HiKOOdGD6GaZdSUa29EDlMdQnc8T
tcGZI32ym/yxk641UkgjAmC2CbGpSmtbSJWSwrMSCGfWzV57khDYoNZJBS0wfUUP
g/FWPfyAbl2WJ394fYuTHwO2Hknd+d65lW59VlqZU2R/WWWqb+SKOW49OM8PkVFw
YKnI3xJuZFMw6AC7xxZhVB2oF0Pja5xlRjLJKQfJ0Gdk32pU/zfN72CqWjncnxvq
2+jhiP6Tv5PKWa0dB8u56occM2MDWXs0cuXnSHOz3dLCWxXTgFk5/lulsV8Bw8Y3
OO9eVIYQQz9nD4UKXQeUiJaxOl/i1Wq2LBECOWFnExC9FsVbupKPc7NLVtF+OFyS
U8F8hWLISYW+bYaafJxb5XFiYqMdAdLqsiR6Y7XTykVLKuRjH0ImmrPhfgn1OKLD
hvLhfu9rLsxBQuQqu8ww
=IGsm
-----END PGP SIGNATURE-----
I will hold onto the funds and decide how to distribute it. I will not distribute any to myself, unless there is some reasonable consensus that I should do so (like, I ended up figuring it out myself because no one else did). Otherwise, I will look to this thread for feedback, and then will make the decision how to proceed. Partial credit is possible. Red Emerald has mentioned that bundling Armory is not easy. py2app didn't work smoothly at all. There's a few awkward dependencies, including bundling PyQt4 in its entirety. Luckily, I know that the Bitcoin-Qt dev team has successfully bundled Qt4 into their package, so their packaging scheme might serve as a good starting point for this task. @Red Emerald: Of course, I was looking in your direction to be the exalted warrior of this bounty, but there is no obligation. I don't currently have a developer key for OSX, but I plan to get one eventually so that I can properly sign the OSX packages. I prefer a solution that extends easily to being natively signed, but I guess I'd still be happy with any kind of standalone packaging. It's worth discussing in this thread what can be done to guarantee the solution allows for that (or acknowledge that any correct solution is signable).
Some of you may have seen my previous rant about how I don't like bounties of this form, and much prefer to raise money to pay someone to work on it up front. Part of the justification for that rant is that most projects for which bounties are declared, may require months of work, and do not have a clear definition of success -- especially when inter-project priorities change, feasibility issues justify changing directions, and there is vast disagreement about what is "complete", etc. In this case, I think the task is relative short, and the exit criteria is pretty clear, so there shouldn't be any controversy about it. I'd also like to see this thread used for collaboration. If there is significant progress made through the collaboration with others in this thread, then I will probably decide to split the bounty. Any splits will be in increments of 10% only. I will not be giving 0.36% to one, 1.83% to another, etc. If people feel like they deserve a small piece for their contribution, they can ask the person who received the bounty to toss them a few bits! Otherwise, your reward for contributing is that you helped make the OSX distributable package possible!
|
|
|
|
|
Show Posts
