Exchanges that can’t lose or run off with your coins

Edit: I changed some things in this proposal after reading hashcoin's suggestions below

The idea here is for exchanges to be relegated merely to issuers of national currency-backed digital currencies.  These digital currencies could then be traded for bitcoins directly, through any escrow (necessary due to Bitcoin's delayed finality of settlement).  Hashcoin's idea here https://bt.irlbtc.com/view/25786.0 could then be used to allow the bitcoin seller to avoid the need to trust the escrow.

If necessary, the digital currency issuers can avoid AML/KYC requirements by limiting redemption amounts or comply with them by requiring ID, and limiting the anonymity in the digital currency’s architecture via e.g. anonymity revoking trustees.  Irrevocability must be cryptographically ensured, but fraud can be compensated for by charging appropriate fees.  I imagine that these fees could be per user, and based on some kind of reputation/cosigning scheme, so as to reduce the "fraud tax" paid by those that are clearly trustworthy.  This would also result in much greater liquidity, and allow for easier exploitation of arbitrage opportunities.

The UX would be such that you must manage your own keys to your digital currencies.  But I see no reason why the same model that WebCoin will use can’t be used here, so that you only have to keep one key safe that is never updated and rarely used.

Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) can be used here for issuing the digital currency, but needs further work in order to incorporate backdoors for KYC requirements.

Very low trust bitcoin mixes

A group of mix operators can get together, announce that they're running a mixing pool that closes at some future block.  They would select an untraceable, unlinkable digital cash server, operating as a Tor hidden service, that would create a single bitcoin address that pool participants would send their bitcoins to in a cryptographic exchange for an equivalent amount of digital cash.  The participants would do this via bitcoin transaction scripts that also ensure that

1) future transactions from the address require unanimous consent from the mix operators (using CHECKMULTISIG)
2) if unanimous consent to distribute them is not reached within some timeframe, then the coins are automatically returned (using nLockTime)

Upon recipt of the digital cash, the participants break it up into pieces of desired standardized sizes, which are necessary to maintain a large enough anonymity set.  Once the pool closes they request redemption of these pieces to newly created individual bitcoin addresses.  If after all the redemption requests come in there are enough bitcoins in the address to satisfy them all, then the digital cash server has clearly not cheated by overissuing, and the mix operators can safely release the bitcoins.  If not, then they are all either returned immediately to their original owners if the mix operators are still present and cooperating, or they can be claimed by the participants after the specified timeframe via the previously alluded to transaction script.

Notice that the participants are only at risk of losing their coins if not one mix operator is honest.  Their anonymity is as good as what Tor can provide them when communicating with the hidden digital cash server, as well as the size of the anonymity sets in the relevant standardized bitcoin quantities.

Of course fees would be charged in order to make this economical for all participants. The blockchain fee per participant scales proportionally to the number of pool operators, while the costs incurred by the mix operators and the digital cash server are proportional to the number of participants, and are relatively small compared to the overall blockchain fees.

If all this works, it would be nice to have a client that can easily interface with these mixes, will only spend your freshly mixed bitcoins without annoying warnings, will manage everything in such a way as to minimize mixing costs, and will only run over Tor.

And speaking of Tor, how anonymous is Bitcoin run over Tor?  Apparently BitTorrent isn't at all (http://arstechnica.com/tech-policy/news/2011/04/not-anonymous-attack-reveals-bittorrent-users-on-tor-network.ars), so could this also be the case with Bitcoin?

agreed, but the ability to store ones wallet in the cloud is essential for mass adoption.  The faster someone figures out how to do this properly with immediate confirmation, the faster you will be able to use BTC retail.

+1 please move this thread to a better place, it contains interesting ideas

Maybe even make a wiki page? I looks more like you are making a proposal document instead of a discussion thread.

Of course, and considering how much of a pain in the ass getting money into bitcoin via the banking system has proved to be, perhaps it would be easier for people to just build up a trust/credit network from scratch and bypass the banking system.

That's a shame.  If it's scaring away most potential developers, then I guess that's not very good.  I do like his vision of a federation of untrusted transaction servers exploiting jurisdictional arbitrage all over the world

I'm just hoping that the more people know about these technical solutions, the more demand there will be for existing/future service providers to implement them.  Considering how they are repeatedly getting burned, I don't really think many people get how this economy should/could look.  So organizing this on the wiki sounds like a plan.

Good ideas.

The problem isn't bitcoin  being secure. The problem is whatever is being purchased with bitcoin isn't secure on the same level.

Sending and receiving bitcoin is certain as certain an be. 

We only need need to eliminate the uncertainty of of the product/service bargained for. Then there is no need for trust at all.

I'm thinking of a fractional reserve insurance association. Because bitcoin is so certain you only need to insure the risk of loss/damage of the non-bitcoin half of the bargain.

Exactly.  That's the idea behind the smart contracts that would be in heavy use in all of these proposals.

This is surely very useful, too.

Well this is the rough draft of what I was thinking.

A wants to sell B a HD 5830 for 10 BTC

A and B join insurance association.

A must deposit 10% of value of any products sold before he can sell. This amount will be recouped if the transaction goes without a hitch.
A and B also pay an additional 1 1/2% of value each to the insurance association. The association takes 2% and put it into an account dedicated to claims payouts.
The 1% left is for operational costs.

The claims account will accumulate money to pay claims. At the end of each quarter, the total transaction value will be computed. Any monies in excess 1 1/2 times of the transaction value for the highest month will be refunded on a prorated basis to each participant.

Now the actual transaction will work like this.

The Bitcoin send will ALWAYS happen first.
If B experience a non-delivery or receives a damaged product and A doesn't fix it to B's satisfaction , the A's 10% reserve is released to B. B makes a claim on the insurance and receives the other 90%. A's reserve will go up 10% for every claim against them.
In the event B is the rip-off artist and making meritless claims, after 2 claims B must deposit 10% plus another 1 1/2% increment on top of the other 1 1/2%. Each additional claim will increase his deposit required for the next sale by 10% plus 1 1/2% consecutively.

Fraudsters will eventually be priced out.
If everything goes right A get's the 10% back and at the end of a quarter gets some of the 1 1/2% refunded. B get's security that he won;t experience a loss and will also recoup some of the 1 1/2 %

There are still several weaknesses that need to be addressed such as people creating multiple identities but that is the general drift of it.

Honest people will have no problems and will recoup money commensurate with the honesty of the association.