Armory - Discussion Thread

[etotheipi]

...Doesn't really help me due to the Python 64bit issues mentioned above (I'm in the same boat), but just letting you know anyway

I just attempted to do a 32-bit python installation along with twisted and pyqt, on a Win7-64 system.  Surprisingly, it compiled in Win32 mode, but Armory crashes as soon as it starts.   I was hoping to make a Win7_64_Python32 build, but that looks like a pipe dream at the moment.

When I finally get real binaries built, this will go away (as all the necessary DLLs will be packaged with the binary).  One day...

[cypherdoc]

i imported 5 private keys from Multibit into Armory.  1 of the 5 should've had .0001 btc in it.  does Armory read that small of an amount?

also, when 2 clients as different as Multibit and Armory have the same keys, can you spend the amounts on those keys from either client?

[etotheipi]

i imported 5 private keys from Multibit into Armory.  1 of the 5 should've had .0001 btc in it.  does Armory read that small of an amount?
client?

Cypherdoc,

Be careful running two clients that use the same keys.  Weird things can happen.  Armory should be robust to most of it, but I'll be interested to hear if that's really true.   Satoshi client has a habit of getting confused, and locking inputs based on transactions that aren't actually valid (because you sent a tx, and then satoshi client tried to spend the same outputs before it got the update, locked the outputs, and then gets stuck).  I don't know how multibit is, in this regard...

If that 0.0001 is in the blockchain, Armory should find it.  However, in some places where values are displayed, the values might be truncated (but that should be big enough...).  Also, sometimes you just have to close the wallet properties and reopen it, in order for the data to be displayed correctly.

The thing to do after importing, is to go into the wallet properties and double-click on the address.  It will show you all the transactions that address has ever seen.  If it shows nothing, then check blockexplorer or blockchain.info for that address.   I've never seen any of those online services be out of sync with what Armory says.  But that doesn't mean it can't happen... (please let me know if it is)

also, when 2 clients as different as Multibit and Armory have the same keys, can you spend the amounts on those keys from either client?

I highly recommend that you wait for the other client to receive the transactions of the first client, before attempting to do more transactions.  They should have no problem, as long as you give them time to have the latest blockchain data before constructing new transactions in either one.

[ctoon6]

Now that you are considering/planing to work on this semi full time, how likely is an arm version for the raspberry pi for offline signing (I can't begin to express how perfect it is for this application).

Some other cool features would be making the full client act as a kind of server or something that light devices could connect to. obviously you would generate asymmetric keys ahead of time to make sure it is all nice and secure.

Overall this looks very promising, and great work.

[etotheipi]

Now that you are considering/planing to work on this semi full time, how likely is an arm version for the raspberry pi for offline signing (I can't begin to express how perfect it is for this application).

Some other cool features would be making the full client act as a kind of server or something that light devices could connect to. obviously you would generate asymmetric keys ahead of time to make sure it is all nice and secure.

Overall this looks very promising, and great work.

ctoon,

I totally agree that ARM would be a perfect platform for offline signing device.  But I don't know a thing about it.  I don't have a clue where to even start with that!  I have enough other things to do on Armory, I think I might leave porting it to ARM to someone else more experienced.  Though, I'll happily provide guidance for how to read/write wallet files, etc.  Perhaps we can emulate a TPM device...

Slightly related, I think once I get a JSON-RPC interface hooked up, there will be a lot of great options for interacting with Armory from other devices or lightweight programs.    Based on feedback, I think JSON-RPC will be my first priority after fixing the clean-shutdown-in-windows issue, and pulling the RAM req'ts down to Earth.  It seems like webservers have a lot to gain from a nice interface to watching-only wallets, and will typically have the resources to hold the blockchain in memory (at least for now) so it would be damned fast for blockchain operations, too.

On that note, I have taken recommendations from earlier in the thread and started looking at mmap() for reducing RAM req'ts.  It's very impressive:  on my linux VM with 1 GB of RAM, it works (using only a couple hundred MB) but it's a little slow.  On my main box with 16 GB of RAM, it not only works, but it caches the whole blockchain and runs just as fast as the full-RAM version!   It appears to be the best of both worlds... but I've only tested it on linux with mmap(), haven't tried the windows equivalent, yet..

[bitclown]

i imported 5 private keys from Multibit into Armory.  1 of the 5 should've had .0001 btc in it.  does Armory read that small of an amount?

Does it show up after restarting Armory? I've had problems with Armory only scanning the first address when importing multiple keys to the same wallet.

[cypherdoc]

i imported 5 private keys from Multibit into Armory.  1 of the 5 should've had .0001 btc in it.  does Armory read that small of an amount?

Does it show up after restarting Armory? I've had problems with Armory only scanning the first address when importing multiple keys to the same wallet.

i just reopened Armory and there it was!  0.00002962 in my imported key.  now granted, this was the first of 5 keys i imported so i can't comment yet on order of action.

[etotheipi]

mila,

I put some thought into how Armory could be used for a webserver application, and I realized that with just a couple lines of python, you can generate addresses no problem on your webserver.  I added a couple convenience functions and committed them to the master branch of Armory. Here's what you do:

(1) Load Armory on your computer.  
(2) Create a regular wallet.  
(3) In Wallet Properties, "Create Watching-Only Copy"
(4) Upload watchonly wallet to webserver
(5) Setup webserver to load wallet and call wlt.getNextUnusedAddress() for each request
(6) Sit at home with the full wallet and watch/confirm/send transactions while the webserver does the work!

Demonstration code to see how to access/manipulate the wallet from a python script:

Code:

from armoryengine import *

wlt = PyBtcWallet().readWalletFile('/home/server/web_server.watchonly.wallet')
wlt.setAddrPoolSize(1000)

# Quick printing of addr info, and shows how to access various props of the addr
def pprint(addr):
   print 'The new address: '
   print '   Hash160:  ', binary_to_hex(addr.getAddr160(), BIGENDIAN)
   print '   Base58:   ', addr.getAddrStr()
   print '   Index:    ', addr.chainIndex
   print '   Have Pub: ', addr.hasPubKey()
   print '   Have Priv:', addr.hasPrivKey()
   
print 'Get the next unused address...'
addr = wlt.getNextUnusedAddress()
pprint(addr)

print 'Generating 10 more addresses:'
for i in range(10):
   addr = wlt.getNextUnusedAddress()
   print '\t', addr.chainIndex, '\t', addr.getAddrStr()

print 'Get addr #15'
a160 = wlt.getAddress160ByChainIndex(15)
print binary_to_hex(a160, BIGENDIAN)
addr = wlt.addrMap[a160]
pprint(addr)

print 'This wallet has %d addresses computed' % wlt.getHighestComputedIndex()
print 'Addresses used: %d ' % wlt.getHighestUsedIndex()

Here's the output on a watching-only wallet (this is actually the output of the second time I ran it):

Code:

Get the next unused address...
The new address: 
   Hash160:   728b0b8cc930cb4756328e743b7b2e7dde93a35f
   Base58:    mpEeSrEr3EiyCMRskT5VrELkY8X9ZwT3BV
   Index:     11
   Have Pub:  True
   Have Priv: False

Generating 10 more addresses:
	12 	mrhzBHQcn7jmhvpbcfW6ebiAFEm9qZF6AL
	13 	moPM3KPygygsWzvUHfeDsmPChL5xWycc5y
	14 	n4ZtG47TNMifGJ57msGAs8ZD1HeVqSqRyx
	15 	mw3cxXKCaKitV8w1wBRrpjQNWu4od5Nd5H
	16 	n1UGPkUgUXiwsotzfpAezpy6NkRg1fGMv5
	17 	muFPi3pAw7Rbb9aGc9UJPX9m6JT1VGHf9J
	18 	n3TRNc86Vmi2EygvjeMsAXXAYhPygR2sQK
	19 	mikSy5FjeSPVBSaXDs8ihMKrMgZsoohsjz
	20 	mwb8h2PJvGGGQTA7QBgvPVrWowQZi43ZD2
	21 	mpBFZ1H6AcRqHUZ7ETz1Xh1PqaPiMvdQDM

Get addr #15
c42ea65330263fd9c02fe5ca2e3a1c44dca356aa
The new address: 
   Hash160:   c42ea65330263fd9c02fe5ca2e3a1c44dca356aa
   Base58:    mw3cxXKCaKitV8w1wBRrpjQNWu4od5Nd5H
   Index:     15
   Have Pub:  True
   Have Priv: False

This wallet has 1021 addresses computed
Addresses used: 21 

Your webserver can run blissfully ignorant about what is actually going on with the wallet, it just gives out a new address on every request.  You can sit at home on your computer with Armory running and the full wallet there, with full control.  But someone who compromises the webserver will not get anything!

If you want the webserver to track incoming transactions, it will require loading the blockchain and checking for new blocks periodically.  It's not a lot of code, but I'll save it for later if you are interested.

One other thing:  Armory uses the crypto++ library, which is not particularly fast at ECDSA operations (and my key generation algorithm is kinda slow, which is why I'll be upgrading to a new one, soon).   My [decent] system can generate about 200 addr/sec.  So this script takes a few sec to run.  But all keys are stored in the wallet, so they don't have to be recomputed when you restart the script.

[Red Emerald]

How does the main wallet know when a watching wallet generates new addresses?

Say 1000 customer's come to the site and each get a new address.  Do I have to run something on the main wallet that makes it generate (the same) 1000 addresses, or is this done automatically somehow?

[etotheipi]

How does the main wallet know when a watching wallet generates new addresses?

Say 1000 customer's come to the site and each get a new address.  Do I have to run something on the main wallet that makes it generate (the same) 1000 addresses, or is this done automatically somehow?

The main wallet is always looking ahead 100 addresses.  As soon as a transaction appears in the blockchain that contains an address not officially generated yet, the wallet will then extend the pool and continue watching.  As long there are no stretches of consecutive unused keys greater than 100 in length, the other wallet will automatically follow along.  100 is just the default, and can be manually increased by using "wlt.setAddrPoolSize(10000)", if your use case results in [potentially] much longer strings of usued keys.  Finally, if you know something like this happened, you can manually tell the wallet to extend the keypool (just not through the GUI, yet).

[Red Emerald]

How does the main wallet know when a watching wallet generates new addresses?

Say 1000 customer's come to the site and each get a new address.  Do I have to run something on the main wallet that makes it generate (the same) 1000 addresses, or is this done automatically somehow?

The main wallet is always looking ahead 100 addresses.  As soon as a transaction appears in the blockchain that contains an address not officially generated yet, the wallet will then extend the pool and continue watching.  As long there are no stretches of consecutive unused keys greater than 100 in length, the other wallet will automatically follow along.  100 is just the default, and can be manually increased by using "wlt.setAddrPoolSize(10000)", if your use case results in [potentially] much longer strings of usued keys.  Finally, if you know something like this happened, you can manually tell the wallet to extend the keypool (just not through the GUI, yet).

Cool. I figured it was something like this.

Now I just need the spare RAM

[etotheipi]

UPDATE:  FULL WINDOWS BINARIES (Please help test!)

Thanks to fornit, I finally figured out a good way to shutdown Armory in Windows, so I can finally release binaries for Windows!   You can download a testing copy of version 0.55-alpha-RC1 from the following link:

https://github.com/downloads/etotheipi/BitcoinArmory/Armory_64bit_0.55-alpha-RC1.zip

There are other new features, too, and if you'd like to try them out on Linux before the official release (hopefully soon), then you'll have to switch to the ecdsacalc branch in order to get the latest. (the windows binary has all the new features in it)


Additional features:  I've also been working hard on a new feature that is almost complete!  It's an ECDSA calculator built into Armory, including the ability to sign messages with one of your private keys, as a way to provide a signed statement that cannot be manipulated by a man-in-the-middle, such as "I sent you 20 BTC from this address, please send the merchandise to 1234 Killian St..."  The signature confirms that only the owner of the specified address could've made that statement.

There is also a raw ECDSA calculator, for doing basic calculations on the elliptic curve used by Bitcoin (secp256k1).  But there's a bug in my wrapping of Crypto++ library calls which prevents it from computing correct answers.  Hopefully by the time everything else is tested, I will have that bug fixed and it will be useful!

Changelog:
-- Fixed the Windows shutdown bug
-- Added "--noblockchain" option to skip using the blockchain, especially useful if you just want to manage wallets or use the calculator
-- Added ECDSA "signature blocks" through the "Tools-->Calculator" dialog.
-- Also use the ECDSA calculator to quickly convert between hash160, base58 addresses, compute public keys from private keys, and decode different private key formats!

And finally, while I know it's silly to verify the integrity of a binary using the binary itself, this is solely for demonstration purposes:

Code:

-----BEGIN-SIGNATURE-BLOCK--------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:   "On 2012-Feb-29 12:55am EST, I, e"
           "totheipi, released Armory versio"
           "n 0.55-alpha-RC1.  The Windows 6"
           "4-bit zip file has the following"
           " md5 hash:  e8914c803daa31f2bebc"
           "dab20738e7ad"
PublicKey:  04
            11d14f8498d11c33d08b0cd7b312fb2e
            6fc9aebd479f8e9ab62b5333b2c395c5
            f7437cab5633b5894c4a5c2132716bc3
            6b7571cbe492a7222442b75df75b9a84
Signature:  9474474dffba5a49338c9df3f6a24e14
            6757d038a116893f4442baf2ca14fe20
            938147a818e1d1fca45a2bc334998aae
            11bae363e525aa9301f3f915d81fd298
-----END-SIGNATURE-BLOCK----------------------------

Go into Tools-->Calculator and click on the "Import Signature Block" button at the bottom.  Copy and paste the above textblock into the window and hit "OK."  It will show you the address (my donation address), its public key, and the validity of the signature!  

[RoloTonyBrownTown]

Brilliant, I assume this'll fix the Python 64/32bit issues on Windows?

I'll try it tonight

[RoloTonyBrownTown]

Wow, that's a lot of DLL's

Good news, it loads on my machine    That's about all I have time to test right now, but so far so good

[fornit]

works on win7 64bit here. shuts down properly, too. the new calculator seems to have a bug tho. when you click "get keys from wallet" nothing happens except the button greys out. doesnt matter if i have one or two wallets.
otherwise everything seems to work. everything i looked at in 20min anyway.

[etotheipi]

Wow, that's a lot of DLL's

Good news, it loads on my machine   That's about all I have time to test right now, but so far so good

Yeah, py2exe just packages up everything into one directory.  I will eventually create a real installer/uninstaller for it, and it won't matter.  Glad to hear it works, so far!  Please let me know if you find any quirks with it.

works on win7 64bit here. shuts down properly, too. the new calculator seems to have a bug tho. when you click "get keys from wallet" nothing happens except the button greys out. doesnt matter if i have one or two wallets.
otherwise everything seems to work. everything i looked at in 20min anyway.

fornit,

Thanks for identifying something that should be clearer:  that button doesn't do what you think it does.  When you enter an address or public key into the calculator that matches an address in your wallet, then that button should un-grey itself (along with displaying an appropriate message), clicking it will allow you to unlock your wallet and fetch the private key.  The use case is this:

(1) I just paid 20,000 BTC to a seller for something super-expensive, one of the funding addresses was 1ArmoryXcf...
(2) Seller requests a delivery address, signed by address 1ArmoryXcf
(3) Copy address into the calculator and "Get Wallet Keys" to fetch the private key for 1ArmoryXcf
(4) Now write your message & postal address into the box and "Sign"
(5) Copy the signature block into an email to seller
(6) Seller plugs signature block into their calculator which will check that Address~PublicKey and that PublicKey+Message~Signature.

Seller now knows that the same person who sent them the money provided this delivery address, and it couldn't have been altered by anyone else (or else it would break the signature).

Another use case might be MtGox wanting to confirm a payout by getting a signed message from the holder of the original address that funded the account.  Then, even if I get ahold of your email address and password, I cannot tell MtGox to send me your money, because they will expect a signed message (so the attacker needs your unencrypted wallet, too).  This is what PGP used to be for, but we might as well use the ECDSA keys that we already have...

EDIT: The Satoshi client 0.6 is going to have this feature too, but so far it will not be interoperable.  Just like with the wallets:  when I see their implementation, I will make an attempt to match Armory to it.  Though, it sounds like I'm going to need compressed public keys to support them (which I don't have yet).

[etotheipi]

Armory Version 0.55-alpha-RC2

Download full Windows 64-bit binaries!
On other OS, you can just checkout the project as usual but switch to the ecdsacalc branch ("git checkout ecdsacalc").  Please help test this release copy so that I can make it official!


The changelog is the same, but now everything works, including the ECDSA calculator.  You can now add elliptic curve points, multiply private keys together, manually compute public keys, etc (all on the secp256k1 curve, which is what Bitcoin uses).  And you can sign arbitrary messages with any private key that you own!   For demonstration purposes, I have supplied the following signature block that can be copied into the "Tools-->Message Signing" dialog and verified

Code:

-----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address:    1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message:    "Armory version 0.60-alpha was released 2012-Mar-"
            "19 07:40pm. Windows binaries have been released "
            "in zip files with the following MD5 hashes:  [Wi"
            "n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
            "930159411483428da40c127f654bf69] Please do not u"
            "se any zip files whose hash values do not match!"
PublicKey:  0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
            b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
            7571cbe492a7222442b75df75b9a84
Signature:  842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
            fcab55433f1d28f569b3771216754f400a5674e24984943d62
            9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK---------------------------------------

EDIT: Updated to 0.60 signature block, because algorithm changes since 0.56

[da2ce7]

wow.... this looks really cool.



 

[cypherdoc]

do u recommend just overwriting the previous install?

[etotheipi]

do u recommend just overwriting the previous install?

Yup!  In Windows, just replace the old directory (or ignore/delete it).  All wallets are stored in your C:/Users/me/AppData/Roaming/Armory directory, which will never be overwritten (or in /home/me/.armory on Linux).

In the case of Linux, you will have to checkout the new ecdsacalc branch and recompile ("cd cppForSwig; make swig; cd ..; python ArmoryQt.py").  Once it gets merged into the master branch, a simple pull will work.