Armory - Discussion Thread

[etotheipi]

I have been cross-compiling it for Pi on one of my Ubuntu VMs. 

I compiled it using the pi itself.  That is very slow , but less hassle than cross compiling.

Depends what you mean by "less hassle".  Doing it my way requires more "down payment" to get it setup, but then it's trivial to compile new versions.  Once I push my latest changes to the repo, I can just switch to the RPi directory, pull, and run "make CXX=<pathtocxcompile-g++>".  3 minutes later I have an RPi release

In fact, I think I don't even have to switch directories!  But I do it anyway to be clean.

[TierNolan]

Depends what you mean by "less hassle".  Doing it my way requires more "down payment" to get it setup, but then it's trivial to compile new versions.  Once I push my latest changes to the repo, I can just switch to the RPi directory, pull, and run "make CXX=<pathtocxcompile-g++>".  3 minutes later I have an RPi release

In fact, I think I don't even have to switch directories!  But I do it anyway to be clean.

Heh, true.  I guess it is the difference between a user and a developer.  

Being able to download the pre-compiled files is easier for everyone.

For multi-sig, are you planning to have watch only wallet capability?  

This would be where you could have 3 watching only wallets installed and it would tell you that a multi-sig payment could be redeemed by 2 of 3 of them.

You could also allow creation of a spending transaction that each private key owner could sign in turn.

This is better for "boards" that have N of M spending requirements.  Each member would have a watching-only wallet for all keys associated with the cold store and one set of private keys.

You could also create 2 level shamir sharing.  For example, you could have 2 of 3 sharing, but each share is then split up into 2 of 3 as well.  This means that each share is protected against loss too by sharing.

[etotheipi]

For multi-sig, are you planning to have watch only wallet capability? 

This would be where you could have 3 watching only wallets installed and it would tell you that a multi-sig payment could be redeemed by 2 of 3 of them.

You could also allow creation of a spending transaction that each private key owner could sign in turn.

This is better for "boards" that have N of M spending requirements.  Each member would have a watching-only wallet for all keys associated with the cold store and one set of private keys.

You could also create 2 level shamir sharing.  For example, you could have 2 of 3 sharing, but each share is then split up into 2 of 3 as well.  This means that each share is protected against loss too by sharing.

This is already supported by the lockboxes!  All parties in a lockbox can be offline keys, created separately and independently.   Each party individually manages their own wallet holding that key, including all the regular methods we have backups... yes you can do a 2-of-4 lockbox between 4 parties, and each party can do a 3-of-5 fragmented backup of their individual wallets (which hold the key).

Speaking of that, we're working on multisig lockboxes on the "devel" branch -- anyone can check it out and play with it.  It's actually looking really good.  Got P2SH working, so you should be able to go above 3-of-3 on mainnet now... but of course I don't recommend using any money you can't afford to lose (yet)!

The lockboxes and all the data passed between devices/parties assumes that all keys are offline, and thus always contain all information needed to sign offline.  The downside to this is that all these message formats have changed, even for regular offline transactions, so all online & offline devices will need to be updated to use this.  But once you do, it does work! 

Will have the last couple pieces of it implemented soon and put out an experimental build to get people playing with.

[TierNolan]

This is already supported by the lockboxes!  All parties in a lockbox can be offline keys, created separately and independently.   Each party individually manages their own wallet holding that key, including all the regular methods we have backups... yes you can do a 2-of-4 lockbox between 4 parties, and each party can do a 3-of-5 fragmented backup of their individual wallets (which hold the key).

Cool, I need to do some forum searching.

[etotheipi]

This is already supported by the lockboxes!  All parties in a lockbox can be offline keys, created separately and independently.   Each party individually manages their own wallet holding that key, including all the regular methods we have backups... yes you can do a 2-of-4 lockbox between 4 parties, and each party can do a 3-of-5 fragmented backup of their individual wallets (which hold the key).

Cool, I need to do some forum searching.

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

[RoadStress]

It is not necessary to upgrade any offline computers just to check wallet consistency.

How do we do that from the Armory menus? Or just restart Armory?

I have upgraded to 0.91.1 and it checked for my wallet consistency when i started it. Guess i don't have to do anything else.

[etotheipi]

It is not necessary to upgrade any offline computers just to check wallet consistency.

How do we do that from the Armory menus? Or just restart Armory?

I have upgraded to 0.91.1 and it checked for my wallet consistency when i started it. Guess i don't have to do anything else.

Notice it says not necessary   If all your hot wallets and watching-only wallets have been loaded on 0.91 or 0.91.1 before, and no notification popped up, no further action is required.  I would guess that 99%+ users will pass this check without issue.  And of those cases with consistency issues, the recovery tool can fix most of them.

Will post more information about this soon.   Working on getting an announcement page up and distributing notifications to older versions.

[RoadStress]

It is not necessary to upgrade any offline computers just to check wallet consistency.

How do we do that from the Armory menus? Or just restart Armory?

I have upgraded to 0.91.1 and it checked for my wallet consistency when i started it. Guess i don't have to do anything else.

Notice it says not necessary   If all your hot wallets and watching-only wallets have been loaded on 0.91 or 0.91.1 before, and no notification popped up, no further action is required.  I would guess that 99%+ users will pass this check without issue.  And of those cases with consistency issues, the recovery tool can fix most of them.

Will post more information about this soon.   Working on getting an announcement page up and distributing notifications to older versions.

Somehow I understood that an upgrade isn't necessary, but we still needed to check the wallet consistency. I got it now. Thank you.

[bitpop]

Basically there's an attack they can't talk about yet, just get updated. The attack makes armory generate addresses from the virus.

[superbit]

What am I doing wrong to verify the file?

It looks like the key file is right?

[goatpig]

Which key are you verifying against? You should have Alan's offline signing public key in your key ring before doing this.

[superbit]

Which key are you verifying against? You should have Alan's offline signing public key in your key ring before doing this.

The one hosted at MIT?  I do and it is marked as trusted.

[goatpig]

He has 2 of these. One that is "online", used for email signing and encryption, one marked as "offline" used for release signing. Also you could try to verify the bitcoin signature.

[marcus_of_augustus]

Basically there's an attack they can't talk about yet, just get updated. The attack makes armory generate addresses from the virus.

 

[superbit]

He has 2 of these. One that is "online", used for email signing and encryption, one marked as "offline" used for release signing. Also you could try to verify the bitcoin signature.

How would I get an "offline" key?

[bitpop]

Basically there's an attack they can't talk about yet, just get updated. The attack makes armory generate addresses from the virus.

 

This also means new best practice is sending to offline wallet using an address created on there. Previously I got an address from the watch only copy.

[bitpop]

He has 2 of these. One that is "online", used for email signing and encryption, one marked as "offline" used for release signing. Also you could try to verify the bitcoin signature.

How would I get an "offline" key?

http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x4AB16AEA98832223

[flipperfish]

This also means new best practice is sending to offline wallet using an address created on there. Previously I got an address from the watch only copy.

Can you explain this a little further? AFAIK, the addresses generated on the offline wallet and the watch only copy are the same? Wouldn't be of much use otherwise...

[bitpop]

This also means new best practice is sending to offline wallet using an address created on there. Previously I got an address from the watch only copy.

Can you explain this a little further? AFAIK, the addresses generated on the offline wallet and the watch only copy are the same? Wouldn't be of much use otherwise...

A virus can compromise your watch only copy to generate addresses that aren't yours. This completely bypasses all security.

You could generate it then glance at the cold storage copy to make sure it's in the list. You may have to generate extra ones to get the number of addresses the same.

[jl2012]

This also means new best practice is sending to offline wallet using an address created on there. Previously I got an address from the watch only copy.

Can you explain this a little further? AFAIK, the addresses generated on the offline wallet and the watch only copy are the same? Wouldn't be of much use otherwise...

A virus can compromise your watch only copy to generate addresses that aren't yours. This completely bypasses all security.

You could generate it then glance at the cold storage copy to make sure it's in the list. You may have to generate extra ones to get the number of addresses the same.

Is that a malware, or a bug in Armory?