Topic: Does Armory use compressed keys? (Read 8954 times)

I tried today again to import a compressed private key, but same error. After your last reply i thought something must have changed, but after i gone through the changelogs again, i found nothing new?!? So the answer to my question


Could be "not yet." or did i miss something?
Its on your to-do-list, right?

ahh ok.. just tried to import an private key (export with bitcoin-core-0.15.1) in Armory-0.96.399.

but https://picload.org/view/dddgggga/apk.png.html

Googled and found this Thread..

wow necro... go through the changelogs.

Nothing new?

Thanks for clearing this up.
Too bad..

New wallet format is not yet available in Armory, so sadly not. Nope, no idea when.

I just bumped into this old thread when I tried to import a (compressed, for sure) privkey
from multibit to armory. Is it really possible that armory *still* does not support importing
compressed private keys?

That's good to know. I check in here occasionally to see what're the latest developments. Thanks for the good work you put into this!

Unfortunately not.  Compressed and uncompressed keys have different addresses.  Even if you get the uncompressed version from Bitcoin Core and import it into Armory, it will show a different address and no balance. 

As mentioned above, the new wallet format is coming soon and Armory will finally understand compressed keys and know what to do with them.

I want to import some private keys from the Bitcoin-Qt. I used the dumpprivkey command to get the keys, but it seems like it can't be imported to Armory because these are compressed keys.

Is there any way to dump non-compresses keys from Qt so that I can use the same addresses on Armory?

Yes. I usually use the previous 2 or 3 generations of older software while they still work on the latest hardware (or because I tend to get old hardware for free or very cheap.)

Good to know that compressed keys will be supported. I think it's way overdue.

XP? *shudders*
:-P

Compressed keys will be supported with the new (BIP0032 compatible) wallet format.
That is one of the next bigger projects, so it'll be here eventually. As I understand it.

Ente

Updates? Also, since MS quit on XP, does that mean you (or Goat Pig) will stop making it work for XP?

(Believe it or not, I still use XP today.)

We're trying hard to get these multi-sig features ironed out, tested, etc.  Once we do that, I'll finish the new wallets, which are like 80% done already.  Then there will be proper compressed key support.

So what's the status on Armory supporting compressed public keys?

I have a "compressed private key" that I'd really like to sweep into my Armory wallet.

I'm serious, but I'm wrong ;-)
Yes, thinking about it, what's in the blockchain is safe. Or something.

So, when eventually all programs know both formats, and may even watch both formats for a given privkey, all is fine.

Ente

Ok now I'm sure you're serious . A firstbits service doesn't need to look at this, it looks at the address and nothing else. Two different addresses can't map to the same fb, period.

As long as all programs recognize both compressed and uncompressed adresses, it's all good.
If, for some reason, a firstbits service only looks through the compressed or uncompressed adresses, or converts all of them to compressed or uncompressed adresses, people are mapping different adresses to the same firstbits.
This probably won't happen.
But then, I tried to import a compressed adress in Armory, didn't work. So I converted it to uncompressed, Armory importet that. But didn't show the balance after rescanning the blockchain..

I now expect unexpected behavior at every corner. Importing/exporting between clients? Blockexplorer? Firstbits? Try to explain that sht to a non-techie..

Ente

Well, firstbits is not really part of the bitcoin protocol. It's just, what are the first parts of your bitcoin address, which is first-come-first-serve in the blockchain or when your address first appears.

Don't give the firstbigs address UNTIL you have seen your FULL address being used.

I use compressed keys almost exclusively now. No reason for me to use any uncompressed keys, except old addresses that are still getting coins sent to them.

Not sure if serious. firstbits is a mapping to an address, whether it comes from a compressed key or not. My 12345 happens to be an uncompressed one—another address that starts with 12345 and comes from a compressed key will have different firstbits due to the need to disambiguate the prefix, not because of the underlying key.

I really hate that whole topic. One of the worst things that happened to Bitcoin. Compressed and uncompressed vanity keys? Really? Then we have compressed and uncompressed firstbits. And with that, there will eventually be lost bitcoins.
I already can't import my Android keys to Armory because of the whole compressed vs uncompressed desaster.
And no, even if I convert between compressed and uncompressed, it doesn't work. Even though they have the same privkey.

/rant

Ente

They are actually from vanitygen modified to compute compressed keys.

All my 1Dabs, 1Poker, 1Lotto vanity addresses are from vanitygen, and they are all compressed.

Congratulations, Alan! :-)
You surely must be a happy man nowadays!

Oh, and just in case: Don't lose the *real* priorities out of sight, right? ;-)

Cheers!

Ente

Congrats!

Will the new wallet format allow importing watching-only addresses created from outside armory?

Armory wallets have not supported compressed keys yet.  They would've by now if I had been able to finish RAM-reduction and gotten around to the new wallet format (that would've supported a lot more exotic things than compressed keys).

To be clear -- I could probably "support" compressed keys "quickly."  They're not complicated and all the pieces I need are waiting in my project for me.  But the wallet code is excessively, thoroughly tested.  That wallet code has hardly been touched in over a year because I'm so careful about making any changes that might compromise the reliability of the algorithms.  I'm concerned about something like getting an address, sending coins to it, and then realizing that it actually sent it to hash(compressed-pub-key-plus-32-bytes-zeros), which would not be spendable.  These are things I have to be extremely conservative about, and while I could implement something that probably works, very quickly, the testing is 80% of the work.

I have to get RAM reduction finished with the fragmented backups.  Then I'm getting married and going on my honeymoon   After that, I'll get a chance to work on the new wallets.

It's compressed? Where did it come from? Probably not self-computed via vanitygen, as I imported a few from there to Armory with no probs.

/freebump

Ente

Bump?

Bump. Just a friendly reminder.

1. Compressed Keys (available since qt version 6.)
2. Aesthetics. (font, qr, etc)

I'm after functionality more than looks, so the last one can wait. I want to import my vanity address but it's compressed. hehe.

1. QR Codes, white border quiet zone.
2. (optional) Let user choose error correction level? Or is it already set to high? Low or none actually works fine particularly if the user takes care of his backup, or if it's a screen zoom, there is no need for error correction, so it can be set to low. I just found out there is no none, Low 7% is the lowest. But your typical Armory user is paranoid enough to want High, even if they don't need it.

You never know if the user will just end up printing the QR code to paper for some reason.

I don't think my app is failing to read the QR code, I just noticed the absence of the quiet zone. Most apps are fault tolerant or can sort of figure it out, but you know, I've noticed magazines and newsletters and posters with no quiet zones and black backgrounds.

Armory appears on my system as "grey" because I'm on default "classic" theme. I keep my desktop background plain all black.

As for font, for the Armory app itself, I prefer 8 point Arial. For showing addresses, I prefer a fixed width font, maybe Consolas, or Terminal or Courier.

I've been using bitcoin-qt this whole time, so adding Armory on top of it isn't much of an issue for me. And then realizing that the offline Armory doesn't need anything else except the OS and USB drivers to recognize flash drives. I'ma see if I have an uber old laptop with Win98 and if it will work there.

Good questions/observations.

I had meant to make the font configurable, but forgot to implement it.

I also did not think to draw a border around the QR codes, but I totally should have.  I basically just create a QR matrix and draw black squares for every cell that is 1.  I guess I should lay down a white square that is (N+2)x(N+2) before drawing the squares.  Good call!  Is one of your apps failing to read a QR code?  Or is it just aesthetics?  Are you using a dark background theme?

But you might have to remind me of these things later.  I have a few other priorities at the moment  

Ok. Confirming what you just said. Imported keys also work as long as they are uncompressed. While I'm on this thread, I might as well ask, Can I change the font used by the the client? It just looks different and doesn't seem to follow my Windows settings.

Also, your QR codes, even when expanded to fill the screen, does not have the required quiet zone. (White border around the entire code.)

Armory does not understand those types of keys. They just don't fit into the wallet format and armory does not know how to compute the addresses for them.  however, if you use on compressed keys, you can import them into the offline computer and the public wallet that you export will have those public keys.

Ok, while we're waiting for the new wallet format, can I import compressed private keys? For example, from my regular bitcoin-qt wallet I extract the private key (and public key). Or I create a compressed private key using bitaddress.org's feature.

Also, if I make a watching-wallet from the offline computer, will the online computer have the corresponding public key of the private key I imported?

The question basically boils down to being able to use keys other than what Armory determines from it's deterministic function.

I'm going to try and see if that will work.

*edit* I just tried it. Can't use compressed keys at all. It seems to be working fine with uncompressed keys. I'm still testing to see if the watching wallet can use imported keys not generated by Armory.

Unfortunately, no.  I had thoroughly tested the wallet file and it was in use by lots of people, before I'd even heard of compressed public keys.  I didn't want to take any risks with the wallet file to support them.  Instead, I'm making a new wallet file format that supports a whole host of new features, and compressed public keys are one of them.  Though, that has been put on hold while I deal with the resource usage.   Hopefully the new wallets will become "real" in a month or two.

Quick question:

Does Armory use compressed keys? I mean, those private keys that begin with letter L or letter K, instead of number 5.

Example:
Uncompressed is 5K6CTWYg7M9doJTUWDfeKYjJvLRgt7g6zYhKEHA2zEdrnk7v3ES
Compressed is L2qwa1Qod1w7RN3rPxuZis3k6Qjy2cTbSztwTcJsmdBgkhiHBHDt