Topic: BANK RUN! - P2P Fiat-Bitcoin Exchange (Read 39079 times)

I created a new thread with the updated resources: https://bitcointalksearch.org/topic/bitsquareio-the-p2p-fiat-bitcoin-exchange-647457

Now that I've read the bitmessage whitepaper more closely, it does seem like they do address scalability (to my satisfaction, anyway).  Currently all the nodes pass all the messages, but as it grows it will split up into a tree structure.

It does still kind of suck you can't just start your node and get your messages quickly (could take up to 2 days).  But I really don't have any suggestions for how to make it any better.

It seems that the whole "Tree Chain" conversation would be relevant here... 

Bitcoin is a lot closer to handling the whole world's transactions today than bitmessage is to handling the world's messaging. 

We can't wait for hardware to solve that, especially when (AFAIK) there are better algorithms that will vastly improve on bitmessage's efficiency.

In order to hide from the network which messages are for you, you do not need to accept all of them. 

You know, back in 2008 that was my response to Bitcoin itself. 

"Wait, every node is getting every message?  Can't scale..."

"Every node has to check encrypted signatures on every message?  Can't scale...."

Scale is still my biggest technical concern with Bitcoin, but when you actually figure out how much data you're talking about bitcoin scales fine.

My impression of bitmessage is the same.  A nice first pass, or proof of concept. 

First major problem is that every node tries to decrypt every message on the network, this cannot scale.  In fact, just having every node get passed every message can't scale either, even if it doesn't have to try to decrypt them all (I'm sure the effort needed to test a message to see if it's "for me" can be reduced).

The other major problem is that if your node is offline for a while, you can permanently lose messages.  So you can't just integrate a bitmessage client into an app, the bitmessage process has to run continuously (or at least periodically).

And just in my casual use, it seems like the proof of work required by default is too small, I got spammed immediately.  That's not a major issue though.

I'm not an expert but there do seem to be better overall designs, but hard to say since they haven't been implemented.

One thing is that it's python, which is not a big problem as with jython it should be not so hard to get it integrated into a java project, but a pure java solution would be more convenient. But that´s not the main reason...
I have not researched yet enough to discuss my skepticism regarding BitMessage in detail, but scalability, reliability and privacy are the areas where I am unsure. But as said, I need to investigate more to have a real opinion regarding those issues.

Nice, looking at the prototype.

Why the Bitmessage is no longer considered?

Just a quick update after some silence...

I started developing a prototype in Java using bitcoinJ. Still totally basic and mainly intended to test the usability of the trading workflow (only BTC seller offer-taker scenario implemented yet).

Here is the current code:
https://github.com/bitsquare/bitsquare

And here are some screenshots:
https://github.com/bitsquare/bitsquare/tree/master/screenshots

Still not sure what to use for messaging. Bitmessage was initially the favorite but not so sure anymore. Any suggestions are welcome!

I have the business background and a visionary entrepreneur/investor. Let me know if we can build a team around this to create a cool start-ups that can serve the community better. PM me and I will give you more details about my professional profile.

The new version of the paper is online:
https://docs.google.com/document/d/1d3EiWZdaM89-P6MVhS53unXv2-pDpSFsN3W4kCGXKgY

Here a list of the changes to the initial version:
- Remove the game theoretical approach as it is not sufficient secure
- Add (optional) arbitrators as most effective protection against most attack scenarios
- Add account (identity connected with bank account nr.), a reputation system based on successful trades and a blacklist for banning teh account of fraudsters.
- Add incentive to earn money when trading closest to the average price (See chapter Market maker in the paper for more info)
- Use contract to define all the trade details

I think that concept is now sound and we will move forward to the technical side.

It is of course a lot of work to implement that all, but many parts can be seen as optional for the first step.
With a modular architecture those parts can be added, improved or excahnged over time.

Any input/analysis/criticism is welcome!
And of course if you are interested to join us, we need more dev and brain forces!
We are also on IRC freenode #bitsquare.

The paper will be transferred soon to the wiki on www.bitsquare.io.

Exactly!
We try to make it module based, so several features can be developed independently and are exchangeable. That is also important for security, as every part has its own attack surface and should not have fatal effects to the overall system if it fails.
To use the bitcoin-otc infrastructure could be a low effort solution for starting.

Here a draft for the overall hi-level architecture.

External systems:
- Messaging system
- Wallet

Core:
- Exchange

Facades (provides internal API to access external system):
- Messaging facade
- Wallet facade

Modules:
- Account
- Offer
- Contract
- Identity check (only API, functionality off-system)
- Arbitration
- Reputation
- Blacklist

As I see it, development could be divided in different steps.
1.- Game-Theoretic-Collateral transactions.
2.- Distributed order book.
3.- Distributed reputation system.

The first step could be developed without the second and the third. Existing working infrastructure (bitcoin-otc channel, order book and reputation system) could be re-used. As the initiative gains momentum and users, progress could be made towards the second and third step.

I added a proposal for an identity (account) and reputation system.
It is described in the paper here:
https://docs.google.com/document/d/1d3EiWZdaM89-P6MVhS53unXv2-pDpSFsN3W4kCGXKgY/edit?pli=1#heading=h.bnpc4r2eii0m

Any criticism/review welcome!

You can't directly sell BTC to Fiat, but you can anonymously spend BTC on whatever you wanted to buy, which is in some cases better. Moreover, I expect the BitBuyer to overpay which means that the BitSpender gets to shop online at a huge discount.
I'm not sure that ANY direct Fiat transfer will ever be scalable and fraud-resistant in the way that this idea is.
You may be thinking of BitSpend.com, which failed precisely because they had to move large Fiat (this idea solves that problem completely).
Merchants would love this as it generates sales in the form of 'Gifts', which to them look just like normal sales. Merchants never break AML or otherwise know they are doing anything out of the ordinary.

You are correct that it may trigger AML issues, which is one reason why we did not move forward with it. However, every other idea in this thread also breaks the same US AML laws (unless the BTC-seller is going to do KYC on the buyer) so I just assumed you lived outside the US or otherwise didn't care.

Thanks for your interest. Outcome is not ONLY decided by vote. There is an incentive system with (theoretically) a unique Nash Equilibirum where everyone votes truthfully. The mechanism is designed such that I actually do expect every single voter to vote exactly the same way (but of course, I designed it primarily with deviant actors in mind, as off-path reasoning is crucial to the game-theory of something like this).

You can just use your existing system for one single transfer, yet set the collateral OVER the transfer amount. It will have almost the same incentive effect, although of course it requires users to tie up more capital.

RE: RE: "... if the parties could never contact each other at all":
More fiat transfer problems you can avoid with the 'Gift' idea. Banks may respond strategically to your Fiat-transfer ideas, but I can't see any merchants or politicians ever banning "The Gift Basket". I feel that direct BTC to Fiat transfer is siren music.

If the service is good enough, rich people might contract someone to spend time pushing their large amounts of money through the exchange for BTC. This upper-tier institution could then develop into a decentralized exchange, with multiple "fiat-rich-person-contractors" attempting to swap Fiat for BTC and developing professional relationships to do just that. These organizations and networks would only exist if there was a foundational reason to tie up Fiat in an exchange-attempt. Improve only a few things at a time, and the project will remain possible.

Indeed I think we all got this wrong early on. Escrow is the worst word when we could use arbitrator. I guess we all picked up the mistake from here: https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation

That wouldn't be an escrower but an arbitrator instead (http://en.wikipedia.org/wiki/Arbitration), so I guess this was all just a problem of vocabulary then.

Maybe we have not clear definitions of what we mean with exchange, escrow, gateway,…
The classical exchanges combine a lot of functionalities into one system.

The main problem what to try to solve is the conversion from crypto currency to Fiat. Of course the exchange itself have to deal with other problems as well, but those are less difficult like the one mentioned before.
The escrow function for us is a trusted 3rd party used in 2of3 MultiSig and used for resolving disputes.
The escrow does not hold any funds and does not provide liquidity, its is more like a judge or notary.


There is only one critical risk with blackmail, that is when the blackmailer manage to use an atomic tx for the blackmail, otherwise he has the "who pays first" problem and is in a weak position. We found a possible solution to avoid that he can use an atomic tx with 3of3 MS and key deletion (described earlier in the thread and in the paper).
The main reason why I think we need an escrow is becaue of the other open problems, mainly system attackers. Therefore other protection mechanism are needed and all introduce their own new complexity and problems.
So escrow seems the most efficient way to protect against most of the attack scenarios.

Thanks for sharing, interesting project.
But more a way to get in BTC into those shopping platforms. It serves good for buying BTC but you cannot sell BTC to Fiat (only for articles from those shops).
I think I have seen some similar idea a while ago. As far as I remember it got closed because of legal issues/pressure form the merchants (don't remember the name and the details).
I think if that idea would scale large they would also run into problems with the merchants, as it will probably break some TOC and it is relative easy to track such transactions (BTC buyer send goods to many different recipients). Maybe it even would trigger AML issues?


Need a bit more time to read your paper and the thread, just quickly read in the thread a bit... sounds very interesting.

My first thoughts on that is:
Does a majority really creates truth?
Galileo Galilei was right even the huge majority was thinking something completly different.
I think consensus used for a decision process is weak and should only be used if we cannot find a solution with mathematical proof.
But of course there are many fields where no mathematical proof is possible so all the human complexity comes in again ;-)...
In real life I guess models with more complex structures works best, like e.g. liquid democracy which is used by the pirate parties. I think flat structures like simple voting are not very powerful for the difficult task to find "truth".
But need to read more about that idea... was just my first reaction...


Yes the idea to stream the fiat tx is interesting, but I think it will suffer from practical problems and risks (single point of failure).
- There are only a few payment processors with open APIs in contrast to a huge amount of normal banks (without those APIs). So these payment processors are more exposed to political pressure.
- The payment processors can easily track those txs (clear pattern with those micro-payments).
- The idea only works if there are no bank tx costs, which is mostly true for those payment processors, but it might violate their TOC where a limited number of tx/time interval might be considered as "fair use". At the end every tx creates costs for them, so they would be stupid to tolerate that.
- The Banks need to report any suspicious bahaviour, and those micro payments could be considered suspicious to them.


RE: "... if the parties could never contact each other at all":
Thats a good point.
I was thinking initially of that strategy to prevent/mitigate blackmail.
The only solution I came up was to use a asymmetric collateral in the beginning.
So Alice has to pay 1.1 BTC collateral and Bob 0.1 BTC + 1 BTC payment = 1.1 BTC (with the values from my example...).
So both have the same money to lose if Alice does not pay the Fiat. So Alice has no advantage for a blackmail anymore.
Then when Bob has received the Fiat he would have an even stronger position to blackmail as Alice has to lose 1.1 BTC + 1000USD -> 2.1 BTC and he only 0.1 BTC + 1 BTC - 1000USD -> 0.1 BTC.
If we can manage to remove the communication channel at that point a blackmail could be prevented.
But the bank details reveal the name so they can find the other peer, even the software does prevent communication.

If we use a pool of traders  and the payout will be randomized than the communication link would be broken.
So if 10 traders (all with same volume and price) will be in the pool and Bob release the BTC at the end to a random peer, a blackmail attempt to his initial trading partner will be in-effective, as Alice will get the money from any random peer (1 to n chance that it is really Bob).
That would at least decrease the probability for blackmail, but of course introduce the complexity and limitations of a pool. 
So I did not follow that idea further, but maybe somebody get inspiration for a better solution out of that?

Sure.

First, requirements are low:
Allowing the BitSpender (spending BTC on stuff) to choose his Gift Basket solves many problems (USD quantity transacted, anonymous use of name/identity/address, specification of merchant/product-version, etc.). The software then requires only the ID of the Gift Basket (a few characters). The website chosen (Amazon, NewEgg, Walmart, etc.) does have access to everyone's info in a connected way, but they do not know that they are party to a Bitcoin transaction, so you can safely use their existing centralized infrastructure for the non-Bitcoin parts. This infrastructure includes private wish lists, shipping/tracking numbers, proof of payment invoices.

The Bitcoin requirements are also mostly low: BitSpender pays 1% of order upon creating the 2 tx's (2 of 3 multisig, one for success, other for cancel/refund). This 1% can be easily verified as a database-entry requirement, invalid entries will chase away counter-parties. If either everything goes well or parties mutually agree to cancel, they simply sign the relevant tx without any new requirements. The reputation system I envisioned was simply a total of all USD volume (easily calculable from the shared database, and possibly even reconstructed completely from the blockchain's shared history, if embedded with OP RETURN). Disagreement statistics ("reputation") can be easily calculated (how often arbitration was req'd, for which transaction sizes, what was the outcome, etc).

Something like BitMessage, which you've already discussed as a shared database idea, can probably handle all of these requirements so far. We also considered BittorrentSync despite its closed-sourceness.

Second, we initially planned to be the centralized arbiters, collecting all the 1% fees for ourselves. However, over time we expected other people to become arbiters and compete with us on fees/service/volume.

Thirdly, I separately developed a math trick (in Truthcoin) that allows people to vote on an arbitrary obvious Yes/No external state, with a Nash Equilibirum of them each voting honestly. Its difficult to translate this math trick into the signature world of Bitcoin transactions but I have some ideas that might make it a little easier if the specific application were known.

Notice, for example, that arbitration is very easy because Amazon/whoever will give receipts. Faking them would probably be too much work for a scammer. Honest individuals could establish long-term reputations and leverage this reputation into better prices. Honesty could become its own industry.