This is basically a non-issue.  Just interpret the timestamp as the lower 32-bits of an infinite timestamp.  It "wraps around" every 138 years, and it's pretty easy to figure out how many times it's wrapped since Bitcoin was created, so it's easy to convert the stored 32-bit value, into your own 64-bit value.

Look at Ufasoft which attempts to do exactly that.  One wallet that is used across multiple chains, and tracks each balance individually.  I don't know much about it (never used it), but it sounds like exactly what you just requested.  Also discussion about it here:

https://bitcointalk.org/index.php?topic=58821.0

If we can figure out what format blockchain.info expects, I can add support to make sure it works.  Right now, I just don't know.

First of all, are you trying to import the paper backup?  If so, that's not going to work, because the paper backup is not the same thing as a private key.  That paper backup is the seed that generates all the private keys in your wallet, and no other app knows how to do that.  To get to the actual private keys, you have to go to "Backup Individual Keys" and copy either the "PrivHex(BE)" or "PrivBase58" fields into blockchain.info.

If that isn't working, it may be that there is spaces inserted in the keys to help you visually parse them (in case you had printed them).  You might try removing the spaces then put them into blockchain.info.  If that works, I'll add an option to the "Backup Individual Keys" dialog to remove the spaces.  Also, maybe the prefix on each line is causing a problem...?

To clarify kjj's point a bit further: you must remember that Bitcoin is a consensus system.  Transactions are not "real" until there is some degree of consensus that it is valid.  This is done by including it in a block.  Therefore, broadcast time, while may be interesting for you, is irrelevant to the system.  The proof-of-work associated with each block is consensus-building feature of Bitcoin, and that transaction doesn't really "exist" until it's in a block.  

Therefore, you use the block timestamp to determine when the transaction first received any degree of "consensus".  The actual broadcast time would not only be a waste of space, not everyone has the same clock, or received it at the same time.  That's part of Bitcoin's charm, is that it can work with millions of users, many of whom are scammers, and some of which are behind slow internet connections and don't see all the traffic.  But it still works.

When Armory displays your transaction, it's only displaying the timestamp on the block in which that transaction was included.  From Bitcoin's perspective, all transactions in that block happened at that time.

You are correct.  They only have to attack your passphrase.  However, Bitcoin-Qt and Armory both use "key-stretching" which is guaranteed to slow down key guessing by a couple orders of magnitude. 

Bitcoin-Qt uses the simplest version -- the password is hashed 25,000+ times to get the encryption key (the exact number is chosen based on your system's speed).  This means that you either try to brute force the encryption key directly (impossible), or you try guessing the passphrase but requires hashing each guess 25,000+ times.  This dramatically slows down an attacker.  But, GPU acceleration is feasible on this, because hashing is so cheap in terms of RAM and simplicity.

Armory uses something more advanced, related to scrypt.  The password isn't just hashed N times, each hash is saved into a lookup table which is then used for another N lookup operations.  This means that they not only have to do the sequential hashing, but each thread that is guessing passwords needs to have N*64 bytes of dedicated RAM to store the lookup table, and that lookup table is specific to the passphrase being guessed (so threads can't share it).  This makes it pretty much useless to apply GPUs, since much of their speed advantage is due to having only a couple kB fast memory per thread, not megabytes.

Armory also tests your system speed to set the parameters to about 0.25sec.  If you use a single CPU on a completely randomized 6-character password, it would take about 500 years for 50% chance to find the password.  Obviously, attackers may have multiple systems/cores to parallelize this, but they have to use CPUs, because of what's mentioned above.  Therefore, if you use approximately 8 characters of real entropy, it's pretty much useless for someone to try, even if they have extraordinary resources.

Of course, people use weak passphrases.  But there's only so much you can do to protect people from themselves...

You might consider doing Red Emerald's brew formula if that's all you want access to.  Obviously, it would be better to just have this work, but apparently the dependencies are still not totally standalone/bundled yet.

I don't think so.  If you are at ABCD and it has only 3 children, "ABCDE" "ABCDP" and "ABCDZ", there's still only 3 seeks.  You seek for "ABCDA", and the iterator ends up at ABCDE (which is the first element equal-to-or-greater-than your seek value).  So you know that's the first child, and that there's no point in seeking for "ABCDB", "ABCDC" etc.  Then your next seek is "ABCDF", which puts you at "ABCDP".  Rinse and repeat.  

WarriorOwl,

Thank you for your criticism/suggestions/comments/whatever you're calling it.  I am in agreement with it.  I just wanted to clarify, though, the "getting the next upgrade out" is not new features.  It is reworking Armory under-the-hood to gain this stability.  The way Armory was designed to interact with Bitcoin-Qt has proven to be unreliable.  And my attempts to deal with them without an overhaul have proven fruitless.  There's a reason there have been no real new features recently, because I'm working on upgrading the engine to be more stable and scalable (and to make the app more usable).

Armory is a big program, and I'm one person.  No one else helps me with it.  And I agree there's a lot of technical debt (I'm a mathematician first, SW dev second).  I hope to get time to deal with all of that, but I do have to prioritize.  My priority is getting the improved blockchain engine implemented that will not only solve 90% of these stability issues, but also be extensible to accommodate future growth. 

I don't blame you for not trusting it, though I recommend considering Armory's excellent track record in your decision.  It's been in use by thousands of people for more than a year, and no one has lost money with it (who made a paper backup).    The parts that matter for wallet security have 1000+ lines of testing code, and I have refused to touch it for even simple upgrades because of risk of breaking its stability.  The interface around the wallets may have some stability issues, but the important parts don't.

Armory is still beta.  It doesn't get its gold status until it achieves what you are suggesting.  And I don't know how when or how it will get there without others contributing.  If it has to stay in Beta for this reason for another year, so be it.  Until then, it's up to you to decide whether this beta software is up to your standards of trustworthiness, given that various compromises had to be made.  My personal [but biased] opinion is that you should consider it anyway, because the wallet security is tested and proven.  That stability of UI may not be, but serious Bitcoin users who seek the security & features will look past that. 

I'm working as hard as I can on the new blockchain engine to fix these issues.  I hope to have it in a couple weeks. 

-Alan

P.S. -- The one exception to the above prioritization (so you are not suprised), is that I will be at the conference next week, and have a couple demo features to finish up. So I am taking a short break to finish those, but will return to the stability-enhancing features after that.

Just throwing it out as an option.  If your existing app doesn't have a feature, you can always use one that does have it.  A lot of people just simply aren't aware that these alt clients exist.  You don't have to be comfortable with it, but you should know it exists.

As for backups... anything that requires a persistent backup solution will fail in the long run.  It won't fail for everyone, but it will fail enough that people will lose money unnecessarily.  Even if you are savvy and diligent, your backup solution may work for 6 months, then you reinstall your OS, or change computers, or your backup drive dies, and you procrastinate on fixing it and setting everything back up again (or you simply forget to re-enable it).  For most things in life, this is unfortunate, but not life-crushing the way losing your primary wallet would be. And now that you have to do persistent backups, you can't do them securely, because it needs to be easily replaceable for the next time you need to backup.  So you make multiple copies, you scatter them around, you keep them nearby.  There's always a risk.  There's always this uneasiness about whether you are sufficiently backed up.

This is why deterministic wallets are so epic in terms of Bitcoin usability.  You make your one backup, ever.  And it's 100%, forever.  You secure the $#!+ out of it (safe-deposit box, bury it, whatever), because it doesn't need to be replaced frequently.  You do it right, once, and forget about it.  And you can print it out on a sheet of paper which is guaranteed to last decades, unlike the digital media you have to save your 1000 private keys on.

Right now, I enjoy having a "market advantage" over Bitcoin-Qt in terms of helping users backup their wallets, but BIP32 really is a necessity for the long-term viability of Bitcoin (or any deterministic scheme).

Well, let me know when you do.  I am always happy to help people get into it (and maybe they'll eventually help out, too ).

If you want to do some of your own exploration, download the repo and look at the "extras" directory.  Specifically:

sample_armory_code.py (lots of simple examples)
cli_sign_txdp.py  (for signing offline transactions from the command line)
createTxFromAddrList.py  (for creating an offline tx from online computer)
findpass.py  (for when you forget your wallet passphrase but remember enough to make brute-force feasible)
frag/unfrag_wallet.py (splitting your paper backup into M-of-N pieces)

Some of it was created a while ago before some major updates, so it may not all be 100%.  But I've tested most of it recently.

I just investigated this myself on my Android device.  I'll give it a 5/5 once you get it set up, but I had a little difficulty with that part.  You must add yourself as a contact for it to work.  It somehow auto-detected me, but the wrong email address, and my gift card was sent to the wrong one.  Once that happened, it was a total mess.  My android device was already linked to the correct address and I couldn't switch logins.  And I couldn't access the gift card without signing up with the other email address.  And even when I did, the web version of it didn't let me return or re-gift my card, and I couldn't switch the user login on my phone to do it.  I finally figured out how to add my alternate email to my Gyft app, but it didn't see previously sent gift cards.  Ugh!

In the end I gave up and used the web interface to redeem it on the Amazon website.  I then removed the bogus contact and now all gift cards end up at the right place.  That would've been super annoying if it was one of those gift cards that you scan at the store, but luckily I picked Amazon which is stupid simple to redeem from a code.

After that, I tried again and it worked fine.  In fact, too well.  I had the gift card in a couple minutes and used it successfully for my next Amazon purchase.  It almost feels dirty... it feels like money laundering.  If this gets big, I'm curious how that will play out. 

Until then, it does seem to give you another option for paying regular people with BTC:  if they have the Gyft app, and you owe them a nice round number of USD (multiple of $5 or $25), then you can instantaneously buy them an Amazon gift card and send it to their phone.  That's something most people can use, and you (as the consumer) basically take no hit on conversion.  Nice.

Ahh.  You know I never used easy_install, but I just tried it.  That really is easy! 

Okay, it works now.  I might have to dig in a little bit to tweak things.  But it looks like exactly what I wanted.  PM me a payment address.
Thanks jackjack!

You can do this pretty simply as a python script.  Here's the entire script:


Here's the output of that script:


Wrap that in a socket server or just invoke it as a system command.  Each call accesses the wallet file, calculates the next address, then marks that address as used in the wallet file.  

This will be a pain in Windows.  But if you're in linux, either install it or build from source.  Then you only need:  _CppBlockUtils.so, CppBlockUtils.py, armoryengine.py.  If it complains about needing anything else, you can probably just comment out those portions of armoryengine, which are unrelated to this operation.  Or just bundle the whole directory with it.

EDIT: actually checking whether money has been received is another story.  Likewise, creating transactions to be signed like this is possible but not trivial.  Let me know if you are interested in doing any more with it.

Code looks good, but I can't try it because I don't have the ecdsa module.  What/where is that?

Btw, it is my intention with Armory to do exactly what you just said is out of scope.  There's no reason to optimize the case of multiple wallets coming from the same seed, because most of the time you don't ever want a single device seeing all the keys.  You want your phone to create one key, your computer to create another key, completely independently.  In the case of a big organization, you want different branches to create their wallets independently, and swap pubkey-chaincode pairs.  They need to do that to guarantee that no one employee ever has access to all the pieces.  And that all the pieces are never geographically co-located. 

Plus, if there's, say, a vulnerability in one of the devices' RNG, you'd prefer that it only affect one piece of the multisig wallet. 

There's a lot of possibilities there.  While there may some use cases where keys are generated on the same device, that's far from guaranteed.  In fact, I think it's the opposite, if we want to promote security best practices.

An interim solution would be to use an alternative client that implements deterministic wallets.  Armory and Electrum both do.

That sounds good to me.  We want the standardized encoding/formatting, but don't need to all the flexibility in those serializations, since we have a very static/simple system for Bitcoin.  So clearsign will be identical to RFC2440 for the message, dash-esc, etc, but the signature will only be 65 bytes in base64.  The opaque version will simply be the header & footer, with the the properly-formatted message as you described above, all converted to base64. 

Where does crc24 fit into this?  Was that implemented and used?  I didn't look too closely at where it fit in.  Or was it only useful for the OpenPGP-formatted stuff?

Understood.  It's okay to deviate from RFC2440 as long as it's documented.  The goal was simply to follow RFC2440 to standardize the implementation as much as possible, but knowing that there would be slight deviations from RFC2440 where it makes sense to use our Bitcoin conventions.  I am honestly not going to be picky about it, as long as what is chosen is well-defined and documented. 

Fantastic.


I guess I don't understand.  The point v1 non-clearsign is that you get a single block of opaque base64 that contains the original message and the signature, together.  The user should have no idea what's in it until they copy it into their wallet and it will spit out the message only if the signature is valid.  This is considered ideal since users have a tendency to only look for the message header and trust it without checking.  This way, they can't get the message unless they also check the signature.  

Does RFC2440 not mention how to encode and concatenate this data?  You can see what I'm talking about by just doing a regular "gpg --sign --armor file.txt".  Then when you "gpg -v file.txt.asc" it checks the signature, and writes out the signed data to a file.  I don't need the file operations, but I do want the bundling.  


No, I was just clarifying.  There seemed to be some confusion earlier about where the key recovery should happen.  I was just clarifying that it needs to happen in the python code, but I'll give "extra credit" for the Crypto++ implementation.

Thanks!

Great, I'll look at it when I get some time.  I won't get to it today, so if you want to tweak it any further, go ahead.  Perhaps, also add a few comments there (or here), describing exactly how the v1 signing is done.  Basically, just mention which parts of RFC2440 were used, and how the signature is created exactly (i.e. I assume it matches the version-0 format, but it should be noted).

And while you're at it, can you add a header to the file declaring that the code in this file is being released to the public domain? 

Thanks!