Thanks, that worked great for a 32-byte hex key. Is it possible to import from WIF? I've tried:
wlt.importExternalAddressData(privKey=SecureBinaryData(base58_to_binary("5KaPWnaXTLUdv5WdbwbiXbjDqUFXEUT1aAgSGrYHtzuGD5mooWv")))
But I get: assert(plainPrivKey.getSize()==32)
Do I have to convert from WIF to 32-byte first? Is there a function in armory? I was snooping in bulkImportAddresses() and found snippets to deal with base-58 private key, but couldn't turn it into anything working.
Edit: It must be in there somewhere because I think you can import WIF from armoryqt. Now I'm on a hunt!
The "parsePrivateKeyData()" method autodetects basically every private key format, including Casascius' mini-private-keys. You could manually read the keys using "base58_to_binary()", but the following will work just as well to convert the data into 32-byte hex that can imported per my previous example: >>> encodePrivKeyBase58('\xaa'*32)
'5K7T2qR7K5MUMDmkJvCEPbUeALuPyc6LFEnBiwWLuKCEVdBp8qV'
>>> parsePrivateKeyData(_)
('\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa',
'Standard Base58 key with checksum')
Edit: I just noticed you that your problem was actually that you crammed the whole 37 bytes into the import function. The first byte is 0x80 which is the "network private key byte", and the last four bytes are a checksum: So you could've just done "base58_to_binary(...)[1:-4]" and that would've worked, too. |
|
|
|
I haven't seen that loop since I started running bitcoin-qt independent of armory. But I've only open and closed it a few times, so it could just be a coincidence.
It really does only happen like once every 10 loads. And then goes away. Which will make it tough for me to track it down. So it's more "expected" than "coincidence"...
I know you're busy, but I have (hopefully) a quick question -- I'm trying to add an address to a wallet following the add 500k address in extras, but only adding 1 key ... Any ideas? You just made me realize I should probably remove that example script... that script is actually "special" because someone had wanted to try running Armory with 500k addresses, and I said that it would be ridiculously slow to import them "the right way" (shown below). So I recommended he manually modify the wallet files with the proper wallet format -- you should not import addresses that way! Instead, use the built-in function, and leave everything blank except for the privKey argument: def importExternalAddressData(self, privKey=None, privChk=None, \
pubKey=None, pubChk=None, \
addr20=None, addrChk=None, \
firstTime=UINT32_MAX, firstBlk=UINT32_MAX, \
lastTime=0, lastBlk=0):
I haven't tested the following code, but it would look something like this (note that key data needs to be crammed into a "SecureBinaryData" object before being passed to any of these methods -- but still pretty simple) # If run from extras dir, need to add parent dir to path
import sys
sys.path.append('..')
from armoryengine import *
# Create the SBD object for the private key which is "aaaaaaaa..."
hardcodedPrivKey = SecureBinaryData(hex_to_binary('aa'*32))
# Read the wallet file (it handles all the backup stuff automatically)
wlt = PyBtcWallet().readWalletFile('/path/to/my.wallet')
# Import the address using the built-in method
wlt.importExternalAddressData(privKey=hardcodedPrivKey)
# Nothing else needs to be done -- the wallet is closed after every operation already
print 'Done!'
# But let's verify it worked:
addr160 = convertKeyDataToAddress(hardcodedPrivKey)
addrStr = hash160_to_addrStr(addr160)
print 'The new address is', addrStr, 'and is in the wallet:', wlt.hasAddr(addr160)
Yeah, it's dead simple when you're using the right calls... sorry for the confusion! Edit updated the script with formatting and with the hex_to_binary() call which is needed if you are plugging in a hex private key. Also, you may have damaged your previous wallet file trying the original script. You might consider removing it and trying the new script on the original to make sure you're not mixing two different things. |
|
|
|
When starting it for the second time, after downloading what blocks it had to, it got stuck scanning on 1%. I found this in the log over and over, for a very long time.
-WARN - 0: (..\BlockUtils.cpp:4865) Marking orphan chain
-WARN - 0: (..\BlockUtils.cpp:4888) Done marking orphan chain
I just added an empty wallet while it was loading and got this loop. I closed and restarted and it's scanning transaction history again, says 20 minutes remaining. Ugh, that's been happening too much. Typically a restart solves it. Before I officially release this version, I'm going to figure out what's causing that and fix it. But it will not finish loading in that state. It thinks that every block is an orphan. It has to be restarted. |
|
|
|
Quick Update:
OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.
PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.
If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.
Attribution is fine. Adding their logo and acknowledgment to our website would probably be fine, too, if we actually integrate the solution into Armory. If that's easiest for you, do it. |
|
|
|
It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.
I see no reason to spend any effort on securing the channel, beyond making sure that the offline device is getting data from the correct online device (no injection). But given the SNR of a direct audio cable, I'm not concerned about that either. This is purely a bandwidth issue. Compression would be great, except I wouldn't count on it to help very much, since the transactions are mostly hashes which aren't compressible. I would guess you'd get no more than 5%-10% compression. So again, the real bottleneck here is how many bits-per-second you can reliably push over the audio channel. |
|
|
|
Agreed. Also, I would prefer something that can't be easily eavesdropped/recorded for analysis later (assuming third and second parties are occasionally allowed into the room where the Armory offline client is stored). At least with a direct audio link this isn't even a factor. I realize there are Tempest-like ways of catching interference even with a direct audio link, but those can be mitigated both electronically and physically(a quality van-Eck-phreaking device isn't going to be easily hidden on one's person).
By the way, there is no security issues with the transfer unless you are concerned about privacy, which probably isn't worth an TEMPEST attack itself. The data moving between the devices is simply an unsigned transaction (online to offline) and a signed transaction (offline to online), which eventually ends up in the blockchain anyway. So just like with the USB keys, there's nothing useful to an attacker besides learning that you have access to some given addresses and where you are sending money. But if they're crazy enough to use such an attack they probably got your watching-wallet anyway. So I'm not too concerned about that. If someone is going to TEMPEST the room, they would better off trying to probe the buses on the device circuitboards. And if that's what's driving you, you can always get yourself a Faraday Tent  |
|
|
|
Winterfrost: can you also send me a copy of your log file? Use File->Export Log File. Then attach it to an email to " bugs@bitcoinarmory.com". This could be an ugly bug to track down because it's probably pretty difficult to reproduce it on demand. Hopefully there's something in the logs that helps... |
|
|
|
Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.
Ack, I haven't seen that one before. Are you sure it has confirmations? Armory on Windows has always had an issue with the memory pool, for some reason it cannot persist through a restart (that's what all the "Memory pool file was corrupt. Deleted. (no further action is needed)" messages are about. But it should resolve itself after the transaction gets one confirmation. If not, then that's a problem, for sure! Does it have one confirmation yet? Yes, this is the address and this is the transaction. Ugh. Okay, definitely a bug. And the saving-between loads is causing it to persist (it's one of the reasons I liked rescan-every-load, from a reliability perspective). Can you do me a favor and close Armory, then restart it with the "--rescan" option? I just realized, I need to put a button into the interface to do that... |
|
|
|
Everything synced fine from a fresh install (Win7 64-bit), but I did find an issue when I sent a transaction. It went through successfully and showed up in the receiving address as well as in the transactions list in Armory. However, when I went away from my computer and came back later, the transaction is no longer there and the wallet has reverted the balance to what it was before. So basically, it now says there are funds to spend even though in reality they've already been sent elsewhere. The bug also persisted across restarting.
Ack, I haven't seen that one before. Are you sure it has confirmations? Armory on Windows has always had an issue with the memory pool, for some reason it cannot persist through a restart (that's what all the "Memory pool file was corrupt. Deleted. (no further action is needed)" messages are about. But it should resolve itself after the transaction gets one confirmation. If not, then that's a problem, for sure! Does it have one confirmation yet? |
|
|
|
Keep in mind that for desktops, the user will probably have to get some kind of audio splitter so they don't have to keep unplugging their speakers every time they want to do this. Or at least an extender so that the cable is easily accessible from their desk chair. It's not the most-convenient method, but it's still damned cool and damned secure. And should be pretty portable. I just wonder if it's going to turn into more of a research project in the end... where it will always work almost well enough, or just good enough under the right conditions, but reach asymptotic mediocrity ... meh. I'll still pay to find out I'd like the bounty to be for a usable proof-of-concept in at least one OS. Once we have a prototype that can move at least a few kB per sec, then we will have something that can be used by someone and we can try to evaluate what it will take to get what we need out of it. At that point, we may switch to some kind of hourly rate. After all, I'm not a big fan of bounties for long, drawn-out activities. But "prototype that moves a few kB/sec in at least one OS across a regular double-ended 3.5mm audio jack" is a pretty clear checkout criteria. |
|
|
|
Let me get this clear, is this bounty for an open air audio data channel or a wired one? I only intent to develop one that works by plugging both computers sound cards to each over with a couple of double ended wires
I think we determined that over-the-air wasn't going to work. If it did it would strictly be a bonus -- I intend to use/require the double-ended audio cables. |
|
|
|
I started it up again, the visual indicator didn't change from 1% until it went straight to the wallet after a few minutes. Looking at the live log file, it stopped right after the completed handshake, also it said the armory version was 0.88 (ArmoryQt.py:1162) also, got this error. (WARNING) -- ArmoryQt.py:1838 - Memory pool file was corrupt. Deleted. (no further action is needed)
Not sure if it's significant. Hope this helps.
So is it working? It sounds like it's working and you're just reporting some inconsistencies in the log file. Don't worry, both those things are normal. I mean, not totally normal, but they happen. |
|
|
|
|
Anyone tried this with Win7-32bit? I'm running it right now, but I don't have a pre-sync'd version, so it might be a while before I can really run it. I guess I could figure out how to bootstrap it...
Btw, I just executed a couple offline transactions using the new version on the online computer (offline computer is still using an ancient version). Everything is smooth, so far. Except for that occasional faulty startup thing. That's my next task after I finish with the Windows LevelDB upgrade from goatpig (thanks goat!)
|
|
|
|
If the 25 BTC is still standing, I'd like to take a shot at this. I'm considering building a lib from the grounds up in C++ with OpenAL.
Raize has offered to send the 5 BTC to me for Armory development. So what I think I will do is keep the bounty open, and switch from {Me: 20BTC, Raize: 5BTC} to {Me: 25BTC, Raize: 0}. That way ATI gets the 5 BTC to use for development if the bounty is never claimed, but it's still available to someone like goatpig who still wants to take a shot at it. I think everyone wins. I think this is a really cool solution, and I'm still happy to pay a $3k bounty for it. It's an excellent option. Though I do think the animated QR codes might be more reliable in the long run, and there might be an already-packaged solution out that we could license... |
|
|
|
When starting it for the second time, after downloading what blocks it had to, it got stuck scanning on 1%. I found this in the log over and over, for a very long time.
-WARN - 0: (..\BlockUtils.cpp:4865) Marking orphan chain
-WARN - 0: (..\BlockUtils.cpp:4888) Done marking orphan chain
Mooshire, is it solved by restarting the app? So far, I haven't seen it get into any permanent bad state. I've seen that happen before, and then it goes away on a restart. (P.S. - I do plan to find and fix it, I just want to make sure that, for now, it doesn't leave anyone in an unusable state) Watching-only wallets contribute to the "Maximum Funds" and "Spendable Funds" totals even if they are configured as "Belongs to: Someone else."
What is the wallet filter set to? If it is "All wallets" it will include all wallets. If you set the filter to "My Wallets" it has the behavior you expect. Bottom-left corner of main window. Leveldb/snappy is still broken:
...
The pull request I sent you on GitHub fixes the problem for me. With that patch applied, the time from starting the program until balances are displayed is about 28 seconds.
I have modified it in my source code and will commit it with the next version. Visual Studio 2012 only supports running on Windows 7 SP1 and later. By default, the created executables will only run on Vista and later. It can build XP compatible executables, but you have to change the project's Platform Toolset to "Visual Studio 2012 - Windows XP (v110_xp)"
I don't want to spend a ton of time on it... but now that the RAM issues are under control, and it previously worked on XP, I would be willing to spend a couple hours getting it work on XP. Especially because some users might have old XP systems laying around they'd want to use for offline use (don't bash them, it's still better than an online computer ) |
|
|
|
It's crappy. It was originally a key calculator, with signing as an after-thought. When it turned out that so few people found it useful (since it wasn't compatible) I stopped doing anythign on it until I had a chance to upgrade it to a compatible one (and isolate message signing from the other stuff). If you want to still use it: click the address book icon above the message box in the bottom left. Select the address you want. Put your message in the box. Then click "Sign" and type in your passphrase when it asks. Once the signature is present, you can click "Copy Signature Block." You can immediately "Import Signature Block" to test it. As I said, it's not really made to be used, right now. But the next version will have it. |
|
|
|
OK thanks for all the hard work Alan (and contributors and team): Tested "Armory version 0.89.99.3-testing" On: Windows 7 64 bit, 4 gb ram, I had it scan the BC over night. This morning i got the message that bitcoin qt appears to be offline or something (sorry missed the screenshot). Armory was online though. I closed armory and reopened. I think it took even less than your 19 sec to download 1 block and go online straight away. very nice. Not a lot of testing apart from that. Will do more and also report on ram usage. First sight looks good.  There appears to be an issue right after it finishes the full DB build. But it seems to be solved by a restart. So far, I've seen a few issues with Armory getting into a bad state like that, but it always resolves itself. So far, I haven't had to "--rebuild" the DBs once. That's a good sign (though --rescanning sometimes seems necessary). |
|
|
|
So far, I've seen a pattern that 32-bit Windows versions don't seem to work. But 64-bit OSes do work. And this strange unicode issue from TierNolan. I tested it on my fiancée's computer: Win7-64bit w/ 4 GB of RAM. About 5 years old. It took forever to download the blockchain (probably 24 hours). And it took about 2-3 hours to build the the DB. But once it finished scanning (I don't know the timing), it only takes 1.5 minutes to start up. And most of that is waiting for bitcoind to initialize. And somehow uses even less RAM than the other systems: 215 MB. Not too shabby. Also had someone report success on a system with 2 GB of RAM! Slow of course. There is no doubt that Armory is still a pretty heavy program... Given the issues with Windows 32-bit that I've seen, I'm going to try to rebuild everything on a native 32-bit VM. Unfortunately, I tried installing MSVS 2012 Express on WindowsXP-32bit, but I got all sorts of crazy errors. If anyone else has WinXP-32bit and feels like donating some time, please try downloading and installing MSVS 2012 Express for Windows Desktop. I ask because, I assume it's possible that there is something wrong with my WinXP system, but I also wouldn't be surprised if Windows XP is just too old at this point for such a new piece of software. Instead, I'm going to install Windows7-32bit and repeat the build process there. If it works there, it obviously has a better chance of working on any Win7-32bit and Win8-32bit. Fat chance for Windows XP, but maybe we'll get lucky. Known Issues: - Doesn't seem to work yet on 32-bit OS. Haven't tried any *nix systems, yet. But haven't heard any success stories from 32-bit Windows users.
- Unicode everything
 Ugh. Will work on that after it works for US users. The next version will get some unicode-TLC (it will mostly be a bug-fix and polishing release, with nothing major except for message signing) - About 10% of the time, I start the app and I get rapid disconnects/reconnects. The log reports a huge string of "Marking Orphan Chain" messages (which indicates the headers are not being processed correctly). I close it, and restart and it works fine.
- Super-slow and no feedback when it's updating a couple days' history after being shut down for a while. The feedback is technically there, telling it to update the GUI every 25 MB... but the update is usually less than 25 MB, and even if it is >25 MB, that can take a couple minutes. Not only do I need to improve the GUI-update cycle, I need to figure out why the initial build is 10x faster than updating on restart (even though they should be using the same code to do it)
- General speed: Obviously some optimizations missed. One of the reasons I picked levelDB was some testing early on where I found that doing a full blockchain scan was 30% faster than my super-optimized blockchain scanner. Now it's 3x slower. I have a good idea what it is -- I'll dedicate a day to tinkering and benchmarking, after the release
|
|
|
|
I check this subforum every once in a while, great work! I may finally be able to soon go back to using Armory!
Well, please try it! I need more people trying it! |
|
|
|
|
Show Posts
