bitsquare.io - The P2P Fiat-Bitcoin Exchange

[anu]

I am not experienced with c++ (unfortunately), so that would be one reason I could not join ZeroReserve.

Not a very good reason for a Java programmer considering how similar Java and C++ are. Especially since there is a lot of Java to do. For example: Currently ZR uses the Satoshi client. But since this is a full Bitcoin node, I'd like to have bitcoinj as a drop in replacement. For this, someone needs to create a bitcoind compatible JSON-RPC layer like Mike Hearn proposed. Eventually there will be a Java implementation - we have to move to mobile platforms.

Another problem I personally have with ripple style concepts is the combination of friendship relationships with money. If I lend money from a friend and I am unable to pay it back, my friend can get in trouble as well and that could have influence to the friendship. All that can easily happen without any bad intention (accident, cannot work anymore,...). I prefer a system which is more abstract and handle those risky with insurance, like the banks are doing it. That does not imply that I am fan of Banks ;-)...

First, you would not necessarily grant your friend a credit that is anywhere near to the amount you trust him with. If a friend really cheats you for that smaller amount, that does influence the friendship, but in that case I'd say: Good riddance.

Another misconception is the meaning of "friend". In ZR context, it is simply someone you trust with money, for any reason. It is not the same as "close friend" or even "drinking buddy".

It is an argument I hear very often. Yet those same people trust a centralized exchange like MtGox or even btc-e. Does anyone know anything about btc-e? And why trust banks, especially today? Historically, banks screwed their customers every 5-7 decades. We Germans got screwed big time after WWII but we generally had the feeling like we deserved it for the war, so it went unnoticed. Now the system in the entire West is heading for another big reset.

Lastly, there is such a system that works since centuries, even millenia: Hawala / Hundi. Ripple is by no means a new idea. It is just that computer-less Hawala doesn't scale well while with computers it does because the software takes care about the complexities of routing. ZR enables everyone who chooses participate to become a Hawaladar. I think we need to walk away from the current banking system as much as possible.

The network effects you mention applies to every P2P system: The more people participate the more attractive it gets. There is the dilemma: 5 guys implementing 5 different system may result in the failure of all 5 systems because none of them ever achieves critical mass. If those same 5 guys had joined in a team to implement one, it may have succeeded. And: Given enough eye balls, all bugs are shallow (Eric Raymond)

[oakpacific]

First, you would not necessarily grant your friend a credit that is anywhere near to the amount you trust him with. If a friend really cheats you for that smaller amount, that does influence the friendship, but in that case I'd say: Good riddance.

Another misconception is the meaning of "friend". In ZR context, it is simply someone you trust with money, for any reason. It is not the same as "close friend" or even "drinking buddy".

So it would be even more difficult to gauge your level of trust with them.

It is an argument I hear very often. Yet those same people trust a centralized exchange like MtGox or even btc-e. Does anyone know anything about btc-e? And why trust banks, especially today? Historically, banks screwed their customers every 5-7 decades. We Germans got screwed big time after WWII but we generally had the feeling like we deserved it for the war, so it went unnoticed. Now the system in the entire West is heading for another big reset.

They indeed betrayed us, but there is no proof that some guys out of the hierarchy will do any better, so it begs the question if it's really worth the effort to reinvent the wheel at all, given that you maybe able to just abandon it, when it comes to money transfer.

Lastly, there is such a system that works since centuries, even millenia: Hawala / Hundi. Ripple is by no means a new idea. It is just that computer-less Hawala doesn't scale well while with computers it does because the software takes care about the complexities of routing. ZR enables everyone who chooses participate to become a Hawaladar. I think we need to walk away from the current banking system as much as possible.

Hawala relations are much more real, they are in your RL social network and you can't just walk away from it, online identities are a completely different matter.

[anu]

They indeed betrayed us, but there is no proof that some guys out of the hierarchy will do any better

Of course you cannot proof that anyone will behave any way in the future. Seems self evident.

Hawala relations are much more real, they are in your RL social network and you can't just walk away from it, online identities are a completely different matter.

How so? Many Hawaladar never met. And there is nothing in ZR that demands that you cannot know people you trust in ZR in the real world.

Many people here put their Bitcoin address in their signature. You might donate $20 worth to a project you like. But you would not grant a credit of $20 to that project? Seems inconsistent to me. But then, maybe you would also never donate, in which case you are at least consistent.

Nothing great was ever achieved without irrational exuberance.

You don't really mean that, do you?

[EDIT:]OK, that was it for me - else it might seem that I want to hijack this thread.

[oakpacific]

They indeed betrayed us, but there is no proof that some guys out of the hierarchy will do any better

Of course you cannot proof that anyone will behave any way in the future. Seems self evident.

So maybe, stop working on stuff that will have to depend on a ultimately unpredictable human factor to function.

Hawala relations are much more real, they are in your RL social network and you can't just walk away from it, online identities are a completely different matter.

How so? Many Hawaladar never met. And there is nothing in ZR that demands that you cannot know people you trust in ZR in the real world.

They may not, but they are connected together by a RL social network, take that away then it won't work, it's a necessary condition, "nothing stops you doing that" is not enough here.

Many people here put their Bitcoin address in their signature. You might donate $20 worth to a project you like. But you would not grant a credit of $20 to that project? Seems inconsistent to me. But then, maybe you would also never donate, in which case you are at least consistent.

There is no inconsistency here, I don't determine Bitcoin's value, so I can just send someone the bitcoins and walk away, otoh I have to be held personally responsible in the future for all IOUs I issue, which is a responsibility I don't want, because I don't know what will become of me in the future, you are comparing apples with oranges. Besides, what my need is really has nothing to do with what I believe is a better system.

[k99]

TLS Notary explained in videos:
https://www.youtube.com/playlist?list=PLnSCooZY6_w9j5tQ8jAeZtrl9l4NnL48G

[CoolBliss]

What happens if I am selling and the buyer says they sent the fiat but they never do, does the signed transaction that we both entered into break and all funds returned after a certain time? As in I never sign the return transaction because I never received the funds. Who is the middle man in this case?

[k99]

What happens if I am selling and the buyer says they sent the fiat but they never do, does the signed transaction that we both entered into break and all funds returned after a certain time? As in I never sign the return transaction because I never received the funds. Who is the middle man in this case?

After a defined time the peer not receiving the money can request arbitration. The arbitrator has to find out the truth and give the money to the honest trader. The refund tx will be created on demand by the arbitrator with the signature of the honest trader.

[R4v37]

maybe build the GUI, where we just "type in" address then "send"
well...we humans always looking for the easiest way 

[k99]

Here is an interview with the great Arthur Falls about bitsquare on Beyond Bitcoin:
http://letstalkbitcoin.com/blog/post/beyond-bitcoin-9-a-new-breed-of-exchange
(starts at min. 20).

[acec]

TLS Notary explained in videos:
https://www.youtube.com/playlist?list=PLnSCooZY6_w9j5tQ8jAeZtrl9l4NnL48G

Private Video

[k99]

TLS Notary explained in videos:
https://www.youtube.com/playlist?list=PLnSCooZY6_w9j5tQ8jAeZtrl9l4NnL48G

Private Video

The author has just re-published the videos. please try again...

[dexX7]

This is the utmost exciting and promising project I've seen in the last time, wow!

I'm not through the text material, but I noticed one thing:

Use case 3: Dispute
In case that Bob does not receive the Fiat payment after the defined timeout period he can contact the arbitrator. He sends a request to the arbitrator with the contract attached and a new payout tx where the arbitrators arbitration fee is included as payment to the arbitrator and where Bob gets back his payments.

Did you think about adding time locked transactions to all this? The basic process would be this:

1. Alice wants to sell 2 BTC for fiat, Bob agrees to buy.
2. Bob and Alice exchange public keys and create a 2-of-2 multisig wallet from which can only be spent, if both parties agree.
3. Alice prepares a transaction which sends 2 BTC to this wallet, but does not reveil it at this moment.
4. She also creates a transaction which spends those 2 BTC back to herself - from the P2SH wallet. This "refund" transaction makes use of nLockTime with a number far in the future - before this time (or block height) the transaction cannot be mined. She passes this transaction to Bob.
5. Bob signs the refund transaction.
6. Alice actually sends the 2 BTC to the 2-of-2 multisig wallet.
7. Once confirmed, Bob initiates the fiat transfers.
8. After Alice receives the fiat, both sign a transaction which spends the coins to Bob.

If Bob doesn't pay, Alice ultimately receives her coins back.
If Alice acts fraudulent and doen't release the coins with the intention of claiming the refund, she has to wait nevertheless and Bob can start to hunt her.

Combined with collaterals and arbitrators it might get even more exciting.

More: https://bitcoin.org/en/developer-guide#escrow-and-arbitration


Edit: just noticed this exists for some months.

[k99]

This is the utmost exciting and promising project I've seen in the last time, wow!

I'm not through the text material, but I noticed one thing:

Use case 3: Dispute
In case that Bob does not receive the Fiat payment after the defined timeout period he can contact the arbitrator. He sends a request to the arbitrator with the contract attached and a new payout tx where the arbitrators arbitration fee is included as payment to the arbitrator and where Bob gets back his payments.

Did you think about adding time locked transactions to all this? The basic process would be this:

1. Alice wants to sell 2 BTC for fiat, Bob agrees to buy.
2. Bob and Alice exchange public keys and create a 2-of-2 multisig wallet from which can only be spent, if both parties agree.
3. Alice prepares a transaction which sends 2 BTC to this wallet, but does not reveil it at this moment.
4. She also creates a transaction which spends those 2 BTC back to herself - from the P2SH wallet. This "refund" transaction makes use of nLockTime with a number far in the future - before this time (or block height) the transaction cannot be mined. She passes this transaction to Bob.
5. Bob signs the refund transaction.
6. Alice actually sends the 2 BTC to the 2-of-2 multisig wallet.
7. Once confirmed, Bob initiates the fiat transfers.
8. After Alice receives the fiat, both sign a transaction which spends the coins to Bob.

If Bob doesn't pay, Alice ultimately receives her coins back.
If Alice acts fraudulent and doen't release the coins with the intention of claiming the refund, she has to wait nevertheless and Bob can start to hunt her.

Combined with collaterals and arbitrators it might get even more exciting.

More: https://bitcoin.org/en/developer-guide#escrow-and-arbitration


Edit: just noticed this exists for some months.

Thanks for your input!

I was considering timelocked refund tx initially but ASAIK there is still no secure solution for the malleability problem, which makes that feature problematic (the refund tx depends on the deposit tx which might have a different tx id in the blockchain as it has when it was created locally, so the refund tx get invalid).
Beside that, the arbitrator can solve any of those problems as well, so an extra refund mechanism would be redundant and like with any feature would introduce new attack surfaces.

Thanks for reading and reviewing the docs. I know its quite a bit of text, but I tried to cover the most important parts (knowing that its still not precise enough).
It is important for the project that others review all that. Until now probably nobody has really analysed it in depth. There might be critical flaws and the more people reviewing it critically the higher the chances to find them.

For me the arbitration system seems to be the most critical part as it solves a lot of other areas but introduce a hi-trust environment which must not introduce any single point of failure or any point of centralisation. The way I designed the arbitration system is that it is itself a P2P system, but it was the latest part and it definitely needs more analysis and review.

Here are the links to the docs:
Basics: https://docs.google.com/document/d/1d3EiWZdaM89-P6MVhS53unXv2-pDpSFsN3W4kCGXKgY/edit#
Arbitration system: https://docs.google.com/document/d/1LJCRFdtM2Jn2Oiv49qRXwBDG8HZD0Hiedy8tNjErHps/edit#heading=h.llbmn2coe21a
Risk analysis: https://docs.google.com/document/d/1LJCRFdtM2Jn2Oiv49qRXwBDG8HZD0Hiedy8tNjErHps/edit#heading=h.llbmn2coe21a


Btw: Bitsquare got some media attention recently.
Interview about bitsquare on Beyond Bitcoin/Lets Talk Bitcoin (start at min 20):
http://letstalkbitcoin.com/blog/post/beyond-bitcoin-9-a-new-breed-of-exchange

Mike Hearn:
"...it works how I expected a P2P exchange to work."
"...this is the kind of app I hoped people would build on top of bitcoinj."
https://plus.google.com/+MikeHearn/posts/BGsiRBLJEh6

[dexX7]

I was considering timelocked refund tx initially but ASAIK there is still no secure solution for the malleability problem, which makes that feature problematic (the refund tx depends on the deposit tx which might have a different tx id in the blockchain as it has when it was created locally, so the refund tx get invalid).

This is an issue, if there is a chain of unconfirmed transactions, e.g. in micropayment channels, but I don't see a problem in this context - because Bob doesn't sign the refund transaction before Alice' BTC payment confirmed anyway. The time locked approach alone is heavily in favor of Alice, but I think it's obvious this is not a replacement for an arbitrator or oracle based approach, but might be considered as an additional tool or option.

Thanks for the reading material. I highly appreciate the level of detail and surely will comment again, once I've found some time.

Cheers!

[k99]

I was considering timelocked refund tx initially but ASAIK there is still no secure solution for the malleability problem, which makes that feature problematic (the refund tx depends on the deposit tx which might have a different tx id in the blockchain as it has when it was created locally, so the refund tx get invalid).

This is an issue, if there is a chain of unconfirmed transactions, e.g. in micropayment channels, but I don't see a problem in this context - because Bob doesn't sign the refund transaction before Alice' BTC payment confirmed anyway. The time locked approach alone is heavily in favor of Alice, but I think it's obvious this is not a replacement for an arbitrator or oracle based approach, but might be considered as an additional tool or option.

Thanks for the reading material. I highly appreciate the level of detail and surely will comment again, once I've found some time.

Cheers!

As far as I understand your proposal it goes like that:
Alice create tx1 with payment of 2 BTC to a 2of2 MS output
Alice create tx2 with the 2 BTC output from tx1 back to herself as a refund tx with a timelock.
She let sign Bob first the refund tx2 and then she signs tx1 and publishes it.
If bob pay the fiat to Alice she creates and signs a payout tx from the output of tx1 to Bob and Bob sign it as well and publishes it. All OK.
If Bob does not pay she has the already signed refund tx2 and can publish that to get back her funds.

But the tx2 input depends on tx1 output. There is the risk for malleability. If the hash of tx1 get changed when published then the tx2 is invalid as it has a wrong tx hash as input reference. Btc devs told me that malleability can also happen without malicious intention.

The other problem is if Alice  would not sign a payout tx for Bob and wait until the timeout is over and pay back to her the BTC.
So she could win 2 BTC + fiat. Bob would lose the fiat.

In the model I use (ignoring arbitration and collateral) that cannot happen. Worst case there is that one lose his money but the other cannot win anything. With collateral both will lose but different high values, which could lead to extortions. Thats why I gave up my original concept based on 2of2 MS and a game theoretical approach in favor for the arbitration system.

If I misinterpreted your proposal please correct me and explain it in more details.

[BANK RUN]

Keep the good work.

[onchain.io]

I take it the DHT runs on each users PC ?

What's the incentive for users to maintain a full node ?

[k99]

I take it the DHT runs on each users PC ?
What's the incentive for users to maintain a full node ?

The trading software (desktop app) will be a node in the p2p network. iIt has not such crazy resource requirements like a btc full node (no 20 gb discspace...) in fact the resource requirements will be so small that it will not be any issue (it is not a filesharing network, just small compressed chunks of data).
The trade process only works fluently if your app is running. You can close the GUI window but it will keep running in background and you need to shut it down via the system tray. When you publish an trade offer your software is waiting for someone taking your offer and will execute that offer automatically even if you are not physical online (but your software is running at least in background). If you shut down the app that process would not work. So that is the incentive for people to let the software running. There might be some others as well but that is not defined yet in details (we like to add a financial incentive).

[CryptInvest]

Is there progress on this project? Already have a completed application on a desktop, with which you can carry out the real deal?

[k99]

on github you can watch the progress. doing a basic trade is functional but not polished enough for the public yet. public pre alpha is planned for mid or end of september.