[tor-talk] BitPay seems to be rejecting payments via Tor

[grarpamp]

On Sat, Mar 18, 2017 at 8:55 AM, Mirimir <mirimir at riseup.net> wrote:
> OK, some streams do last more than a day. But then they must pin the
> exit relay, right? So in that case, you'd keep the IPv6 until the stream
> ended, even if there were circuit changes with different middle relays.
>
> I don't get why changing exit IPv6 would break resuming by client-side
> apps. They don't (and shouldn't, obviously) manage exit IPs. Tor daemon
> handles that. So they'd be oblivious as long as exit IPv6 persisted as
> long as relevant streams, right?

Pinning exit only helps if the exit is the effective IP connecting
to whatever clearnet service / peer user is using.
If talking about using VPN, NAT, or whatever thing after the exit, then the
output side of that thing is what is doing the TCP/UDP to the service.
And pinning exit helps stability to input side of that thing as well.
Whatever your effective IP is, if it's flapping around out from under
your app, your app breaks, at least momentarily till it's noticed.

>> Millions of circuits worth of v6 a day also happen.
>> But yes you could get and SWIP a v6 /whatever worth
>> and throw them once a week or whatever your get and use
>> model for users rationally permits. Once a week is 52.
>> One per requestor, spread across all exits, probably possible.
>> v6 are unlimited but hosters probably still charge like gold for them.
>> Some operators should try it and see.
>
> Well, I got a couple /64 for free from GigaTux for a low-end VPS. For
> the VPN-testing project. And they do run a Tor relay, if I recall
> correctly. A /64 gives you 1.8 x 10^19 IPv6. With ~2 x 10^6 daily users,
> that's ~10^13 circuit days per user. So hey, I'll ask.

Trying to extend some new tor level circuit api out to a new control
interface on OpenVPN / NAT seems much work, and unrelated
to dodging censorship... circuits only serve anonymizing / protective
purpose internal to tor involving choosing its path and exits.

OpenVPN itself, or kernel nat filter rules, could be extended
to shove / switch matching traffic (like hashes of destination address
prefixes or flow tuples) over some IPv6 rotation machine schedule.
There may already be some kernel kit for the matching part.

IPv4 blocks cost money to play with and deploy so that's
moot as far as rotation goes. But an extra ipv4 address is
still valid for an exit or openvpn operator to park an
openvpn node on for getexitbridges.

I posted some long thing somewhere once about various
ways operators could bind openvpn to tor exits for use by users.
SSH or some other v6 proxy, authenticated or not, could also work.
Operators could also raise funds by running these things.

> But how would Tor Project's relay monitoring work for exits with no
> stable IPv6 address? Wouldn't they lose the exit flag?

If you're providing some passive nat rotation scheme...
1) As before, someone should research the net result of providing DNSEL's.
Not just to legal strategic friendly of TPI / tor, but to speech / reading.
2) No, the stable flag is probably of more interest.
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2231

If you're 'getexitbridging' that requires user to connect up...
then neither TPI or tor code are a problem.