Topic: Eliminating the need to trust in the Bitcoin economy (Read 3055 times)

Um, don't buy their overpriced shit and their prices will have to come back to reality lest they go out of business?  They might also price their goods in more stable currencies, and convert during sales so that their advertised prices don't get out of wack while exchange rate fluctuates.  There's an incentive to use it to avoid the banking system (provided you already own BTC...).  Plus, added privacy - you don't have to give your personal/credit card information out to every single website you deal with.

I feel like a salesperson now.

But really, one thing at a time.  This thread is about the trust problem.   

+1, but what is the incentive to use BTC retail? Its overpriced.

There is a Bitcoin Developer Mining Pool thread:
https://bitcointalksearch.org/topic/announce-bitcoin-developer-mining-pools-25441

which lists the two bitcoin developer charity pools, which give one percent of the generation to the bitcoin developers on this list:
https://github.com/Unthinkingbit/charity/blob/master/bitcoindonationinformation.html

To get on that list, an open source bitcoin developer can message me or post in an active devcoin thread like this one:
https://bitcointalksearch.org/topic/50-btc-total-bounty-for-groupcoin-development-and-help-24813

They could also post in the original induction thread:
https://bitcointalksearch.org/topic/bitcoin-donation-information-18498

However, since no one has ever posted in the original induction thread I'm not checking it often.


In preliminary testing is the devcoin:
https://bitcointalksearch.org/topic/m.422068

Devcoin is an ethical currency where 90% of the generation goes to open source developers and 10% to the miners:
https://github.com/Unthinkingbit/charity/wiki/Devcoin-Description

However, devcoin is still alpha, which means devcoin has not had problems for several days, but if new problems develop it may still be necessary to reload the client and/or daemon and/or restart the blockchain.

Have there been any talks of setting up some kind of 501(c) to fundraise and employ full-time developers?

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.

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.

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://bitcointalksearch.org/topic/trust-free-crypto-currency-exchange-with-time-conditional-scripts-22581
https://bitcointalksearch.org/topic/instant-tx-for-established-business-relationships-need-replacementsnlocktime-25786

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.

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.

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.

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.

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-

Good ideas.

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.

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.

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.

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

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.

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.

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.

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?