Armory - Discussion Thread

[Lumpy]

Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?

I haven't implemented coin-selection yet, though it's on my list of things to do.  There is demand for it, but I have some other priorities that need to happen first.

Glad you are enjoying the program

I suppose if I really needed to I could create a new wallet, export/import the relevant private key(s) to that wallet, use the new wallet for the spend, and delete it afterwards. Aside from the obvious warning when importing duplicate keys, is there any reason this workaround wouldn't work?

[1714215857]

1714215857

[1714215857]

1714215857

[1714215857]

1714215857

[etotheipi]

Another question: Is it possible to choose inputs in Armory -- e.g. if I want to spend coins from a specific address?

I haven't implemented coin-selection yet, though it's on my list of things to do.  There is demand for it, but I have some other priorities that need to happen first.

Glad you are enjoying the program

I suppose if I really needed to I could create a new wallet, export/import the relevant private key(s) to that wallet, use the new wallet for the spend, and delete it afterwards. Aside from the obvious warning when importing duplicate keys, is there any reason this workaround wouldn't work?

I haven't done much testing with duplicate wallets, so it's kind of: "use at your own risk".  That said, the risks are mainly that it won't work, not that you'd lose coins.  But last time I played with duplicate addresses, I seem to remember that it did work...

Btw, the "Backup Individual Keys" dialog gives you a list of private keys.  The "Import Multiple Keys" dialog was designed to import that list directly (among other formats).   You can just cut-and-paste to a text file, and then close the dialog and open the import dialog.  Copy them in and delete all the keys you don't want before importing.

Just be aware that when you cut/copy text, it goes to the clipboard which is accessible from lots of different programs.  There's not a good way to protect against that, but perhaps you just do it on the offline computer, bring the new watching-only wallet back, and then execute your offline transaction.  It's a lot of work, but it's the best I can do right now.

[Red Emerald]

I installed from red emerald hombrew formula so I am not sure whIch branch it is.

My formula is pointing to the dev branch.  Using the master branch doesn't work because the mac checks are not merged into cppForSwig/Makefile.  Did you miss those by accident, etotheipi?

I also put up a pull request that makes your makefile accept a custom $DESTDIR properly and adds some stuff to help with mac development, but it might be better to just make these changes manually in your master branch.

https://github.com/etotheipi/BitcoinArmory/pull/18
https://github.com/WyseNynja/BitcoinArmory/commit/523477690d9ff9c167f85d4239f22e9126a28713

[etotheipi]

I installed from red emerald hombrew formula so I am not sure whIch branch it is.

My formula is pointing to the dev branch.  Using the master branch doesn't work because the mac checks are not merged into cppForSwig/Makefile.  Did you miss those by accident, etotheipi?

I also put up a pull request that makes your makefile accept a custom $DESTDIR properly and adds some stuff to help with mac development, but it might be better to just make these changes manually in your master branch.

https://github.com/etotheipi/BitcoinArmory/pull/18
https://github.com/WyseNynja/BitcoinArmory/commit/523477690d9ff9c167f85d4239f22e9126a28713

Yeah, sorry, I keep forgetting to look at the pull requests.  I thought the last changes I made to the Makefile were good...?  Did I never merge that to the master? 

I can't change the Makefile yet, without risk of breaking my debian package build.  It uses DESTDIR, so I need to do some testing on it before committing the change.  My guess is that it won't work right, but I guess I can always branch the makefile based on detected OS.

It doesn't need to get done right away, anyway.  No major bug fixes to master that aren't already in dev.  So you can stay on dev and everything will be fine...

[kjj]

Question about watching wallets...

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

Generating a list of (pseudo)random numbers to use as private keys is easy enough, and deriving public keys from them is also pretty simple.  But I can't figure out how to write a generator for a sequence of public keys that doesn't involve generating the list of private keys and then deleting them.

[caveden]

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

I'm not a cryptographer so perhaps someone else can answer you with more details, but from what I've read around here, the seed is an ECDSA key pair itself. A sort of "master key". So, you use the master private key for the private key series, and the master public key for the public key series. It's a nice feature of ECDSA, apparently.

[JompinDox]

Question about watching wallets...

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

There is actually a website for merchants (http://acceptbit.com/) that is based on that very idea.
That site is tailored for Electrum, but I think it should be possible in Armory too, as it uses
similar deterministic wallets.

[kjj]

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

I'm not a cryptographer so perhaps someone else can answer you with more details, but from what I've read around here, the seed is an ECDSA key pair itself. A sort of "master key". So, you use the master private key for the private key series, and the master public key for the public key series. It's a nice feature of ECDSA, apparently.

Heh, I'm no cryptographer either, that's probably my problem.  But I do have an implementation of ECDSA that I'm somewhat familiar with, and it works correctly with bitcoin keys.

I was just going through the code that I use to generate ECDSA keypairs, and the multiplication used to create the public key didn't look like it could possibly be done in that way.  The multiplication depends on every bit in the private key, and you can't back out a step if you want to change one of the private bits.  (My understanding is that if you could do that, it would totally break ECDSA's security.)

Because of that, I had assumed that Armory generated a couple thousand (or whatever) private keys, made public keys for them, and gave you the option to export just the public keys for watching elsewhere.  If it turns out that there is a pair of iterator functions that can create halves of a keypair without the other half present, I've gotta see it.

[etotheipi]

Question about watching wallets...

Someone is saying that with your deterministic wallet you can create a watching wallet that generates a sequence of public keys that matches the sequence of private keys generated elsewhere.  Is that true?  And if it is, how the heck do you do it?

Generating a list of (pseudo)random numbers to use as private keys is easy enough, and deriving public keys from them is also pretty simple.  But I can't figure out how to write a generator for a sequence of public keys that doesn't involve generating the list of private keys and then deleting them.

It's the same process as diffie-hellman key exchange: here's the simplest way to do it:

a:  Private Key (32-byte integer)
P:  Public Key (a point on the secp256k1 curve)
G:  Public "generator" for ECDSA curve (another point on the curver)

A public key is just a "multiple" of the generator of the group:

Code:

P = a*G   (ECDSA special multiplication)

Note that ECDSA multiplication cannot be reversed.  This is secure.  Let's pick another point, c, which is our chaincode.  I create a new private key:

Code:

new_a = c*a

What is the public key?

Code:

new_P = (c*a)*G = c*(a*G) = c*P

So if you have a keypair and a chaincode, you can make the publickey+chaincode the watching-only wallet, and the privatekey+chaincode is the private wallet:

Code:

a[i+1] = c*a[i]       (this is the full wallet)
P[i+1] = c*P[i]       (this is the watching-only wallet)

What Armory does has a few more details, but that's it.  Note that this is necessarily secure for the same reason that your private key isn't compromised by your public key:  ECDSA "multiplication" can't be reverse (efficiently)

[kjj]

What is the public key?

Code:

new_P = (c*a)*G = c*(a*G) = c*P

That's pretty cool.  The EC multiplication routine doesn't look like it should associate and cancel like that.

I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c.  Brainwallets come to mind.

[LoweryCBS]

"There's some security issues with being able to import arbitrary public keys for watching-only purposes"

What issues could be presented just by monitoring the balance on a public address in a watch-only wallet?

I also have a brain wallet I'd like to monitor (for which of course I have the ability to recreate the private key) and a coinbase.com wallet (for which I don't have the private key)

I'm having a lot of fun learning about creating transactions and signing messages by using Armory - thank you for all the work!

I'm new to Armory, but been watching it for a while.  I have a "Brainwallet" savings address based on a very long password. I'm having trouble figuring out how to make it work in a watching-only wallet. What I want to do is import only the PUBLIC key into Armory without exposing the private key. I originally generated the private key on a non-networked boot of Ubuntu Privacy Remix and it has never been used on a networked computer. Now it seems my current options are:

1) Boot my computer into non-networked Linux to generate the Armory wallet (but I would have to go online to download libraries and build from source).
2) Boot my computer into my normal Windows install without networking to generate the Armory wallet (but I strongly distrust Windows and the security of doing this).
3) Boot some other non-networked Windows install to generate the Armory wallet and wipe the disk (but I have no such "expendable" installations on hand).

So is there a better way to do this? With Electrum I was able to import a "junk" keypair and then replace the public key only with my savings address to accomplish the same thing. However, it looks like the Armory wallet format is not human readable.

There's some security issues with being able to import arbitrary public keys for watching-only purposes.  The best thing to do is to import it into your offline wallet and then re-make your watching only wallet.  Remove the old watching-only wallet from your online system, and re-import the new one.  It will destroy any comments you currently have in the file, but that is something I'm going to fix in the upcoming wallet format.

Alternatively, I kind of like your idea for over-writing a junk key pair.  I documented the file format, here: http://bitcoinarmory.com/index.php/armory-wallet-files

Though, to do it your way you have to start with a watching-only wallet with a junk keypair.  I would recommend make a new wallet, import a junk address, then make a watching only wallet, and remove the full wallet.  The imported key will be at the end of the file.  You have to change the first 24 bytes to be [Address20 + checksum] and change the 65+4 bytes where the public key is (the last four is also a checksum).  The checksums are just the first four bytes of the double-sha256 hash of the data. 

That's probably not what you were hoping for.  Sorry I couldn't make this easier...

[etotheipi]

What is the public key?

Code:

new_P = (c*a)*G = c*(a*G) = c*P

That's pretty cool.  The EC multiplication routine doesn't look like it should associate and cancel like that.

ECDSA "multiplication" doesn't exactly resemble the multiple that most folks are familiar with, but it's still associative.  a*G is just "adding" G to itself a times.  Then c*(a*G) is just adding P to itself c times, which was just adding G to itself a times.  So it makes sense (to me) that it's associative, but I've been doing this stuff for a long time...

I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c.  Brainwallets come to mind.

That's the basis for this thread: https://bitcointalk.org/index.php?topic=102349.0
The idea is to make the standard clients only accept certain kinds of seeds, thus requiring brainwallet users to add X bits of hard entropy to their [probably crappy] brainwallet seed.  I'm not a fan of brainwallets, but we know that folks insist on it, so we want to try to be responsible about it.

What issues could be presented just by monitoring the balance on a public address in a watch-only wallet?

You have a watching-only wallet on your system monitoring your offline coins.  Then through some feat, either through unauthorized access, or exploiting users' ignorance of how Bitcoin works, they import one of their own addresses into your wallet.  You don't know, because you don't pay attention to every address that is in your wallet at all times.  Now they offer to buy something from you for 1000 BTC, send the coins to their own address -- and it shows up in your offline wallet watcher!  Snugly, you believe that the coins have been sent, because there's 3000 confirmations by now.  You send the merchandise, and then they sweep the address.  SCAM!

What I was considering doing was the following:
(1) Create a special kind of watching-only wallet just for this, and it's balance will never be included in your master balance
(2) Allow a user to import a watching-only address if it is signed by one of their offline private keys. 

Part (2) sounds inconvenient, but it actually isn't that bad.  Most people would import their private key to the offline computer, first, anyway.  The program can sign the public key with one of your existing addresses, so that it can be imported to your online computer. 

It's just one of those things where I'm putting security above convenience.  The vast majority of users could do all this responsibly without hand-holding, but while Bitcoin is still immature, it's my integrity on the line when they screw up.  So I want to help them avoid this...

[kjj]

I guess that means that if Moore's law holds for a bit longer (heh), it will become possible to attempt rainbow tables attacks on schemes like this if they don't start with a good entropy source for a and c.  Brainwallets come to mind.

That's the basis for this thread: https://bitcointalk.org/index.php?topic=102349.0
The idea is to make the standard clients only accept certain kinds of seeds, thus requiring brainwallet users to add X bits of hard entropy to their [probably crappy] brainwallet seed.  I'm not a fan of brainwallets, but we know that folks insist on it, so we want to try to be responsible about it.

scrypt seems to be the only safe way to do it, and with terribad parameters so that it takes forever even on a decent box.  Real users won't do it often enough to be put off by it, but attackers have more resources.

Agreed on the brain wallets.

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

[etotheipi]

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

The first private key and chaincode are each 32 bytes.  Even if the chaincode was smaller, it wouldn't matter much.  The purpose of it is simply to add entropy to the iterative process.  And in Armory, the chaincode is actually calculated from the hash(PubKey) so it changes on every step.  In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose.

[kjj]

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

The first private key and chaincode are each 32 bytes.  Even if the chaincode was smaller, it wouldn't matter much.  The purpose of it is simply to add entropy to the iterative process.  And in Armory, the chaincode is actually calculated from the hash(PubKey) so it changes on every step.  In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose.

Ahh, so it is bytes.  I read your chart wrong.

Hmm, that makes your scheme (very!) slightly less secure against rainbow tables.  Yeah, I know, rainbows for this are totally impractical because you have a good initial a, but a (very!) lucky hit would reveal the rest of the sequence without the bother of having to search for the c that generates the next one.

And just to be clear to people following along at home, the level of "very lucky" that I'm talking about is probably along the lines of an attacker being saved from Death By Meteor when another meteor hits the first one at the last second, knocking it aside.  In practice, it isn't much better than brute force, as long as a is strong.  If some idiot modifies it to accept a weak a from the user, all bets are off.

[etotheipi]

The rainbow attack would be huge, and sneaky.  You are using 32 bits for the chain, so find one collision and 2 billion operations later (on average) you've got the entire rest of the sequence, forever.  I know you care enough to carefully generate high quality a and c values, but a brain wallet using this system starting with a and c derived from user input is a disaster waiting to happen.

The first private key and chaincode are each 32 bytes.  Even if the chaincode was smaller, it wouldn't matter much.  The purpose of it is simply to add entropy to the iterative process.  And in Armory, the chaincode is actually calculated from the hash(PubKey) so it changes on every step.  In the end, the chaincode only protect your privacy, not your security... I had recommendations to shorten it considerably for this reason: it doesn't need to be a full 32 bytes to accomplish its purpose.

Ahh, so it is bytes.  I read your chart wrong.

Hmm, that makes your scheme (very!) slightly less secure against rainbow tables.  Yeah, I know, rainbows for this are totally impractical because you have a good initial a, but a (very!) lucky hit would reveal the rest of the sequence without the bother of having to search for the c that generates the next one.

And just to be clear to people following along at home, the level of "very lucky" that I'm talking about is probably along the lines of an attacker being saved from Death By Meteor when another meteor hits the first one at the last second, knocking it aside.  In practice, it isn't much better than brute force, as long as a is strong.  If some idiot modifies it to accept a weak a from the user, all bets are off.

The security drawbacks of a deterministic wallet like this are basically insignificant.  A common complaint is that someone could compromise your seed, and then wait for your to make a big deposit and steal it at a later time.  The Satoshi wallet, "unsteals" itself after some time.  I think this argument is bogus:  they still have 100 addresses in your address pool to wait for some juicy coins to come in with your Satoshi wallet, and frequently there's enough there to be worth taking it right away.  There's very few situations where the deterministic wallet compromise is actually non-negligibly worse than a Satoshi-wallet compromise.  You're screwed in both cases.

On the other hand, the security benefits of the deterministic wallets are so dramatic, they far outweight anything else (and hence why the Satoshi client wants to switch to deterministic wallets in a future version).

-- One-time backup -- many more users are going to accidentally delete their wallet or have a failing disk drive, than those who will suffer because the deterministic nature of the wallet enabled a very unique attack on their already-compromised wallet.  Backup your wallet one freakin' time, ever.  Generate milllions of addresses, you're always protected.  This is the biggest fear users have with the Satoshi wallet, and regular, persistent backup solution will fail for the average user... they may keep it up for a whlie, but they swap their backup drive, and forget to set-up their backup system again, or just too lazy.  Nay -- print off your wallet once, put it in a safe-deposit box, and live merrily knowing that you won't lose them.

-- Offline wallets -- you don't need me to tell you the benefits of it.  You already know.  The ability to store the private seed offline and never touch the internet is why the attacker won't get the seed to compromise you. 

[kjj]

The security drawbacks of a deterministic wallet like this are basically insignificant.  A common complaint is that someone could compromise your seed, and then wait for your to make a big deposit and steal it at a later time.  The Satoshi wallet, "unsteals" itself after some time.  I think this argument is bogus:  they still have 100 addresses in your address pool to wait for some juicy coins to come in with your Satoshi wallet, and frequently there's enough there to be worth taking it right away.  There's very few situations where the deterministic wallet compromise is actually non-negligibly worse than a Satoshi-wallet compromise.  You're screwed in both cases.

On the other hand, the security benefits of the deterministic wallets are so dramatic, they far outweight anything else (and hence why the Satoshi client wants to switch to deterministic wallets in a future version).

-- One-time backup -- many more users are going to accidentally delete their wallet or have a failing disk drive, than those who will suffer because the deterministic nature of the wallet enabled a very unique attack on their already-compromised wallet.  Backup your wallet one freakin' time, ever.  Generate milllions of addresses, you're always protected.  This is the biggest fear users have with the Satoshi wallet, and regular, persistent backup solution will fail for the average user... they may keep it up for a whlie, but they swap their backup drive, and forget to set-up their backup system again, or just too lazy.  Nay -- print off your wallet once, put it in a safe-deposit box, and live merrily knowing that you won't lose them.

-- Offline wallets -- you don't need me to tell you the benefits of it.  You already know.  The ability to store the private seed offline and never touch the internet is why the attacker won't get the seed to compromise you. 

I'm in total agreement.  I was skeptical of deterministic wallets early on, because I know that they are full of traps waiting to catch the unwary.  But done right, the difference in security is negligible at worst (and with a huge upside 99.9% of the time).  And the negligible security loss is only in the amount of work the attacker has to do after he's already done the impossible.  Seems like a good trade.

However, for my personal deep safe wallet, I still prefer that my keys be unrelated and totally random (well, as random as /dev/random).  Keys generated offline using known code (using something like a live distro that predates bitcoin, heh), encrypted and burned to M*Disc DVDs and printed on archival paper, addresses burned to different DVDs and also printed.  Copies of the encrypted private keys stored in different cities.  Easy to send money to a wallet like that, but very difficult to get money out, which fits my needs very well (but is not practical for most people or most uses).

The sad thing is that for every person that thinks that I went overboard, at least one other person will think that I wasn't careful enough.

[ErebusBat]

Cross posting this here as there may be some interest:

I made a fork/addition to bitaddress.org that allows easy printing of blockchain.info wallet exports.  If this is interesting/useful to you then you can read more here:

https://bitcointalk.org/index.php?topic=105066.0

[etotheipi]

Btw, I finally got around to posting a version with windows networking issues fixed:

https://github.com/etotheipi/BitcoinArmory/downloads

It appears to affect a very few number of users.  If you're not having a problem, there's no reason to upgrade to 0.82.3 (though, I might have fixed a bitcoin: URL-handling issue, too... I don't remember if that was fixed in the last version or this one)

[Garr255]

I just had to delete my settings after upgrading to the version before this one. Thanks for the update, regardless