Saturday, February 27, 2016

Some of my geeky tech jokes -- with explanations!

I know the line: explaining a joke is like dissecting a frog; you understand it better, but it dies. Still, not everyone will get these, and I figure I might as well have a place where you at least get a chance. So here are some of my own creations, explained.



Girl, you make me feel like a fraudulent prover in a stochastic interactive zero-knowledge proof protocol ... because I really wish I had access to your random private bits!

Explanation: In a stochastic zero-knowledge proof protocol, there is a prover and a verifier, where the former wants to convince the latter of something. But for proof to work, the verifier must give the prover unpredictable challenges. Think of it like a quiz in school -- it's not much of a quiz if you know the exact questions that will be on it.

The information to predict the challenges is known as the verifier's private random bits Those with a legit proof don't need this, but a fraudulent prover does. Thus, a fraudulent prover in a stochastic interactive zero-knolwedge proof protocol wants access to the verifier's "random private bits".



A historian, a geologist, and a cryptographer are searching for buried treasure. The historian brings expertise on practices used by treasure hiders, the geologist brings expertise on ideal digging places, and the cryptographer brings expertise on hidden messages.

Shortly after they start working together, the cryptographer announces, "I've found it!!"

The others are delighted: 'Where is it?'

The cryptographer says, "It's underground."

'Okay, but where underground?'

"It's somewhere underground!"

'But where specifically?'

"I don't know, but I know it's underground!"

'Slow down there. If all you know is that it's underground, then in what sense did you "find" anything? We're scarcely better off than when we started!'

"Give me a break! I just gave you an efficiently-computable distinguishing attack that separates the location of the treasure from the output of a random oracle. What more could you want?"

Explanation: In cryptography, an encryption scheme is considered broken if an attacker can find some pattern to the encrypted message -- i.e. they can identify telltale signs that it wasn't generated by a perfect random number generator, a "random oracle". Such a flaw would be called a "distinguishing attack". So in the cryptography world, they don't care if the attack actually allows you to decrypt the message; they stop as soon as they find non-randomness to the encrypted data. Applied to a treasure hunt, this means they would give up as soon as they conclude that the treasure location is non-random, which the cryptographer here things s/he's done simply by concluding that it's "underground".



So, 16-year-old Johnnie walked into an Amazon Web Services-run bar...

"Welcome," said the bartender. "What are you drinking?"

Johnnie replied, 'What've you got?'

"Well, we have a selection of wines and the beers you see right here on tap. But if you prefer, we also have club soda and some juices."

Johnnie thought, Wait a second. Why is he telling me about the wines and beers? Does he even realize ... ?

'Okay, I'll take the Guinness.'

"Bottle or draft?"

'Draft.'

"Alright, and how will you be paying?"

Johnnie only had large bills from his summer job and gave the bartender a C-note.

"Sorry, but I gotta check to make sure this is real." The bartender took out a pen and marked it, then counted out the change. Johnnie reached for the beer.

"Hold on a second! Make sure to use a coaster!" The bartender slipped one under the glass. "Okay, now enjoy!"

Johnnie lifted up the glass to drink. Before he was able to sip, the bartender swatted it out of his hand.

"WHAT ARE YOU THINKING!?! Don't you know 16-year-olds can't drink!"

Explanation: On the AWS site, they will gladly let you click on the "Launch server" button and go through numerous screens and last-minute checks to configure it, and only at the very last stage does it say, "oops, turns out you don't have permission to do that" -- so it's like a bartender that takes you through a entire transaction, even verifying irrelevant things (like whether the money is real), while knowing the whole time he can't sell to you.



How is a Mongo replica set like an Iowa voter?

In primary elections, they only vote for candidates they think are electable!

Explanation: Databases can have "replica sets" where there are multiple servers that try to have the same data; secondary servers depend on an agreed-upon "primary" to be the "real" source of data. Often times, the primary server goes down, so they have to decide on a new primary, known as a "primary election". But there are some restrictions on who they will vote for -- if they e.g. have reason to believe that a server can't be seen by other members, and in those cases it will regard that server as unelectable. So you can get funny messages about "server42 won't vote for server45 in primary election because it doesn't think it's electable".

Saturday, February 20, 2016

More funny and insightful Slashdot posts I remember

If you liked the last post on this here are some more you might like. This time, I think they're more insightful than funny, but often times, insight is funny!

Also, I thought I'd point out the value of forums: in all of these exchanges, it seems to take three people to get the "aha" moment, not just one or two.



Topic: some new superstrong carbon nanotube material is discovered.

A: So it seems like they're planning to use this stuff for armor. But what about weapons? It seems that anything strong enough to make good armor would also have value as a weapon.

B: That doesn't follow at all! They're completely different use-cases. For example, leather is known to make good armor, but you never see a leather sword!

C: Sure you do -- it's called a "whip" and we dig them up all the time!




Topic: Some dating site is blocked from emailing University of Texas students (at their school email) because of too much spam.

A: Well, their defense is that they're complying with the CAN-SPAM Act, in that they have an unsubscribe link, use their real name, etc., so UT can't just block them wholesale.

B: What? That doesn't matter; that's just the *minimum* requirement for sending such emails. Obviously, any domain owner can impose whatever extra restrictions they want!

C: Yeah, it's like saying, "I have a valid driver's license. I am the legal owner of this vehicle. I have paid the appropriate taxes and registered it. I hold the required liability insurance, and the vehicle is in good working order. I have complied with all applicable traffic laws and operated it in a safe manner. Therefore, I have the right to park on your lawn."



I actually use C's last example when explaining to people the difference between authentication (proving who you are) and authorization (what that identity is allowed to do).

If the minimum wage prohibitions are so easily circumvented ...

The recent Talia Jane story just made me realize we have a possible inconsistently in policy. To get you up to speed, Jane took a low-wage job in the San Francisco Bay Area, hoping to work her way up to her passion of being a social media manager for a major company. But because of rental prices, she paid 85% of per post-tax pay just for rent (!), complained about her employer paying so little, and then was fired.

But as for the inconsistency:

Illegal: paying someone below $X/hour.

Legal: paying someone ($X + $Y)/hour (Y positive) to work in a place where their discretionary income would place them in extreme poverty (e.g. 85% of post-tax on rent).

And yes, that's just an (arguably trivial) corollary of "minimum wage (and tax brackets for that matter) is not automatically cost-of-living-adjusted". But if the goal is to stop people from being taken advantage of with low job offers that hold them in poverty, that seems like a pretty big loophole.

And it's not just that -- let's say someone moves farther out to be able to afford to live there. Then they're traveling an extra N hours just to make each shift which should rightly count against their effective hourly wage.

So, food for thought: what are we really trying to optimize for here? What would the law have to look like to not just avoid these loopholes, but "carve reality at the joints" such that it's fundamentally impossible to scalably circumvent such a law?

If you keep raising the minimum wage for a locality, and people keep commuting greater distances to get that income, what have you accomplished?

Thursday, January 7, 2016

Funny Slashdot exchanges, before they're lost to time

In the time that I was a regular reader of Slashdot, I saw a few exchanges that stayed in my mind. I later went back to find them, but was never able to. So that they're not lost to time, I figured I'd post all the ones I remember. What follows is from memory, and prettied up a bit. (Not trying to plagiarize, if you can find the original post for any of these, let me know.)

Enjoy.



[Story: Armadillo Aerospace has a failed rocket launch.]

A: Well, I think we can close the books on Carmack's little project.
B: Come on, now. Private space travel is still in its infancy. There are growing pains. Not everything works the first time. But what's important, is that we're learning from these events. Armadillo is learning. They'll adapt. And the next voyage will be better and safer!
C: You mean, even safer than a big orange fireball?



A: [long rant] So that's the problem with this ban on incandescent light bulbs.
B: Whoa whoa whoa, slow down. There is no "ban" on incandescent light bulbs. It's just that the government passed new efficiency standards, and incandescents don't meet them.
C: Oh, that's clever! I should try that some time: "See, I'm not breaking up with you! I'm just raising my standards to the point where you no longer qualify."



[Story: a pedophile was caught because he took pictures of his acts and tried to blur out the victims' faces, but police analysts were able to unblur them.]

A: Hah! What an amateur! Everyone knows you have to do a true Gaussian blur to destroy the information content of the picture!
B: Yeah, or entropize it by blacking out the whole face.
C: Right. Or, you know, you could just ... not molest children.

(IIRC, C was heavily voted down and criticized for assuming guilt.)



[Story: police used "big data" analytics techniques and discovered that most robberies occur on paydays near check-cashing places, which allowed them to ramp up arrests.]

A: I don't know, this seems kind of big-brothery...
B: Not at all! This is the kind of police work we should applaud! Working only off publicly available, non-private data, they found real, actionable correlations. It wasn't just some bigoted cop working off his gut: "Oh, this must be where the thugs go ..." No, they based it on real data. What's more, it let them avoid the trap of guessing the wrong paydays, which can actually vary! Some people get paid weekly, some biweekly, some of the 1st and 15th. For example, I get paid on the 7th and 21st.
C: So, uh ... where do you cash your checks, by chance?

Wednesday, December 30, 2015

What every programmer *really* should know about ...

So there's a common kind of article that comes up a lot, and annoys me. It's the "What every programmer should know" or "needs to know" about this or that. About time, or names, or memory, or solid state drives or floating point arithmetic, or file systems, or databases.

Here's a good sampling on Hacker News of the kinds of things someone out there is insisting you absolutely have to know before you can knock out "Hello, World", or otherwise meet some higher standard for being a "real programmer".

I hate these articles.

For any one of them, you can find about 99% who don't already know something from the article, and yet they manage to somehow be productive enough that someone is paying to produce a product of value. To me, they come off as, "I want to be important, so I want to make it seem like my esoteric knowledge is much more important than it really is." If taken seriously, these articles would heavily skew your priorities.

So here's my standard for when you're justified in saying "what every programmer needs to know about X":

Think about the tenacious, eager kid from your neighborhood. He picks up on things really quickly. Once he learned to program, he was showing off all kinds of impressive projects. But he also makes a lot of rookie mistakes that don't necessarily affect the output but would be a nightmare if he tried to scale up the app or extend its functionality. Things you, in your experience, with your hard-earned theoretical knowledge, would never do. When you explain it to him, he understands what you mean quickly enough, and (just barely) patches that up in future versions.

What are those shortcomings? What are those insights, that this kid is lacking? What of this kid's mistakes would you want to give advice about to head off as soon as possible? That's what every programmer needs to know.

The rest? Well, it can wait until your problem needs it.

Sunday, December 6, 2015

The Scylla-Charybdis Heuristic: if more X is good, why not infinite X?

(Charybdis = care-ib-dis)

A Scott Alexander post really resonated with me, when he talked about one "development milestone" (#4): the ability to understand and speak in terms of tradeoffs, rather than stubbornly try to insist that there are no downsides to your preferred course of action. Such "development milestones" indicate a certain maturity of one's thought process, and greatly change how you discuss ideas.

When a Hacker News discussed Alexander's post, I remembered that I had since started checking for this milestone whenever I engaged with someone's advocacy. I named my spot-check the "Scylla-Charybdis Heuristic", from the metaphor of having to steer between two dangers, either of which have their downsides. There are several ways to phrase the core idea (beyond the one in the title):

Any model that implies X is too low should also be capable of detecting when X is too high.

Or, from the metaphor,

Don't steer further from Scylla unless you know where -- and how bad -- Charybdis is.

It is, in my opinion, a remarkably powerful challenge to whether you are thinking about an issue correctly: are you modeling the downsides of this course of action? Would you be capable of noticing them? Does your worldview have a method for weighing advantages against downsides? (Note: that's not just utilitarian cost/benefit analysis ups and downs, but relative moral weight of doing one bad thing vs another.) And it neatly extends to any issue:

- If raising the minimum wage to $15/hour is a good idea, why not $100?

- If lifting restrictions on immigration is good, why not allow the entire Chinese army to cross the border?

- If there's nothing wrong with ever-increased punishments for convicts, why not the death penalty for everything?

One indicator that you have not reached the "tradeoff milestone" is that you will focus on the absurdity of the counter-proposal, or how you didn't advocate for it: "Hey, no one's advocating that." "That's not what we're talking about." "Well, that just seems so extreme." (Extra penalty points for calling such a challenge a "straw man".)

On the other hand, if you have reached this milestone, then your response will look more like, "Well, any time you increase X, you also end up increasing Y. That Y has the effect/implication of Z. With enough Z, the supposed benefits of X disappear. I advocate that X be moved to 3.6 because it's enough to help with Q, but not so much that it forces the effects of Z." (I emphasize again that this method does not assume a material, utilitarian, "tally up the costs" approach; all of those "effects" can include "violates moral code" type effects that don't directly correspond to a material cost.)

I've been surprised to catch some very intelligent, respected speakers failing this on their core

What about you? Do you make it a habit to identify the tradeoffs of the decisions you make? Do you recognize the costs and downsides of the policies you advocate? Do you have a mechanism for weighing the ups and downs?

Wednesday, December 10, 2014

Bitcoin mining pools attacking each other for profit?

So after posting our new Bitcoin book, my buddy Tim Swanson alerted me to the problem of Bitcoin mining pools attacking each other.

Reminds me of the recent Tax Interaction Effect post, where I had to unearth the core of a counterintuitive result: in this case, the claim that not redeeming some of your solutions can increase your return.

I don't think I'm entirely there, but I at least have an analogy to understand the mechanics of the attack.

Bitcoin mining model:As you might know, mining is like buying a bunch of (positive sum) lottery tickets. A fixed reward is given out every hour, then divided equally among the winning tickets. Some people join into pools, where they buy tickets with the proviso that *if* it's a winning ticket, they share the winnings equally among all the tickets in their pool.

The attack: You use some of your money to buy tickets for someone else's pool (call it the "attacked pool", but hide and destroy the winning tickets for that pool.

The effect: There are fewer total wins per period. Each (non-destroyed) ticket gets a larger fraction of the hourly reward. The attacked pool gets a smaller fraction the reward.

My response/confusion: This increases the return to all winning tickets, not just those of the attacking pool, so the attacking pool effectively subsidizes all the others, and dilutes the value of its own tickets across the set of all players.

But maybe I'm missing something here.

Tuesday, December 9, 2014

Our new Bitcoin eBook is up!

Phew, been a while, eh? Well, Bob Murphy and I have a new free eBook up about the economics and mechanics of Bitcoin! Check the site for it, or, if you're too lazy, just go straight to the book itself.