Topic: Armory - Discussion Thread - page 215. (Read 521749 times)
given today's Linode heists of Slush, Gavin, and Zhou i predict Armory is going to enjoy great success.
I'm just plucking up enough courage to transfer my entire savings balance over to Armory (right now it's inside an encrypted Truecrypt file, on an encrypted disk, such a PITA when I want to spend something). It's not a massive amount (close to 200BTC, I've been a bit spend happy lately 
), but more than I'd like to lose.
The silly thing is I know it'll be fine, and I have paper backups should something go wrong, but there's always that little niggle telling me to wait
), but more than I'd like to lose.The silly thing is I know it'll be fine, and I have paper backups should something go wrong, but there's always that little niggle telling me to wait
Rolo, don't rush yourself. If your coins are already offline, you are in no hurry to switch. But arguably, you are right: you have a paper backup, what could go wrong?
The best thing thing to do is delete the offline wallet and restore from paper backup. It'll calm your nerves a bit, knowing that you are using the exact same wallet you'd be using if something went wrong and you had to restore again (but they are the same, I promise). And also load the offline wallet and online wallet and generate about a dozen addresses on each. Verify that the generated addresses are the same. Once you see that, hopefully that that niggle will go away.
Then as extra credit, move a couple BTC to it, and transfer 0.1 BTC to yourself a couple times using the USB key. Even though I wrote the program, it still felt a little bit like magic that it works. But it's easy to get used to
I'm just plucking up enough courage to transfer my entire savings balance over to Armory (right now it's inside an encrypted Truecrypt file, on an encrypted disk, such a PITA when I want to spend something). It's not a massive amount (close to 200BTC, I've been a bit spend happy lately ), but more than I'd like to lose.
The silly thing is I know it'll be fine, and I have paper backups should something go wrong, but there's always that little niggle telling me to wait
), but more than I'd like to lose.The silly thing is I know it'll be fine, and I have paper backups should something go wrong, but there's always that little niggle telling me to wait
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.
do u recommend just overwriting the previous install?
wow.... this looks really cool.
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
EDIT: Updated to 0.60 signature block, because algorithm changes since 0.56
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
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
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.
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).
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.
otherwise everything seems to work. everything i looked at in 20min anyway.
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
Good news, it loads on my machine
That's about all I have time to test right now, but so far so good
Brilliant, I assume this'll fix the Python 64/32bit issues on Windows?
I'll try it tonight
I'll try it tonight
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:
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!
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!
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?
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).
Now I just need the spare RAM
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?
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).
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?
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?
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:
Here's the output on a watching-only wallet (this is actually the output of the second time I ran it):
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.
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.
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.
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. 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.
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..
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.
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.
Jump to: