This is what we need, i want to see tons of working decentralized exchanges happening.
What is the difference if you compare this to Coinffeine??
then why does the BTC community prefers centralized shit exchangers?  Prefer? Ther is no decentralized alternative yet out. |
|
|
|
Just popping up to say thanks to Dor for the kind intro, and to invite anyone who wishes to discuss our technology to chat.
I'm available here obviously, as well as on twitter @yuvadm, and by email at yuval (at) synereo (dot) com.
I would be very interested in which tehcnology/language you will use and which frameworks you consider. I am working on bitsquare.io and we use Java with TomP2P as DHT/messageing framework. Would be good to exchange experience if we have something in common... (beside the logo and color ;-)) |
|
|
|
We're happy to announce that Synereo has found its dream CTO and development team leader, Yuval Adam.
Yuval is a full-stack technologist, with experience ranging from building distributed web services through deploying wireless mesh networks and to embedded systems development. Yuval founded the Tel-Aviv chapter of CryptoParty, advocating for privacy and digital liberties. He holds a B.Sc in Computer Sciences from Ben-Gurion University.
Yuval can usually be found lurking in the dark corners of the Tel-Aviv Makers hackerspace.
Yuval and I are in the process of finalizing the tech architecture for Synereo. We will soon determine the scope of our first phase of development and recruit more developers as necessary.
We've been getting a torrent of applications to join our development team. If you're interested in joining us, there's still time - don't hesitate to contact me.
Congratulations! Can you tell already a bit about any details? Which technology are you going to use? Will it be open source? |
|
|
|
|
Is the project open source? Which technology is used (P2P network)?
|
|
|
|
beta available?
We just publisehd the first binaries (OSX and Linux only yet, Windows will follow soon): https://github.com/bitsquare/bitsquare/releasesDocs and instructions will follow soon as well. If you want to build from source, here are the instructions:https://github.com/bitsquare/bitsquare/blob/master/doc/build.md |
|
|
|
Hi, I have not read the whole thread in the links but if it is a 2of2 MultiSig then it is the initial concept i tried out which turned out that it is unsafe regarding blackmail. as the deposit is async the party with less money locked can blackmial the other in sending a pre-signed blackmial payout tx. that way its rational to accept the blackmail. If the concept you mentioned is differnt to that what I assumed, can you describe it quickly? I don't have much time yet for reading too much... |
|
|
|
|
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.
|
|
|
|
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). |
|
|
|
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. |
|
|
|
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-arbitrationEdit: 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.llbmn2coe21aRisk analysis: https://docs.google.com/document/d/1LJCRFdtM2Jn2Oiv49qRXwBDG8HZD0Hiedy8tNjErHps/edit#heading=h.llbmn2coe21aBtw: 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-exchangeMike 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 |
|
|
|
Private Video  The author has just re-published the videos. please try again... |
|
|
|
Seems interesting, but bank transfers are dangerous anyway. You can tell that somebody transfers money from your account, or that money can be stolen money from other one's account. I think the 2 hand shake signature http://bitsquare.io/images/overview.png is an interesting method. But using a digital method is more secure than direct bank to bank transfer. What do you mean with "digital method"? Crypto-crypto exchange? That would be easier indeed regarding the trust problem. But the main problem IMO is how to the fiat in/out btc. Instead of a bank transfer a send cash by mail method could be used as well. But as that is much less convenient I did not consider that more, but it would be not so much problem to use that (but that would have other problems like: you know the post address of the trading peer, which could be a security risk). The model use more then just the simplified process described in the hi-level overview diagram. Basically the security model is based on an arbitration system (itself a P2P system) and a fraud list to block scammers (stolen bank account, bank chargeback). By digital method, I mean like ukash codes, wester union, okpay o something similar. Something faster, not bank accounts. Ah that you meant: It is not limited to classical bank accounts only. I have not used and investigated ukash or western union, but okpay for instance should be no problem to use. basically it will be just a form to define the money transfer type and the necesssary id fields. western union will be probably too expensive, they take a huge fee asaik.... |
|
|
|
Seems interesting, but bank transfers are dangerous anyway. You can tell that somebody transfers money from your account, or that money can be stolen money from other one's account. I think the 2 hand shake signature http://bitsquare.io/images/overview.png is an interesting method. But using a digital method is more secure than direct bank to bank transfer. What do you mean with "digital method"? Crypto-crypto exchange? That would be easier indeed regarding the trust problem. But the main problem IMO is how to the fiat in/out btc. Instead of a bank transfer a send cash by mail method could be used as well. But as that is much less convenient I did not consider that more, but it would be not so much problem to use that (but that would have other problems like: you know the post address of the trading peer, which could be a security risk). The model use more then just the simplified process described in the hi-level overview diagram. Basically the security model is based on an arbitration system (itself a P2P system) and a fraud list to block scammers (stolen bank account, bank chargeback). |
|
|
|
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. |
|
|
|
I presented yesterday at a local BTC meetup my idea for a funding model ( https://docs.google.com/presentation/d/1OXuqPHMAESPbTvymAyn2uqko8R9X32yGOb9yCRVLMP0). The feedback was very positive and there were interesting discussions following. So I am going to continue with that funding model, but I would need some help for preparing the funding process. Basically I need help in those areas: - Communications - Webpage - Video Communications: I need someone for the communication with the community, explaining and presenting the concept. Sombody like Stephan Tual (who do communications for Ethereum) would be a perfect fit. Webpage: We need a webpage with all relevant information. Video: The classic info-graphics style is kind of over-used but as long we don't find a better solution for explaining the idea, I would consider it as the way to go. That video is pretty well done: https://www.youtube.com/watch?v=ETCP8NeXasYThe funding model will consists in several funding rounds. Eeach round will take place after a milestone is reached (continuous deployment). The funding target in every round will be the money needed for the reached milestone. So basically the payment to developers and other contributors (communications, webpage, video). People who are stable contributors and share the mindset of the core team will be invited to become members of the non-profit organisation. We cannot guarantee any payment, but if the funding is successful you get paid for your efforts. Feel free to contact me at: team [at] bitsquare.io or in our IRC channel #bitsquare.io (at freenode). More details to the funding model you can find here: https://docs.google.com/document/d/1MysGJcPydv3EabshTFiFTtwQC86_4-HG7dSPp0_YhHc/edit#heading=h.q7h5twnzf2u0 |
|
|
|
|
Show Posts
