Arti: A pure-Rust Tor Implementation for Zcash and beyond

[holmesworcester]

@str4d

It is not a requirement (we support running zcashd without Tor, with Tor outgoing-only, and with Tor listening), but if we are going to bundle a Tor implementation then it would make sense for it to replace all cases where we use Tor

@str4d, what do you think about the following perspective?

@teor

In Zebra, we’re not planning to download the entire chain over Tor, because that puts a lot of load on the network, and doesn’t provide much extra anonymity. Since you’re downloading the entire chain, network-level observers can tell you’re using Zcash, but they don’t know which transactions you’re actually interested in.

Teor is saying that in the full node context, it’s much more important to send tx’s via Tor than it is to receive tx’s via Tor.

Assuming there are a few nodes that can receive on an onion service, or assuming you don’t need to connect to an onion service to safely deliver your tx to the network given some checks to make sure it was actually delivered (I think this might be true) maybe onion service support is not so critical to zcashd.

Thoughts?

Asking because being able to leverage work on Arti as soon as it can connect over Tor safely seems better than having to wait until Arti folks finish onion services.

[alchemydc]

Hi @nickm_tor and welcome to the Zcash community! We are all glad to have you here.

I’ve been a long time user and supporter of Tor, and am very excited to see the progress to date on Arti. A native Rust implementation of Tor that’s easy to import as a library to provide network level privacy would be a significant benefit, not just to Zcash users, but to the world!

I believe that @holmesworcester is correct that the Zcash community would want to see capability delivered that delivers value directly to Zcash clients, and he’s correctly enumerated the key players in the Zcash ecosystem to date.

Recently, I’ve run into issues when spiking on network privacy for Zcash light clients. The issue is related to the Zcash light client SDK’s use of grpc, which is rapidly gaining in popularity as the ‘on the wire protocol of choice’ for some of the best dev teams on the planet. grpc is awesome, but presently lacks SOCKS5 support and is unlikely to get it anytime soon. It’s my understanding that the interface of choice for client connections to Tor is SOCKS5, and that other methods (eg HTTP CONNECT) increase the risk of DNS leaks and don’t support plain HTTP. Given this, it would be an important success criteria IMO for the Arti team to work with the Zcash Light Client Working Group to ensure that the interface Arti exposes works well with the Zcash light client SDK and the underlying grpc protocol.

Finally, to Holmes’ assertion that security is important, I agree and would advocate that the proposal be structured to include iterative security reviews, with a preference for working with security auditors that provide findings as failed test cases, so that regressions can be identified programmatically via CI.

Overall, I’m super excited to see this proposal floated. Zcash + Tor == <3

DC

[str4d]

@holmesworcester

@str4d, what do you think about the following perspective?

I think that perspective is perfectly fine for a new full node implementation with no current userbase. But zcashd has an existing userbase, some of whom may be relying on this feature, so we need to take that into account. We can’t know for certain whether anyone is using the feature (in part because I explicitly do not want to be in the privacy-degrading business of enumerating Tor onion services and figuring out what they are being used for), but given that zcashd will automatically listen on an onion address if a Tor daemon is accessible, it’s very likely there are some users who are relying on it without realising.

I don’t think this should block work on Arti, and it doesn’t necessarily mean that we would not release an initial Arti integration into zcashd without onion service support, but we would be considering the usability of such a version before deploying it to our users. It would most likely be placed behind an experimental feature flag.

@alchemydc

It’s my understanding that the interface of choice for client connections to Tor is SOCKS5, and that other methods (eg HTTP CONNECT) increase the risk of DNS leaks and don’t support plain HTTP.

One of the top benefits of having a Tor library: the interface would be Rust APIs, not a SOCKS proxy

[earthrise]

Since, as others have noted, Zcash nodes already receive transactions privately by dint of downloading everything, probably the highest impact use of Tor for Zcash would be to broadcast transations privately, because that isn’t private right now. So it sounds like Arti would be extremely helpful for fixing this by adding anonymous broadcast functionality into full nodes and light wallets.

I’m planning to recommend light wallets take the same approach—download everything to acheive transaction receipt privacy—so I want to play devil’s advocate and push back a little bit on Tor’s overall utility to light wallets.

As I explain in that post, fetching transactions over Tor doesn’t plug some of the important information leaks that are visible to network eavesdroppers, even ones who are only local to the wallets they are spying on. Wallets’ actions (downloading blocks, broadcasting transactions, fetching memos) are probably still visible through bandwidth side-channels, so eavesdroppers like an ISP or a country monitoring its inbound/outbound traffic can probably still figure out the graph of who’s paying who.

Even from a compromised lightwalletd perspective, Tor doesn’t plug the privacy leaks. Once transparent addresses are implemented, the wallet will be asking lightwalletd for its UTXOs by disclosing its transparent address. Even if all of the wallet’s actions happen over fresh Tor circuits, by matching up transaction fetches with UTXO fetches by timing, the adversary can still learn a lot about the transaction graph (modulo things we might do to minimize that leakage, like gating it behind a button click).

These are two reasons are why I don’t consider Tor to be as helpful for light wallet privacy specifically. Thinking longer term, and realizing that Zcash is an anonymous communication network, to scale Zcash we will need an ACN that’s as scalable as we want Zcash to be and has privacy properties as strong as we want Zcash’s to be (for example, do we care about global passive adversaries?). With that in mind, perhaps we should instead be funding mixnet R&D to replace Tor where we’re currently using it.

(Note that Arti is quoted as requiring two years to complete, and by that time I imagine Zcash will have implemented zk rollups and will be in the market looking for an ACN that’s secure against global passive adversaries. But in the shorter 3-6 month term quoted for a minimal safely usable version, I still see a strong need for Tor to broadcast transactions.)

Even with these caveats, it sounds like there’s enough existing use of Tor and user demand for Tor that Arti would be worth funding—and I love the concept—let’s just be careful that we don’t think of Tor as a magic bullet and end up bolting it onto things under mistaken beliefs about how well it will plug the privacy leaks, and let’s make sure it’s not taking away from mixnet R&D that we will need as Zcash scales.

[chelseakomlo]

@earthrise

As I explain in that post, fetching transactions over Tor doesn’t plug some of the important information leaks that are visible to network eavesdroppers, even ones who are only local to the wallets they are spying on. Wallets’ actions (downloading blocks, broadcasting transactions, fetching memos) are probably still visible through bandwidth side-channels, so eavesdroppers like an ISP or a country monitoring its inbound/outbound traffic can probably still figure out the graph of who’s paying who.

Hi Taylor- this “probably” is covering a lot of ground here. End-to-end timing attacks in a blockchain setting (where all transactions must be synced to the blockchain before the other party can receive them) seem less practically viable than an end-to-end timing attack in real-time applications like messaging apps.

So, let’s remember the setting we are in and be careful when applying conclusions made for different application settings. In parallel to this work to build out Arti, I think it would be valuable to work with external researchers to quantify exactly what is required for adversaries in blockchain settings to perform end-to-end timing attacks, while considering factors such as the size of the anonymity set as well.

[earthrise]

@chelseakomlo

Hi Taylor- this “probably” is covering a lot of ground here. End-to-end timing attacks in a blockchain setting (where all transactions must be synced to the blockchain before the other party can receive them) seem less practically viable than an end-to-end timing attack in real-time applications like messaging apps.

So, let’s remember the setting we are in and be careful when applying conclusions made for different application settings. In parallel to this work to build out Arti, I think it would be valuable to work with external researchers to quantify exactly what is required for adversaries in blockchain settings to perform end-to-end timing attacks, while considering factors such as the size of the anonymity set as well.

Hi Chelsea!

I’m imagining an attacker who’s learning timing/bandwidth information by eavesdropping on the wallet’s network traffic directly rather than through the entire blockchain/p2p stack. I think this kind of leakage is important even in a blockchain wallet setting. At the risk of being too verbose here’s why I think these are practical concerns.

The most practical way to exploit this leakage right now would be to eavesdrop on the lightwalletd server’s traffic. An attacker in that position would be able to see when each wallet connects and disconnects (wallets being identified by IP address currently), and they could also tell by the amount/“shape” of data the wallet sends/receives when the wallet is submitting a transaction, downloading compact blocks, requesting a memo, and so forth. (I’m like 90% confident that the current gRPC-over-TLS protocol actually leaks all of this information, but I haven’t PoC’d it)

I believe that leaks an approximation of the entire transaction graph, because the attacker learns a bunch of facts like:

• “127.8.7.5 submitted a transaction just before block 285875 was mined”
• “50.4.80.2 connected and synced, and around where you’d expect them to be at height 285875 they requested a memo”
• “67.90.122.73 connected and synced, and never fetched a memo for this range of blocks”

From this the attacker learns 127.8.7.5 paid 50.4.80.2 in that particular transaction, and that 67.90.122.73 didn’t receive any transactions since the last time it synced.

Now add Tor, and the IP addresses go away, but depending on how well Tor pads traffic, the general structure is still visible to the attacker. It’s not clear to me how much worse the attacker’s approximation of the transaction graph gets, but it’s at least clear that there’s still some leakage that could be of practical importance. I totally agree it would be amazing to see some research that investigates how feasible the attack still is!

Switching away from light wallets and thinking about a full node broadcasting a transaction, adding Tor has this effect:

Before Tor

• The wallet’s ISP and the first peers it sends the transaction to all learn “Wallet 67.90.122.73 just sent transaction 0xFFF33CCC…”

After Tor

• The p2p peers no longer learn who originated the transaction since it came through a Tor exit node or connection to a .onion peer.
• The wallet’s ISP still learns “Wallet 67.90.122.73 just sent transaction 0xFFF33CCC…”, because they (a) know the wallet’s IP address because they’re its ISP, (b) see some Tor traffic from the wallet, which they reliably guess is a transaction broadcast, then (c) they quickly look for the latest transaction to show up in the mempool to find out which transaction the wallet sent.

I agree Tor is worth doing to cut off the leakage to p2p peers but we should keep in mind that leakage to local eavesdroppers is still there (at least until we’ve done research to quantify how much of a problem it is—which I’d love to see/contribute to!)

[earthrise]

Oh, I might have misunderstood what you meant by the timing attacks being end-to-end. They are end-to-end in the sense that the attacker watches one wallet broadcast a transaction and then has to wait for the other wallet to download it after it’s mined etc.

However the attack I’m proposing isn’t to correlate the timing of the send to the timing of the receive, it’s to figure out which wallet sent which transactions, then figure out which transactions other wallets fetched, and match them up that way. Of course with Tor the lightwalletd eavesdropper doesn’t learn “which wallet” anymore (aside from however well they can be identified by their behavior, I’m unsure how well that is), so it does start to look like doing timing correlations end-to-end through the whole system. My hunch is that it’s still leaking a lot of information about the transaction graph, but yeah research is needed here. Local network eavesdroppers like ISPs do still have the “which wallet” information, so there it’s a question about how much do users care about that leakage.

[nickm_tor]

Thanks for the feedback, everybody!

Thanks to the information above from developers on Zcashd and Zebra, I’ve substantially revised our planned milestones. Instead of “First all the security, then all the features”, I’ve reorganized the arti plan to focus on a few target releases (release numbers may not be actual):

• 0.0.1 – a minimal secure-enough release that might not be so usable, but has solid internals and won’t wreck your privacy. Alpha-level embedding support, suitable for internal testing by developers.
• 0.1.0 – a release targeted for usability and embedding. Beta-level embedding support, suitable for giving to users and gathering experience.
• 1.0.0 – a production-ready release for general use. Stable embedding support.
• 2.0.0 – a full-featured release that can replace the C tor client for all purposes.

You can see the current milestones and their tickets on our gitlab instance. Here are some highlights (see gitlab for full details):

• 0.0.1 (estimating 4 months)

  • Decent test coverage
  • Guard-node support
  • Stream isolation
  • Correct circuit-construction logic
  • Initial APIs for embedding safely and avoiding the most common Tor usage errors.

• 0.1.0 (estimating 4 months)

  • Preemptive circuit construction for improved performance
  • Full API support for configuration and embedding in more circumstances, with some efforts towards API stability.
  • API support for reporting on on bootstrap status and issues

• 1.0.0 (estimating 6 months)

  • Security audits
  • Stable API
  • Stable CLI
  • Automatic detection and response of more kinds of network problems
  • Work on network bottlenecks TBD
  • API level “dormant-mode” support for constrained-bandwidth clients.
  • Performance work for parity with C client in bootstrapping and networking

• 2.0.0 (estimating 15 months)

  • V3 onion services (client side)
  • V3 onion services (service side)
  • Censorship evasion support (client side)
  • Improved fairness and queueing (for high-load clients and onion services)
  • Circuit and channel padding support (for traffic analysis resistence) “Optimistic data” for faster start on streams
  • Possibly, automatic dormant mode for mobile clients
  • Possibly, backward compatibility with some of the existing Tor controller protocol.
  • Support for rate-limiting and bandwidth accounting
  • Supported C FFI.

Note that the feature breakdown for these milestones is in flux, and is deliberately somewhat flexible in order to meet evolving needs from downstream developers. It’s likely that something I’ve identified as “not needed for our first production release” will actually be something that Zcash wants after all; if so we can move some of the features above around as needed.

Here are our next steps here:

• I’m going to make sure to be in contact with teor and str4d (along with dconnolly, pili, chelseakomlo, and anybody else I’m introduced to) about those milestones and their general suitability.

• We’re doing test-builds on mobile (especially iOS) as a proof-of-concept for deployment there.

• Based on the above, we’ll write our grant appplication and submit it to ZOMG!

[teor]

@nickm_tor

0.0.1 (estimating 4 months)

• Decent test coverage
• Guard-node support
• Stream isolation
• Correct circuit-construction logic
• Initial APIs for embedding safely and avoiding the most common Tor usage errors.

Having an alpha release after 4 months fits well with our rough zebra-client timeline. We should be ready to give some feedback around then.

But there’s still a lot of decision-making and detailed planning to be done on all sides, so let’s check back in a month or two.

[holmesworcester]

Reading through this thread, I think one question that might come up on the ZOMG side is: to what degree could increased funding shorten the timeline?

@nickm_tor

It’s likely that something I’ve identified as “not needed for our first production release” will actually be something that Zcash wants after all; if so we can move some of the features above around as needed.

This is really helpful, since our priority is to fund work that makes Arti usable in Zcash tools as soon as possible.

Another side of this is, are you open to dropping requirements that ECC and ZF do not have, as their requirements come into focus, in order to ship something that’s ready to incorporate into zebra and zcashd?

[teor]

@holmesworcester

This is really helpful, since our priority is to fund work that makes Arti usable in Zcash tools as soon as possible.

Another side of this is, are you open to dropping requirements that ECC and ZF do not have, as their requirements come into focus, in order to ship something that’s ready to incorporate into zebra and zcashd?

Sending Transactions

Looking at the milestone summary above, here are some features that Zebra (and likely zcashd) won’t need for sending network-anonymous transactions using Arti:

• Preemptive circuit construction for improved performance
• Performance work for parity with C client in bootstrapping and networking
• Improved fairness and queueing (for high-load clients and onion services)
• “Optimistic data” for faster start on streams

Since Zcash transactions only get turned into blocks every minute or so, we won’t be particularly concerned about performance.

Here are some things we might want sooner than 2.0.0:

• Censorship evasion support (client side)

Censorship evasion helps us support users on networks that try to block Tor. We need censorship evasion (or a non-anonymous fallback) before we enable tor by default.

Light Clients / Wallets

We might need better performance if we’re using Arti to provide anonymity for wallets and light client servers. We should check what wallet users expect, and how latency affects different wallets.

And if the light client servers or Zcash nodes are using onion services, we’ll want these features in 1.0.0:

• V3 onion services (client side)
• V3 onion services (service side)

[nickm_tor]

@holmesworcester

Reading through this thread, I think one question that might come up on the ZOMG side is: to what degree could increased funding shorten the timeline?

That would work, but would require some ramp-up. If we could hire another Rust programmer beyond our existing team, that would help us somewhat for a few months as they come up to speed with Tor and we all share knowledge, and it would help us a lot after the first few months. So it would probably speed up the first milestone only a little, but remaining milestones significantly more.

@holmesworcester

Another side of this is, are you open to dropping requirements that ECC and ZF do not have, as their requirements come into focus, in order to ship something that’s ready to incorporate into zebra and zcashd?

Yes, in most cases. There are things that we couldn’t drop or defer, since they’re privacy requirements, but I think we can be reasonably flexible otherwise.

@teor

here are some features that Zebra (and likely zcashd ) won’t need for sending network-anonymous transactions using Arti:

• Preemptive circuit construction for improved performance
• Performance work for parity with C client in bootstrapping and networking
• Improved fairness and queueing (for high-load clients and onion services)
• “Optimistic data” for faster start on streams

Thanks for the feedback! I think we can easily defer all of this, except for the preemptive circuit construction, where I think there are likely to be privacy implications.

@teor

Here are some things we might want sooner than 2.0.0:

• Censorship evasion support (client side)

That’s probably doable.

@teor

And if the light client servers or Zcash nodes are using onion services, we’ll want these features in 1.0.0:

• V3 onion services (client side)
• V3 onion services (service side)

These ones are big; they’re likely to have a major effect on this size of the milestones. If they need to be there sooner rather than later, I think we might do better to contemplate a “milestone 1.1” for them, possibly.

[aiyadt]

@holmesworcester

Thanks @aiyadt, it’s really helpful to know that you think this would be helpful for Nighthawk. If you at any point have updates from your tests on Tor integration it would be great to know more!

On the Android front, we’ve tried 3 different implementations of tor setups:

1. GitHub - thaliproject/Tor_Onion_Proxy_Library: Provides a JAR and an AAR for embedding the Tor Onion Proxy into a Java or Android Program
2. GitHub - jehy/Tor-Onion-Proxy-Library: Provides an AAR for embedding the Tor Proxy into Android Program. Forked from https://github.com/thaliproject/Tor_Onion_Proxy_Library and updated with the latest Tor binaries, JtorCtl library and good samples.
3. GitHub - horizontalsystems/tor-kit-android

The first two are not updated in a while which makes them incompatible with the recent versions of Android, and the 3rd one is the Unstoppable team’s implementation which works with minor exceptions(when resuming the app from the background resulting in ungraceful UX), and it requires minimum Android API version to be updated to 26(Android 8.0 Oreo) that leaves a large portion of users with older devices behind.

Making tor work on Android client app via libraries is one thing and making it work all the time is another. The worst thing would be to give the user a false sense of privacy for when the tor connection gets interrupted and Android networking resets for the app, resulting in information leaks.

I am leaning towards making tor integration happen at the rust later of the SDK(via Arti), that way no info can ever leave the SDK without the tor circuits being active.

[holmesworcester]

@teor

And if the light client servers or Zcash nodes are using onion services, we’ll want these features in 1.0.0:

@teor I had a question about this, which might be relevant to ZOMG funding:

Am I correct that lightwalletd’s do not need to provide onion services for users to get the privacy benefits of using Tor, as long as the wallet app has the correct SSL certificate for the lightwalletd it is connecting to?

That is, I’m trying to figure out if milestone 1.0.0 above gives us an Arti that can provide meaningful network layer privacy benefits to wallet app users, through straightforward integration into lightwallet SDKs.

My sense is that it does, but I want to make sure.

[teor]

@holmesworcester

Am I correct that lightwalletd’s do not need to provide onion services for users to get the privacy benefits of using Tor, as long as the wallet app has the correct SSL certificate for the lightwalletd it is connecting to?

That is, I’m trying to figure out if milestone 1.0.0 above gives us an Arti that can provide meaningful network layer privacy benefits to wallet app users, through straightforward integration into lightwallet SDKs.

With Arti 1.0.0, light wallet clients can connect to light wallet servers via Tor exits. And users will have good network privacy. At the moment, they have no network privacy at all, so that’s a big improvement.

In Arti 1.1.0, onion services will provide an incremental improvement in security and privacy, and defend against some edge cases. For example, onion services don’t rely on DNS or SSL certificates, they do their own end-to-end authenticated encryption. And all the communication is kept within the Tor network.

(The DNS and exit-to-server edge cases are mitigated by SSL certificates anyway, so they are lower risk for light wallet clients.)

Onion services are also a bit more complicated to deploy, so we’d want to start using Tor exits first anyway. Adding a Tor exit is just like adding any other proxy. But with onion services we need to change server addresses on the client, and set up an onion service on the server.

[teor]

@nickm_tor

@teor

here are some features that Zebra (and likely zcashd ) won’t need for sending network-anonymous transactions using Arti:

• Preemptive circuit construction for improved performance
• Performance work for parity with C client in bootstrapping and networking
• Improved fairness and queueing (for high-load clients and onion services)
• “Optimistic data” for faster start on streams

Thanks for the feedback! I think we can easily defer all of this, except for the preemptive circuit construction, where I think there are likely to be privacy implications.

Hi Nick, I’ve just noticed that IPv6-only network support is in the Arti 1.0.0 milestone.

Most wallets just use DNS, and the Zebra and zcashd nodes use generic IP address objects. But the Tor protocol still makes quite a few internal distinctions between IPv4 and IPv6. So IPv6 support isn’t automatic.

So in Arti 0.0.1 or 0.1.0, wallets or nodes might suddenly stop working on some networks. (Some mobile networks are IPv6-only, and it’s becoming more common across all kinds of networks.)

Ideally, Arti integrators shouldn’t even have to think about IPv6-only networks.

(And if Arti restricts IP version handling to a small number of its internal modules, it will be a lot easier to build universal abstractions.)

For the alpha and beta versions, we’ll need to fallback to direct connections anyway. So maybe we don’t need to move IPv6-only support into an earlier milestone.

But I certainly wouldn’t object to having IPv6-only work earlier.

In any case, wallets and nodes will really benefit if Arti just works across a wide range of networks. So I’d encourage you to use generic addresses inside Arti. As a developer, I’ve really enjoyed being able to use SockAddrs all over the place, and just have them work.

(I hardly notice when my broadband falls over to mobile, and I get an IPv6 address.)

[holmesworcester]

@nickm_tor ZOMG discussed your proposal at our meeting this week and there was a lot of support for it among ZOMG members.

Given the size of the grant and the length of the grant timeline, we’re considering committing as far as one of the middle milestones, e.g. 1.1.0 in the milestones, and we wanted to know whether that would work for you or change the proposal in any way.

This would take us about 15 months into the grant, at which point a future ZOMG would have more information about whether to renew. 1.1.0 is also significant in that it’s the point where Arti would be ready to integrate into Zcash wallet apps like Zecwallet, Nighthawk, and Unstoppable, for which hidden service support is not required, as it would be for full Zcash nodes to use Arti.

I assume that funding for 15 months, with the likelihood of continued funding if things are successful, would be a good outcome here for all of us! But if there are any issues with this, or if it changes the proposal in any way, could you let us know?

I should also say that it’s still possible we’d decide to commit to the entire grant, with milestone-based payouts along the way, but having the flexibility to commit to the shorter ~15 month timeline makes it more likely we will fund you at some level.

Finally, the most important factor in us choosing to fund this grant will be, “is this important for Zcash, and will it definitely benefit Zcash users by becoming part of popular Zcash tools?” Most of us here are big fans of Tor, obviously. But our mandate is to fund work that strengthens Zcash and we take that seriously. We have key people at the ZF, ECC, and Nighthawk saying here in this thread that it is useful and will be used. But given the grant size we’re hoping to get an official thumbs-up from both organizations. So we’ll be reaching out to them both about that!

We’re also wondering if there’s any work we should budget for on your end that would increase our confidence that Arti will be integrated in Zcash tools. For example, could your team dedicate resources to actually integrating Arti into the wallet app SDK, or Zecwallet? Or to work alongside Zcash teams doing the integration? Could Zcash integration itself be one of the grant milestones? Given that ZOMG doesn’t itself have a development team, and that ECC and ZF have shifting priorities, it seems like we should do everything possible to consider “last mile” work right now in this proposal. Again, anything we can do to increase the likelihood of Tor getting integrated into Zcash tools—and benefitting Zcash users—will help ZOMG approve this proposal, so we’re open to ideas about this, and we’ll be asking the same questions to the teams working on these tools.

[teor]

@nickm_tor

You can see the current milestones and their tickets on our gitlab instance .

Looking at the milestones and tickets, it seems like Arti is aiming for a similar async architecture to Zebra:

• Async, service-based network stack: A New Network Stack For Zcash - zcash foundation
• An async verification/encryption pipeline: zebra/0002-parallel-verification.md at main · ZcashFoundation/zebra · GitHub
• Concurrent futures for Tor cells and directory documents

An async architecture like this makes things really fast, particularly on machines with lots of cores and good network connectivity. And it makes batch cryptography really easy to implement: Composable Futures-based Batch Verification - zcash foundation

The Zebra team is happy to do an architecture walkthrough if you’d like. We’re also working on a list of common async Rust pitfalls.

[nickm_tor]

Hi, @holmesworcester !

@holmesworcester

Given the size of the grant and the length of the grant timeline, we’re considering committing as far as one of the middle milestones, e.g. 1.1.0 in the milestones , and we wanted to know whether that would work for you or change the proposal in any way.

We could certainly work with an initial plan to fund only through 1.1.0 milestone. This would give us time and space to make significant progress and show the benefits of this approach, and get our early integrations together.

@holmesworcester

We’re also wondering if there’s any work we should budget for on your end that would increase our confidence that Arti will be integrated in Zcash tools. For example, could your team dedicate resources to actually integrating Arti into the wallet app SDK, or Zecwallet? Or to work alongside Zcash teams doing the integration?

Good questions! As for those integrations: we at Tor aren’t necessarily the right team to develop patches for apps in the Zcash ecosystem. (That’s not where our expertise lies, and our performance at this task would probably be less efficient than more experienced cryptocurrency developers.) But we would be more than happy to put forth the work and effort to support wallet developers at every stage of their integration plans. We especially want to make sure that their needs are met by our APIs, and have included the cost of that that needs-discovery within the Zcash ecosystem as part of our project estimates.

We hold ourselves ready to plan collaboration with the developer teams at ECC and ZF, whenever it’s a good time for them to do so, and we look forward to identifying all the ways we can make such an Arti integration successful. The right outcomes here will also depend on ECC and ZF and their own timelines.

Once we are in communication with the right folks at ECC & ZF (we hope you can set this conversation up, to make sure we’re talking with the right people), we can figure out the best details for this collaboration, possibly with refinements to the roadmap.

Does this sound like a good way forward?

[nickm_tor]

@teor

Most wallets just use DNS, and the Zebra and zcashd nodes use generic IP address objects. But the Tor protocol still makes quite a few internal distinctions between IPv4 and IPv6. So IPv6 support isn’t automatic.

Hi, @teor!

Given this need, here’s what I see as the best way forward. I think we should move minimal IPv6-only client support forward from 1.0.0 into 0.0.1, but leave complete support for 1.0.0. This way integrators and beta testers can run on IPv6-only networks from the beginning.

By “minimal IPv6-only client support”, I mean that clients that only have IPv6 should be able to bootstrap and connect to the Tor network and work reasonably okay. (This would probably involve a not-very-optimized ‘happy eyeballs’ style approach.) Unless I’m wrong, doing this part won’t add more than a day or two to our 0.0.1 estimates.

By “complete IPv6-only support” I mean a more complete set of features where clients adaptively learn whether they’re v4-only, v6-only or multistack; where the application can tell Arti to only use a single stack; where we optimize our connect()-probing agorithm for better behavior, etc.

How does that sound?

@teor

Looking at the milestones and tickets, it seems like Arti is aiming for a similar async architecture to Zebra:

That’s right. We’ve been trying to structure our crates into (roughly) three tiers with respect to async-ness:

1. The lowest level of code doesn’t know about async-ness at all. It’s just straightforward blocking code.[^*]

2. The middle tier knows about async programming and futures, but nothing about specific async runtimes. Because of that, it can’t spawn tasks, listen, launch network connections, sleep, etc.

3. The top tier knows about runtimes, as abstracted through a compatibility crate.

[*]: To make it easier to add asyncness later on, we require that expensive cryptographic operations are in different function calls from everything else though. For example, signature checking and parsing are always separate calls.

@teor

The Zebra team is happy to do an architecture walkthrough if you’d like. We’re also working on a list of common async Rust pitfalls.

Both of those sound excellent to me. I’d also love to bring Zebra devs in on an Arti walkthrough some time, if you’re interested. (I don’t expect I’d teach you much, but you would probably spot areas where we could do better.)