In such cases, it's probably best to just write the data down by hand. Pen and paper is fine.
Only the four lines of text are important. The QR code is just there for convenience (it contains those four lines). Arguably, many people feel safer doing this, anyway, to limit the number of devices that have seen your unencrypted root key.
If someone has hijacked my printer I have more pressing problems methinks. For a lot of people: "if someone has hijacked my printer I am totally freakin' screwed". A lot of people are holding extraordinary amounts of money offline, and with the recent rise in price of BTC, their lives have changed, and will change for the worst if that happens. Don't want to be another "allinvain" I understand that, i was more making a comment on how likely that is to happen in the real world. I am reminded of this comic:  Yeah I love that XKCD one. Including the mouseover text "Actual ACTUAL reality: you'd be hard-pressed to find that wrench for $5"  The printer thing is actually in line with that comic, though : they're not breaking your encryption, they're just compromising one of your devices and getting around the encryption. It's scary how bad some companies are with security. |
|
|
|
In such cases, it's probably best to just write the data down by hand. Pen and paper is fine.
Only the four lines of text are important. The QR code is just there for convenience (it contains those four lines). Arguably, many people feel safer doing this, anyway, to limit the number of devices that have seen your unencrypted root key.
If someone has hijacked my printer I have more pressing problems methinks. For a lot of people: "if someone has hijacked my printer I am totally freakin' screwed". A lot of people are holding extraordinary amounts of money offline, and with the recent rise in price of BTC, their lives have changed, and will change for the worst if that happens. Don't want to be another "allinvain" |
|
|
|
So, is this safer than the regular latest bitcoin client?
I'm not sure what you mean by "safer"? The regular Bitcoin client is the gold standard for network security and blockchain validation. Armory uses Bitcoin-Qt/bitcoind in the background so that Armory gets the same benefits. But it has completely independent wallets, blockchain scanning, and of course, offline wallets (with a pretty interface). I would argue that it is absolutely better for just about everything -- you get the deterministic, only-backup-once-ever wallets, with a print option, you get multiple wallets, and you have an easy transition to using offline wallets. I'd like to think that its design takes the best parts of Bitcoin-Qt/bitcoind and adds everything it's lacking. I haven't touched bitcoind for about 12 months, except to install it so that I can run Armory. And soon I'll have that hidden, so the user won't even see that. But they do still have to download the blockchain. As far as I'm concerned, that's the price of security. |
|
|
|
|
Armory has arbitrary transaction lookup, but armoryd is fairly immature and has a stupid crash-on-every-new-blockfile bug (every week or so). But if you're just using it to for arbitrary lookup, you can add a function call to the python code to get any information you want about any transaction. Hopefully that bug will be fixed in the next couple weeks.
It's very straightforward if you can access it via python code (armoryengine.py). You can checkout the project and check extras/sample_armory_code.py for how to access arbitrary blocks & transactions.
I don't recommend it (yet) for a production environment, but it is usable for lots of things.
|
|
|
|
A digital backup is a copy of your wallet file. If your wallet is encrypted, so is your backup. If your wallet is watching-only, so is your wallet. If you have a digital backup and you haven't forgotten your encryption password, it's like a paper backup. More about it, here: https://bitcointalk.org/index.php?topic=152151.0 |
|
|
|
|
Ironically, that's the kind of transaction the network likes. It is tidying up the UTXO set for everyone -- that's 657 UTXOs that everyone used to have to store and track, now they only have to track 2.
The point he was trying to make, without being knowledgeable on the subject, is the possibility that people could flood the network with spam. The thing is, the network already has spam protection -- that's what fees are for. The system could be improved, but I wouldn't call it the "Achilles heel". At worst, we have an inconvenience.
|
|
|
|
Somehow Armory isn't reading past Block 229672. Can you do something for me. When you start Armory and it starts scanning, you'll see a bunch of lines like this: Opening file 44: /home/alan/.bitcoin/blocks/blk00043.dat
Opening file 45: /home/alan/.bitcoin/blocks/blk00044.dat
Opening file 46: /home/alan/.bitcoin/blocks/blk00045.dat
Opening file 47: /home/alan/.bitcoin/blocks/blk00046.dat
Opening file 48: /home/alan/.bitcoin/blocks/blk00047.dat
Opening file 49: /home/alan/.bitcoin/blocks/blk00048.dat
Opening file 50: /home/alan/.bitcoin/blocks/blk00049.dat
Opening file 51: /home/alan/.bitcoin/blocks/blk00050.dat
Opening file 52: /home/alan/.bitcoin/blocks/blk00051.dat
Opening file 53: /home/alan/.bitcoin/blocks/blk00052.dat
On my system, the last one is blk00052.dat. Can you check which is the last one listed there, and then check your /home/user/.bitcoin/blocks directory and make sure you have the same number. It's almost like it's not seeing the last blockfile... |
|
|
|
Bump.
I get these crashes as well. Is there a branch, different from master, that I should try?
Nope, this is a bug that I've tried to fix a couple times, and I have some pretty brutal unit-tests to try to squeeze it out (which pass, by the way), but it still fails on the actual network. I would spend more time to fix it, but it's actually going to become irrelevant in a couple weeks. When I get the persistent blockchain utilities implemented, I won't even be reading block files any more and this won't be a problem (I will use it for full scans, but not for each block update). This is also why I haven't spent much time on armoryd... because it's not very useful as a server if it's just going to crash like that every few days  |
|
|
|
|
@steamboat
Can you PM me the full log file? I can't see the context I need from that snippet. It's obviously abnormal behavior, but I need more info.
|
|
|
|
Hm...strange thing is happening-2. I start Armory, after scanning, it shows Connected (228672 blocks) at the bottom right corner. While 'bitcoind getinfo' telling '"blocks" : 229725'. WTF? Ok, I`ll try git thing it a bit later. That usually means Armory couldn't access the correct/updated block files. Frequently happens if you change your bitcoind --datadir=X, but don't start Armory with the --satoshi-datadir=X. Then Armory is talking to the current bitcoind, but using the old blockfiles. |
|
|
|
I have no idea why I didn't do this before, but I just realized I don't have to wait for official releases to sign my commits. I can sign intermediate commits with my personal, online GPG key. I'll still sign full releases with my offline key. So I just made the first signed commit. It's the managesatoshi branch, which is currently being used for testing. Though I just realized maybe I should merge it into the testing branch..>? Anyways, you can see the signature by importing the public key 0xFB596985 and then doing "git log --show-signature" inside the directory. It looks like all my Class2 SSL certificates are free (now that I've paid for the service), so I guess I could do the same on Windows -- keep a lower-security signing key online to use for testing releases... |
|
|
|
Do the following: git checkout managesatoshi
git pull origin managesatoshi
git log --show-signature
That should spit out the log and show you the signature. My personal GPG key is 0xFB596985. |
|
|
|
I`d like to, but I`m a little bit paranoid Can you sign package somehow, since git checkout from github is not done even with ssl. Maybe I`m wrong, I am not really good at compiling and programming stuff. You bring up an interesting point. I have been "inconvenienced" by having to go to the offline computer for signing. But there's no reason I can't sign the intermediate commits with my personal, less-secure key that is on my online computer, and switch to the offline key for major releases... hmmm Let me see what I can do... |
|
|
|
|
Hey, I don't want to be a drag, as I'm sure it's been mentioned a bunch of times -- but I've actually skipped your store and bought from Amazon because I didn't realize you had certain items. It's just so difficult to find anything.
You desperately need to put your high-demand products up front. If nothing else, put a couple featured things up front like your Sony Xperia smartphones. That's something that lots of Bitcoin users would actually buy, but it's impossible to find it because I have to go through stuff like shaver accessories.
If you can't improve the search function right away please add links in the front, to pre-configured listings showing high-demand items. This is critical to getting people to actually buy stuff. I'm a developer, I know how much work it is to revamp a whole portion of your product (the searching), but you can at least fill in the gaps for now, without much effort by doing this.
|
|
|
|
Hi etotheipi! Strange thing just did happen. I tried to sent 1 btc from wallet and apply coin control functions. I could send it only with third try, Armory said that "Blockchain is not accepting transcation blah-blah" or something similar. After 3 tries, this window poped up again, but transaction finally get to the blockchain and it was visible in transactions filed of Armory. After ~30 min I opened Armory again (it was minimized): that transaction disappeared and balance show previous numbers like 1 btc was never sent. Restarting didn`t work...how can I do rescan in Armory so it will see this transaction? I use Arch Linux + bitcoind 0.8.1 + Tor + Armory 0.8.7.2-beta.
P.S. What is mempool.bin file? Deleting it changes nothing.
Can you find the transaction on Blockchain.info or blockexplorer? Make sure it wasn't a double-spend. Transactions don't usually disappear from the ledger, unless a block came in with a conflicting transaction. Next, when it's online, can you see that the block-count in the bottom-right corner is the latest? Make sure the number matches the latest block on the network (latest seen on blockchain.info). If it's behind, that's why it's missing ... Armory doesn't have access to all the blocks for some reason... mempool just holds zero-confirmation transactions. If you delete it when there's a zero-confirmation transaction in your ledger, it will disappear on the next load. |
|
|
|
Has there been any progress on updating the offline bundle to support these scripts?
Actually, I haven't because I wasn't ready to release yet. But Linux seems pretty stable. I might as well. I'll do it (and sign it) if you checkout the latest "managesatoshi" branch and test it online for me (in Linux). |
|
|
|
I have interface details to work out on that front. (like, company creates master wallet, and gives each employee their own subwallet/chain. It could be a full chain or watching-only chain. The point being that the company can sweep each employee's work-wallet at any time, refill it, or just watch/verify what they're doing. Or a company can create sub trees for each location, which get broken down by department, then employee, and maybe even further. A question I had about BIP 32 that I never saw a conclusive answer to is how much of the total tree can be recreated from the private key of a single node. I hope it means an employee can use his private key to generate the private keys of all descendents from his node, but not those of sibling or ancestor nodes. I thought that was the idea, too, but reading over the proposal, I'm not 100% sure: "Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key). This means that extended public keys must be treated more carefully than regular public keys." From: https://en.bitcoin.it/wiki/BIP_0032There's a lot of discussion about this right now. The nature of the offline/watching-only wallet split, makes it possible to actually go backwards up the tree, only if you have the private extended key for the node, and the public extended key for the parent node. That's why BIP 32 may be changed. We are pretty sure we can avoid that. |
|
|
|
For simplicity, users can use the alternate Ubuntu install CD, which has an option for encrypted LVM, and includes encrypting swap. It encrypts everything but the /boot partition.
Exactly what I used to install my offline machine :-) As for NTFS journaling, I actually have no idea. I don't want to gamble on it. But I do know that FAT32 will have the desired behavior.
As does ext3/ext4 with data=ordered, of course, but I assume we were talking about Windows - at least, I assume you're not advocating the use of FAT32 on Linux systems :-P Well you can't use FAT32 as your OS drive in Linux, but you can still use FAT32 partitions in Linux. If you can't use full-disk-encryption, at least you could put your wallet on a FAT32 partition and shred the hell out of any files that are put there. As you mentioned, the SSS splitting does have that problem right now. |
|
|
|
|
Show Posts
) I try set lower then 0.0005 but armory don't let me do it its bolox....
