I had just finished fixing that crypto++ problem too.  Ah well a little thinking never hurt anyone. Anyways I was wondering if you could shed some light on this problem I'm having importing my wallets. Every time i try I just get this error: Thanks in advance! Ahh yes, I introduced a silly bug in 0.60 when adding the wallet-migration and it's a super-easy fix. In fact, I just changed two lines and pushed it to the repo. Do a pull and try again. Hope that helps! |
|
|
|
|
New cryptoppstatic branch for Linux & OSX!
This is for Linux & OSX: Please do a fresh checkout of Armory and do a "git checkout cryptoppstatic" to switch to the new branch. Just pull in the new changes and try it again (git pull). You should be able to follow the instructions exactly the same as before, but there will be no dependence on libcryptopp.so/.dylib. This should clear up some OSX issues, and in Linux you should no longer need the "LD_PRELOAD" command.
It will take longer to build the first time, because crypto++ will be compiled (it wasn't, before). Then when Armory is built, it will include libcryptopp.a in the compilation, and never has to look for any cryptopp-related dynamic libraries or shared objects ever again!
So far, this works fine on my linux system: nearly transparent except for the first compile time. The downside is that it increases the final shared object from 2 MB to 11 MB. But that's pennies, and acceptable considering all the problems I'm fixing! If I hear that this solves some problems with OSX, I will merge it into master.
EDIT: I just tested it in Ubuntu 11.10 and it works fine without the LD_PRELOAD command. So far, I'm not finding a downside!
EDIT2: I just merged it into master. So don't even bother switching branches!
|
|
|
|
The only .so or .dylib files that I could find are $ ls -lah /usr/lib | grep crypto
-rwxr-xr-x 1 root group 3.2M Jun 25 2010 libcrypto.0.9.7.dylib
-rwxr-xr-x 1 root gtoup 4.1M Apr 23 2011 libcrypto.0.9.8.dylib
-rwxr-xr-x 1 root group 786K May 29 2009 libcrypto.0.9.dylib
lrwxr-xr-x 1 root group 21B Jun 2 2011 libcrypto.dylib -> libcrypto.0.9.8.dylib Well, that's confusing. Is there a .dylib in the Armory directory? There must be something else going on that I don't understand. To clarify (torus), it works on your system and you can't find a libcryptopp.dylib anywhere? I wonder what it's linking against... Maybe it got compiled somehow? Sounds like I should stop talking about static linking and finally do it. I'll make a new branch and see if I can get the Makefile to work for this purpose. Sooooo many compilation problems will go away. Especially easy since I actually have all the Crypto++ source code in the project because it's needed for Windows, so I might as use it for the other platforms too. It shouldn't be too hard: I'll work on that right now. |
|
|
|
Files with the .a extension means statically linked. I have been thinking about doing that to avoid these problems in the future, but haven't done it yet. Until then, the project is setup to use the -l options, which requires a .so or .dylib.
You can do a 'find . | grep crypto' from any directory to search the entire subdir tree for a file with that name.
Well that would be a problem. I ran the find command from my homebrew folder. $ find . | grep crypto
./Cellar/cryptopp
./Cellar/cryptopp/5.6.1
./Cellar/cryptopp/5.6.1/include
./Cellar/cryptopp/5.6.1/include/cryptopp
./Cellar/cryptopp/5.6.1/include/cryptopp/3way.h
./Cellar/cryptopp/5.6.1/include/cryptopp/adler32.h
./Cellar/cryptopp/5.6.1/include/cryptopp/aes.h
./Cellar/cryptopp/5.6.1/include/cryptopp/algebra.h
./Cellar/cryptopp/5.6.1/include/cryptopp/algparam.h
./Cellar/cryptopp/5.6.1/include/cryptopp/arc4.h
./Cellar/cryptopp/5.6.1/include/cryptopp/argnames.h
./Cellar/cryptopp/5.6.1/include/cryptopp/asn.h
./Cellar/cryptopp/5.6.1/include/cryptopp/authenc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/base32.h
./Cellar/cryptopp/5.6.1/include/cryptopp/base64.h
./Cellar/cryptopp/5.6.1/include/cryptopp/basecode.h
./Cellar/cryptopp/5.6.1/include/cryptopp/bench.h
./Cellar/cryptopp/5.6.1/include/cryptopp/blowfish.h
./Cellar/cryptopp/5.6.1/include/cryptopp/blumshub.h
./Cellar/cryptopp/5.6.1/include/cryptopp/camellia.h
./Cellar/cryptopp/5.6.1/include/cryptopp/cast.h
./Cellar/cryptopp/5.6.1/include/cryptopp/cbcmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ccm.h
./Cellar/cryptopp/5.6.1/include/cryptopp/channels.h
./Cellar/cryptopp/5.6.1/include/cryptopp/cmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/config.h
./Cellar/cryptopp/5.6.1/include/cryptopp/cpu.h
./Cellar/cryptopp/5.6.1/include/cryptopp/crc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/cryptlib.h
./Cellar/cryptopp/5.6.1/include/cryptopp/default.h
./Cellar/cryptopp/5.6.1/include/cryptopp/des.h
./Cellar/cryptopp/5.6.1/include/cryptopp/dh.h
./Cellar/cryptopp/5.6.1/include/cryptopp/dh2.h
./Cellar/cryptopp/5.6.1/include/cryptopp/dll.h
./Cellar/cryptopp/5.6.1/include/cryptopp/dmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/dsa.h
./Cellar/cryptopp/5.6.1/include/cryptopp/eax.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ec2n.h
./Cellar/cryptopp/5.6.1/include/cryptopp/eccrypto.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ecp.h
./Cellar/cryptopp/5.6.1/include/cryptopp/elgamal.h
./Cellar/cryptopp/5.6.1/include/cryptopp/emsa2.h
./Cellar/cryptopp/5.6.1/include/cryptopp/eprecomp.h
./Cellar/cryptopp/5.6.1/include/cryptopp/esign.h
./Cellar/cryptopp/5.6.1/include/cryptopp/factory.h
./Cellar/cryptopp/5.6.1/include/cryptopp/files.h
./Cellar/cryptopp/5.6.1/include/cryptopp/filters.h
./Cellar/cryptopp/5.6.1/include/cryptopp/fips140.h
./Cellar/cryptopp/5.6.1/include/cryptopp/fltrimpl.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gcm.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gf256.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gf2_32.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gf2n.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gfpcrypt.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gost.h
./Cellar/cryptopp/5.6.1/include/cryptopp/gzip.h
./Cellar/cryptopp/5.6.1/include/cryptopp/hex.h
./Cellar/cryptopp/5.6.1/include/cryptopp/hmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/hrtimer.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ida.h
./Cellar/cryptopp/5.6.1/include/cryptopp/idea.h
./Cellar/cryptopp/5.6.1/include/cryptopp/integer.h
./Cellar/cryptopp/5.6.1/include/cryptopp/iterhash.h
./Cellar/cryptopp/5.6.1/include/cryptopp/lubyrack.h
./Cellar/cryptopp/5.6.1/include/cryptopp/luc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/mars.h
./Cellar/cryptopp/5.6.1/include/cryptopp/md2.h
./Cellar/cryptopp/5.6.1/include/cryptopp/md4.h
./Cellar/cryptopp/5.6.1/include/cryptopp/md5.h
./Cellar/cryptopp/5.6.1/include/cryptopp/mdc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/misc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/modarith.h
./Cellar/cryptopp/5.6.1/include/cryptopp/modes.h
./Cellar/cryptopp/5.6.1/include/cryptopp/modexppc.h
./Cellar/cryptopp/5.6.1/include/cryptopp/mqueue.h
./Cellar/cryptopp/5.6.1/include/cryptopp/mqv.h
./Cellar/cryptopp/5.6.1/include/cryptopp/nbtheory.h
./Cellar/cryptopp/5.6.1/include/cryptopp/network.h
./Cellar/cryptopp/5.6.1/include/cryptopp/nr.h
./Cellar/cryptopp/5.6.1/include/cryptopp/oaep.h
./Cellar/cryptopp/5.6.1/include/cryptopp/oids.h
./Cellar/cryptopp/5.6.1/include/cryptopp/osrng.h
./Cellar/cryptopp/5.6.1/include/cryptopp/panama.h
./Cellar/cryptopp/5.6.1/include/cryptopp/pch.h
./Cellar/cryptopp/5.6.1/include/cryptopp/pkcspad.h
./Cellar/cryptopp/5.6.1/include/cryptopp/polynomi.h
./Cellar/cryptopp/5.6.1/include/cryptopp/pssr.h
./Cellar/cryptopp/5.6.1/include/cryptopp/pubkey.h
./Cellar/cryptopp/5.6.1/include/cryptopp/pwdbased.h
./Cellar/cryptopp/5.6.1/include/cryptopp/queue.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rabin.h
./Cellar/cryptopp/5.6.1/include/cryptopp/randpool.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rc2.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rc5.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rc6.h
./Cellar/cryptopp/5.6.1/include/cryptopp/resource.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rijndael.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ripemd.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rng.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rsa.h
./Cellar/cryptopp/5.6.1/include/cryptopp/rw.h
./Cellar/cryptopp/5.6.1/include/cryptopp/safer.h
./Cellar/cryptopp/5.6.1/include/cryptopp/salsa.h
./Cellar/cryptopp/5.6.1/include/cryptopp/seal.h
./Cellar/cryptopp/5.6.1/include/cryptopp/secblock.h
./Cellar/cryptopp/5.6.1/include/cryptopp/seckey.h
./Cellar/cryptopp/5.6.1/include/cryptopp/seed.h
./Cellar/cryptopp/5.6.1/include/cryptopp/serpent.h
./Cellar/cryptopp/5.6.1/include/cryptopp/serpentp.h
./Cellar/cryptopp/5.6.1/include/cryptopp/sha.h
./Cellar/cryptopp/5.6.1/include/cryptopp/shacal2.h
./Cellar/cryptopp/5.6.1/include/cryptopp/shark.h
./Cellar/cryptopp/5.6.1/include/cryptopp/simple.h
./Cellar/cryptopp/5.6.1/include/cryptopp/skipjack.h
./Cellar/cryptopp/5.6.1/include/cryptopp/smartptr.h
./Cellar/cryptopp/5.6.1/include/cryptopp/socketft.h
./Cellar/cryptopp/5.6.1/include/cryptopp/sosemanuk.h
./Cellar/cryptopp/5.6.1/include/cryptopp/square.h
./Cellar/cryptopp/5.6.1/include/cryptopp/stdcpp.h
./Cellar/cryptopp/5.6.1/include/cryptopp/strciphr.h
./Cellar/cryptopp/5.6.1/include/cryptopp/tea.h
./Cellar/cryptopp/5.6.1/include/cryptopp/tiger.h
./Cellar/cryptopp/5.6.1/include/cryptopp/trdlocal.h
./Cellar/cryptopp/5.6.1/include/cryptopp/trunhash.h
./Cellar/cryptopp/5.6.1/include/cryptopp/ttmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/twofish.h
./Cellar/cryptopp/5.6.1/include/cryptopp/validate.h
./Cellar/cryptopp/5.6.1/include/cryptopp/vmac.h
./Cellar/cryptopp/5.6.1/include/cryptopp/wait.h
./Cellar/cryptopp/5.6.1/include/cryptopp/wake.h
./Cellar/cryptopp/5.6.1/include/cryptopp/whrlpool.h
./Cellar/cryptopp/5.6.1/include/cryptopp/winpipes.h
./Cellar/cryptopp/5.6.1/include/cryptopp/words.h
./Cellar/cryptopp/5.6.1/include/cryptopp/xtr.h
./Cellar/cryptopp/5.6.1/include/cryptopp/xtrcrypt.h
./Cellar/cryptopp/5.6.1/include/cryptopp/zdeflate.h
./Cellar/cryptopp/5.6.1/include/cryptopp/zinflate.h
./Cellar/cryptopp/5.6.1/include/cryptopp/zlib.h
./Cellar/cryptopp/5.6.1/INSTALL_RECEIPT.json
./Cellar/cryptopp/5.6.1/lib
./Cellar/cryptopp/5.6.1/lib/libcryptopp.a
./Cellar/cryptopp/5.6.1/LICENSE
./Cellar/cryptopp/5.6.1/README
./Cellar/openssl/0.9.8r/include/openssl/crypto.h
./Cellar/openssl/0.9.8r/lib/libcrypto.0.9.8.dylib
./Cellar/openssl/0.9.8r/lib/libcrypto.a
./Cellar/openssl/0.9.8r/lib/libcrypto.dylib
./Cellar/openssl/0.9.8r/lib/pkgconfig/libcrypto.pc
./Cellar/openssl/0.9.8r/share/man/man3/crypto.3
./Cellar/openssl/0.9.8r/share/man/man3/ERR_load_crypto_strings.3
./Cellar/openssl/0.9.8s/include/openssl/crypto.h
./Cellar/openssl/0.9.8s/lib/libcrypto.0.9.8.dylib
./Cellar/openssl/0.9.8s/lib/libcrypto.a
./Cellar/openssl/0.9.8s/lib/libcrypto.dylib
./Cellar/openssl/0.9.8s/lib/pkgconfig/libcrypto.pc
./Cellar/openssl/0.9.8s/share/man/man3/crypto.3ssl
./Cellar/openssl/0.9.8s/share/man/man3/ERR_load_crypto_strings.3ssl
./Cellar/pyqt/4.9.1/share/sip/QtCore/qcryptographichash.sip
./Cellar/qt/4.8.0/lib/QtCore.framework/Versions/4/Headers/qcryptographichash.h
./include/cryptopp
./lib/libcryptopp.a
./Library/Aliases/libcryptopp
./Library/Formula/cryptopp.rb
./Library/LinkedKegs/cryptopp Should I try linking to the ones installed with openssl? pkgconfig and libcrypto.dylib are there. Btw, you should use "code" blocks for those chunks of info, so it doesn't consume the whole screen. (I applied it in your quote above) It looks like cryptopp is getting copied to the system, they even provided you a library for static linking, but I don't see where it would be dynamically linked. libcrypto.dylib and OpenSSL are different libraries. In fact, I started with Crypto++ for reasons I can't explain, and now I keep wondering if I should switch to OpenSSL or something that will have less linking problems. I think I just need to modify the makefile to statically link crypto++ and this problem will go away entirely (90% of compile/linking issues on non-OSX is related to it) |
|
|
|
Congratulations to etotheipi! Too shame for missing the donation period...  For now, if folks still want to donate to my 1ArmoryXcf address, I will offer the same rewards. I have extras of each reward, so it's not a problem to continue providing them. I can even continue updating this thread, but I already did all the part-time stuff at work, so it won't change that. Many here donate just because they know it will help me continue to do this work, so don't let me stop you from that I guess the big difference is that I can no longer take credit-card donations... but this is the Bitcoin forums, after all! Feel free to donate: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv, then email me and I will send the appropriate rewards when I get them in. On the topic of rewards: I am still waiting for shirts... it might be another week (hopefully not two). Sorry! I'll get them out ASAP! |
|
|
|
Could this be the file we are looking for: $ ls -lah /usr/local/lib | grep crypto
lrwxr-xr-x 1 user group 42B Feb 5 20:00 libcryptopp.a -> ../Cellar/cryptopp/5.6.1/lib/libcryptopp.a Do you have in your path? Files with the .a extension means statically linked. I have been thinking about doing that to avoid these problems in the future, but haven't done it yet. Until then, the project is setup to use the -l options, which requires a .so or .dylib. You can do a 'find . | grep crypto' from any directory to search the entire subdir tree for a file with that name. |
|
|
|
I have not upgraded to Lion yet so I can't reproduce.
...
Why does your installation only compile EncryptionUtils.cpp?
Regarding bsddb3, what error do you get? Did you pull the latest commit?
It looks to me like Red Emerald had already tried a few compilation steps, so all the .cpp's had already been compiled. For whatever reason, only EncryptionUtils needed to be recompiled on this step (did you change something in that .cpp file?). The real issue you are running into here is that linking is failing when trying to find libcryptopp.so (or whatever extension it is in OSX). My guess is that you need a "-L" option in the make file to tell it where to find this non-standard library. If it was brewed/installed already, it probably exists somewhere like /usr/local/brew/cryptopp/libcryptopp.dylib, in which case you can modify the makefile to say: -L/usr/local/brew/cryptopp -lcryptopp That says that it needs to link with "cryptopp" (i.e. it should look for libcryptopp.dylib somewhere), and then the -L tells it where it might find it. Figure out where it is, then plug in the correct path. If it is a "default" location for cryptopp when using homebrew, then let me know where that is, I might be able to modify the makefile to accommodate... Btw, a long time ago, Swift Geek helped me setup a cmake system for Armory. It was still around version 0.51, and I don't know if it worked. It didn't solve the problem I had been working on that day, so I simply switched back to master and kept developing. Who knows, maybe it will improve the OSX compiling. If someone has some patience to try it with that branch, and it happens to resolve a lot of problems, I can look into merging it into master. |
|
|
|
At least one of the device need to be connected to the Bitcoin P2P network obviously.
There is two devices:
- connected device (to Bitcoin P2P network)
- signing device (interfaces limited to QR or NFC)
You need a fully updated blockchain on the connected device. You create a tx with that device, send the tx to the signing device using QR or NFC, sign, and send back to the connected device. The connected device distributes the tx into the P2P network.
Actually, this usecase is not yet fully implemented by Bitcoin Wallet. But part of it is already there, maybe someone wants to continue on that side project?
What you described is exactly what Armory does with a second computer. And having an old, spare laptop is probably more likely for many people than having a spare smartphone that's not connected to any network. That's not to say that it is unnecessary to have such a smartphone client, but I'm telling you that that precise functionality exists in an available program already, using a second computer. I'm working with a friend on two-factor authentication, to be used with Armory (or any other BIP-0010-supporting program). There's no reason I can't combine the two ideas to use a smart-phone as the offline signing device. It will just require transferring the signatures back from the phone to computer. |
|
|
|
If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year! All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz. Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership." Again, the only person that can provide such a message, must be the same person that originally funded the account! That isn't failproof, people use Gox or any wallet to receive payments from others. I guess that's why you mention the dwolla number, but some people won't have a dwolla number and in some cases an attacker could have been paying a person dwolla and then switched to paying them coin straight into Gox. Also a webwallet or service provider would have a lot of "other people's" keys. Gah, I keep forgetting that "web wallets" exist. I've never used one because I never understood why I'd have another service hold my money when the regular Bitcoin client seemed simple enough to use...? So, the concept still works but only if the agreement starts out that way. It could be a prerequisite that, in order to use a certain online gambling site, that you must fund the account yourself and be able to sign messages with that original address. Or, there's an option when you start an account "I will create a login & password / I will use the first funding address as my identity." |
|
|
|
FYI: I have added a message signing and verification interface into Armory, as part of the the ECDSA calculator. The interface is a little weird, because it was merged with a privatekey/publickey/address calculator, but it is very functional. Why is this useful?It's not so much for "verifying ownership of a wallet," but it is a good way to send messages that the receiver can verify came from the owner of an address. Here's a couple excellent uses for it: - You purchase something online for 1,000 BTC and the seller needs a shipping address. Send them a signature block with your shipping address via email, signed with one of the addresses you used to pay them. They know it must've come from the same person who paid them, which is the only important part. No one can spoof an email from you to have them ship it somewhere else.
- If this functionality had existed at the time, it would've been a brilliant way for MtGox to verify users' accounts after the hacking last year! All they had to do was send out emails saying "Account #0582921 was originally funded with address 1Ahgk48sfQz. Please provide your name, address, and Dwolla acct number in a signed message by Bitcoin address 1Ahgk48sfQz to claim ownership." Again, the only person that can provide such a message, must be the same person that originally funded the account!
- Expanding on the Mt.Gox idea: services can start using this for anonymous account management, especially online gambling. A user funds an online gambling account completely anonymously using Bitcoins. Then, they decide they want move money around, buy stuff, play big games, or cash out to a different address. The only requirement for doing so is that they make the request using a signature block signed with the very first address that ever funded the account. They never have to identify their own name, address, make any kind of account login&password, password recovery, not even email address! All that matters is that the same person who funded the account, is the person making the current request!
  To Sign a Message with Armory (works fine in offline mode): - Open Armory, go to the menu, "Tools"-->"Message Signing"
- Put your address into the "Bitcoin Address" box. If this key is yours, a message will pop up saying "This key is in one of your wallets!".
- Type in your message into the message box. You can use the buttons to insert random hex characters, or the current datetime. The only restriction is to not use any newlines in the message.
- Click "Get keys from Wallet" at the top of the window to pull in your private key for signing. (I will remove this step in the next version, it's unnecessary)
- Click the "Sign Message" button which will dump a raw signature in the box to the right.
- Click the "Create Signature Block" button which will copy the signature block to the clipboard.
- You can test it by clicking "Import Signature Block" and pasting the clipboard into it. You will see what the verification window looks like.
- Send the signature block in an email or pastebin.
To Verify a Signature Block with Armory (works fine in offline mode): - Open Armory, go to the menu, "Tools"-->"Message Signing"
- Click on "Import Signature Block" at the bottom of the screen.
- Paste the signature block, and click "Okay"
- Address will be checked against public key, public key checked against signature for the given message
None of this requires the blockchain, so if you are on a system that couldn't normally run Armory, you only need to run with the "--noblockchain" option. This allows you to verify Armory signature blocks without even having an Armory wallet! If you're intrigued, try this one: ( get Armory if necessary) -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "Armory version 0.60-alpha was released 2012-Mar-"
"19 07:40pm. Windows binaries have been released "
"in zip files with the following MD5 hashes: [Wi"
"n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
"930159411483428da40c127f654bf69] Please do not u"
"se any zip files whose hash values do not match!"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
fcab55433f1d28f569b3771216754f400a5674e24984943d62
9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK--------------------------------------- Btw, these signatures are not compatible with the Satoshi client signatures. I will make an effort to synchronize them later after RAM-reduction. P.S. - This works with offline wallets, too, since it doesn't require the blockchain. Just get on your offline computer, create the signature block as above, and copy it to a USB key to take to the online computer. It's even easier than an offline transaction because you can start on the offline computer and only need to move data one direction.
|
|
|
|
What about changing how the database is stored on disk? It seems to me that using the Berkeley DB library might be causing the problem, but I don't know enough on how that works to be sure. Maybe using some other database library (like SQLite) would have less disk IO.
The blockchain is actually stored in a flat binary file. It's just one raw block after another, serialized into blk0001.dat. It's the wallet file that is stored using Berkeley DB. |
|
|
|
TorusJKL just submitted a pull request, for a small change to the wallet-migration code that will allow it work on OSX. I'll update and push that change, now. In his pull request, I see that he created a paste: Building Bitcoin Armory on Mac OS X 10.6.x using Homebrew. It looks more complete than the instructions I have had posted, so it might be worth trying ( Splatster!). Please, someone look at that and tell me if it works! |
|
|
|
And while a mac mini may be more pricey than some other PCs. Try to find a computer that size with an internal power supply, a core i5, thunderbolt, wireless N, the best customer support, etc. It's not as expensive as it looks when you look at what you are actually buying.
Red Emerald, I totally appreciate the "value" of a Mac, and what you pay for. But value is relative to the person getting it. I have absolutely no use for the Mac except to compile binaries on it then go back to my hex-core, 16 GB RAM, dual 1920x1200 monitor desktop to continue developing stuff. I don't really care how amazing it is, because I know I can execute my one mission (compiling binaries) on a used system. Maybe one day I'll be bored and decide to spend more time digging into it... but it's not that time yet. I will explore the VM options, first, then consider a physical system. It sounds like others have experience with the VM approach, so many they could email me and help me out  After all, there's a reason I have 16 GB of RAM in the first place: to run lots of VMs. I don't know what you mean by "borrow" a system, if I go with a physical one, I don't want to have to return it. |
|
|
|
Well this is kinda OT, but if you buy a mac, I HIGHLY recommend you buy it from apple. Apple has the best customer service for computers by far and if you buy from craigslist or some 3rd party, you don't get that.
Mac minis start at $599. All you'll need after that is a monitor that supports HDMI or DVI.
That's pretty heavy for a computer I'm not ever going to really use. I basically anticipate only compiling binaries on it... and if I have to do multiple versions (like 32-bit and 64-bit), I might need a second one. I really want the cheapest I can get, I'm not too concerned about warranty service. Even if one dies and i have to get another, it was still cheaper to get each for $200 each than pay $600 for one. Rather than buy a Mac just for compiling sake, could you not just set up a couple of virtual machines running OSX (or whatever it's called nowadays) on your Windows box? I know it's possible as I did it myself a while ago, although I'm not sure if that messes anything up with regards to compiling to be honest. I've tried to set up an OSX VM no less than 3 times, but it's never worked. I just don't have the touch (they're very finnicky, because of strict hardware specs). Though if it does work, there's no reason the compiled binaries wouldn't work. That's how I compile the Windows binaries... Maybe I should just convince my girlfriend her laptop is crappy and she would looove a new mac mini! "It's so cute! And you totally make enough money to afford it...." If anyone can help me out with this, please email me. Either used hardware you could send me, help setting up a VM, or other ideas... (etotheipi a t g mail com) |
|
|
|
Well this is kinda OT, but if you buy a mac, I HIGHLY recommend you buy it from apple. Apple has the best customer service for computers by far and if you buy from craigslist or some 3rd party, you don't get that.
Mac minis start at $599. All you'll need after that is a monitor that supports HDMI or DVI.
That's pretty heavy for a computer I'm not ever going to really use. I basically anticipate only compiling binaries on it... and if I have to do multiple versions (like 32-bit and 64-bit), I might need a second one. I really want the cheapest I can get, I'm not too concerned about warranty service. Even if one dies and i have to get another, it was still cheaper to get each for $200 each than pay $600 for one. |
|
|
|
I wish I could find the email, but Thunderbird search is failing me... Someone emailed me a month ago to tell me that the directions on the Building Armory from Source page worked flawlessly on his OSX installation except for one line: /usr/local/share/python/easy_install-2.7 twisted (just needed to add the abs path to the easy_install) I updated it in the build instructions, but never followed up with anyone else about it. I guess that's not the case for everyone (anyone?). I would track down the email but I remember that's all he said. And I still don't have any Mac/OSX system on which to try it (and even if I did, I'm not sure I would know how). I guess I'm going to need to get a Mac system, do it myself, and then compile binaries... but Macs are expensive... I think that person was using snow leopard. I used the linked directions on my Lion system and had no luck. With lots of fuxing around, I got it to this: $ python ArmoryQt.py
********************************************************************************
Loading Armory Engine:
Armory Version: 0.55
PyBtcAddress Version: 1.00
PyBtcWallet Version: 1.35
Detected Operating system: Mac/OSX
User home-directory : /Users/bwstitt/Library/Application Support
Satoshi BTC directory : /Users/bwstitt/Library/Application Support/Bitcoin/
Satoshi blk0001.dat : /Users/bwstitt/Library/Application Support/Bitcoin/blk0001.dat
Armory home dir : /Users/bwstitt/Library/Application Support/Armory/
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap: 6
Perhaps it's worth starting a separate Armory+OSX thread in the Alt Clients subforum. Mainly because I have absolutely no experience with OSX at all. I've never even touched an OSX machine. And at the moment, I couldn't dig into it even if I wanted to (no access to such a machine). On the other hand, if others dig in and have a place to discuss it, I will happily offer as much assistance as I can, and then I'll have some place to go when I finally do get my hands on such a machine, and maybe it'll soften the blow for me to get into it... On that note, if I were to start searching craigslist or ebay for a Mac, what should I get? Presumably, something "relevant" but not anywhere near top-of-the-line, either. I would probably start on it, myself, when I am finished with RAM-reduction, so I especially don't need anything too powerful. |
|
|
|
mmap appears to be the correct solution here (and possibly gmaxwell's solution as well)
Any developers of the satoshi client looking at this? I'd be willing to try my hand at a patch if someone can point me in the right direction, but I'm not familiar with the bitcoin client code or libdb (which may need altered if it doesn't already provide mmapability for databases).
That implementation sounds fantastic! Exactly what we need. Would be great if this could be implemented, I really think this is quite a high priority. Getting started with bitcoin should be as painless, fast and easy as possible for new users. Good luck with this Notme I'm pretty sure the Satoshi client already uses something along these lines. In fact, I know I saw mmap in the source code for opening wallets... Perhaps the difference is that Armory does a full rescan on every load (but does not do full verification, that would take a while), whereas the Satoshi client (I think) only re-scans the last 2500 blocks. This gives me an opportunity to get the whole blockchain into cache, whereas the Satoshi client won't get it into cache until the first time a scan is done. If I'm right and it does use mmap for the blockchain, then a second scan (for instance, on an address import) will go much faster if your computer has 4-8 GB of RAM. |
|
|
|
I wish I could find the email, but Thunderbird search is failing me... Someone emailed me a month ago to tell me that the directions on the Building Armory from Source page worked flawlessly on his OSX installation except for one line: /usr/local/share/python/easy_install-2.7 twisted (just needed to add the abs path to the easy_install) I updated it in the build instructions, but never followed up with anyone else about it. I guess that's not the case for everyone (anyone?). I would track down the email but I remember that's all he said. And I still don't have any Mac/OSX system on which to try it (and even if I did, I'm not sure I would know how). I guess I'm going to need to get a Mac system, do it myself, and then compile binaries... but Macs are expensive... |
|
|
|
|
I've updated the title and top-post with a "wrap-up" section. Thanks again to everyone, and please contact me if you donated but did not receive an email regarding rewards.
|
|
|
|
I'm all out of bugs to report  . What a shame... |
|
|
|
|
Show Posts
