Red Emerald: Are you going to release 0.86 in homebrew, too? Not that it is hard to compile by myself, but your homebrew formula is easier  Updated! Sorry for the delay. brew update
brew doctor
brew fetch --deps armory-qt
brew upgrade armory-qt
Once it's installed, you don't need to prefix armory-qt with "wysenynja/bitcoin/" A fresh install does tho: brew update
brew doctor
brew tap WyseNynja/bitcoin
brew fetch --deps wysenynja/bitcoin/armory-qt
brew install wysenynja/bitcoin/armory-qt
Note that case matters for `tap`, but not for the other commands. |
|
|
|
It's trying to be something that it isn't and can't be.
And I'm on the opposite end of the spectrum. Single-use paper Bitcoins are even better than paper currency. The QR code is scanned and and the document discarded. Either there were funds from it or there weren't. For the change I get my local currency and coin, just as if I had paid cash. Or I can show the public ("load & verify") QR code for my the next one and get a receipt from the merchant showing the address and the transaction id. I think Richy is talking about trying to make bills that stay in circulation. Single-use notes work great. |
|
|
|
|
Great writing as always, evoorhees!
|
|
|
|
etotheipie, would it be possible to add the root key + chain code to the "backup individual keys" option, so it can be easily saved to a file? I would like to encrypt it with a password me/my family knows and print it out. This way if a burglar found it it wouldn't be so easy to sweep the funds. Or even better yet, have the option making an encrypted paper backup, but that would be probably much more time consuming to implement.
I've been meaning to add the root key+chaincode to the "backup individual keys" window. But I didn't have any plans to make the backups encrypted. Once you have an encrypted wallet and an encrypted backup, you effectively have a brainwallet (requiring either brain+paperdata or brain+HDDdata). And I've ranted before about this, so I'll not go on a rant this time. But the gist is this: you don't anticipate using your paper backup, potentially for 5 years. If you encrypt it, you will forget that password within 5 years, and then your backup is useless. Even if you don't forget it, you're very likely to take it to the grave with you when you get hit by a bus, and I'm sure your family would be thrilled to find evidence of $20k worth of BTC in your safety-deposit box, but no way to recover it. Yes, yes. I'm protecting users from themselves. That's what I hate about the "war on drugs" -- the difference is, I'm not going to arrest you if you encrypt it yourself I just don't want to encourage it, because then everyone will do it by default, and lots of people will lose BTC. For most Bitcoin users, 99% of the risk is virtual, not someone gaining physical access to your paper backup. Okay, so I guess I ranted about it, anyway I will add the data to the individual keys dialog. I should've put it on there from the start, anyway. If you want to encrypt it, you can save it to a file and encrypt it however your little heart desires EDIT: I just realized there could be a MINOR benefit to the encryption: "Please print out this sheet of paper and then write this code on it in permanent ink!". It would print out an encrypted copy, which would protect against malicious printers. And then the user writes the code on it so that it's not a brain-required backup, but the printer doesn't have access to it. Hmm... You should check out BIP38 |
|
|
|
So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others. I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it. Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following... Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction Runs this script against the unsigned file If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form) Shutdown the Pi I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts? Of course, I can't endorse it as a general solution, but it seems like an okay compromise for users that are knowledgeable and crave convenience. It sounds like the risks are: (1) Remembering to disconnect the cable when you're done (2) Making sure that your offline system username & password is not the same as online computer or any of the saved logins in your browser. (3) Keyloggers Keyloggers should be bolded there, because that seems like a big risk. Once a keylogger gets your username and password, it would only take a couple seconds to login and fetch the wallet file. I guess, if you kept the wallet file in some non-standard location, such automated attacks wouldn't be so clean. Although, if your wallet encryption password is further different than online, offline, and all your browser-saved passwords, then this is considerably safer than an encrypted online wallet. If the encryption password is unique, then the encryption would really shine, as there's no real way to get that password from the host system (I assume you still have to explicitly type your password on the offline computer, not through the terminal... and assuming they didn't get a keylogger onto the offline machine, synchronized with the data transfer). But depending on how much BTC you hold and/or how paranoid you are, this could be a reasonable solution. I suppose you could set up ssh keys on the rasbpi and access it like that ... no user/password typing for keylogger (once intialisation is complete). Seem to remember some tricky stuff you can do to wrap the screen tty session inside (around?) a ssh shell . http://serverfault.com/questions/21806/how-can-i-launch-a-screen-session-with-a-command-over-ssh-on-a-remote-server-froWhile keys are more secure than passphrases, they won't protect you in the case we are talking about. If your system is compromised enough to have a keylogger, it is more than likely compomised enough for the attacker to use your ssh keys. They would just record you password for unlocking the ssh key (assuming you set a password) and use that key instead of the password. I don't think having your offline system connected like this to a computer that is connected to the Internet can be considered safe. There are some other hardware wallet implementations being worked on where restricted communication happens over USB. Allowing a full remote login into the rpi is too risky IMO |
|
|
|
It seems to me that a would-be scammer could slice off the cap with an X-Acto knife or a razor blade, scan the QR code, and carefully apply a second layer of tape. Subsequent recipients of the note probably wouldn't notice until it was too late.
A last resort for tamper proofing is to apply the lottery scratch card method of rubbery sealing over the private key. But then the note might have to be in plastic?. It for sure will get a very ugly rubbery blob, in place of a beautiful BTC marked hologram  . I canīt imagine high tech is needed to apply the rubber (?) covering over the private key, and it canīt cost much as it is already in widespread use for cheap lottery tickets. And how do you prove to the person you are paying that there is actually a private key underneath the rubber? |
|
|
|
We're getting a bit off topic here, but this stuff is important (the extension won't work but other approaches that convert the web app into something you "install" might do). The 60% figure comes from the Chrome developers and I believe it's the total of all displayed interstitials. I don't understand why you think self-signed certs provide any security. It isn't "easier" to do a MITM, it's the same as with no SSL at all. Unless you have communicated the cert to your users out of band (no first time visitors) AND they are installing the cert themselves, it provides no security. You say you don't understand, but then you go on to say "unless you have communicated the cert" which is exactly what I'm doing, so I guess you do understand. Additonally, blockchain.info doesn't use a SS cert. I was simply using that example to show how those numbers are inflated by people like me. The number of benign SS certs that are accepted is sadly not part of that number. Even if it's half (which I doubt), 30% is still too many compromises and obviously something needs to be done to educate the users. The click through rate on SSL errors for modern browsers should be zero because they don't let you click through (except for self signed certs, and even then, only with a lot of hassle). That change was made because the previous clickthrough rates were close to 100%.
I agree Your belief that users are "dumb" if they ignore warnings is worthless because it categorizes all users as dumb, which is usually a good sign that actually your expectations are wrong. The real reason users clicked through these alerts was usually one of the following:
1) They didn't understand what the warning meant.
2) They have seen the warnings before in non-dangerous situations (like the clock being set wrong or a self signed cert).
Well I do still think most all users are dumb. Not dumb in all things, just in how this tech works. After reading the studies you have linked, I'd also add that being dumb is not prerequisite for failing to check that everything is secure as even intelligent people make mistakes. What word would you use instead of "dumb?" Clearly the users are something less than fully aware of their surroundings if they are ignoring warnings that are going to lead to them being robbed. This is not intelligent behavior. In my experience, you have to treat your users like they are idiots or malicious attackers who will do everything wrong and the software still has to be 100% secure and still work. As you've pointed out, Blockchain.info sadly does not have this level of security yet, as it requires use of a secure passphrase and knowledge of two-factor auth and installation of a plugin. I still don't understand why you think the plugin is useless. You seem to be taking the stance that it is an impossible task to trust users not to click the button "Hack me" button no matter how scary we make it. If that's true, then aren't you the one calling the users dumb? If this is really about only promoting clients with perfect security, then I'd say that you can't promote any of the desktop clients either as they are all vulnerabile to key logging and the beloved satoshi client has difficult to manage backups. Tangent: I wonder how many coins have been lost by deleting/losing wallets compared to being stolen because of weak security. It sounds to me like if a user is going to be unsafe with their computer and accept bad SSL certs and generally ignore any warnings that things are going bad (as the studies you have linked prove), then these people more than likely have compromised computers anyway in which case their funds in their desktop wallet are also at risk and we have saved them from nothing by getting them to fear web wallets. The only secure solution is a hardware wallet that can interface with any client, desktop or web. Then the private keys are never anywhere that can be compromised by a hacker. |
|
|
|
FYI the entire discussion in this thread will with the arrival of hardware wallets soon be irrelevant. I hope that even blockchain.info will make use of them.
OMG YES |
|
|
|
Neither approach is likely 100% cheatproof. A custom or semi-custom seal might improve security a bit, but at what expense? Probably nothing short of a custom hologram (like what Casascius uses) would be truly secure, but the setup charges and minimum orders likely make that cost-prohibitive. The supplier I'm using can customize their designs with an overprint. That then raises another question: would they offer that same customization to all takers, or would it be for your exclusive use?
And what stops them from counterfeiting your bills? |
|
|
|
EDIT: Here's something more substantive: This would solve the Vanity Address Service conundrum. Scenario: Alice wants a Vanity Address, but does not have the CPU power to generate one. Alice sends Bob her intermediate_passphrase_string. Bob has lots of compute power and can generate addresses without any knowledge of the private keys. When Alice's desired vanity string is found, Bob can provide the address and encrypted key to Alice, who can decrypt the private key and use it without fear that Bob will exploit it later. Bob can even show proof that he has found a valid vanity address before releasing the encrypted private key back to Alice (e.g., to request payment for service).
I've seen something like this proposed for vanity addresses before, but I believe this BIP solves it rather well. Is this accurate?
I think this would work for vanity mining. That problem does already has some solutions. https://vanitypool.appspot.com/How would proof be given? |
|
|
|
Yes it is, centralized manufacturing of the hologram is a practical and economical way of identifying the issuer of the notes - and making them hard to forge also.
It will be nothing like a central bitcoin bank issuing all notes, which opens the possibility for all notes being redeemed by a scammer holding all private keys. The possibility for this happening with distributed issuing will have only local impact, and will be far less likely to happen.
A CENTRALIZED manufacturer is a problem. IMO, for paper bills to work and remain in circulation, there has to be a 100% way for any party to validate that their bill is secure. The bills presented here can only be fully trusted if you are part of the manufacturing process. Bitcoin is impossible to counterfeit. The proposed bills are possible to counterfeit. Any solution where counterfeiting could be a problem is a non-starter for me. |
|
|
|
|
So bitcoin 0.8 has some changes for the blockchain storage IIRC. Will this break your blockchain loading? Have you started working on support for this?
|
|
|
|
the hologram which only casasius produces.. never resells separately. insures its a casasius multiparty note and not a privately printed note where the producer has seen the private info
The less centralized solution, more in the spirit of bitcoin, is to sell only the hologram. This should contain something like the PGP signed email address of anyone wanting to start issuing their own notes. Still a chain of trust, but a short one: casascius has to be trusted only to sell his customized hologram stickers to the owner of the email address. After that the one remaining link is to trust the local issuer, identified by this very email address. Everyone trusting a list issued by one person is not a "less centralized solution"... |
|
|
|
Red Emerald
by you printing them off yourself the person you hand it to has to trust that you dont have the info stored elsewhere to then wipe the address clean once they walk 3 paces away from you. so encrypted or not/hologram or not you have still seen the private key or the bip38 to have had the opportunity to keep a copy to redeem whenever you like.
if you are seeking a one use only method between you and a friend for quick easy wallet transfer without having to have a smart phone on you then it would be more like a bitcoin bond/giftvoucher/cheque kind of thing which wont need any security as you have been the producer of all 3 stages, you have seen all the info.
the idea i said doesnt involve giving any one person trust as no one person sees all the info...allowing for circulation to happen between complete strangers without the worry of trust. the address generator/encrypter/api program i said would be open source for people to see that casasius only receives the bip38 and public address. and the program user only knows the passphrase and never sees the bip38 as the program doesnt show it and the notes delivered to him are already covered by the hologram.
leaving only the redeemer able to get at all the info once they remove the hologram and read the passphrase on the back to match it up
I don't think it's possible if you don't know the issuer. Once the bill has changed hands a few times, how are you supposed to know that the bill you are holding was made securely by multiple parties or made by someone who knows all the private parts or made by parties that are colluding? What if there is nothing under that security sticker? BIP 38 makes it somewhat better with the encryption key having a hash of the address exposed, but I'll have to think more about BIP 38 since I just saw it today. Additionally, I could make a bill that looks exactly like whatever multifactor bill you come up with, but I know all the parts. I then distribute the bills and if someone trusts the security measures, it won't get back to me. |
|
|
|
|
What does 60% mean? You will pay $30 worth of bitcoin, or you will pay $80? Why would anyone take that much of a loss?
|
|
|
|
NEVAR!
That's too bad and it's totally against anything bitcoins ever stood for. Satoshi would be spinning in his grave if he was dead instead of just fleeing from the absurdity people made of his vision. I think this is likely true of all inventors/creators. |
|
|
|
I understand that it helps a bit with trust in some situations. I was responding to franky saying that this would keep the bills in circulation longer. I don't agree since in that case you probably do not know who printed the bill.
my theory was if casascius was the only bill printer using his trademarked holograms which authenticates they are his bills. for instance. then also knowing that casascius doesn't know the passphrase. and i dont know the private key because all i seen and copy and pasted to him was the bip38 version. .. break for 50 seconds of thinking... apart from the fact that i could possibly have kept the bip38 lists and used my passphrase to decrypt it.. now i come to think about it.. its still not a 100% trust system. .. break for 50 seconds of thinking... maybe the vanity program i proposed casascius making with the added bip38 security does not reveal to me the bip38 but sends it via API to casascius. so when ordering bitnotes from casascius. i just type in a passphrase into the vanity/brainwallet program and an amount of bills. and the only response i see is "transaction sent - please allow 10 days for delivery" thus i only know the passphrase. casascius's servers only sees the bip38 and the end user who finally gives up circulating the notes and cashes out.. will get to see them both after ripping off the hologram and reading the hand written passphrase on the reverse side. Sounds like too much trust is required for that to work. It's safer and easier to just print them yourself without any encryption. I really like the idea of paper wallets, I just think they need to be refined a bit. Here are all the ways I could see using paper. 1) Note with address and unencrypted private key. Useful for quick offline storage and paying friends. If you are paid by someone untrusted with this note, you can easily sweep the private key to a new address. Sweeping from the bill may incur a fee depending on how fresh the coins are. The funds could potentially be stolen by someone peeking over your shoulder unless you have some sort of sticker or something covering the private key. 2) Note with address and encrypted private key. Useful for cheap, easy, and secure offline storage. The funds would be protected from someone peeking over your shoulder unless you don't cover the private key and you print the passphrase on the note. 3) Note with address and BIP38 encrypted key. Useful for secure offline storage on pretty paper or in a coin that would be too hard to make yourself. If you are paid with this by someone untrusted, you can relatively easily sweep the private key to a new address assuming you know the passphrase. The funds would be protected from someone peeking over your shoulder as long as the code is covered by a sticker and you don't print the passphrase on the note. This is what I would want to buy to store in a bank safe. 4) Note with address and no private key. The key is kept elsewhere, either digitally or printed. This would be useful for accepting bitcoin payments on the go when you can't load your wallet app because your smartphone's battery is dead. 5) Note with just a private key (encrypted or not). Not really sure how useful as it would require some work to securely check the balance. A note with just an encrypted private key could be very small. I wrote a quick and dirty python script last night for printing codes. It takes an electrum wallet, an image (I've been using Psy's beautiful note, but any will work) and a config file with x,y coordinates for the qr codes and then generates a few different things using electrum. Eventually, I want each note to look very different so they can be easily distinguished. I'll throw it on github tonight or tomorrow once it works well enough. I wrote it not because I don't trust Casascius' utility, but rather because I don't like running windows. Note 1: Uses a randomly generated (and promptly discarded) electrum wallet to generate the addresses on each note. I leave these notes unfunded until I need to use them, but they could be funded right away. Losing the note loses the funds. If I want to accept a payment, I have the other person pay to the public qr code and then I have a funded bill. If I want to pay someone else, I pay to the note's address and then hand it to the other person. This requires that they trust me at least a little bit. I could, for example, not print the actual private key on the bill, or sweep the funds before they have a chance to. Best case is that they have their own notes printed up, and I can scan one of their public qr codes and then they have no need to trust me. These can stay in circulation, but I don't think they should as there is no guarantee that I didn't keep the private keys for myself. Note 2: Uses an electrum wallet to generate addresses and keys for each note. I keep this wallet file somewhere safe and offline. I can leave these notes unfunded or fund them as I print them. If I ever lose a note, I can still recover the funds through electrum. I can use these like checks. If I want to place a "stop order" I can do so until the funds have been swept elsewhere. I like these because I am less wary of losing them or having them stolen. If I pay someone with these, they should sweep the funds right away, and not keep them in circulation as I admit to having the private keys. Note 3: Uses a deseeded electrum wallet to generate addresses, but not keys, for each note. I use these notes to easily accept payments to my savings account. I can easily and securely print off an unlimited number of these with a system connected to the internet without risk of having any funds stolen. These are only useful for accepting payments, and not for paying others. I'm considering printing the master_public_key where the private key would go so that you can tell which wallet the funds are in. Now my main problem is a crappy printer. Any recommendations for cheap color printers that don't have wifi that handle that cotton paper well? Also, any recommendations for cotton paper? |
|
|
|
The problem with having an extension that says "Something changed, watch out!" is that it's not going to work. This isn't debatable, if you think this will work you need to spend an evening reading usability studies of SSL in web browsers. For something like 90% of its history HTTPS simply had no effect despite all the fancy maths because all (seriously, all) users clicked through the warnings when something went wrong. Even since browsers have moved to big red screens that say "Don't proceed!" as plainly as possible, the clickthru rate on Chromes self-signed SSL cert interstitial is 60% - despite that accepting a self signed cert completely defeats the point of SSL.
I will give you that most users are dumb and just click right on through scary alerts no matter how large and glaring they are. But I think your 60% number is a bit inflated. That is probably 60% of people ignoring the alerts for SOME self signed cert. Also, not all self signed certs are bad and they don't "completely defeat the point". I use them all the time for my own services because they still provide security. It is just easier (though still not trivial) for someone to implement a MITM. I think a much more important number to find would be the click through rate of broken SSL certs on banking websites or websites where security actually matters. If I visit joesmoeblog.com, I probably don't actually care that he has a self signed cert. But, how many people go to bofa.com and get the big red warning and still click through? I'm sure it's still some, but I'm also sure it's less than 60%. I also don't feel remorse for people who can't read a big red warning when handling money. |
|
|
|
Electrum is based on 2.7 or 3.3 python?
I tried with 3.3 and it didn't compile the setup.py, error on line 16
Windows User here
python 2.7 This question seems to be asked rather a lot. Maybe when you check for ecdsa and the other dependencies, you should check that python is 2.7. The check in setup.py should probably be changed to only allow 2.7, too. |
|
|
|
|
Show Posts
