New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web-based XCAT tool for easy ZEC↔︎BTC atomic trading #29

Open
jasondavies opened this Issue Sep 15, 2017 · 28 comments

Comments

Projects
None yet
8 participants
@jasondavies

jasondavies commented Sep 15, 2017

Motivation and overview

Building on the excellent work by @arielgabizon, @arcalinea, and others, I propose to make their work more accessible by providing a simple web-based tool that facilitates:

  • Easy setup of an XCAT trade. This includes optional generation of the random secret in-browser. Once the trade parameters have been agreed between the parties (secret hash, 4 addresses, 2 amounts), a URL can be generated for easy (and optional) sharing/bookmarking. The page would provide instructions for creating and sending the relevant transactions. The page may also allow the transactions to be broadcast, in the case where users cannot easily do so themselves.
  • Optional monitoring of a trade. The XCAT mechanism will be illustrated visually, and progress of the requisite transactions can be optionally monitored. The visual aspect helps educate users and developers about how XCAT works, and if monitoring is enabled, it allows users to see which parts of the trade have completed, and easily see what to do next to complete the trade (or revoke it if something goes wrong).

The purpose of the tool is to facilitate easy trading and educate users about how XCAT works.

Technical approach

  • The majority of the work involves designing a nice user interface written in JavaScript, HTML and CSS, and intuitive visualisations for the trade and its progress along the two selected blockchains.
  • Initially only ZEC and BTC will be supported.
  • The optional monitoring of trade progress will require a server running both Zcash and Bitcoin nodes ideally with txindex=1.

Background and qualifications

MA (Cantab) CompSci, Univ. of Cambridge, contributor to various open-source projects; most relevant to this proposal is my work on D3.js, and you can see various visualisations on my personal website.

I've been following Zcash since its inception and have made some minor contributions so far:

I also helped @arielgabizon test the first ever XCAT trade with ZEC/BTC on their respective testnets.

Evaluation plan

The following deliverables are required:

  • A web page that allows the main XCAT parameters to be entered and agreed upon between two parties.
  • The web page should provide instructions for generation and broadcast of the appropriate transactions.
  • A visualisation of the progress of the trade, with optional monitoring which requires some information to be sent to the server.

Security considerations

As this page is intended to be used to exchange money, extreme caution will be required in terms of ensuring the page and its code are not tampered with. I would welcome suggestions on this front. Of course, I would serve the page over HTTPS but additional protections would be helpful.

Aside from the above, I also want to ensure that the parties to the trade are able to select the level of privacy with respect to leaking information to the server, ranging from no information to I am one of the parties involved in this XCAT trade (the latter is required to monitor how far along the trade has progressed).

Furthermore, care should be taken when suggesting redeemblocknum parameters to the users, such that sufficient margins are in place for the cases where the counterparty does not follow through, and the trade needs to be aborted.

Budget and justification

I have spent some time thinking about how the UI and visualisations might look, so I'm already part-way along in the process. As I mentioned above, I have also helped Ariel test their XCAT code so I also already have an understanding of how it fits together.

I estimate that around $15k would be sufficient to fund the development of this tool, with a turnaround time of around 1-2 months. I'm happy to take on hosting costs etc. myself.

@tromer

This comment has been minimized.

Collaborator

tromer commented Sep 17, 2017

As you point out, the web page would be an attack vector affecting all transactions using this system. This is a big concern.

What is the maximum damage that could be done by an attacker who gained control of the servers (or domain name+certs)? In particular, is it limited to the funds involved in the specific trade, or can the page steal the whole balance from the user's address?

What security mechanisms are used by other systems that use web-served JavaScript to manage users' funds or keys?

@tromer tromer added the security label Sep 17, 2017

@zmanian

This comment has been minimized.

zmanian commented Sep 17, 2017

I've been going back and forth about how secure a web based XCAT service could be.

Probably the most critical thing is to know that users funded their HTLCs before publishing a preimage. Users can have multiple sources of confirmation that funds are actually committed to their HTLCs via blockchain explorers.

@jasondavies

This comment has been minimized.

jasondavies commented Sep 17, 2017

Just to clarify, my original vision for a web-based tool does not involve any private keys being shared with the tool; it should only instruct the two parties to enter their {fund,redeem} addresses for the respective blockchains used in the trade, and later they may optionally monitor the trade's progress if they are happy to share some information with the server.

Given the XCAT parameters (4 addresses, hash of secret, 2 redeemblocknums) agreed upon by the counterparties, the tool should generate appropriate HTLC (escrow) scripts and accompanying P2SH addresses, and then instruct the users to send their funds to these addresses in the correct order while checking for sufficient confirmations. As @zmanian correctly points out, users should be encouraged to double-check for sufficient confirmations on other blockchain explorers and/or their own clients.

The maximum damage is that an attacker could steal all of the funds involved in a specific trade. If the attacker could modify the tool, they could do this in various ways e.g. by modifying the generated escrow script in a subtle way, such that only the attacker can retrieve the funds from the escrow.

This means that if all security mechanisms fail and an attacker is able to modify the site, each party would need to independently verify the HTLC scripts to prevent this attack to make sure their addresses/redeemblocknums/hash_of_secret have not been modified and the script is definitely doing XCAT. This could be mitigated by providing standard tools (e.g. Python scripts?) for easy independent verification of the HTLC scripts.

If the attacker is a counterparty for a trade, they might instead prefer to steal the initiator's preimage (secret) so that they can redeem the funds from the escrow without fulfilling their side of the trade. This would be harder to detect, since the HTLC scripts would pass independent verification. One way to mitigate this would be to avoid entering the preimage in the website until the counterparty has sent funds to the HTLC, but this would require additional steps for the initiator (i.e. they would need to generate a random preimage and compute its hash outside of the browser).

Ultimately, if XCAT becomes a standard way to do these types of trades, it should probably end up being something that wallets support (since users have to trust them anyway). For now, a web-based tool also serves as a way to educate and illustrate how XCAT works.

@tromer

This comment has been minimized.

Collaborator

tromer commented Sep 17, 2017

Good.
Assuming an honest-but-curious web server (i.e., the HTML+JavaScript t is correctly served but all traffic is logged), what information about the transaction is necessarily exposed to the server, and what remains in the client-side JavaScript?

@jasondavies

This comment has been minimized.

jasondavies commented Sep 17, 2017

In the case where the user does not elect to monitor the progress of the trade, only the user's IP address and user-agent (browser) information is exposed to the server, and the fact that they might be interested in performing a trade at the time they request the page. In this case the page is only used as an instructional tool and generates the appropriate HTLC addresses in-browser without further communication with the server. The user will be told how to monitor the trade themselves.

(However, note that timing could be used to correlate both counterparties if they both use the tool at similar times for the same trade, and assuming either does go ahead with a trade, it may be possible to correlate with XCAT transactions on either blockchain, which may be easy to locate if they are rare initially. The IP address/user-agent information could be anonymised e.g. using Tor/I2P to mitigate this.)

In the proposal, I mentioned the ability to bookmark/share a trade between counterparties, but this does not require additional information to be sent to the server; the trade parameters can be stored in the URI fragment which is never sent to the server.

If a user does elect to monitor the progress of a trade, the page could theoretically be implemented in a such a way that minimised information about the trade being sent to the server. For example, the client could effectively do SPV and filter for transactions in-browser. This still leaks some timing information to the server, however.

It would be simpler to give the server the two HTLC (P2SH) addresses and monitor whether they have been funded/redeemed yet. This eventually reveals everything about the trade to the server once it succeeds (amounts, source addresses for funds on Bitcoin, timing of transactions involved in trade, receipt addresses, refund addresses, preimage). This information is already public on both blockchains, of course, but the server potentially has information about the users' IP address and user-agent. Again, something like Tor/I2P could be used to mitigate.

@tromer

This comment has been minimized.

Collaborator

tromer commented Sep 17, 2017

Sounds good! I'm glad to see you're on top of things.
All of these need to be considered in the UI design and documentation, of course.

Regarding monitoring: can this be done with better privacy using IPFS? (Do we have robust IPFS feeds for the Zcash blockchain? What are the privacy properties of IPFS fetches? Pinging @arcalinea, @whyrusleeping).

@whyrusleeping

This comment has been minimized.

whyrusleeping commented Sep 20, 2017

If you implemented all the XCAT logic in a static webpage using javascript and made all api requests to local zcash and bitcoin clients, you could add the page to ipfs, and users could fetch the app through the network. An attacker would be able to see that a user fetched that data, but wouldnt gain any info about the specific transaction being watched. the URI fragment (assuming the link is handled securely) would be able to inform the page about which transaction to watch.

Specifically:

What are the privacy properties of IPFS fetches?

An attacker could see data is being fetched. There is an experimental Tor plugin being developed by the OpenBazaar crew, which would theoretically obscure that, but we havent had the plugin properly audited and don't advocate people rely on its privacy yet (getting an audit set up for it is in progress).

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Oct 4, 2017

Every informal proposal has multiple reviews by the review committee. The reviews are being collected and discussed in a private google doc (the 5 reviewers all have edit access to it, no one else can view it). By way of early, informal feedback, the reviewers have made a list of projects that they consider leading candidates for grant funding.

In that vein, your project was selected as one of the leading candidates, and the review committee encourages you to submit a full proposal by October 6th and looks forward to reviewing it.

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Oct 6, 2017

Also just a reminder @jasondavies that the submission deadline is October 6th! Please endeavor to have a final proposal submitted by then, as an attachment to this issue (and yes, it can be October 6th anywhere in the world).

@jasondavies

This comment has been minimized.

jasondavies commented Oct 6, 2017

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 21, 2017

@jasondavies, what are your thoughts on XCAT for z-addresses?

@tromer

This comment has been minimized.

Collaborator

tromer commented Oct 21, 2017

@jasondavies, do you propose to run a public online service, or just release the tool (and hope that someone else will run and maintain a server)?

We hope the proposal includes running a public server (say for 12 months).

@jasondavies

This comment has been minimized.

jasondavies commented Oct 21, 2017

We hope the proposal includes running a public server (say for 12 months).

Yes, happy to run this for at least 12 months (probably indefinitely).

@jasondavies

This comment has been minimized.

jasondavies commented Oct 21, 2017

what are your thoughts on XCAT for z-addresses?

Good question. The initial sending of funds to the escrow address can happen from a z-addr (on the Zcash side of the trade, of course).

However, the escrow address itself is a t-addr (P2SH address), and so funding the escrow will still reveal the amount involved in the trade. Later, when the escrow is redeemed, the full escrow script is also publicly revealed. A successful trade will ultimately reveal all of the trade parameters (4 addresses and random preimage/secret).

In terms of redeeming the funds from the escrow address, note that the "addresses" I mentioned are in fact pubkey hashes (P2PKH addresses). Thus, collecting the amount from the escrow address on the Zcash side could be done by providing an appropriate signature for redemption (i.e. using the private key for that pubkey hash) and sending the amount to a z-addr.

Assuming this is desirable and not too confusing, I could see modifying the instructions for the Zcash side of the trade to allow z-addrs for both funding and redeeming.

(From my understanding of the plans for Sapling, it should be possible to do XCAT privately on the Zcash side in future e.g. via zcash/zcash#2425.)

@arielgabizon

This comment has been minimized.

arielgabizon commented Oct 21, 2017

Yeah unless we have p2vk it seems hard. I'll use this chance to once again advertise my z-addr xcat with Ethereum, that makes use of contract and snark verification on their side

https://gist.github.com/arielgabizon/7e9906d3e06106cb5cfb7651a954c8b4

@jasondavies

This comment has been minimized.

jasondavies commented Oct 21, 2017

I'll use this chance to once again advertise my z-addr xcat with Ethereum, that makes use of contract and snark verification on their side

Very nice indeed! It would be great to add support for this type of XCAT in future. I checked all of the various cases while taking into account your two footnotes (subtleties) and it all seems to work fine. It would need a similar time-related (block number) lock on the ETH contract to ensure Bob has sufficient time to redeem their ZEC with sufficient confirmations, before Alice is allowed to redeem the ETH.

@zmanian

This comment has been minimized.

zmanian commented Oct 21, 2017

@jasondavies A massive amount of funding has gone into decentralized exchange protocols in the last few months, it would seem natural that some of them will be XCAT tooling for Zcash into their settlement layer. What is your analysis of the possibility that this tool might be obsoleted in the near future?

@arielgabizon

This comment has been minimized.

arielgabizon commented Oct 21, 2017

@jasondavies thanks for going over it!

@zmanian As far as I know no one is working on bitcoin-Zcash XCAT, do you know otherwise?

@zmanian

This comment has been minimized.

zmanian commented Oct 21, 2017

It's in phase 2/ phase 3 of a couple roadmaps. Most people want to do easy stuff like erc20 then other chains.

But once you have price discovery and matchmaking for multiple assets adding XCAT settlement is easy....

@jasondavies

This comment has been minimized.

jasondavies commented Oct 21, 2017

What is your analysis of the possibility that this tool might be obsoleted in the near future?

I suppose my proposal has two aims, and one of them is to improve the public’s understanding of how XCAT works. This is both for non-technical users and the more technical users who may be interested in developing their own services and wallets that support XCAT. The main way I hope to achieve this is by representing the protocol visually (with optional monitoring for specific trades). I think the protocols that you’re referring to are probably more focused on providing order books and hiding the details of the protocol from end users (which is fine for their purposes).

The second aim is to facilitate real XCAT trades between any two parties, e.g. OTC-type trades, starting with support for ZEC/BTC. The idea would be to add support for other compatible blockchains afterwards, and potentially even extend the tool to support other cross-chain protocols. The semi-private ZEC/ETH protocol that Ariel suggested is one example of this. So I think it’s still going to be quite useful to have a tool and service that makes it easy to understand and experiment with these types of trades.

@zmanian

This comment has been minimized.

zmanian commented Oct 21, 2017

Good answer!

@acityinohio

This comment has been minimized.

Collaborator

acityinohio commented Nov 21, 2017

@jasondavies : I'm thrilled to inform you that the Grant Review committee—and the Zcash Foundation board—has tentatively approved your proposal! While the recommendations are already posted, we are planning to make a more public post tomorrow morning (November 21st) Pacific Standard Time.

Next steps: please email me josh [at] z.cash.foundation with an email address suitable as a point of contact. Due to our newfound 501(c)3 status there are additional reporting and compliance burdens that may delay or change disbursements, but we are working through them as fast as we can.

Just in case you didn't see it, please find the committee recommendation for your project below, and congratulations again!

Proposes to implement a web-based service for creating and monitoring of cross-chain atomic trades (XCAT) between Zcash and Bitcoin. The proposal extensively discusses the privacy and security tradeoff in the design of the such a system. The budget includes both the development of open-source software and running it as an online service for 12 months. The implementation will initially perform unshielded (t-address) trades, and may be later extended to shielded trades.

One concern was that similar XCAT tools may be developed independently, by recently-funded decentralized exchange platforms; the proposer made compelling arguments that this tool will nonetheless remain useful to the Zcash community.

@acityinohio acityinohio added the awarded label Nov 21, 2017

@techoluwoye

This comment has been minimized.

techoluwoye commented Jan 25, 2018

@jasondavies

Happy new Year hope all is well! My name is Oyedeji Oluwoye founder of Coincentrix Capital and fellow recipient of the Zcash Foundation Q4 grant. I am putting together material for the education of Zcash and would love to know and dive into the ZEC↔︎BTC atomic trading concept. Will you be available sometime next week briefly to Sync?

Regards,

Oyedeji Oluwoye

@jasondavies

This comment has been minimized.

jasondavies commented Jan 25, 2018

@techoluwoye Sure, send me an email?

@techoluwoye

This comment has been minimized.

techoluwoye commented Jan 25, 2018

@jasondavies this email: jason@jasondavies.com correct?

@jasondavies

This comment has been minimized.

jasondavies commented Jan 25, 2018

Yes.

@techoluwoye

This comment has been minimized.

techoluwoye commented Jan 25, 2018

@jasondavies perfect!

@sonyamann

This comment has been minimized.

sonyamann commented Jun 20, 2018

Requesting an update on this grant too :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment