One question I do have is how do imported addresses and the deterministic wallet work? You can rebuild the deterministic wallet based on the seed value, and I assume imported addresses are just held completely separate.
btc_artist, That is exactly right. There's actually a warning box when you decide to print a paper wallet that warns you that imported keys are not part of that backup. However, that's why there's also a wallet option labeled "Backup Individual Keys." Clicking that gives you a list of private keys that you can manually copy/save/print (and a checkbox for imported-keys-only). The goal was to allow you to be able to get your individual keys if you want to import them into another program, or just create a imported-key-backup to supplement your deterministic backup. |
|
|
|
|
Joric succeeded at reading encrypted wallets, and I do want to eventually allow the move, but I want to make sure it's possible to run Armory without running bitcoin-qt/bitcoind at the same time. Sharing some addresses between the two wallets while also having some independent addresses can lead to you having absolutely no idea how much money you have (and usually over-estimating).
At the very least, I want to allow people to switch to Armory, but I can't reliably create a perfectly synchronous dual-wallet system. I designed the Armory wallet specifically to be simple and straightfoward, and easy to maintain among multiple clients. The Satoshi client wallet uses a database engine, which not only requires a separate library, but I also think it comes with extra risks (like the encrypted-wallets-not-actually-encrypted bug 0.4.0). I will not add any support for Satoshi wallets beyond pulling keys out of them.
In the future I will not only implement a bulk-import feature, but also leverage pywallet code to do a direct import of the Satoshi wallet, but with a warning to stop using the Satoshi wallet (perhaps a print-backup-then-delete option). Until then, just create a new wallet and send it some money.
The single-address-import function was aimed more for vanity-gen addresses and Casascius physical bitcoins.
|
|
|
|
Wake me up when Armory can transition existing data in. Sorry
for the rant, I have a feeling your app. has a ton of potential, but
I can't get it to do what feels like the very obvious.
znort, I have actually, explicitly, decided not to allow people to import their wallet.dat. It's because stupid things happen when you have two clients open using the same keys, and users shoot themselves in the foot. Not to mention, I don't want everyone blindly converting their entire wallet to a piece of alpha software. Armory is good, but it needs to survive in the wild a bit longer before I start allowing people to import their entire wallets. This way, users know to approach cautiously. I should've explained, that the point was for you to make a new wallet, and transfer some of your money to the new wallet. If you're comfortable transferring all of it, I won't stop you. If you have some popular addresses you want to move over, you can use pywallet to get them and import them to Armory. Once I get some other features implemented, I will be making a bulk-import dialog. |
|
|
|
|
Man I suck at quality control. I had tested the pseudo-binary solution in Windows, except I used a machine with python already on the path which wasn't part of the install instructions. I updated install_zope.py and tested it on a fresh Windows7-32bit VM. Works perfectly now.
Also, it gave me the opportunity to test the XP-32bit binary on Windows7-32bit, which did work. So I renamed them simply to "Armory_32bit.zip" and "Armory_64bit.zip". Only the rare few with WinXP-64bit may have an issue. And I don't have a sample system like this, so I can't test it. If you do have such a system, let me know how it goes.
I'm still working on the full-binaries, but the issue I'm having is inconsistent, so I don't have a good way to know for sure. I just have to do some more exhaustive testing. Thanks for your patience!
|
|
|
|
I don't have enough RAM to hold the whole main network blockchain, that's why.  The GUI issues are nothing severe, it just looks a bit ugly with overlapped text and buttons : https://i.imgur.com/BOQ6d.pngMatoking, thanks. I have seen that a couple times on systems with screens smaller than my own. But it doesn't appear to happen on any other tables, so it should be easy to isolate why that's happening. At least, ugly is better than dysfunctional! I will look into it this weekend! Given the previous discussion in this thread about mmap, I might be able to fix the RAM issue sooner than later! It's not as difficult to implement as I expected (and the madvise() function is exactly what I need to optimize the operation for blockchain scanning). Linux will get the upgrade first, but hopefully Windows won't be far behind! -Alan |
|
|
|
Tried it out, other than some problems with the UI, it looks very nifty! I can use it only on the testnet at the moment, though.
Why can't you use it on the main-network? Is it an issue with Armory itself? And please let me know what problems you have with the UI. I can't fix them if I don't know what they are!  |
|
|
|
|
I updated the packages (and md5sums), and they now include the full zope.interface source (with license information), and a short python script to install it for you. Now, in order to install zope, you just double click on the script "install_zope.py." Everything else should just be a straight download and install.
If you have not yet tried Armory, please try it now, and let me know if it works from a fresh system without any python-related stuff prior.
|
|
|
|
|
Pseudo-binaries posted (for Windows)! It's probably about 1/4 the amount of work to get it running using the zip files, and no MSVS needed!
Let me know if the psuedo-build instructions don't work!
|
|
|
|
|
Joric! You are awesome! You will get yet another donation from me (and anyone else who helped, too). I will look at your patch/updates more closely, tonight. I'm sure many of the changes can be folded directly into the project without affecting build/runtime on other architectures, and then it will be even easier for OSX folks to get it running. If I can get my hands on an OSX computer, I could actually compile binaries...
Just a question: did you use my pre-swig'd .cxx and .py files that I gave to splatster? Or did you actually get swig running in OSX along with everything else? I'm still trying to decide whether I can&should leave swig out of the equation (for other people), instead just create them and commit to the project like every other source file. (i.e. I will run swig, and commit the output instead of requiring others to run it).
Red Emerald,
I did 90% of my development in Ubuntu 10.04. For sure, the layouts are best in Ubuntu 10.04, but they're not that bad in Windows. I can't speak for OSX, yet (I still never figured out a robust way to do table-column-sizing). Though I prefer Ubuntu fonts&themes over Windows' any day, Armory appears to work smoothly in both. (btw, both Python 2.6 and 2.7 work).
Great! When I get home tonight, I will modify the code with Joric's patches and fix a small bug reported by Runeks. After I verify that everything still works on both other architectures, I will try to package up a single zip-file for Windows users (both win32 and x64). For now, I don't see the necessity of making binaries for *nix systems, since I feel like the build instructions are pretty damned easy (at least it is, in Ubuntu).
|
|
|
|
|
Alpha release-copy #1! See the top post for information about what this means. In a nutshell, this will be the "final" alpha version, barring minor bugs I've introduced recently. Complete binaries won't be available for Windows, but I'll be posting a half-way solution that should work for everyone (and be dramatically easier to setup than the full build instructions).
All features I wanted for alpha have been tested and stable for a while (relatively speaking). I've even moved all my own funds to an offline laptop I adopted from a coworker (offline mode works with only 512 MB of RAM!). PLEASE let me know if you find any issues with the release copy (via PM) and hopefully I'll have the official, alpha version solidified by the end of the week!
First priority after alpha is "normal" RAM requirements!
|
|
|
|
Works, I manually copied and renamed SWIG_compile_dll_MSVS2005.dll, thanks! I was unsure if there was some sort of signing/packaging going on in that step, so didn't realize I could do that bit manually. Very odd that it has trouble copying stuff, as the repo is within my user's directory.
Thanks for holding my hand!
My guess is that MSVS 2012 compiles the .dll into a different directory structure than previous versions, meaning that the "copy" command fails to find it. Now that I think about, why on earth didn't I just compile it directly to the right location? I'll have to have a talk with myself about that... |
|
|
|
Anyway, so here's some more messages from the output: SWIG_compile_dll_MSVS2005.vcxproj -> C:\Users\Nuri\Repositories\BitcoinArmory\cppForSwig\Release\SWIG_compile_dll_MSVS2005.dll
2> 1 file(s) copied.
2> python: can't open file '../pyqt/setup.py': [Errno 2] No such file or directory
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "copy Release\SWIG_compile_dll_MSVS2005.dll ..\_CppBlockUtils.pyd;
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: python ../pyqt/setup.py py2exe --includes sip,hashlib -d ../pyqtexplore
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 2.
========== Build: 1 succeeded, 1 failed, 1 up-to-date, 0 skipped ========== It looks like there's something wrong with PyQt4, but it's definitely installed. I tested Python's PATH from command line, and that works, too. Hmmmm ... nhodges, the errors you're showing me there all occur after the SWIG module is compiled. If that's true, then you should already be done. "1 file copied" is the last step needed to get from SWIG_compile_dll_MSVS2005.dll to _CppBlockUtils.pyd. Anything involving setup.py or py2exe is all extras you don't need. In other words, if it's not working, there should've been other errors upstream. I would need to see those, instead. And now that we're up to about half a dozen posts about this, please PM me to continue figuring this out. If we resolve it (assuming it doesn't work already) I'll feed the updates back to this thread. Cheers, -Eto P.S. - I just checked on one of my VMs... that is the exact error I get when I don't have the extra binary-compilation tools around. Once I see that, I can just click on ArmoryQt.py and it works! |
|
|
|
It looks like the SWIG_compile_dll_MSVS2005.dll isn't even getting built on my system, the py2exe error comes right after the copy command to put the .pyd in the root directory. It definitely gets so far as creating as creating the "CppBlockUtils_wrap.cxx" file indicated by the README text file. Can I manually compile this somehow?
I don't know anything about manually compiling in Windows. Though, I do plan to finally release alpha soon, which means binaries will come with it. I got a not-cleaning-up-properly bug in the current binary that has to be fixed, then I'll maybe post a release-copy. So worst case, wait a day or two and you can skip this |
|
|
|
I've tried it under both. I have Python 2.6 for 32 bit systems installed. Is 2.7 a requirement on Windows? When I try to compile under 32 bit, I do get the "CppBlockUtils_wrap.cxx" file, but it seems like it dies there when trying to create the pyd/dll. I get this error in this case: error MSB3073: The command "copy Release\SWIG_compile_dll_MSVS2005.dll ..\_CppBlockUtils.pyd;
python ../pyqt/setup.py py2exe --includes sip,hashlib -d ../pyqtexplore Is there any debug information I can wrangle up that might help in figuring out what I'm missing? Thanks (1) Both 2.6 and 2.7 work on my Windows machine, when using MSVS 2008. I haven't tried any other python versions. (2) Ignore any errors to do with py2exe... that is an additional compile step that is unnecessary unless you are building binaries. I suppose I could've created a new configuration just for compiling the binaries... On point (2): It's possible, if it got that far, that you actually completed the build, just got distracted by the py2exe red herring... Check the root proj directory for _CppBlockUtils.pyd . If it's there, try running ArmoryQt.py. (If you want to test it on testnet, you can create a shortcut in that root directory, and select properties and add " --testnet" to the target line) |
|
|
|
Trying to build solution on W7 w/ VS2012, however seem to be getting about 85 of these types of errors:
error LNK2001: unresolved external symbol __imp_Py*
I definitely have python installed and in my path, as well as all the other requirements. Any thoughts?
It's possible that you are trying to compile for the wrong architecture. Make sure you're selecting "Release" and "x64" at the top of MSVS (if you are on a 64-bit system) and make sure you have 64-bit python installed. In my case, I got errors (albeit, different ones) if I tried compiling in 32-bit, because my installed C:\Python27\python27.lib file is only for 64-bit systems. I suppose it could also be a SWIG problem, but it sounds like you got all the way to the linking phase, so SWIG had probably done it's job by then... |
|
|
|
^ Can you point me to the place in the code where it tries to make this connection? I'd like to try to debug it if possible.
It's using python-twisted, which can be awfully bizarre/confusing if you're not familiar with it, but it doesn't hurt to look at it. Please PM me to discuss specifics if you need clarification or if you identify an improvement. The code is in ArmoryQt.py, search for the function "setupNetworking" (around line 500). The twisted protocol/client/factory definitions are located in armoryengine.py around line 8350. Let me know if you find something! (just so you know, I haven't gotten any other reports of network problems... because if the networking is botched at the beginning, it goes into offline mode, or in online mode it's pretty successful at reconnecting if it gets disconnected. somehow you are getting into online mode, but then losing the connection and it's failing to reconnect...?) |
|
|
|
That does still look like a connection issue. Unfortunately, Armory only initiates the connection when it first starts up. If it can't connect on startup, it won't connect until you restart Armory. If it does connect, you'll see on the console output something about "Handshake finished! Connection Open.".
How does Armory connect to the local bitcoin client? Via the RPC interface on port 8332? It connects as a regular peer, but through localhost. Port is 8333. It does the handshake, and then regresses to nothing but a leech: it ignores all messages except for new tx, which it requests (to get zero-conf tx), and sends tx that you create (which is then broadcasted if it is valid). No other communication is used. |
|
|
|
Having trouble on W7 VS2010, does it require 2005?
MSVS 2008 works for sure (that's what I've been using). Someone else way earlier in the thread said they got it working with MSVS 2010, but I remember having trouble with it when I tried once (but didn't try too hard). |
|
|
|
Now I get the same error that I mentioned before when trying to send a donation to you via Armory. This time I'm trying to send some coins from the wallet restored from a paper backup, to the wallet from the Satoshi client. This time I know the original Bitcoin client is running. ....
Traceback (most recent call last):
File "/home/rune/Programming/BitcoinArmory/qtdialogs.py", line 3558, in createTxAndBroadcast
self.main.broadcastTransaction(finalTx)
File "/home/rune/Programming/BitcoinArmory/ArmoryQt.py", line 1359, in broadcastTransaction
self.NetworkingFactory.sendTx(pytx)
File "/home/rune/Programming/BitcoinArmory/armoryengine.py", line 8531, in sendTx
raise ConnectionError, 'Connection to localhost DNE.'
armoryengine.ConnectionError: Connection to localhost DNE.
Runeks, That does still look like a connection issue. Unfortunately, Armory only initiates the connection when it first starts up. If it can't connect on startup, it won't connect until you restart Armory. If it does connect, you'll see on the console output something about "Handshake finished! Connection Open.". At the moment, I can't find a way to recreate that problem on my own machine. If the Satoshi client is open, and restarting doesn't help... then I'll have to defer this because of a lack of ability for me investigate it. However, if nothing else works, you can always copy the raw tx from the console output into Nibor's webtool for broadcasting tx: http://bitsend.rowit.co.uk/ . (it's all the hex right after "Raw serialize tx:" right after you click "Send"). In the short term, I'll make a note to add a real pop-up message box about this error, and even refer the user to Nibor's tool (speaking of which, I should send him a donation!) |
|
|
|
Now it works. Turns out I made no fewer than four errors when typing back in the letters from my self-written paper backup (good thing I kept a screenshot). On a related note, have you considered using a dictionary when making paper backups, instead of letters? There is a total entropy of about 342 bits in both the root and chain key as far as I can figure out. The same entropy is offered by 22 words from a ~50,000 word dictionary. When using a printer this would cause fewer errors when typing the keys back in, and if you're writing the keys down too it'll cause fewer errors in both writing down and typing back in. The example 50k word dictionary is available on Ubuntu (and probably other Linux distributions) via this command: grep -v "s$" /usr/share/dict/words (which excludes words ending in "s" in the dictionary /usr/share/dict/words) We can easily get 22 random words with this command: grep -v "s$" /usr/share/dict/words|shuf -n 22 --random-source=/dev/random which will produce series of words like the following: lofted dazzling Dorothea wrangling purist mellow indirection windsurfed patrolman recalcitrance curtly valor pane cagey parodying freewheeled reverting jaunted haltingly shuddering biodegradable telephoned
browning masquerade oiling prevaricate clemency groggy steeling macerating unpleasantly sea chaplain rifted extension purulence Wake ventilation Meghan shipshape retaking cleverest substantiated Christensen
irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederating
owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy miked
So we could have a paper wallet like this: Root key: irresistible steering narced pricked joker gunpowder dangling oceanic Mariano hybridized barreled hob baleen backslide quarrelsome interlocutory Pauline stratify caribou Zen Adrienne confederatingChain code: owing windswept Morrow fathead papoose scallion streaking dissenting Gray overact pendent Freemason cannoned horsy volumed arise Wicca wrong assaulter sapping entropy mikedRuneks, I have considered this. Given the amount of error correction I already built into the restore-paper-backup dialog, I wasn't too worried. But it's something I'll keep in mind. Perhaps I'll add an option to save it in whichever form you want. Glad it worked, and thanks for the recommendation! |
|
|
|
|
Show Posts
