given today's Linode heists of Slush, Gavin, and Zhou i predict Armory is going to enjoy great success.
Yeah, I noticed that today, though I haven't been following the discussion. I noticed slush using the term "cold storage," which probably refers to some custom-scripted offline wallet solution. I wonder if I should somehow tie in the phrase "cold storage" into the Armory description: I assume it's the same thing... yeah, cold=offline. eto, will Armory's offline main wallet run on Windows Vista? I don't have a Vista machine on which to test it... in fact I forgot that Vista even existed! I would really love it if someone with a Vista 64 machine would test it, because I have no idea! I went for the reckless approach and just transferred it straight over  I feel....liberated  Congrats! Please let me know how it works out for you, and especially if there's anything I can do to improve the interface. And don't forget that you can append donations to offline wallet transactions, too |
|
|
|
Isn't it possible to compute the public key from a signature? I don't know if this is useful client-side but who knows.
Yes. It's called "key recovery." But you need to add an extra couple bits to the signature (I think). I haven't implemented this in Armory yet, but I will, along with compressed public keys. Sub.
Uh... what? |
|
|
|
given today's Linode heists of Slush, Gavin, and Zhou i predict Armory is going to enjoy great success.
Yeah, I noticed that today, though I haven't been following the discussion. I noticed slush using the term "cold storage," which probably refers to some custom-scripted offline wallet solution. I wonder if I should somehow tie in the phrase "cold storage" into the Armory description: I assume it's the same thing... |
|
|
|
<3 I need to install OpenOffice and then I'll watch my reward  I sent you the powerpoint version, too, didn't I? Since you liked the previous example so much, let's get a little more advanced: use python + armoryengine to create and verify signatures. Note: These functions all take "SecureBinaryData" objects, which are memory-locked, auto-destructing binary data objects. These are not cast implicitly by python/SWIG, so it's a little more fiddling to get it right. But that's why this is the "advanced" examples (btw, the security of SecureBinaryData objects is probably diluted by accessing them via python, but there's no reason not to implement them correctly in C++, which may be re-used in other C++ applications later) from armoryengine import *
# Note, all the following operations use SecureBinaryData objects which must be cast
# using .toBinStr() or .toHexStr(), or constructed SecureBinaryData(binData)
newPriv = CryptoECDSA().GenerateNewPrivateKey()
newPub = CryptoECDSA().ComputePublicKey(newPriv)
print 'PrivKey: ', binary_to_hex(newPriv.toBinStr())
print 'PubKey_x:', binary_to_hex(newPub.toBinStr()[1:32])
print 'PubKey_y:', binary_to_hex(newPub.toBinStr()[33:])
print 'PubKey Valid? ', CryptoECDSA().VerifyPublicKeyValid(newPub)
print ''
msg = SecureBinaryData('Beware the buffoon hiding in the corner!')
sig = CryptoECDSA().SignData(msg, newPriv)
print 'Msg: ', msg.toBinStr()
print 'Sig_r:', sig.toHexStr()[:64] # 64 because sig is already in hex, not binary
print 'Sig_s:', sig.toHexStr()[64:] # 64 because sig is already in hex, not binary
print 'Verified?', CryptoECDSA().VerifyData(msg, sig, newPub)
This produces the following output: PrivKey: 11b40d463341aa7da3f1abf35893a94a4516a16a3aa7b83ded3a36dcfb0884ef
PubKey_x: ec5acc6ec078e8c1860222a6c9152d437607ab5f99fd36ed4a364db0435f61
PubKey_y: 859858c3bf78719b390f3d8b39b78acd303ee12537fba3a5ea78e216ab8349a3
PubKey Valid? True
Msg: Beware the buffoon hiding in the corner!
Sig_r: cc3dc787e7a5797274d41b48161ddac6956dbf15325cb44152bc8a5827de344c
Sig_s: 4f9c1443fbcddac98f03cef017497367a994164052488f571fd49af4796e173a
Verified? True
|
|
|
|
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 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 |
|
|
|
Is any of this accessible from the command line? I want to experiment with it and then modify vanitygen to do the job of generating the second private key. Then I could generate vanity addresses for other people and they wouldn't have to worry about me having access to their funds.
The following python code will give you access to this: from armoryengine import *
intA = hex_to_binary('abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234')
intB = hex_to_binary('eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee')
intCx = hex_to_binary('abababababababababababababababababababababababababababababababab')
intCy = hex_to_binary('de7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7dde7d')
intDx = hex_to_binary('6666666666666666666666666666666666666666666666666666666666666666')
intDy = hex_to_binary('abc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc1')
A_times_B = CryptoECDSA().ECMultiplyScalars(intA, intB)
A_times_C = CryptoECDSA().ECMultiplyPoint(intA, intCx, intCy)
C_plus_D = CryptoECDSA().ECAddPoints(intCx, intCy, intDx, intDy)
print 'a*b =', binary_to_hex(A_times_B)
print '(a*C)_x =', binary_to_hex(A_times_C[:32])
print '(a*C)_y =', binary_to_hex(A_times_C[32:])
print '(C+D)_x =', binary_to_hex(C_plus_D[:32])
print '(C+D)_y =', binary_to_hex(C_plus_D[32:])
The output of the above script is: a*b = 1a779cdad61f5f00ad22b4cb2d967a53678423055c08b3a4d43da39a49a080e6
(a*C)_x = 0f9ddccd4a2c5be720b99b9a6e32291ce7333a97a61282f2f2c72400d6af6d2d
(a*C)_y = 260991fe8b15f849a7139dca2ce1b7231d60178feb257ab9dee959084d52379d
(C+D)_x = ade6b9f3995f5d6a6b9ec4d8b73bd0d284744468c4a5e3be2306537e31077bcb
(C+D)_y = ded5ac1195fc3e6239659169ccf3384d70d6e1fb03ffb9840d090fff2d4f459a
Pretty simple, eh? P.S. - there's also an "ECInverse" function, but I haven't tested it. Use at your own risk. |
|
|
|
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. |
|
|
|
Shamir's Secret SharingShamir's Secret Sharing is a mechanism where you split a secret into N pieces and decide for a number K which is less than N. If you have K different pieces of the original N it is trivial to calculate the secret. If you have K-1 pieces the secret is completely undetermined, meaning that any possible value is likely. Details here: Shamir's Secret Sharing This is actually already possible for N=K using Armory's elliptic curve calculator (meaning that you need all of the pieces of paper to recover it). For instance, you create 3 private keys and use the calculator to multiply them together. The result is the final private key where the money is stored. Then you print off all three keys separately. To recover your wallet, you collect all three, and use the calculator again. Even better, this can be implemented without any two keys ever touching the same computer! Computer A produces a key, and gives the public key to Computer B. Computer B mulitiplies PublicKey(A) by its own private key to make PublicKey(A*B). Then this is given to computer C which multiplies it by his private key to make PublicKey(A*B*C). This is now a public key which can be converted to an address and funded. The only way to recover the private key, is to collect all three sheets of paper and multiply the private keys together! I don't promote this as the best solution, but it's one that is already available with Armory 0.55-alpha. In the future, this will all be unnecessary by simply putting all of your funds into a M-of-N multi-signature transaction. If it's a 2-of-3 transaction, you backup all 3 private keys separately, and any two will work. It's a protocol-level implementation of Samir's or Reed-Solomon. Believe it or not. I was once a consultant on a project where a similar procedure was done (paper shares, stored in various banks in different locations), where as a safety procedure the printer used had to be blown to pieces by the military afterwards. This was a backup for the root key of a CA. I guess they were paranoid of what you can get off a printer roller.
I totally believe it. A root CA key requires the highest level security, especially if it will be used for military operations. I'm surprised thermite wasn't involved Brain Wallet will be a killer app. I am choosing multiple encryption methods including mnemonics, music notation, a personally developed cryoptogrphic algorithm, and motor memory. It will be interesting to see how many keys I can create and remember, maybe enough to last a lifetime.
I have considered brain wallets, but I think they are too risky, unless you include extra entropy stored on the computer (which partially defeats the purpose). As mentioned above, too many users use passphrases that are way too simple, and will end up sharing wallets (or make it too easy for an attacker to create the same wallet without ever accessing your computer). When their coins disappear, don't count on the user admitting that they used a weak passphrase. Instead, it will make the protocol/program look insecure. |
|
|
|
Paper is cheap, easy to store, and visually verifiable: if you can read the letters on the piece of paper, your backup is safe.
The one problem with this is, if someone obtains the paper, they have your savings. Multi-sig paper back ups stored at several physical locations would be fantastic. You are correct. Most of my focus in Armory development has been online threats, not physical threats. But that doesn't mean I've ignored it: I just think that having someone break into your house and going through your bookshelf to find the paper backup is 100x less likely than the random online attacker scanning millions of computers looking for open ports/vulnerabilities and getting access to your system. In the future, I can add a feature in Armory to allow you to add a passphrase/encryption to your paper backup, but I honestly think that just adds more risk than it adds value: your paper backup will likely not be used for years, and you're bound to forget the passphrase by then. If you're really concerned, put your paper backup in a safe-deposit box. Or back it up to 5 different USB keys and put them all in your safe-deposit box. Again, for the average user, I am most concerned about online threats, especially since a highly-targeted physical attack against your wallet will likely not be stopped by anything anyone can put in a Bitcoin client (keyloggers, especially). Multi-sig paper back ups stored at several physical locations would be fantastic.
Multi-signature transactions and two-factor authentication w/o third-party will become part of Armory. But I have a few other priorities to implement first. |
|
|
|
Encrypt wallet.dat with Truecrypt, put a GOOD password and backup it in various hard disk/usb things and put it also online, like email or cloud storage services. <-make sure the password is a good one.
Users don't use "good" passwords, regardless of whether they know it's a good idea or not. Additionally, I hate the idea of scattering your encrypted wallet all over the internet... what if there's a bug in the wallet encryption that actually leaves the private keys unencrypted? You probably won't even know until your coins are gone, and you know you can never remove your wallets entirely from these online storage places. You can transfer the coins immediately to a new wallet, but then you have to store/backup those somehow. And of course, even if you get all this right... see my previous comment about how easy it is to forget passwords... EDIT: I overlooked the comment about TrueCrypt ... it removes most of the is-this-encryption-really-secure-? uncertainties, but there's still plenty of other reasons to not like it I think the better way is to use wallet encryption on your own computer, and print off a paper backup. Paper is cheap, easy to store, and visually verifiable: if you can read the letters on the piece of paper, your backup is safe. Keep it in a book on your bookshelf, or store it away securely in a safe-deposit box. If you don't have a printer, you can backup to USB key instead, but there's always a risk that that key isn't going to work when you plug it in the first time two years later. And, with the Satoshi client, backups are not "forever." This may change in the future with deterministic wallets in the Satoshi client, but it's not currently there. This is one of the key features of alternative clients like Armory, and Electrum -- you only need to create a backup once when you create the wallet, and never again. With the Satoshi client, you need to create a new backup every 100 addresses, and thus you have to have some kind of regular backup solution which users are notoriously bad at doing (especially when you have to manually re-encrypt each time and redistribute it to your various backup locations). |
|
|
|
Oh, sorry. It's been a while since I've read the complete Armory thread. I've probably purposely tried to ignore it because of how excited I've been to use it! The last time I read it (probably over a month ago!) you were still suggesting not to use Armory on the live Bitcoin network. I will definitely update myself today! I guess I never gave an official "Go-Ahead" for main-network. But people have been using it, and I've only encouraged caution about using it with lots of money. That's exactly why I encourage following the "I'm Scared" procedure, so that you don't have to trust me: you can prove to yourself that it's reliable! |
|
|
|
by then, finger muscle memory was the only thing that saved me, but it took me about 20 tries to get it.
That's awesome! So cool. Regarding the OP, I did everything required to use Armory offline transactions a year ago. Obtain sterile offline computer, create new wallet, etc.. I'm just waiting for Armory to catch up so I can spend my coins!  Holliday, What are you waiting for? The offline wallets work already! I use it for all my funds. That doesn't mean you should dive in blindly... but it is 100% usable, you only need to follow the "I'm Scared" section of the Offline Wallets Page to convince yourself to use it, too. If there's something missing, let me know what it is! |
|
|
|
All over the D&TD forum, there has been talk about creative things you can do with private and public keys, to emulate multi-signature transactions, or create shared secrets. While these things are all theoretically possible, it takes programming experience and familiarity with an ECDSA library to actually execute them. Not anymore!. I have just recently integrated an ECDSA calculator into Armory, and anyone can use it, even with low-RAM computers by running Armory with the --noblockchain option. Using this interface you can: - Multiply private keys together
- Scalar "multiply" elliptic curve points (public keys)
- Add elliptic curve points together
- Compute addresses from public keys
- Compute public keys from private keys
- Create and verify signature blocks to send through email
- Import addresses created with the calculator into your wallet
- Do all of the above with arbitrary keys, not necessarily in any wallet!
You can download Windows binaries, or find instructions for building on Linux on the Armory webpage. If you find this useful/interesting/amazing, please consider donating to my crowdfunding campaign, to help me continue to work on Armory (donate with credit card or BTC)! All donations of $10 or more come with my hour-long cryptography seminar titled Understanding Cryptography: Using Boring Math for Something Useful. It includes a brief introduction to elliptic curves.   So, what is this calculator useful for?Here are lots of great uses for this calculator. Here are two specific examples: (1)Emulated 2-of-2 multisig Note: this is only for the case that one party will be redeeming the full amount of the encumbered funds: there is no trust-free way to split the funds with this method (which makes it useful for Casascius+OtherParty physical bitcoins). - Each party produces a new address (which should not be in their wallet [explained later])
- From the wallet properties dialog, or the "Keys" tab in the calculator, fetch public keys and exchange with the other party.
- Fetch your own private key for the public key you just sent
- Use the middle entry in the calculator dialog, to multiply the other person's public key (enter x,y pair) by your private key
- Both parties get the same answer! This is because party A has private key a and public key a*G and party B has private key b and public key b*G. Both parties then end up producing a*b*G which is a new public key. However, neither party can calculate a*b (which is the private key for the public key both parties calculated).
- Calculate the address for the public key, and fund it with the amount of money agreed upon.
This is called an "Elliptic-Curve Diffie-Hellman" exchange (ECDH). It is usually for creating a shared secret with your public keys (such as an encryption key). In this case, it lets you produce an address that only someone with both private keys can access. At the end of this process, one person must send the other person their private key, so that they can calculate the shared private key and redeem the funds! This is why the private key you generate should not be part of any wallet, because it will eventually be shared and you never want to share a private key in one of your wallets! This could be used by Casascius and another party: Casascius and other party execute the process above, and fund the address with 1000 BTC (for a 1000 BTC gold bar). Casascius gets his hand on the gold bar, and puts his tamper-proof private key on it. He sends it to the other party, and they put their tamper-proof private key sticker on the other side. Now, the user with the gold bar is the only person that will ever see both private keys (once he peels them off) and thus, the only person that can ever spend them! Just plug one into the 'a' field of the calculator and the other one into the 'b' field of the calculator (if Casascius wanted to do this, I would add a simpler, reduced interface for multiplying private keys, but it is technically do-able as-is). (2)Send Signed Messages Remember when MtGox got hacked, and they had to retroactively verify every account's identity? This could've been soooo much easier: "Dear user: We need to verify the identity of account 198483202. The first time this account was funded, the address 1Qkj3F3qZjkPdkj389 was used to send BTC. Please provide your name and email address, in a message signed by address 1Qkj3F3qZjkPdkj389." This works because the account must've been originally funded by an address owned by the user. If this message signing interface existed, it would've given MtGox a very easy way to identify most users. In case the user doesn't have the address anymore, they can just email MtGox and ask for alternative identity verification (which turned out to be the default). Also consider the online casino situation. You dump 200 BTC into this anonymous online casino. Now, 3 weeks later, someone attempts to gamble with the money and/or cashout. How does the casino know that you are authorized to do these things? Well, all they care about is that the person requesting the cashout is the same person who originally funded the account. To be absolutely safe, they could've collected your identity and provided you a login, but that would dramatically reduce the anonymity of the system. Instead, the casino only records the first address ever used to fund your account, and that is your "username"! The user signs a message saying "I would like to withdraw 100 BTC to the following address: ..." Or it could be used as a way to "sign in" to your account. In all cases, the user never had to identify themselves, and the only piece of relevant information: that the same user who funded the account is requesting something: is easy to verify with a signed message! |
|
|
|
Download bitaddress.org or a similar tool that will create a private key by doing a SHA256 hash of a passphrase. Use it offline to be sure that noone ever sees the private key.
Create a long passphrase and repeat it to yourself 10 times every night when you go to bed. It's not hard to remember a long passphrase as long as it makes any sort of sense and by repeating it every night it will be virtually impossible to forget it. Write a little poem or something.
This is a passphrase
and it might be lame
but it is the key
to my fortune and fame
You'll feel pretty safe when the phrase you chose is stuck in your head. Also, you don't have to rely on any service to still be there, knowing that it's simply a matter of doing a SHA256 hash.
I prefer this method, but make the passphrase better, like this: This is a passphrase 27 beetles
and it might be lame
but it is the key l1m3 p13
2toTWOt00 my fortune and fameUnfortunately, this is a disaster waiting to happen. No matter how much you try to memorize it: you will forget it. I have a 16 character password at work protecting my encrypted hard-drive. It was trivial to remember it for 3 months straight, because I typed it in every day. But then I got a new primary system and didn't touch the old one more than once in 6 months -- by then, finger muscle memory was the only thing that saved me, but it took me about 20 tries to get it. Fwhew! From then on, I have it written down in a sealed envelope inside a safe. The method described here is safe only if you write it down and store it safely somewhere. But you won't be able to access the funds at all. Sure, you can send money to it, and use blockexplorer to watch it: but how do you spend any of the money? How do you monitor incoming transactions? Sit there refreshing blockexplorer every 10 seconds? |
|
|
|
Im getting to the point where i have so many coins im starting to worry about them. Im wondering what you guys do to protect yours. I have mine spread around. Some in deepbit, some in MTgox, a few different wallets, on several hard drives, and USB sticks. But despite all that im still concerned with their safety. Is there anything else i can do to play it safe?
This is exactly why I made Armory Offline Wallets. (1) Get a super-cheap laptop. Disable all ethernet/wifi adapters (2) Generate a wallet (3) Make a watching-only copy of the wallet, transfer to online computer with USB key (4) Generate addresses and monitor transactions the same way as a full wallet If someone steals your online wallet, they get nothing! When you want to spend the coins, get out your USB key (1) Create the transaction as normal, but "Send" button will be grey'd out. (2) Click "create unsigned transaction" (3) Copy it to a USB key, take it to the offline computer (4) Click "Offline Transactions-->Sign Transaction" (5) Save the signed transaction (automatically overwrites the unsigned one) (6) Take to online computer and "Broadcast" The process of spending coins from an offline wallet is less than 60 seconds once you get the process down, and the whole interface walks you through the process.  The Armory Offline Wallets page describes not only how to use the feature, but also has a section titled "I'm Scared!" which describes a process you can follow to convince yourself it works. You should always make a backup (paper is best), put a few BTC in it, and then once or twice a day execute a small offline tx, to yourself if necessary. You'll find that it always works, 100% of the time. After 3-100 days, you'll eventually realize that there's nothing to be scared about and that it actually works -- flawlessly. Not to mention you have a backup just in case! There is no better way to secure large amounts of Bitcoins. I made the interface because so many people have complained about not feeling safe. This way, you don't have to rely on any external service. You can keep your money stored on a computer without any internet access... and anyone who gets your online (watching-only) wallet gets nothing, except knowing what addresses you own -- but they can't spend your Bitcoins! |
|
|
|
While I agree that security is not currently a huge risk, that doesn't mean it isn't relevant. As said above, this becomes a much bigger deal when adoption grows, especially less-savvy folks. You get both: less-knowledgeable users, and more-determined attackers. To suggest otherwise is like saying "Well I never use my airbag. I guess I don't really need it." There is also an aspect of perceived security. One of the reason I made Armory Offline Wallets, was so that people had the tools to secure large amounts of Bitcoin without all the uncertainty and complexity of hacking the Satoshi client to do it. People holding thousand of dollars in Bitcoins can do so with confidence that they don't have to worry about theft, which may have been a barrier for some users pondering a large investment... and hopefully business owners will feel comfortable adopting Bitcoin -- they already have enough risks associated with integrating Bitcoin into their business model, hopefully the huge boost in security can remove one dimension of uncertainty. The fact that lots of people have identified they lost money through online services (loss & theft, sometime indistinguishable), is what I hoped to solve with Armory. Give people the tools to manage their own Bitcoins, without relying on someone else -- which appears to be a non-negligible percentage of voters reporting loss. |
|
|
|
Armory Version 0.55-alpha-RC2Download 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 -----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--------------------------------------- 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 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). |
|
|
|
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.zipThere 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: -----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!
|
|
|
|
Well, I will happily take suggestions and go from there. Perhaps if I get some good recommendations I will consider. Unfortuantely, I'm leaving town for a week and I have no time to deal with this right now. And re-branding will be no trivial task. "Armory" is all over this project  |
|
|
|
|
Show Posts
