Eliminating the need to trust in the Bitcoin economy

[d'aniel]

tl;dr = Open-Transactions' digital cash, Bitcoin's transaction scripts, and Webcoin's key management scheme can be combined in various ways to solve all the trust issues plaguing the Bitcoin economy, without compromising convenience.

Over-reliance on trust within the Bitcoin economy has obviously failed horribly.  I believe it’s largely unnecessary, so I’m starting this thread to try to converge on some better standards that bitcoiners could reasonably expect from their service providers.

I'll start with a few ideas mostly borrowed from elsewhere:

[1713970173]

1713970173

[1713970173]

1713970173

[1713970173]

1713970173

[1713970173]

1713970173

[1713970173]

1713970173

[d'aniel]

Web based wallet that can’t lose or run off with your coins

WebCoin (http://bitcoinjs.org/) seems to have the right model here: They split the private keys between your device(s) and their server, and require you to enter a PIN to access theirs.  The keys are recombined only during transactions, thereby minimizing the time they face the Internet.  If you enter the PIN wrong too many times they lock it, and to unlock it you have to provide a master key that you securely store offline.  All of your keys are derived from this master key, so it provides a backup that’s valid in perpetuity.  You also use this master key to activate other devices.

The UX should be dead simple with Webcoin – safely store one single key that’s never updated, and rarely used, and enter a short PIN when you want to make a transaction.

You do give their server access to your public keys, though, so you end up trusting them with your transaction history.

Edit: This seems relevant:

Not giving you my private keys for storage, but using the data stored with you together with my local secret every time a key is needed.

But how would you see that work with a web service? You could implement a large part of the Bitcoin protocol in JS, but if it is served from the wallet provider, it could steal any key that you enter by injecting a keylogger into the JS as well.

That's the most common argument leveraged against LastPass, and it's indeed valid (see below). The solution, so far not implemented anywhere, is to sign a hash of the JS snippet in question and have that verified by the client. When the code needs an update it has to be vetted before clients approve a new hash or signature.

I believe this is on its way into the HTML specifications but I haven't looked for some time. If we control the client implementation (Android, PCs) it's however implementable already today.



In the LastPass case, they are considered trusted (reputation, company) and the architecture is meant to protect against hacking instead. They take great care to make sure their systems serving up the JS in question aren't easily manipulated, and if a hacker were to extract their databases they still cannot do anything with them since everything is encrypted and only the end users have the corresponding keys.

[d'aniel]

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://bitcointalk.org/index.php?topic=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.

[d'aniel]

Zero trust Bitcoin “accounts”

Edit: I removed the original proposal after reading hashcoin's suggestion: https://bitcointalk.org/index.php?topic=25786.0

In the event that blockchain transactions are prohibitively expensive/time consuming for some use and you might think a bitcoin account on a website is necessary, think again.  With hashcoin's idea described in the link you can have instantaneous, free transactions, without trust, with a single person, all using only Bitcoin's internal transaction scripts.

I figure native the UX would be as follows: clients would allow you to create accounts with people where you optionally enter their addresses if you expect to be receiving transactions as well as sending them, and when you fund it, you'd have to enter a lifetime after which your unspent balance is returned to you, as well as "activate" the funding via some direct communication channel with the person.  I imagine the UX would simplify greatly when dealing with a website, since your browser then provides a convenient direct communication channel.  Any ideas on how this might all look to the user?

[d'aniel]

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?

[d'aniel]

All the tools exist such that we don't need to place very much trust in service providers, and I'd like to see this old model finally abandoned.  If the only complication to the user experience is that they have to safely store a rarely used, never updated private key, then I think that's something most people can easily adapt to.  Notice that this is the exact same UX as Firefox sync, so it's not exactly unprecedented in mainstream use.

[UrbanAdventurer]

All the tools exist such that we don't need to place very much trust in service providers, and I'd like to see this old model finally abandoned.  If the only complication to the user experience is that they have to safely store a rarely used, never updated private key, then I think that's something most people can easily adapt to.  Notice that this is the exact same UX as Firefox sync, so it's not exactly unprecedented in mainstream use.

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.

[d'aniel]

All the tools exist such that we don't need to place very much trust in service providers, and I'd like to see this old model finally abandoned.  If the only complication to the user experience is that they have to safely store a rarely used, never updated private key, then I think that's something most people can easily adapt to.  Notice that this is the exact same UX as Firefox sync, so it's not exactly unprecedented in mainstream use.

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.

I think the important part is having your wallet automatically synced between your multiple "activated" devices, something which the above ideas solve.  I don't think lack of access from public terminals is going to be such a big deal, especially with the rising ubiquity of smart phones.  I'm hoping at least that those for which it is a problem will be exceptions to the rule.

The immediate confirmation problem is already solved using bitcoin-backed digital cash issued on Open-Transactions servers.  But bitcoin transactions via the blockchain are likely already fast enough for retail (i.e. they propagate across the network in seconds, and you probably don't need any confirmations when transacting face-to-face).  This is the sentiment of the bit-pay guys, anyway.

[wumpus]

(It would be nice not to have this thread ignored in newbie jail, so mods feel free to move it to a better place if you think it's worthy.)

+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.

[Mike Hearn]

Some of these ideas are already documented on the wiki (see the Contracts page). Others are either new or were only discussed on the forums, AFAIK, moving more of the discussion onto the wiki and organizing it all better would be a good start.

Issuance of USDcoin/EURcoin etc is one way to reduce needed trust in exchanges, but they still need to back those coins and interface with the banking system. It's possible to decentralize exchanges further using ideas from Ripple.

I think the focus on Open Transactions is misguided. FellowTravellers passion is admirable but as far as I know everyone who has looked at OT walked away overwhelmed by its complexity and generality. Simpler, more specific systems are likely the way to go.

Many of the centralization and trust issues in the Bitcoin economy have technical solutions, but unfortunately the required skill and time to implement them is scarce. Collecting proposals on a forum thread won't change that - what's needed is people to step up and implement them. There is a CHECKMULTISIG implementation pending, it hasn't got in yet because of concerns that there need to be unit tests for these new functions lest new bugs be introduced. Helping develop that work is a good start, and would assist the new dispute mediation providers like BTCrow and SecureCoin get over the initial trust hurdles.

[d'aniel]

Issuance of USDcoin/EURcoin etc is one way to reduce needed trust in exchanges, but they still need to back those coins and interface with the banking system. It's possible to decentralize exchanges further using ideas from Ripple.

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.

I think the focus on Open Transactions is misguided. FellowTravellers passion is admirable but as far as I know everyone who has looked at OT walked away overwhelmed by its complexity and generality. Simpler, more specific systems are likely the way to go.

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

Many of the centralization and trust issues in the Bitcoin economy have technical solutions, but unfortunately the required skill and time to implement them is scarce. Collecting proposals on a forum thread won't change that

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.

[d'aniel]

One more:

Auctions without trusted auctioneers

Here's a paper http://eprint.iacr.org/2008/068 describing a recent real-world implementation of a blind double auction using multi-party computation.  What's so cool about it is it keeps bids and asks secret - even from the auctioneers - so that privacy is ensured, and conflicts of interest are avoided.

[Astrohacker]

Good ideas.

[markm]

I would be using Open Transactions by now but for three separate relatively minor problems.


tl;dr I do not find it too complex etc, I merely find it is not yet ready for use.


One, his docs claim the actual math currently used is not secure enough, that it all needs to be re-done with more bits in the algorithms. If this means all accounts set up using the current number of bits would have to be scrapped that is useless for my purposes as my "players" would want any "test system" to grandfather in as "real", not be scrapped as meaningless test data like happened to testnet. This is due to using games as the "tests"; non gamers might like to think of game currencies and accounts as meaningless but gamers often don't.

Two, no markets yet. I was specifically looking for market software when I first came across Bitcoin and Open Transactions, so its not actually being able to do markets yet put it on back burner.

Three, cheap hosting often does not allow having daemons on arbitrary ports. This is why my first code toward using Open Transactions involves making a TCL library for use in eggdrop IRC bots. I was heading toward using IRC as a way to be able to run from home without incoming ports to work around the incoming ports problem which for me applies even at home not just at hosting places.

Of course there is also the problem that I do not at all like the idea of hosting financial applications on machines I do not physically control. If I manage to come up with a business plan that can reliably pay I would probably try to get internet access from home of sufficient quality to allow running a server just so I have physical control of the machine the money is on.

-MarkM-

[indio007]

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.

[d'aniel]

Many of the centralization and trust issues in the Bitcoin economy have technical solutions, but unfortunately the required skill and time to implement them is scarce. Collecting proposals on a forum thread won't change that - what's needed is people to step up and implement them.

I don't know what goes on behind the scenes with the developers, but I'm wondering if that the lack of resources to develop this stuff might be because they're simply not being properly asked for.  There's a lot of people investing in Bitcoin who would probably be willing to help secure their investment by contributing to a kind of technical development fund if a coherent, big-picture proposal were put together by the reputable developers of the various relevant projects.

[d'aniel]

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

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

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.

This is surely very useful, too.

[hashcoin]

You might find these two threads I made helpful.  The second in particular describes how one could setup an "untrusted bank/exchange".  I'm not familiar with webcoin, but the procedure in the second thread is the "correct" way.

https://bitcointalk.org/index.php?topic=22581.0
https://bitcointalk.org/index.php?topic=25786.0

Also to above poster: please, please do not run something like financial services on shared hosting.  Use a VPS at minimum.  EC2 small instances are like $40/month and Amazon takes physical security very seriously.  There are cheaper VPS hosts (e.g. $5 at prgmr.com) but it can be hard to judge physical security.

[indio007]

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.

[Mike Hearn]

I don't know what goes on behind the scenes with the developers, but I'm wondering if that the lack of resources to develop this stuff might be because they're simply not being properly asked for.  There's a lot of people investing in Bitcoin who would probably be willing to help secure their investment by contributing to a kind of technical development fund if a coherent, big-picture proposal were put together by the reputable developers of the various relevant projects.

Gavin will soon be starting work on Bitcoin full time, but I think most of his effort will be going on stability, scalability, code maintenance and other such things. I'll get around to working on contracts stuff eventually I hope, but the work needed for mobile (in person) payments is taking priority.

It's certainly true that the project could use better organization and more of an authoritative voice. First step would be an improved website with a "project ideas" type section.