|
If I can get myself a 10.8 image for a Mac VM, I can try out a new build process that picobit posted. So far though, Apple doesn't want my money, as I would be willing to pay for it but there's no way to get it. Period.
Am I mistaken? Any recommendations?
|
|
|
|
I see. So that's already 28 gigabytes of HD space wasted. This is getting ridiculous.
It is ridiculous, but it's what we had to do to get the new version working. It also maximizes security and leaves open the possibility of having remote bitcoind/bitcoin-qt instances, etc. And will be useful for heavyweight Armory servers in the future. For now, it's what we gotta do. We'll scale it back in future versions after this design is stable. ----- Ubuntu/Debian
Only 10.04 and 12.04 are mentioned. Is the 12.04 deb/installer compatible with 13.10? Good question! I actually don't know. Anyone want to make some VMs and try it out for me/us? |
|
|
|
(WARNING) ArmoryQt.py:1391 - Tried to start bitcoind, but satoshi already running
(WARNING) ArmoryQt.py:932 - running from: C:\Users\vbox\BitcoinArmory\ArmoryStandalone\ArmoryQt.exe, key: "C:\Users\vbox\BitcoinArmory\ArmoryStandalone\ArmoryQt.exe" %1
(WARNING) ArmoryQt.py:1013 - app dir: C:\Users\vbox\BitcoinArmory\ArmoryStandalone
(ERROR) armoryengine.pyc:13135 - Resetting BDM and all wallets
Traceback (most recent call last):
File "ArmoryQt.py", line 22, in <module>
File "psutil\__init__.pyc", line 85, in <module>
File "psutil\_psmswindows.pyc", line 15, in <module>
File "_psutil_mswindows.pyc", line 12, in <module>
File "_psutil_mswindows.pyc", line 10, in __load
ImportError: DLL load failed: The specified procedure could not be found. Unfortunately, the new version doesn't support Windows XP, yet. Goatpig has a solution, but it looks like it would complicate this release (0.90-beta), so it's being reserved for the release after this one (0.91-beta). |
|
|
|
bitcoin.conf is default. Never touched it.
I noticed that bitcoind listens on localhost:8332, but Armory's error message (below) led me to believe I had an RPC problem.
Actually, when you use auto-bitcoind (the default), Armory does use RPC to connect to it and determine the current synchronization state. If you manage Bitcoin-Qt yourself (disable the first checkbox in the settings), RPC is never used. For people with problems like these, I recommend disabling auto-bitcoind in the settings and try running it separately. Just make sure Bitcoin-Qt/bitcoind are fully synchronized before starting Armory. |
|
|
|
|
Sorry, there is no way to do this without importing the keys or merging all of them. But as you said, they are compressed, so Armory can't import (or sweep) compressed keys yet. There really isn't a good way to do what you're looking for with the current version of Armory.
However, after this next release is out and stable, I will be working on the new wallets which will support compressed keys.
|
|
|
|
|
"SecurePrint" is part of the new release. It should ease some nerves about this.
@Hukfinne: I used that exact printer with my offline 10.04-32bit system about 6 months ago. It is definitely there in the default installation (and I just checked again in my 10.04 VM). Are you sure you were looking at the HP drivers and not some sublist (i.e. it's just "DesignJet 110", not "Color DesignJet 110")?
|
|
|
|
Just sent my first transaction to an .89 armory wallet, and it has 5 confirms in the blockchain, but Armory is reading 0 confirms on the transaction and no spendable balance. Any ideas?
What does the bottom-right corner say? Usually something like "Connected (260837 blocks)". Connected 270973 blocks -- but I just restarted bitcoind and it says it needs to reindex the blocks on disk, so that might be it. Letting it run now. Yeah, looks like you're about 60 blocks behind the network. I'm actually kind of curious if Armory figures out what's going on on the next restart... (I don't see why it wouldn't work, but yo ucan always be surprised...) |
|
|
|
So is this intended to be last testing release prior to 0.90-beta?
Barring any showstopping issues, yes. I plan to have it posted alongside 0.88.1, and if someone has enough RAM, they can still use the old one which may be more reliable for now. But it seems that this version is working quite well for a lot of people, and 0.88.1 is getting more unreliable, so I have to release it sometime! Version 0.91 will be tons of polishing, bug fixes, unicode fixes, and optimizations. I expect that that version will edge 0.88.1 on reliability. |
|
|
|
Just sent my first transaction to an .89 armory wallet, and it has 5 confirms in the blockchain, but Armory is reading 0 confirms on the transaction and no spendable balance. Any ideas?
What does the bottom-right corner say? Usually something like "Connected (260837 blocks)". |
|
|
|
RELEASE SCRIPTS COMPLETE:These things are bad-ass. Not only do they sign everything, bundle everything, hash everything (offline), and then verify and upload everything to S3 (online), it prints out a bunch of forum-formatted and HTML links! Below I have raw copied the forum-formatted links here after a raw upload to S3. This may not be perfect [yet], but it's pretty darned close. Please download things, verify signatures, install and run, etc. The two things I'm not sure about: Vista support, and offline-bundles properly bundled! Please try it out!
Try 0.89.99.16-testing!
All installers have offline-signatures, directly in the debs, and in the hashes file Armory 0.89.99.16-testing for Windows Vista, 7, 8 (Both 32- and 64-bit) Armory 0.89.99.16-testing for Ubuntu/Debian 10.04-64bit Armory 0.89.99.16-testing for Ubuntu/Debian 10.04-32bit Armory 0.89.99.16-testing for Ubuntu/Debian 12.04-64bit Armory 0.89.99.16-testing for Ubuntu/Debian 12.04-32bit Armory 0.89.99.16-testing for Mac/OSX 10.8 and 10.9 Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 10.04-32bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 10.04-32bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 12.04-32bit Armory 0.89.99.16-testing Offline Bundle for Ubuntu/Debian 12.04-32bit Armory 0.89.99.16-testing: Signed hashes of all installers
|
|
|
|
Okay, I'd like to beef up the instructions for verifying downloads in Windows. It will take a bit of work, but it can be done! I'm going to post my instructions here, and I'd like others to try it and tell me what I got wrong, or what needs to be improved. After about 20 replies, I expect we'll have something that can reliably check your installer on windows, even if it requires a bunch of steps and installing some stuff. Here goes: - Download and install GPG for Windows: Get gpg4win here. It allows you to check GPG signatures in Windows.
- Download a sha256sum utility: For computing the SHA256 hashes of files. I trust Kanguru for stuff like this. Someone else please recommend more well-known tools (I can't believe this kind of thing isn't built into Windows anywhere.... is it?)
- Download our offline-signing GPG key: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x4AB16AEA98832223
- Download installer and hash file: Go to our download page and grab the installer for Windows, and the "GPG-signed SHA256 hashes of all installers" for the same version
At this point you should have the following in your downloads directory: - gpg4win installer
- Our GPG key (0x98832223)
- sha256sum.exe
- armory_<version>_win32.exe (or similar .msi)
- armory_<version>_sha256sum.txt.asc
Run the gpg4win installer, and import the GPG key (I'm not sure how complicated this is...let me know). After that, do the following: - Verify the hash of the installer against the signed hashes: Open a windows terminal and "cd" to your downloads directory. execute sha256sum.exe armory_0.90-beta_win32.exe (or whatever the installer name is). Open the .txt.asc file in a text editor and confirm that the output on the terminal matches the line for the same filename.
- Verify the signature on the signed hashes file: I don't know if gpg4win gives you good windows explorer utils. I presume you can simply right-click on a file and check it's signature..
I'll update this posting when I get feedback, and then once it's stable I'll post it on the website. |
|
|
|
I want to have an offline deterministic wallet that's a sort of savings wallet. I'll follow it as read-only on an online computer. But the thing is that I don't want to reuse addresses on the offline one. Is it possible to send BTC from my online wallet to a brand new address on the offline wallet?
Or better yet, is it possible to figure out the offline wallet's next address through the online one, and give that to someone else to send BTC to?
Yes to both. That's why deterministic wallets exist. To clarify: that's exactly how Armory already works! Everytime you hit "Receive Bitcoins", Armory generates a new address from the watching-only wallet that hasn't been used before. As long as you keep using "Receive Bitcoins" every time you need to receive money, you always get a new address, and guaranteed that the offline computer has the private key for it. |
|
|
|
Also... at this point a lot of people are using 10.04 for their offline computers, and I don't want to tell them "sorry, gotta destroy and rebuild your super-secure system...have fun!" (including one of my own offline systems  ) |
|
|
|
For reference, BIP 10 is what I use in Armory to do the same thing. It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB. It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon. I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol... Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values. Can the payment protocol handle it? The payment protocol has absolutely nothing to do with offline wallets or transaction signing. Kind of... when I posted to the mailing list about making a better version of BIP 10 and asking for community support... Mike Hearn insisted that everything we need will be in the payment protocol. I took his word for it. Or I misunderstood him. If that's not the case, then I'll need to come up with another spec to replace BIP 10 that accommodates signed payment addresses, multisig, and supporting-transaction-lists. Again, I may just be ignorant about it, because I haven't had any time to look at the payment protocol yet. And/or I misunderstood Mike. |
|
|
|
Yes you are missing something.
The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.
Ahh, of course - I was overcomplicating things in my mind. Thanks for setting me straight. My test harness was making up these previous hashes for the purpose of tx signature testing, so I mentally wrote them off as arbitrary. If my device is presented with the previous transactions for addresses A, B, and C (which include their total value) I can simply SHA256 these, make sure the hashes in the outpoint structures for the tx I'm going to sign match, and then I know the total alleged value for A, B, C and can present outputs and fees to the user. As you said before, the worst thing the SW feeding me stuff to sign can do is make me create a bogus transaction that will be rejected by the network. A bit of a hassle, but at least its just doing a streaming calculation of a SHA256 (not ECDSA thank goodness!) and no blockchain data is necessary. I feel alot better now, back to making progress However, life as a HW wallet designer would still be much better with the proposed addition. For reference, BIP 10 is what I use in Armory to do the same thing. It was intended to be an ASCII-based way to move all this data in "blocks", either through email or text files on USB. It does work (Armory has been using it for offline transactions for 2 years), but it will be replaced soon. I'm told the payment protocol can replace this, but I still haven't had much time to dig into the payment protocol... Of course, that dramatically increases the complexity of it, having to pass around potentially MB of supporting transactions to verify those 8-byte values. Can the payment protocol handle it? |
|
|
|
Hi,
Warning - this might be a user error:) - if so, feel free to verbally slap me.
I have downloaded and installed the Armory client. Before committing any funds I wanted to try - Test a Paper Backup. Trouble is, when I press the test backup button, after entering the full root key, nothing happens.
Many thanks & good work on this fantastic client.
Send me a log file. support@bitcoinarmory.com . I can usually identify these things pretty quickly! |
|
|
|
Ubuntu 10.4 LTS support.
Installing armory_0.89.99.12-testing_i386.deb gives dependency error: libstdc++6 >= 4.6
On 10.4 LTS the most recent available is 4.4.3
Maybe more dependencies will give this error, but no tools available on this offline machine.
Ack, I should've labeled those better! Those are 12.04 installers. I am actually in the process right now of upgrading my release process to include 10.04 and 12.04 installers by default. AND name them appropriately! Sorry about that. Part of 0.89.99. 16-testing will be testing the new release scripts, which sign all the debs, create all the offlien bundles, tag and sign the git repo, and compute all the hashes and signs them. I'm hoping that once I get all the packages compiled and into one place, that it will be one command to do all that from the offline computer (with my GPG key password of course). This whole release process used to take hours. Now CircusPeanut got me a painless NSIS install script integrated into MSVS, and with the automatic offline-bundling, getting from compile to signed-release may be a lot faster now. Will have a 10.04 offline bundle for you tomorrow morning |
|
|
|
|
When Armory "sweeps" addresses, it is simply executing a transaction on the network. It's identical to if you had gone into your new wallet, generated a receiving address, then gone into the old app and sent all your coins to it. It creates a tx spending all your coins to the new address and sends it to the network.
Importing, will import the private keys to your new wallet, but won't touch the coins where they are. If someone else has access to those private keys, they will maintain access to them after import.
I would not be concerned about the security of address reuse -- though the privacy implications are much worse than people realize. But in the far far future where quantum computers become real (probably 30+ years from now) or the math behind ECDSA is broken, any addresses that have been reused are vulnerable (security-wise). But in the absence of these two events happening there is no security risk: in the real world, public keys are reused all the time (after all, they are intended to be persistent identities -- but in this case we're trying to avoid being persistently identifiable).
Bear in mind that all of internet security is broken in these cases, so it's not a unique problem to bitcoin. All of internet security is based on neither of those two things happening, and because neither of them are considered feasible. It just so happens that Bitcoin has accidentally protected itself from those events if you don't reuse addresses. And even if it was going to happen, we'd probably have months (in the event of a math breakthrough) or years (QC breakthrough) to upgrade the system in anticipation of those effects becoming exploitable.
|
|
|
|
I had trouble sending a transaction, as the Send! button didn't seem to respond. The first time I got a message my transaction fee was insufficient, yet when I agreed to a higher one .... nothing, no response at all. Cancelling the transaction and trying again didn't work, restarting Armory didn't work.
However, a minute later it did get trough. This was right after a new block was found. Just a few minutes before this transaction, I sent the same amount (0.1 out of 0.35) to a new address from a previously restored paper wallet, in effect sending it to itself. Only after this transaction got it's first confirmation was I able to send the second one.
Zomdifros, Perfect, send me a log file! When you click a button and it doesn't do anything, it's dumping an error message in the log file every time. Usually those are very stupid errors and quick fixes. "File"->"Export Log File" and we'll give you a 1x bounty if there's a real, actionable error in there. |
|
|
|
|
Show Posts
