Topic: bitsquare.io - The P2P Fiat-Bitcoin Exchange - page 11. (Read 34688 times)

hey guys was at today's presentation...

let me ask a question, why arbitrary system and why not bithalo system for escrow??

https://github.com/OpenBazaar/OpenBazaar/issues/528

http://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf

two sides escrow may include a "security" 3rd part escrow in case users agree...

New article about Bitsquare: https://bitscan.com/articles/bitsquare-plans-to-launch-new-peer-to-peer-bitcoin-exchange#sthash.PQxuMDuA

Here are some new videos: https://www.youtube.com/playlist?list=PLXvC3iNe_di9bL1A5xyAKI2PzNg8jU092

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.

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

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

I take it the DHT runs on each users PC ?

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

Keep the good work.

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.

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!

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

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:


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.

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

Private Video

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

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

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.

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?

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

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

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.