Does Armory use compressed keys?

[Dabs]

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

[1715374267]

1715374267

[1715374267]

1715374267

[1715374267]

1715374267

[1715374267]

1715374267

[1715374267]

1715374267

[etotheipi]

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.

[Dabs]

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.

[etotheipi]

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.

[Dabs]

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.)

[etotheipi]

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.)

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  

[Dabs]

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  

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.

[Dabs]

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.

[Dabs]

Bump?

[Ente]

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.

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

[etotheipi]

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.

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

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.

[cp1]

Congrats!

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

[Ente]

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.

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

[Dabs]

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.

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.

[Ente]

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.

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.

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

[dserrano5]

Then we have compressed and uncompressed firstbits.

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.

[Dabs]

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.

[Ente]

Then we have compressed and uncompressed firstbits.

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.

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

[dserrano5]

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 […]

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.

[Ente]

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 […]

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.

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