Topic: Armory - Discussion Thread - page 218. (Read 521829 times)

Do you plan adding support for non-deterministic wallets? I don't think I would like to use a deterministic one. (I can't really give a reason why, I just don't like the idea.)

Also, if the client will not do block validation, please keep the option to only accept blocks through the satoshi client.

Edit: Oh, by the way, I mentioned I can't create transactions with insanely large transaction fees. Here's the error message I get when trying to send 1 satoshi with a 2200 BTC fee: "SelectCoins returned a list of size zero.  This is problematic and probably not your fault." I don't think this is a real problem, but I thought it's worth mentioning.

Using LD_PRELOAD fixed it for me.  Thanks!

btc_artist,

(1)  Did you try the LD_PRELOAD command before running Armory?  I've noticed I need that on any Ubuntu after 10.04:
  Make sure that /usr/lib/libcryptopp.so exists, or check for libcrypto++.so and use that instead.   But they should be there if you installed all the packages on the first step.

(2)  If that doesn't work, there's a different problem.  From the project directory, go into a python shell and type "import CppBlockUtils".  It will fail again, but will give you a more-descriptive error message.  If it's something like "InteratedZZ8CHashZ5Function", go back to step 1 (cryptopp has a problem).  If the error is something else, please PM me and I'll address this off-thread.   So far, I haven't seen any other errors besides the cryptopp linking at runtime (which is what the LD_PRELOAD line resolves).

I tried compiling and running Armory on Ubuntu 11.10 and got the following error.  I followed your instructions to the T, and get this:


Both of the files mentioned in the error message are in the BitcoinArmory directory (where I run python ArmoryQt.py).

It appears that there really is a one-line fix, or very close to it.  I confirmed it only saw 2/13 tx before, and sees 13/13 with the fix.   But it will have to be more thoroughly tested, so I'll throw it in with the other updates I've been working on, for the next round of testing.  I hope that Armory provides plenty of satisfaction even with the bug, until the next release.

Actually, yes!  Until now, I haven't run into any "strange" transactions that "regular" users would be encountering, but this appears to be an exception.  As I look back to the code, I see that once I hit a strange TxOut, the code skips the entire tx, marking it as "Non-standard."  In hindsight, I don't see why I can't just skip that TxOut and keep going.  When I originally wrote the code, I guess I expected the "transaction" to be non-standard or not... didn't consider the individual inputs and outputs.

Could you give me the address (just the address string, no private keys), of an address that receives coins from at least one of these transactions, but also has a few other regular transactions in the blockchain?  There may be a one-line fix to the C++ blockchain utilities, but I won't know for sure until I do some testing with a relevant address.  

I'll look into it ASAP! (PM it to me, so you don't have to advertise any extra addresses to the forum!)

Armory doesn't show my outputs from P2Pools generation transactions. Is this related to the "strange" output script that always appears first in these transactions?

The other option I saw was BundleBuilder.  That might be worth looking into as another option.  Unfortunately, I still don't have any OSX system yet.  But I'm working on it...

Actually, the offline systems have no RAM requirement at all, as long as it can run a modern OS.   Simply because there is no blockchain to hold.  It only has to hold your wallet.

I was trying to create a binary app with py2app but was not successful. It links to some python files that are not at the specified location.
I will keep trying but if someone else has more knowledge on how to do this then don't wait for me.
As for compatibility I guess it should be fine for 10.6.x and 10.7.x when compiled on 10.6.x.
If you compile a binary I can test it on both systems.

Given the ancient laptops have enough memory to keep the blockchain in RAM. :-)

That was the fundamental issue I had when developing BIP 0010 for offline/multisig transactions.  How do you verify that the what you're signing is absolutely what you intended?  I do not support a device that blindly signs txs, and that's why I went a step further with BIP 0010 and made sure that input values can be verified (without it, someone can't steal your money, but they can have all your funds emptied into your next transaction's fee).  I wanted to make sure that the signing device has the capability to understand (and verify!) what is being signed and present it to the user.  If someone wants to create a device that blindly signs it... well that's their choice, but I won't be using it.

In the case of offline computers, there might be a way for someone to use my computer to inject a USB virus which infects the offline computer, and then uses that trick my offline computer to show the same incorrect/malicious data.  That's orders of magnitude less likely than someone simply breaking into open ports on my internet connected computer, but a TPM-device would close that gap:  the TPM chip was designed without the ability to modify the software, and without the ability to pull off the private keys.  It's simply a hardware-like black-box wallet with a display. 

I believe Bitcoin needs these devices, but offline systems will do, for now.  As I found out when I sent out an email at my work about spare, ancient laptops:  everyone seems to have one they want to get rid of.  Perhaps Armory gives them a reason to keep it and use it

The problem here is that it's fine that we have a chip that does the signing without revealing the key. But I have no way of knowing if the program I'm using to create transactions that are signed is telling me the truth.
Say I want to create a transaction on my infected computer of 2 BTC to address 1Jks... and the modified program actually sends a transaction of 1000 BTC to address 1H4xor... to the TPM chip which happily signs it and my money is gone.
That's why we need to have a separate device that displays the address(es) and amount(s) from the transaction it's been sent before letting the user affirm with a button whether he approves or not.

Create a new wallet, go into "Wallet Properties" and click "Import Private Key".

How does it work exactly; does it behave like the hypothetical device I explained above?

How can I manually import a private key? This is from a paper wallet and I accept any risks.

Ok. 

I absolutely plan to have that, but not until Armory can be used without the Satoshi client running with the same wallet.  I found out yet another thing that can go wrong when you have multiple apps using the same wallet (I've got 8.2 BTC locked by the Satoshi client right now, possibly due to such issues)...

I believe I mentioned I do use Ironkeys to store my offline wallet.  It does have its own built in encryption chip along with a lot of other cool features.  I'd explain more but i'm on my phone now.  If anyone has questions about it I'd be happy to try and help.

Would just like to say, that there NEEDS to be a wallet import option in the future for Satoshi wallets.  If I am going to use this wallet solely, I don't want to have to risk not getting payments made to my older addresses.  I don't care if you make it hard to get to, it just needs to be there somewhere.

I have a variety of old addresses everywhere.  I may or may not receive donations or payments to those addresses in the future.

Examples:
- Hard-locked deepbit mining payout address.
- Operation fabulous payout address.
- Firstbits address that I use for many transactions.  Also have it posted on the forum.
- Addresses hardcoded into software for donations.

You get the idea.  Anyway, I cannot switch fully over to armory until it has wallet.dat importing, so I hope you plan to have that option!

Yubico makes these Hardware Security Modules which may be suited to the task: https://store.yubico.com/store/catalog/product_info.php?products_id=56

I believe what you're looking for is TPM Chips.  I don't know much about them, but I know a lot of laptops actually come with them.  However, you would need a customized TPM chip, specifically for accommodating multiple private keys, and ECDSA operations which are not usually part of the onboard encryption ops.  Actually, I guess you could have one master key, and use a deterministic key generation algoritm with random access.  Then the device takes the data to be signed, and a list of "key indices."  Then, generating the correct keys will just be a preprocessing step of the signing algorithm.  (btw, I believe the IronKey is a TPM-like device... all encryption/decryption happens on the device itself)

At least, the nice thing about an offline computer is that you could technically do other stuff with it.  It might be slightly less convenient for Bitcoin ops, but as long as you have it, you might as well do financial stuff on it that you would prefer to be offline, anyway.  I'm sure there's other things you can do that would be appropriate for a crappy, offline laptop

^ Interesting read all of it. I didn't find the post you linked to when I searched for the wallet encryption bug previously so that was very handy information.

It seems to me that Bitcoin is not only suffering from a lack of software developers, but also from a lack of hardware developers. The perfect savings account for me would be a small USB stick-type device, with a small screen, that with the touch of a button generates a new random key on the device. The USB stick contains no wireless communication chips - it only communicates with a host computer via USB. Whenever you want to spend money from your savings account (which is a key, or multiple keys, generated on this device) you connect the device to your computer, send a transaction to the device using some application, a message pops up on the device saying "Do you want to send X bitcoins to

" and if I press the OK button on the device it signs the transaction and sends it back to the host computer. The key never leaves the device; the device can only sign transactions. If we can implement a secure hardware device like this, the only way to steal the money on your savings account would be to steal the device itself. And if you have to steal the device itself, we can get no better security, if you ask me.

Until this type of device enters the market though, I'm going with your offline laptop-method. I've just paid for a used laptop that I'm going to be using as an offline wallet. I will pull the WiFi card out, install Ubuntu and Armory on it, and shuttle offline transactions to on a USB stick until I'm comfortable with sending my entire savings account to it. That seems like it can't get much safer either. Much like the aforementioned device, only a lot bigger and with a smell of old laptop.