You're right!   It doesn't use the https links!  It looks like there's no problem simple swapping http for https, so I'll go back through my scripts and make sure that's done in the future.  Nice catch!

The "Remember for future transactions" does save the setting just for the wallet you're using.  I just verified that's how the code is written.  Let me know if you don't see it behave that way.

If the wallet has one address, then checking "send change to first input address" and "Remember" should forever keep the coins circulating through that single address.

Currently, Armory chokes when inputs come from multiple wallets.  At least it should -- I remember putting in error/warning messages about such transactions (at least for offline signing).  But I never tried it to see what would happen.

Isn't this entirely resolved by the customizable change address option "Remember for future transactions"? (in expert usermode)

Let's say I was going to have wallets without any deterministic components, and without the ability to generate new addresses.  If you create such a wallet and import a key, and then you send a transaction... where is the change supposed to go?  How is Armory supposed to handle this?  The way I see it, there's only two real options: (1) send it back to one of the input addresses (first option), or let the user specify where to send it (second option).  Both options are available, and can be remembered between loads by checking the box.

The only gap I can think of is the case that the user wants to send change back to one of the input addresses, but not the first one.  Perhaps they want to see a list of input addresses used and want to pick one.  I can't see that being useful enough that it would be worth the implementation time.

---

Since this thread is titled "New Wallet Format", I will link to my other post where I mention a bunch of features the new wallet will have:

https://bitcointalk.org/index.php?topic=56424.msg1489639#msg1489639

That list may not be complete, but it should be enough to understand what I'm doing.  One thing I left out, is that it will have wallet-recovery challenges:  a user forgets their passphrase and wants help brute-forcing their wallet, but doesn't want to just post their entire wallet for everyone to see.  Armory will produce a nice block of text that they can post/email someone, which will fully describe a way to find the passphrase, but without giving the helper access to the wallet.  Furthermore, the person helping will be able to *prove* they found the passphrase, without actually giving it to the user.  Thus, they will be able to negotiate the terms of exchange.  I'd like to think it's not that useful, but I have had endless requests for help with this, and it's actually quite easy to implement ... so why not?

Yes and Yes. 

Armory 0.87.2 works fine with Bitcoin-Qt 0.8.  And Bitcoin-Qt/bitcoind 0.8 is an order of magnitude faster than the previous version.  If you've been offline for a week, you'll be re-syncing in 5 min instead of 2 hours. 

Yeah, I had made a lot of progress on that, then SatoshiDice took it all back

I will be fixing it for real -- as in fairly-optimally for real... soon.  With the blockchain continuing to grow so rapidly, I recognize this as a very high priority.  Just have to work out some database/persistence upgrades and Armory will see a lot of improvements beyond RAM usage (at the expense of doubling the blockchain on disk, for a while)

While I do plan to upgrade my site to https, it's actually necessary for downloads:  the downloads are hosted at

https://code.google.com/p/bitcoinarmory/downloads/list

Which is HTTPS.  And all the installers are GPG-signed (though I recognize it can be difficult to check GPG signatures in Windows).

As for versions.txt... I need to do something about that.  I was just fantasizing about signing each versions.txt with a hardcoded public key in Armory... but yeah I should just do the SSL thing...



Also, you might have to modify the Armory shortcut on your desktop (right-click --> Properties), and add the following to the "Target:"   


Put both of those after the existing text in the "Target" field (and make sure there's a space between ".exe" and "--skip...")

I've already described a similar use-case in one of the above posts, but I am considering doing this right now, so I thought it was appropriate to post here what I'm doing, and what the alternatives are.  I want a simple offline computer to conduct trade, and I want to back it up...

A quick note:  One of the benefits of Shamir's Secret Sharing is that if N pieces are needed to reconstruct the secret, having N-1 pieces is as good as having 0 pieces:  you have nothing.  Compare this to some scheme where by you simply split the private key into four 8-byte fragments... if you accumulate 3 of them, you only have to brute force 8 more bytes to get the fourth piece, which is completely feasible.  With this scheme, the last piece could be any N-bit (x,y) pair on the finite field plan, and no one point is any more likely than the others.

I emphasize this, because I don't want anyone reading to believe that somehow an attacker with 7 of 8 required pieces is a threat (outside of the fact that he has less remaining pieces to find than someone without any).  Those seven pieces are 100% useless without an eighth one.  It's one of the beauties of the SSS.

So onto the use case:

Right now, I have a wallet, backed up onto a single sheet of paper.  That sheet of paper by itself allows anyone who finds it, to recover all the coins in my wallet.  I have put a copy of this piece of paper in a safe-deposit box at the bank, for safe-keeping.  If a fire at my house destroys everything, I can still get my coins back with a visit to the bank.

Of course, the paranoids out there are concerned about bank employees snooping.  I would say it's being too paranoid, but to some extent you can't be too paranoid with BTC, since all security failures are completely untraceable and unrecoverable.  It would be impossible to prove that the employee did this.  And declaring that life is unfair does not get me my coins back.  Similarly, someone who breaks into my house finds one of my two sheets of paper will get all my coins.  

This is my point of comparison:  the fragility of the single-backup system.  You want to backup, but you don't want the vulnerabilities associated with it. I would propose a or 3-of-5 fragmented backup.  You put 2 pieces in the safe-deposit box at the bank.  You keep two at your house in different locations, as protection against losing one, and you give the 5th piece to a friend, family member, or your attorney (who should be good at keeping stuff).  Make it 3-of-6 if you are extra concerned about your house burning down, and give one to another friend.

A lot of things have to go wrong for this to fail.  The 2 pieces at the bank are useless without a third one, so no problem with snooping bank employees.  Someone breaking into your house, even if they find both pieces, will get nothing unless they also infiltrate the bank or break into your friend's house, too.  If your house burns down (and somehow both pieces are completely destroyed), you still have a friend/lawyer with a copy which compliments the third available at the bank.  If the banks disappears, you still have three pieces between you and your friend.

And even if somehow these things happen, they will usually not happen at exactly the same time that your offline computer dies.  Bank goes out of business?  Well open your offline computer, decrypt your wallet, and print the two pieces again and put them in another bank.  

And why would we do this instead of multisig?  Well, I don't want multisig.  I am still a single person using an offline computer to operate my business, and it's quite simple to use single-sig offline transactions without any extra complexities (plus, you can only go up to M-of-3 using multi-sig).  I just want a way to mitigate common side-channel compromises that are associated with my backups.

I was short because I was in a hurry to respond.   Now I have 30 more seconds  

The reason is that your bitcoin address is the hash of your public key.  If you use a compressed public key, you get a different hash than if you used the uncompressed key.  The ECDSA is all the same after uncompressing, but you need to make sure you're using the right address.

As such, the Bitcoin-Qt devs decided to add a 0x01 byte to the end of all private keys that use compressed public keys.  If it was not there, then having the raw ECDSA key would give no indiciation of whether to use compressed or uncompressed for hashing to create the address.   For instance -- in Armory, the 0x01 byte will be added when keys are "encoded" to be moved around, but in the file format, they will be stored as 32-byte integers with a one-bit flag identifying whether they are compressed.  That's why it matters.

Because you get a different address.

EDIT:  It's not terribly complicated to implement the correct logic, it's just that I tested the bejeezuz out of the current wallet format, and it is the most sensitive part of the application.  I didn't want to mess with what was working.

If you're not clear on why compressed keys give you a different address and how they are handled in Bitcoin-Qt, you should do a little research before moving keys between wallets.  

Well, I just stumbled on this thread for the first time.  I guess I need to browse the project development forum more often...

I started writing a response here, but realized it's something I had been meaning to express in the more-general thread here.

In summary, I like where justus is going.  Fund the developer to do the work, don't pay for a completed product.  "Completion" is too fuzzy and controversial.  Build and leverage trust, and give developers some leeway to make decision on their own without worrying about their financial security being at risk.

I was just about to respond to this thread about bounties for ultimate blockchain compression, but this was actually something I had been meaning to post in this thread for a while.  So I'm posting it here, because it's a more general thought about bounties and donations, etc, and it just so happens that the UBP/UBC idea is a perfect example of why I propose this:

tl;dr -- I'd like to see us move away from "traditional bounties."  Fund the developer to do the work, don't pay for a completed product.  "Completion" is too fuzzy and controversial.  Build and leverage trust, and give developers some leeway to make decision on their own without worrying about the financial security of their endeavor.

My general thought on bounties:  "completion criteria" is frequently too complicated and too controversial.  The bounty-driven idea might be reshaped, reprioritized and improved over the course of development, at which point the original criteria are no longer valid.  The question of whether the idea was actually implemented becomes controversial.  People will complain the money shouldn't be released until it's 100% done even when 95% of it is completed, and even when it's not clear exactly what should qualify as 100%.  If certain aspects of the design happen to be infeasible, but the spirit of it was still completed, does the developer get 80% of the money?  0%?  100%?

Some bounties are fairly clear-cut, because the task is relatively simple and well-defined.  A task as epic and complicated as Ultimate Blockchain Compression is going to fall into this gray area.  Parts of the idea may be found to be infeasible, major aspects of its implementation may be swapped out with something better/similar/possible in order to try to achieve results.  Additionally, for some bounties, it may be found to be completely infeasible, period.  Should the developer who spent 3 months demonstrating that it was infeasible be left with 0% of the bounty?  Strictly speaking, he still made a valuable contribution to the community (probably because he kept a thread going and collaborated with lots of smart people to try to figure out how to work around problems, and there was no reasonable path forward).  If the bounty is supposed to be released only upon completion, even users who otherwise would be satisfied with his work may have to give into others who argue that he didn't do the job, he shouldn't get the money.

So what's the solution to all this?  Not bounties (in the traditional sense).  Just like justusranvier posted on that thread, the solution is trust -- you are donating money to someone you trust to put in a reasonable amount of effort to solve your problem in reasonable time.  Someone whose judgment you trust to do the right thing, and make good decisions, which may involve changing directions of the original task for various reasons.  It would be best if a task was not held hostage to the complaints of users who don't understand the technical complexities of what is being implemented.

This works in the long-run:  developers solicit "funding" to accomplish some task that would otherwise be covered by a bounty.  There may be a threshold, or it may be part of a series of funding whereby the developer agrees to work primarily on the task that receives the most funding.  Then the developer receives the money and does his best to complete that task.  This has the added benefit of providing financial security to the developer. 

If that developer does nothing -- well then people will be pissed at him and he won't be trusted anymore.  He won't receive any further bounties/funding.  If he's untrusted  at the beginning, he wouldn't have received the money at the beginning.  Someone who has very little reputation may develop reputation by presenting evidence that he has already developed some significant portion of a task that would otherwise receive funding.  Therefore, he develops reputation by "donating" his own time to a project with no guarantee of receiving money, and people are willing to give some money to see it completed.  After that, donors can judge how much bang they got for their buck (bang for their bit?), and offer their money to someone else if they were unhappy.  

Discussion on the forums will aid in smoothing out the opinion -- those with more technical background can help inform others how challenging certain things and whether the developer is BS'ing about why things don't work.  Not everyone will be happy, but I think satisfactory equilibria can be reached.

This is not too much different than "the real world", I just got there by explaining why "traditional bounties" are not ideal for some of the things we want the most.  In the business world, companies get contracts from other companies (sponsors) to do some kind of work.  Usually something small, at first, until there is some trust built up.   The sponsor periodically receives status updates and decides whether to continue funding after the contract period is over, and/or whether to hire that company for other tasking as well.  If the company doesn't meet their needs, they go contract with someone else.

---

So in practice, how does this work?  Most importantly, the donors/contributors must be willing to give money up front.  It doesn't have to be one year's salary all at once:  perhaps the developer claims he needs $2k/month to do it and it will take 9 months.  So $6k will be raised to support him for three months.  After that, people will have the opportunity to give him more money if they like what he's doing.  If they don't give it to him, he's likely to stop developing it and work on something else.  This creates a feedback loop where people who originally wanted to see it done, will want to contribute more to see development continue (it would be a waste for all that work already done to be dropped).  Or maybe after three months it will be deemed infeasible (either by the developer himself, or by the donors), and the money will stop.

At the moment there must be trusted third parties to collect and hold the money, but only to the point that funding goals are reached.  The criteria for releasing the money is simple, and creating new bounties/campaigns is also simple.  In the future, assurance contracts can be used, at least for Kickstarter-type (all-or-nothing) funding.  

For reference, Armory's wallet format is documented here:

http://bitcoinarmory.com/armory-wallet-files/

Armory, at one point, also had code for reading the Satoshi wallet, encrypted or not.  The code was based on pywallet's code.  However, that code is commented out because Armory couldn't support Bitcoin-Qt's switch to compressed public keys.  Thus, there actually is not a way to convert new wallets to Armory format, because it will calculate different (incorrect) addresses for the private keys.  This will be fixed soon in Armory (with new wallet format), but I suspect Armory won't be the only app that has this problem.

Once I get Armory's resource usage down, then it too will run in the background, along with Bitcoin-Qt, bitcoind.  The user will just keep both programs up.  Running and keeping Armory open will be done in the same way that users would run and keep Bitcoin-Qt/bitcoind open all the time.

The problem with your logic is assuming that more than 10% of target users understand or care about these details.  They heard about Bitcoin from a friend and want to get some coins and buy stuff from Bitcoinstore.com because it has good prices.  I have instantly lost that user if they have to install multiple programs and follow directions to start it.  And it's unnecessary -- I can manage it myself, and they'd prefer me to manage it for them.  This can be win-win for the vast majority of users.   And its default behavior can be the same as bitcoind/-qt:  minimize to tray and run all the time.  Nothing's really different than the way they run bitcoind/-qt, except they have a much more powerful interface on top of bitcoin-qt.

For the 10% of users that do care/understand:  that's what the "Allow using existing already-open Bitcoin-Qt/bitcoind instances" option is for.

Vanitygen should still be using uncompressed keys, and most other programs still use uncompressed public keys.  I noticed in the bitcoinj 0.7 release notes yesterday, that they just started using compressed public keys by default.  All apps will be moving in that direction, they just haven't yet. 

If your wallet was created after Satoshi client version 0.6, and you export your private key and import it into Armory, you will get a different address. 

In fact, you won't even be able to import it, because the core devs added an extra 0x01 byte to the end of these private keys as a way to distinguish that they are supposed to use compressed public keys (and thus will have a different address).  Armory will not recognize the 33-byte private keys, and will generate the wrong addresses. 

I used to have a "Bitcoin-Qt Wallet Migration Tool".  I finished it and integrated it about a month before the Bitcoin-Qt devs made the change.  I tried to keep the migration tool in there for users who would benefit from it, but I ended up with users complaining about how Armory was broken because it claimed that they could migrate their wallet, but it never worked.  It was much simpler and more-pleasant to just remove it altogether than to try to explain the complex situations in which it will work, and that situation is actually quite rare by now.

It switched over in satoshi client version 0.6.  That was a about a year ago.

Thanks Erebus, I will play with that. I had seen something about CACLS, but didn't realize that's a ubiquitous, reliable cmd tool in Windows.  (it looks like icacls is the one to use, actually; cacls has been deprecated, apparently).

---

As I implement this solution further, it's feeling very hack-y.  I know it's not elegant.  And I'm likely to have problems with non-standard installations, etc.  For standard setups it looks like it will work fine, and in some cases I will be installing/copying with a standard configuration.  But I am wondering if there's a better way.  One thing that crossed my mind was that I could try to jam all the Satoshi code into a library, and change the main() function to a regular function that could be called in a separate thread from inside Armory.  Then I don't have to deal with any of this multi-process stuff...

But that comes with it's own inconveniences -- mainly that the user no longer gets the choice about which bitcoind/-qt version to use, and I have to a lot of work to integrate and compile new version of bitcoind directly into my codebase (this is probably pretty ugly in Windows).  I have to manually integrate and modify each new release of the satoshi client, and if, say, there was a critical vulnerability/update to the satoshi client, I would have to critically update and release a new version of Armory immediately.

I just don't feel like there's any clean solutions here.  But I feel like something must be done to improve accessibility -- having specific requirements/instructions for downloading and installing a separate program, and then not starting/initializing Armory until certain conditions are met... it's a lot to ask of marginally-interested users who don't really understand Bitcoin...

Since a bitcoin address is the hash of the public key, if you use a compressed public key you get a different address than using the same, uncompressed public key.  As such, the same private key can be associated with two different addresses (one for compressed and uncompressed).  Right now, Armory would compute the wrong address, even if it could uncompress the keys.

The correct behavior is not super-complicated once you have the code to compress and uncompress the keys, it's just that the old wallet format and code/algorithms have been very thoroughly tested and are rock-solid.  I didn't want to risk breaking that to support this... especially when I'm soon going to have a new wallet format that will have to go through all that testing again, anyway... might as well do it all at once.

That actually won't work either, because the current wallet format of Armory (and underlying library code) doesn't accommodate compressed public keys.  Trying to import them will just cause errors.  As I keep mentioning the new wallet format:  it will handle compressed public keys -- in fact it will use them by default.  But until then, the support isn't there.

For now you're just going to have to send the funds through the blockchain to get it to the new wallet.  I recognize not everyone finds this solution satisfactory (they'd like to take some addresses with them), but it's the best I can do for you until the new wallets are complete (which unfortunately have become slightly lower priority in favor of upgrading Armory's resource management).