I agree with Meni that this problem isn't exactly "solved", but most of the blackmail concern is mitigated with the two-way "risk deposits" I mentioned above.  The remaining asymmetry is only when one party values money much more than the other party (and doesn't mind losing a few dollars to screw over the other person).

The important part to remember about what I described: 
(1) Both parties contribute money to the 2-of-2 address  (both parties have money at risk)
(2) Both parties put their money in simultaneously  (either both parties are committed, or neither of them are)

Point 2 is important for the blackmail concerns:  if the Risk Deposit is 20%, the buyer can construct a transaction using "SIGHASH_ANYONECANPAY" that allows him to supply 1.2*X BTC to a transaction that has 1.4*X outputs.  This transaction is not valid, and no coins are committed until someone supplies the remaining 0.2*X.  If the seller does not put 0.2*X BTC into the transaction, then the transaction was never valid, and the coins never left the buyer's wallet.  So the only way for the seller to get the buyer to commit coins is to commit coins, himself.  If the two parties are mutually untrusted, 100% risk deposit should be used, so that the seller has as much at risk as he would otherwise gain by being a jerk.

As for the concerns about large transactions:  once transactions are big enough that the risk deposit becomes prohibitive, that's when third-parties should probably be involved as arbitrators (using 2-of-3 tx).  My primary motive is small transactions on the internet, for which getting third-parties involved would cost more than the transaction itself. 

The one thing Gavin and I didn't finish figuring out, was how to allow the coins to be recycled in case of not being able to complete the transaction agreeably.  Gavin proposed time-locked transactions for automatic movement of coins to the seller after some amount of time, but I didn't care much for that solution because one party could abuse it, and the other party would have to find a miner to help them to prevent it.  If time-locked transactions were officially enabled on the network, I think his solution would work, as long as the buyer's wallet app made it easy to replace a time-locked transaction that was broadcast by the seller prematurely.

I like the tabular format.  It helps visualize what's going on here.

I recommend reading through the discussion between me and Gavin about this.  There's a lot of overlap with what you posted, but also some details that we already worked out that you're missing:  https://bitcointalk.org/index.php?topic=75481.0

We referred to the "guaranteefee" as a "risk deposit", and it's something that both parties have to contribute.  It's the only way to make the remaining risk symmetric -- if everything goes smoothly, everyone gets their risk deposits back.  Until then, both parties have financial incentive to resolve the transaction agreeably.   Any off-nominal behavior could result in loss of risk deposit.  The size of the deposit can be set depending on the level of trust (or lack of) between the two parties.  20% might be agreeable for online sellers with reputations at risk, but 100% would be expected between two parties contacting each other on craigslist.

It is possible, with multi-sig and non-standard signature hashtypes, that the buyer can create a transaction including purchase price plus buyer-risk-deposit that is invalid until the seller commits his risk deposit to the same transaction (which will all go to the 2-of-2 "wallet").  It won't be valid until the seller commits a risk deposit of the correct size to the transaction.  In other words, either both parties get their money in at the same time, or no one does.  This is a prerequisite for any contract/escrow that requires money from multiple parties.

Also, I strongly disapprove of key-sharing, for any reason.  Also, it doesn't work if the money is ultimately split at the end  (Alice puts in (1+Risk)*X and Bob puts in Risk*X, and at the end, Alice gets Risk*X and Bob gets (1+Risk)*X).  When one party gives up their private key, there's nothing stopping the other party from taking 100% even if the two parties agreed to split it in some way.   Additionally, it is a potential security disaster for app developers to have to accommodate private keys for which it is epic-fail if they are revealed, but other keys are expected to be revealed.

This is why multi-sig was created (P2SH).  You create a wallet specifically for these types of escrow transactions.  Buyer and seller each generate the next private key in their wallet, and exchange public keys to create the 2-of-2 "address" to which funds will be committed.  At the end of the transaction, one party creates the payout transaction as they'd like to see it (usually (1+R)*X to Bob and R*X to Alice, but could also be a refund transaction, or some split due to wacky situations).  That party signs it with their private key and sends it to the other party.  That party verifies the distribution is correct, then signs and broadcasts it.  No one compromised any private keys, and P2SH was used to its fullest potential

I'm sure your relatives will appreciate you taking your Bitcoins to the grave when you get hit by a bus.

Seriously, people:  if you want a "brainwallet", at least hand-write it onto a sheet of paper, with identifying markings, and pay the $5/mo for a safe deposit box.  I'm sure there's more stuff you'd like to store in there anyway (car title, birth certificate, etc).  Then, when you've forgotten your brainwallet after 2 years, or something unfortunately happens, your relatives will gain access to it and the coins won't be lost forever.

And of course, I don't condone brainwallets -- most people do not create strong enough "passphrases", and of course what I mentioned above about losing coins forever.  If you're going to go this route, boot up an offline computer wiht a linux Live-CD, and install Armory and use it to generate a high-entropy wallet.  Go to the "Print Paper Backup" dialog, and manually copy down all the information on the sheet (you can use a printer if you trust it).  Also copy down the first X addresses so that you have some addresses you can use for putting money into it.  Keep that address strings, and put the paper backups into envelopes.  Put one envelope in a safe-depost box, perhaps another one in a safe.  Live happily knowing that your coins are both secure and recoverable.

But if you're going to do this, you might as well use Armory offline wallets.  It is exactly what I said above, but you also get a watching-only wallet so you can monitor it online and distribute new addresses (private keys never touch the internet).  Spending is easiest if you keep the wallet on the offline computer, but you can just as easily reboot into a live session, and re-enter the paper-backup information to regenerate the wallet each time you need to sign something.  If you don't move the coins often, keeping the paper backup in your safe is sufficiently secure and convenient.

Download from the 64-bit version from the downloads page:  https://github.com/downloads/etotheipi/BitcoinArmory/armory_0.82.4-1_amd64.deb
 
The package should replace itself correctly, but let's assume it didn't.  Go to the command-line and type the following.  First line removes any existing Armory installation, second one tries to reinstall it:


If that gives errors about unmet dependencies, then you need to install them.  Luckily, Ubuntu remembers what you were missing when you last tried to install such a package, so I believe you only need to type the following:



Finally, if that still doesn't work, then explicitly install all the packages you need and try again (found on the Building Armory from Source page):


If that still doesn't work... well I'll reset my Ubuntu 12.04 VM and see if can walk through it from fresh install and try to replicate any issues.  Until then, I think this should work.

Great!   I bet there's a lot of folks who will like this.  I guess I should just warn folks, that Gentoo can be a bit daunting.  I used it once -- "emerge" was great, but everything else was rather difficult.  I'm sure there's plenty of users out there who are comfortable enough with linux for this, I just wanted to put the warning out there. 

Thanks for doing this.  I'll have to update the original post with an index to side-projects such as these.  I love seeing people expand on my work! 

Awesome!  Good to know!  I bet that explains a lot... since I connect as a regular peer, I guess the localhost (Armory) can get dropped if you are at max connections.

I'll keep that nugget of information around for folks who are having network issues.

It should work.  I can't think of why it wouldn't.  Try the latest version (0.82.4):  https://github.com/etotheipi/BitcoinArmory/downloads

I didn't link directly, because I don't know if you're in 32-bit or 64-bit.  

I highly recommend against opening Armory until the blockchain is finished downloading.  Although the latest version is a lot better at "drinking from the firehose", Armory is much happier when it can retrieve all the data it needs from the blkXXXX.dat file.

Wallet files are 100% portable between OS.  You can just copy the watch.wallet file from one system to the other.   There is an issue is if you are trying to merge multiple wallets into one.  There is currently no way to do that, though it is on my development plan.  But I got seriously snagged with the multi-threading (pulling my hair out).



It looks like there's some symbols missing in your CppBlockUtils.  It's not from one of my updates, though, it's an issue with the cryptopp library, somehow not compiling everything into the .so file.   I don't know how you got to your current state, but go to cppForSwig directory and do a "make clean;  make swig" then try again.

That kind of error happens frequently when the program was compiled to dynamically link to a *.so file on your system, but your system has a different version of that *.so file.  That's why I started static compiling crypto++ into libcryptopp.a, to avoid this.  Perhaps you have crypto++ installed already on your system, and your Makefile was modified to dynamically link...?

FYI, I have absolutely no familiarity with the cryptopp Makefile.  It is straight from the cryptopp download, unmodified.  All the stuff in that file is completely foreign to me, only that the hashes of the zip files matched what was listed on the crypto++ website. 

Problems with that line sound familiar though.  I did a good search and found:  http://old.nabble.com/Crypto++-does-not-compile-on-Mac-OS-X-PPC-td29571081.html, which describes the exact problem you specified (I think).  I might as well modify the Makefile to prevent this from causing problems for others in the future (with the exception of causing problems for the first person to try to compile Armory on Sun!).

I'm on my phone right now,  so it's tough to get the link for you,  but I recently committed a script for doing exactly this.   It should be in the master branch, in the "extras" directory.  I posted about it a couple weeks ago,  but I don't remember which thread that was in.   Please let know if you can't find it,  and I'll try to dig it up for you.


 The script requires you to manually specify the location of your wallet and the unsigned.tx file,  but it does work with encrypted wallets,  and gives you a chance to verify the tx details before you sign it.

I'm not sure what triggered it, but it sounds like the memory pool is corrupted.  I'll have to add a button for clearing...

Simply delete /home/<username>/.armory/mempool.bin.  If you are in Windows, it is C:\Users\<username>\AppData\Roaming\Armory\mempool.bin.  That file holds all wallet-relevant transactions that haven't made it into the blockchain.

I'm not arguing against having competition in the world of Bitcoin.  What I'm arguing is that it doesn't exist yet, and if it does, it's not going to happen for free.  And when it does, it will be with much worse intentions than this non-profit made up of people who actually care about Bitcoin.  

The complexity of the protocol and securing the fully-functioning network requires some serious devotion and skill.  The current devs have been doing this for years, for free.  Yes, maybe they made some money from BTC savings.  A lot of people did.  But no one [should] doubt their devotion to the success of Bitcoin, regardless of who they are working for or how much money they made.  These guys are serious nerds, and seriously devoted.   There's never been a reason to doubt that.  Except that you have, in an extraordinary and insulting fashion.  As if devs getting compensated for their time turns them into bloodlusting, selfish scammers.

Because of the complexity of the system, there's no way for competition to exist without salaries.  When it does, it will probably be supported by a profit-motivated "corporate overlord".  We should be happy that the first formal face to the outside world is a non-profit made up of these guys.  Because any other company trying to dive in like this will probably be profit-motivated, and made up mostly of people who don't actually care about Bitcoin.

The reason I was so straightforward in my previous message is because you've offered no evidence that the high degree of credibility developed by Gavin&friends over the years is in question.  Everyone on the Bitcoin Foundation has been contributing to Bitcoin in some way, for a long time.  They've promoted it, defended it, secured it, developed it, and tried to expand it.  But none of this matters to you.  You see that someone gets compensated for their time, and nothing good can follow.

All I can say is, in order for Bitcoin to succeed in the long run, something like the Bitcoin Foundation is necessary:  without it, "Silk Road" will remain the public face of Bitcoin, and it will never expand.  And if some organization is going to come about to try to organize, promote, and maintain the network, we should be damned happy it is these guys.

Your reaction to the Bitcoin foundation is extraordinary and FUD.  The team that works on the main Bitcoin client has not only proved themselves capable, but they have tirelessly fought to keep the network secure and moving forward, and all for free up until now.  To wildly assume that adding formal representation to Bitcoin and compensation for its contributors is the end of Bitcoin as we know it, is quite destructive. 

Whatever it is that you think is going to happen, keep in mind that Bitcoin-Qt/bitcoind is the Bitcoin network right now.  And it will be like that for a while.  I would be scared if these guys were unwilling to continue working on the main client (say, because they need income and were unappreciated).  Regardless of who they "work for", they will continue protecting the network and adapting it to future needs. 

To contrast this to others:  I mean no offense to electrum guys (or myself, working on Armory), but what they we are doing is re-implementing the Bitcoin protocol.  We write programs to interact with the network as it exists due to the Bitcoin-Qt/bitcoind.  But that's not the same as having to evolve this complex system in order to avoid security vulnerabilities and accommodate future growth (and the electrum guys contribute to that, too, but I don't think they could do it alone).  It's a lot easier to implement an existing solution than it is to solve it from scratch.  Gavin and the rest of them are the ones solving these problems.

tl;dr -- Whether you like Gavin and his new position or not, we rely on him and the rest of that team.  All other clients are dependent on the quality of Bitcoin-Qt and bitcoind.  The next major vulnerability that is discovered will be fixed by them.  It's possible to replace them, but not without paying large salaries and risking poorer quality -- and that is exactly what you seem to be complaining about.

EDIT: in the far future when Bitcoin gets bigger, this may change.  But it will change due to corporate influence much worse than this non-profit organization run by the guys that have poured their lives into seeing Bitcoin succeed.

Interesting!  I haven't seen this before.  For offline, there's no reason it shouldn't work, no matter how little RAM you have. 

Are you in 32-bit WinXP or 64-bit?  I imagine an error like that could happen if you downloaded the 64-bit version and tried to run it on a 32-bit OS.

So is reverting to a previously-considered-insecure security model after 6 months, which is long enough for the user to forget about it.

Anyone who handles important documents/information makes copies.  They keep them in a safe place for when they need them.  Bitcoin private keys should be handled the same way.

The math works out fine for any number of keys, but the amount of exchanging of information between devices gets annoying:

Private key is A
Public key of A is A'
Public generator point of the Bitcoin elliptic curve is G.

Device 1:  Creates private key A.  Computes public key which is  A*G = A'
Device 2:  Creates private key B.  Computes public key which is  B*G = B'
Device 3:  Creates private key C.  Computes public key which is  C*G = C'

Ultimately, the combined private key will be A*B*C, and the public key will be (A*B*C)*G.   However, in order to do this, Device 3 needs to give device 2 its public key (C' = C*G).  Then Device 2 can produce B*(C*G)=(B*C)*G.  Then you transfer that to device 1 which can then produce A*(B*C)*G = (A*B*C)*G.   No one device has seen any private keys other than its own (so far).  Send coins to the address associated with that public key.

In order to create the private key, you just collect A, B and C onto the same computer and multiply to get (A*B*C).  Import that into a wallet and sign.  If you want to play with this, I recommend downloading Armory and run it in offline mode (because you won't actually use it for your wallet), then go to "Tools->ECDSA Calculator". 

I don't understand what you are asking:  if your system holding your wallet is compromised already, your wallet is toast.  Get a system that will never touch the internet again, wipe it and put a clean version of whatever OS you want on it.  Install Bitcoin software (insert Armory plug here), and manually copy down the private keys and addresses (in Armory, it is "Backup Individual Keys").  There's your paper wallet.  If you want to "watch" it, produce a watching-only wallet.

In the absence of any good multi-sig solutions, you can do "manual" multi-sig using Armory's built-in ECDSA calculator.  It requires some mathematical prowess, but everything you need to know is on the forums.  The gist is:  create two private keys on two separate computers that have never touched the internet.  Copy/print the private keys on separate pieces of paper and store them away safely.  Copy/print the public keys and exchange them.  Now one computer has PrivA & PubB, and the other one has PubA & PrivB.   Both systems can use this to create a public key that is associated with a private key that is only recoverable when both original private keys are on the same computer. 

You can use this address for collecting money.  Use it for savings.  But it will be a bitch to move:  you'll have to transfer the private key from one computer to another.  Then plug them into the ECDSA calculator to get the master private key.  Create a new wallet and import that private key.  Then sign the transaction and take to an online computer to broadcast.

I don't actually recommend this because it's not simple by any means, but if you are that hardcore it can be done.  That's actually why I made the ECDSA calculator, for devs, and hardcore users like (and for myself to check ECDSA math when debugging stuff).  But it sounds like you're looking for something like this.

Consider the various values of n:

n=1:  1-of-1
n=2:  2-of-3
n=3:  3-of-5
n=4:  4-of-7
n=5:  5-of-9
...

It's any transaction with an odd number of public keys, and any majority subset of those signatures makes the transaction valid.  Democratic money:  perhaps 9 board members on a company all have their public keys in a 5-of-9 "wallet".  Any five signatures is enough to spend it.

Yes, this is exactly what Armory does.  It's why I made it.  As far as I know, it's the only program out there that has a simple graphical interface for managing offline wallets, watching them using online wallets, and spending coins using USB keys.  Your private keys never touch the internet, but you can still generate addresses online with no risk to your funds (only your privacy).   Once you get past the long load times it is a phenomenal solution (and I'm working on the load-time thing for the next release).

This basically is two-factor:  your online computer has to create the transaction, and offline computer must sign it.  In many ways, most things that would compromise this setup would compromise a two-factor auth setup as well.





Armory avoids this security issue by using BIP 10 which actually provides all the input transactions so that your offline computer can fully verify every part of that transaction it is signing, without the blockchain.  This is why it's so simple:  no need to sync the blockchain to the offline computer.  You just save the unsigned transaction to USB key, take it to the offline computer, sign it, bring it back and hit the "Broadcast" button.