The "high taxation is not slavery, because you voted" argument lost all merit once net recipients of the welfare state became able to out-vote its net contributors - which has already happened in the US.

> make sure old people don't starve

If only that were what the extent of what social security actually does. But it's not properly asset tested. So broke millenials are paying a ton of payroll taxes, which are - after substantial adminsitrative overhead - transferred to their elders who almost always have significantly more assets than they do, and often don't even need a transfer at all, let alone as their only way of avoiding starvation.

It is true that acts of extreme violence are less common than they were in the 19th century South, but that alone does not make the system "not slavery" given that a threat of overwhelming force still underpins it.

This is not correct, and pretty much all of the US Elite, above a certain wealth level, have some offshore structure(s), because there actually are major, legal benefits - including ones that can zero out the US individual tax liability for that activity, at least in some years.

As a result it's only the legally- & financially- relatively unsophisticated middle classes, and perhaps the lower-upper-class, that has literally every single transaction subject to US taxation.

If anything is actually protecting clients against crypto theft, it's the exchange's privately-purchased insurance rather than the government. Although I wouldn't rely on that for much either as insurers are rarely eager to pay out.

The $20 gift from grandma is exempt, but not because they don't demand insight into intra-family transfers.. it's only non-taxable because of its size. If you have a rich grandma and she gives you $20k, that needs to be reported.. even if no tax is ultimately due, it probably reduces the future value of her estate tax exemption. Dying is a very complex taxable event!

If you want to follow the thousands of pages of rules to the letter - sufficient to sign a letter declaring under penalty of purjury, etc - the tracking and compliance burden on many US taxpayers is enormous, even with assistance from the commercial closed-source SW packages that you are more or less forced into buying each year because they won't let you e-file with them directly over HTTPS+JSON or whatever.

There are of course also many closed-source products that will never get a TCP/IP stack update. I haven't tested it but I doubt Win7 will ever be able to reach 0.1.2.3 over the public internet. Even if that's a bogus example, you get the idea: millions of dollars worth of old closed source gear out there where it's impossible for the owner to patch the TCP/IP stack.

As a result, to prevent strange connectivity problems on 0.X% of their connections, almost everyone will pay (and, if needed, significantly bid up) the ~$20/yr "normal" IPv4 address cost to get an existing "non-reclaimed" IPv4 address instead of taking a gamble on one of these new ones that will definitely have problems with many other hosts. In short I don't see a voluntary rational buyer or user until the IPv4 market rises 10X+ and probably more like 100X+; until then they seem like more of a liability than an asset given how annoyingly long it will take to retire (or somehow otherwise ensure that you'll never need to talk with) non-updatable IPv4 hosts.

Not that I like this, or am trying to defend or justify it, but I think it is an accurate assessment.

TLDR: pretty much everyone will actively avoid these addrs given that millions of hosts will never be able to reach them.

0. Put a CAPTCHA on expensive/abused functionality.

1. Rate-limit costly transactions to 1 per hour/day/etc (whatever's appropriate) per IPv4 address.

2. Limit total amount of data added to the db per time period per IPv4 address.

3. Iff you get a lot of abuse from VPS/cloud providers, block or even-more-severely-limit their published IPv4 ranges. Generally speaking a normal user will not write to a pubkey db from a cloud IP.

4. Iff you get a lot of IPv6 abuse, either go IPv4-only (no doubt this will make some people super-mad.. but when it's the only way to keep the service operational..). Sometimes treating every /64 as roughly equal to one IPv4 address is a sufficient defense.

5. If you don't like using IPv4 as the scarce good, then use some other primitive such as SMS verification of a phone number (that may be unacceptable for sks due to obvious privacy and highjacking concerns.. but it's basically what Signal does..)

6. Users (and environmentalists) will hate it, but if all else fails, require proof-of-work/hashcash. Periodically expire keys that didn't submit a $1-10 POW ticket each year, etc. Or an equivalent minable cryptocurrency payment.

Storing serious amounts of money in any of these stablecoins for any real length of time is economically irrational because by exiting their walled garden, you can obtain a higher return in exchange for reduced risk. Withdrawing is even better than a risk-free reward; it's a risk-reducing reward.

Thus, a user faces systemic banking system risks plus all firm/stablecoin-provider risks. That combined risk will almost certainly be strictly larger than the systemic banking system risk you'd face by just depositing funds in a bank account that you directly control.

AFAICT power ultimately rests with whoever can modify the most widely-used consumer SW implementation, which would probably be FB here. Though Apple and Google may have considerable veto power over updates pushed through their app stores, iff FB makes this primarily a cell phone app instead of a web app.

It's a Linux-specific implementation defect, not an intrinsic problem with the TCP SACK wire protocol or spec.

Well, the Internet does not strictly require all traffic between two parties to go through a MegaCo Cloud. Location privacy in this system would appear to be greatly enhanced (vs Apple-as-an-adversary) if A and B communicated directly, or through a server that they controlled, instead of through iCloud. In concise security terms, Apple man-in-the-middles the encrypted traffic in this system and thus may perform traffic analysis, deanonymization-via-inference, etc as I said above.

It's certainly true that NAT, firewalls, and a lot of other things make direct communication between two iDevices inconvienent and frequently impossible - that's fine and fair enough. But then the Company should not be making at least partially untrue privacy and anonymity claims that are essentially impossible to satisfy when by design all of the traffic flows through their cloud.

AFAICT Apple (and likely its host governments) will still need to be trusted parties in any scheme that flows through their infra, unless you care only about protecting your precise location, and are willing to expose your coarse location to them.

To be clear, they may already have that info from other services, and you'll have to trust Apple a lot anyway since they're making the phone and some custom silicon within it. And them having coarse location is certainly preferable to them having precise location data - so this system (as we are inferring it to work) is not worthless, and is still an improvement over a naive implementation.

But real internet anonymity and location privacy is hard to achieve; just ask any tor developer. So please don't let the marketing dept openly claim that, or even imply that, when the claim can't realistically survive a two minute security audit by HN infosec nerds. To be specific the WWDC claims that "this whole interaction is ... anonymous" and "there’s no need to worry about your ... privacy" are what I am taking some issue with here.

That is to say: the asym crypto may strongly protect the precise (GPS or LTE triangulation) location from Apple and from others, but I do not see how a cloud-based system can ever hide coarse location from Apple and/or from governments as, given the short range of BT, they can reliably infer that a device (and hence its owner) is/was near whatever IP sends the encrypted precise location to their cloud. Then it's just a matter of mapping the device's "randomized" ID back to an actual user/phone. That seems easy enough as soon as a second device accesses it from an IP that's mappable to a specific residential address, Apple account, etc.

e.g.

A and B both log into iTunes or some other Apple service using a@apple.com and b@apple.com from HOMEIP at some point in the past. HOMEIP is never used by any other Apple accounts.

A(lice) and B(ob) exchange a secret and otherwise begin participating in this "private" tracking scheme.

A goes out shopping and while there it pushes its encrypted precise location to the Apple cloud, using random ID 424242, from MALLIP. Perhaps A's device sends it directly, or perhaps it's relayed from BT to Mall wifi to Cloud by C's device if A has both LTE and wifi disabled.

A few minutes later S(omeone) requests encrypted location for random ID 424242, from HOMEIP.

Apple (and any government compelling it to share information) can reliably infer that "Someone" was A or B attempting to track either B or A, and that the tracked phone was at/near the business address of MALLIP - their coarse location - even if they can't decrypt the precise location without the secret key. If you know from public records that A and B are married, and assume that women are more likely to be at a mall on their own than men, you may further assume that A is at the Mall while B is at home.

Result: the "private"/"encrypted" precise location beaconing has an unfixable metadata side channel that will leak coarse location data to Apple and to any governments that compell it.