I have now tested the new testing build on macOS X 10.12.5. The good news is that it runs, and the few features I have tested work as expected. The bad news is that you are going to get a lot of posts from frustrated users who cannot start the app: It looks like if you unzip the application, you cannot run it until you have manually moved the app bundle to another folder !I am 99% sure it is App Translocation, a new security feature in macOS which causes this as a side effect. App Translocation prevents some forms of attacks to some type of apps by copying the entire app into a disk image which is then made read-only. Then the app is executed from within this disk image. Once an app is moved with the Finder (but not with mv) then App Translocation is disabled for the app, since moving it prevents the kind of attacks App Translocation was designed to protect against. So if you do not move Armory, it is executed from within a read-only disk image, in my case from this path: /private/var/folders/cq/5k4g7j_j5q3crgmh_glgp8yr0000gn/T/AppTranslocation/75F2CD25-05E9-4AC8-A15C-98AEE371C58F/d/Armory.app/Contents/MacOS Why would that matter? After all, Armory does not care from where it is executed? Well, the problem is that this disk image is read-only, and the first time Armory starts it makes a softlink inside itself. That fails if the disk image is read-only, and then the Armory startup script cannot execute Python! # OS X has a quirk. For whatever reasons, if you execute Python from a different
# location than the location of what actually gets executed when you run Armory,
# the menu bar calls Armory "Python". However, if you symlink Python and run the
# symlink from the execution directory, the app name from Info.plist is used.
# Also, the link should be here so that the link works wherever this is
# executed, and not just on the build machine.
ln -sf "${FRDIR}/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python" "${DIRNAME}/Python"
# Assume all args are meant for Armory. Assuming otherwise, for shell scripts
# at least, it horribly painful.
exec "${DIRNAME}/Python" "${ARMORYDIR}/ArmoryQt.py" "$@"
Symptoms: - If you download Armory as a zip file, unpack it, and run it by double-clicking Armory.app, it fails to start
- If you drag Armory to /Applications (or anywhere else for that matter), it suddenly works (since this disables App Translocation).
- Or, if you start it on the command line in the original location by typing /path/to/Armory.app/Contents/MacOS/Armory, then it is run without AppTranslocation, and works. Now the softlink has been made, and double-clicking on Armory.app will now work (since although App Translocation is still in place, the softlink was made in the original App)
Info about App Translocation: http://lapcatsoftware.com/articles/app-translocation.htmland more detailed, including a similar case to what we see with Armory: https://www.synack.com/2016/12/16/untranslocating-apps/Recommendation: Since the softlink inside the app is internal, it could be made when the app is build instead of as a workaround when running it. Then App Translocation will not matter. |
|
|
|
Your NeXT question will be - "How can I be sure noone else have created the exact same address"? The answer to that is "You can not"! But the risk of that is less that 1 to 1000000000000000000000000000000000 or something like that. In practise no risk at all.
I think you are missing approximately 150 zeros in that number  ... which is why it will never happen. |
|
|
|
You mean using the same private keys? Yes you are essentially using the same "wallet". Another way to thank about Bitcoin is really you are not holding any "coins". All that you are "holding" is in the blockchain which you control through your private key.
Yes, the same private keys. Thanks for confirming my understanding. So, in this scenario, I could send/receive bitcoins from either Armory installation, in any order, without any problems? Yes, as long as you let both installations sync with the blockchain, they will see the transactions made on the other machine. The only thing you miss is any comment you have made on one machine, they will not appear on the other. And if you spend from one machine, and try to spend from another machine before the first transaction has confirmed, you may accidentally create a double-spend, in which case only one of the transactions will ever be accepted (probably the first). |
|
|
|
git submodule init
dit submodule update
I don't know why this isn't done automatically but it seems to be required on OS X at least. Should have worked that one out myself I really like git, but the submodule stuff is so user-unfriendly that I decided to do something else in one of my own projects (a bit more work for me, but people who clone it have a chance). I also pulled from the testing branch, probably shouldn't have done that, as I get a crash much earlier: ********************************************************************************
Unpacked: /Users/****/development/BitcoinArmory/osxbuild/workspace/downloads/Python-2.7.13.tar.xz
/Users/****/development/BitcoinArmory/osxbuild/workspace/unpackandbuild/.DS_Store
/Users/****/development/BitcoinArmory/osxbuild/workspace/unpackandbuild/Python-2.7.13
*** ERROR: tarfile unpacked more than one object! ***
Modify Python modules setup files.
OpenSSL path = /usr/local/opt/openssl
Traceback (most recent call last):
File "build-app.py", line 834, in <module>
main()
File "build-app.py", line 142, in main
compile_python()
File "build-app.py", line 450, in compile_python
modSetupFile = path.join(bldPath, 'Modules/Setup.dist')
File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/posixpath.py", line 70, in join
elif path == '' or path.endswith('/'):
AttributeError: 'list' object has no attribute 'endswith'
But you probably should not waste time helping me with this. Goatpig has released 0.96.0.2 last week with an OSX build ( thank you !!!), I will try that tonight. |
|
|
|
In this case, the build target is OS X 10.7. Until I get the go-ahead to switch it to 10.8 (I believe goatpig wanted to ensure that older Mac users could get a version of Armory with SegWit support), users will have to swizzle the bits manually. The easiest thing to do is to go into the OS X build script and change the target version from 10.7 to 10.8. That should fix your issue.
I tried it, unfortunately the build still fails the same way. I found this in the build log: ********************************************************************************
2017-Jun-11 09:23pm
Executing: "make DESTDIR="/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py" install -j4 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Executing from: ".."
Making install in cppForSwig
Making install in lmdb
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
Making install in fcgi
make[2]: *** No rule to make target `install'. Stop.
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
Finished executing: "make DESTDIR="/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py" install -j4 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: ".."
******************************************************************************** and this a bit later: ********************************************************************************
2017-Jun-11 09:23pm
Executing: "patch -p0 < /Users/****/development/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Executing from: "/Users/****/development/BitcoinArmory/osxbuild/objc_armory"
patching file ./Makefile
Hunk #1 FAILED at 15.
1 out of 1 hunk FAILED -- saving rejects to file ./Makefile.rej
Finished executing: "patch -p0 < /Users/****/development/BitcoinArmory/osxbuild/qmake_LFLAGS.patch 2>&1 | tee -a /Users/****/development/BitcoinArmory/osxbuild/build-app.log.txt"
Finished executing from: "/Users/****/development/BitcoinArmory/osxbuild/objc_armory"
******************************************************************************** |
|
|
|
Yes, I am following the build nodes - more or less, at least. I have not downgraded Xcode as that would cause other problems for me. As I understand it, downgrading Xcode would be to build an app that also works on older versions of macOS. macOS 10.12.5 Xcode 8.3.3 ~$ clang --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin I have a good deal more installed with Homebrew than what is listed on the installation page. ~$ brew list
autoconf jpeg pcre
automake lame pkg-config
boost libevent povray
dcraw libffi python
ffmpeg libmpc readline
fftw libpng sqlite
freetype libtiff swig
gcc libtool the_silver_searcher
gdbm libxc ufraw
gettext little-cms2 watch
glib mpfr wget
gmp netpbm x264
imagemagick open-mpi xvid
isl openssl xz
jasper openssl@1.1 zlib If the Armory build itself has failed, I would have expected that the build script terminated with an error, but of course things may go wrong in many ways. I will trawl through the log file, and see what I find. If I get time, I might try to build in a clean virtual machine, where I can follow the instructions to the letter without messing up my day job |
|
|
|
|
I cannot find your transaction on the blockchain explorers. Maybe it was never sent.
|
|
|
|
I tried again to build for OS X. The same problem as previously appeared: ArmoryQt.py is not copied into the .app If I copy it in manually, then it fails when it tries to import CppBlockUtils as Cpp There is nothing named CppBlockUtils.* in the .app. To me, it looks like all prerequisites are compiled and installed in the .app, but Armory itself is not. |
|
|
|
what if i forgot pw?
The passwords protect your wallet file so nobody who gets the file can steal your coins. But that also means that if you have forgotten the password, there is no way to access the bitcoins. Which is why Armory asks you to type in the password three times when you generate the wallet, and print big fat warnings against forgetting the password. If you have a paper backup, then you can restore from it without knowing the password. |
|
|
|
|
Could it be one of your own change addresses?
When you spend bitcoins from an address, you have to spend whole inputs. So if you got 0.4 BTC at some time, and send 0.25 to somebody else, you will send the remaining 0.15 back to yourself, but typically to a new address in your own wallet.
|
|
|
|
Hi guys, I am trying to get up and running with Armory and an offline wallet. Im stuck at a couple of questions though:
1 Is the new version of Armory that was just released, 0.96, only available for AMD chipsets running Linux? No intel chipset version for Linux? Whats up with that?
The amd64 in the name is the Linux way of saying x86_64, i.e. a 64-bit Intel or AMD chip. It works fine on Intel. 2 Can I run a windows listening only wallet and a Linux offline wallet easily and without serious issues? Any known issues?
No problem at all. This is a common setup. 3 Would it be possible to run different version of Armory on my listeneing and offline wallets? I have an old 32 bit intel chipset laptop I want to use for the offline and a 64bit wondows for the listening wallet. Does that make sense or is it possible?
If the versions are not too different, then it works. At some point the communication was changed, but I cannot remember at what version. I think it was between 0.92 and 093, but I am not sure. Also, the new 0.96 introduce new kinds of scripts disabled per default, but if you enable them you need a 0.96 signer as well. |
|
|
|
Thank you very much stroto and gangtreat for your time to help me. Indeed last solution worked very well and was so easy that even me could do that easily. Keep it going guys Just because we are not young anymore does not mean we cannot force a computer to do our will. |
|
|
|
|
Armory is quite a mouthful to get running, it is an advanced wallet but that unfortunately also means that it is technically complex.
If you transferred all your funds to a single (or a few) bitcoin addresses i Armory, then the simplest is probably to export the private keys corresponding to those addresses. Go to Wallet Properties / Backup This Wallet, and select export keys. Then you can import (or better, sweep) the keys in another wallet, either MultiBit HD, Electrum, or anything else.
|
|
|
|
|
The "unconfirmed" problem is because the Bitcoin network is running at maximum capacity. If the fee you paid is low, it will take a while to confirm. I think you can check your fee directly in the Electrum client, otherwise find it on tradeblock.com or blockchain.info. If the fee is around 150 satoshi/byte, it will eventually confirm.
In the absolutely worst case your transactions will be lost from the memory pool within a few days to perhaps a week. Then Electrum will see that the money in reality never left the original private keys, and you can try to sweep again with a higher fee. You may also be able to trigger an earlier confirmation through "child pays for parent" by making a transaction that moves the unconfirmed bitcoins to a new address in your wallet, this time with a high fee. If you need help with that you probably need to ask in an Electrum forum.
|
|
|
|
|
I am running 0.96 with Core 14.1. I have not seen any problems, but then I have only made two transactions since I upgraded to these versions.
macOS Sierra 10.12.5
Edit: NOT 0.96 of course. The latest prerelease, 0.95.99.3-beta
|
|
|
|
|
Don't panic, your bitcoins have probably not been stolen! In that case you would see the transaction stealing the coins in the wallet (it would get it from the blockchain).
By far the most likely explanation is that Armory or the underlying Bitcoin Core software has not fully synchronized with the Bitcoin network. That entails downloading around 100GB of bitcoin transactions, and verifying all of them. With a fast internet it takes a week or so. When Armory is running, it displays the number of blocks it sees in the lower right corner. Right now it should say 466882. If the number is lower, or it says "Offline" then your wallet is not synchronized.
|
|
|
|
Use the testing branch. Building on macs right now may not work though, but you can try.
Same problem as with the master branch: It builds just fine, but cannot run. Starting it on the command line gives this error: 22:28 workspace$ Armory.app/Contents/MacOS/Armory
/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/Python: can't open file '/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py': [Errno 2] No such file or directory
Manually copying ArmoryQt.py into that location gives a new error: 22:29 workspace$ Armory.app/Contents/MacOS/Armory
Traceback (most recent call last):
File "/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/MacOS/py/usr/local/lib/armory/ArmoryQt.py", line 37, in <module>
from PyQt4.QtGui import *
ImportError: dlopen(/Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/QtGui.so, 2): Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
Referenced from: /Users/****/development/BitcoinArmory/osxbuild/workspace/Armory.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui
Reason: Incompatible library version: QtGui requires version 46.0.0 or later, but libpng16.16.dylib provides version 45.0.0
As you can see, I have libpng installed through homebrew. That is pretty common, though, so Armory should pick up its own version anyway. Uninstalling libpng does not change the error, although /usr/local/opt/libpng is then gone. |
|
|
|
|
Adding to the list above:
If you use an offline instance of Armory then it is easy to accidentally generate a double-spend. Just make two transactions, then sign them both at the same time. Only if you make a transaction, sign it and broadcast it before making the next can Armory avoid making a double spend. This is because the online version of Armory cannot know if you are ever going to sign an unsigned transaction it made, or if you abandon it. So it cannot block those coins from being spent again.
Of course, once you have created two transacations that double-spend the same amount, Armory and/or Bitcoin Core should normally prevent you from transmitting both of them. But many things can go wrong that causes them to lose track of the first unconfirmed transaction, and allow the second to be transmitted.
|
|
|
|
As I got it the amount to send was not automaticaly fit to the new fee choosen.
I am pretty sure that if you change the fee, you have to press the Max button again to recalculate the amount you are sending. The Max button does not set a flag stating you want to send everything, instead it calculates what "everything" is, and fills the amount for you. But if you do something to change that calculation, you have to redo it (i.e. click Max again). |
|
|
|
|
Does it make sense to attempt a build on my Macbook?
If so, which git branch should I use?
|
|
|
|
|
Show Posts
