You can't make this shit up

Well, at least I can't.  The Marietta Daily Journal writes the following, which I will simply reproduce here without comment because, well, it just leaves me at a loss for words.  (BTW, if you decide to follow the link to the original article, the Journal has a really annoying paywall, which you can circumvent by disabling Javascript in your browser.)

One woman who has not [decided to support same-sex marriage] is Georgia GOP Chairwoman Sue Everhart of east Cobb, although she’s aware of the movement. 

“Lord, I’m going to get in trouble over this, but it is not natural for two women or two men to be married,” Everhart said. “If it was natural, they would have the equipment to have a sexual relationship.”

Everhart said while she respects all people, if same sex marriage is legalized across the country, there will be fraud.

“You may be as straight as an arrow, and you may have a friend that is as straight as an arrow,” Everhart said. “Say you had a great job with the government where you had this wonderful health plan. I mean, what would prohibit you from saying that you’re gay, and y’all get married and still live as separate, but you get all the benefits? I just see so much abuse in this it’s unreal. I believe a husband and a wife should be a man and a woman, the benefits should be for a man and a woman. There is no way that this is about equality. To me, it’s all about a free ride.”

Everhart said if she had a young child, she wouldn’t want them to have gay parents who would influence that child’s sexual orientation.

“You’re creating with this child that it’s a lifestyle, don’t go out and marry someone else of a different sex because this is natural,” Everhart said. “But if I had a next door neighbor who was in a gay relationship, I could be just as friendly to them as I could be to you and your wife or anybody else. I’m not saying that we ostracize them or anything like that. I’m just saying I’m against marriage because once you get the gay marriage you get everything else.”

OK, I'm game

The Guardian reports that a creationist has put up $10,000 for anyone who can prove in a mock-trial that evolution is true.  OK, I can use an extra ten grand, so I went to see how I could sign up.  The Guardian didn't have a link, but through the comments on Reddit I found the guy's web site.  What I could not find were instructions on how to accept the $10,000 challenge.  I looked at all of the obvious places, including the FAQ, and I couldn't find anything.  Compare that to the very straightforward instructions on how to apply for the James Randi prize for demonstrating paranormal phenomena.

I did find Joseph Mastropaolo's email address.  Maybe I'll just drop him a line.

[UPDATE] What the heck, I had a little down time this morning, so I sent Joe this note:

Hello,

My name is Ron Garret.  I want to accept your $10,000 evolution mini-trial challenge: 

http://www.lifescienceprize.org/

But I can't find any indication of how one goes about doing it.  For example, the James Randi foundation has very straightforward instructions for anyone who wants to accept their challenge: 

http://www.randi.org/site/index.php/1m-challenge.html 

but I can't find anything analogous on your site.  What am I missing? 

Thank you, 

Ron Garret, Ph.D.

Anyone want to lay odds on whether he responds?

[UPDATE2] Heh, that didn't take long. "Undeliverable mail -- invalid mailbox."

What a surprise.

OK, Joseph Mastropaolo, I'm calling you out: I want to accept your Life Science Prize min-trial challenge.  How do I do it?

Disgusting concessions from the proponents of gay marriage

I'm on the road so I don't have time to give this the thorough treatment it deserves, but I had a little down time that I used to read the transcript of today's oral arguments in Proposition 8 Supreme Court case.  I was completely disgusted by the arguments on both sides, but mostly by the concessions made by the proponents of gay marriage.

Justice Alito:  Traditional marriage has been around for thousands of years. Same-sex marriage is 25 very new. I think it was first adopted in The Netherlands in 2000. So there isn't a lot of data about 2 its effect. And it may turn out to be a -- a good thing; it may turn out not to be a good thing,...But you want us to step in and render a decision based on an assessment of the effects of this institution which is newer than cell phones or the Internet?

The proper response to this is: No, gay marriage cannot possibly turn out to be a bad thing even if we concede the erroneous assumption we have only thirteen years of actual data to go by.  How do we know this?  Well, first, because we have thirteen years of actual data to go by, and if there were even the slightest hint that gay marriage had deleterious effects the opponents would long ago have seized on those and trumpeted them as a prominent part of their case.  But they haven't, because there aren't any.  But more than that, opponents of gay marriage have not even been able to put forth any credible hypothetical scenario whereby gay marriage might have any harmful effects on society.  The only argument against gay marriage is tradition, and some possible harmful effects that no one has actually been able to imagine, let alone demonstrate.

That argument didn't get made.  Not only that, but one of the advocates for gay marriage actually conceded that states could legitimately ban gay marriage, but only if they had not already granted gays other rights like civil unions.  I won't even try to extract the twisted reasoning behind this.  Go read the transcript if you really want to know.

The case of Loving v. Virginia, the case the legalized interracial marriage, was brought up, but no one has drawn the correct analogy: it is actually possible to raise a much more legitimate argument against interracial marriage than against gay marriage.  That people of color are discriminated against in the United States is a demonstrable fact.  That marriages that involve people of color tend to produce children of color is also a demonstrable fact.  Therefore the state has a legitimate interest in preventing people of color from marrying white people in the interests of preventing the production of children who will be the subject of societal discrimination.

Are you disgusted by that argument?  You should be.  It is a disgusting argument.  No one but the most hardened racist bigot would raise that argument in today's world.  And yet, that is exactly the argument that is being danced around in the Supreme Court today.

Here's a question I wish one of the justices would pose to the opponents of gay marriage:  "Please rank the following parental situation in order of their desirability for the children:

1.  One father, one mother, married
2.  One father, one mother, unmarried, but in a committed relationship
3.  A single parent
4.  A gay couple, married
5.  A gay couple, unmarried but in a committed relationship
6.  Foster care by a straight couple

Can you seriously imagine anyone going on the record rating foster care or single parenthood over a gay couple in today's world?  Honestly, what else is there to say?

That Christian Nation Nonsense

Dr. Richard Carrier utterly destroys the notion that the United States is a Christian nation.  Not that this should have been news to anyone, but the thoroughness of his takedown is truly awesome.  Long, but well worth reading, even if you already believe the conclusion.

Join CRMTL to repeal the California MTA

Following up on my earlier call to action to repeal the California Money Transmission Act (MTA), I have helped form a group called the Coalition for the Reform of Money Transfer Law (CRMTL, pronounced Core-Metal).  We have written a letter that we are submitting as formal testimony for the hearings on March 11.  We would welcome additional signatories to this letter.  If you want to add your voice to ours please send an email to Mark Farouk: Mark.Farouk@asm.ca.gov.  Here is some suggested language:

Re: Assembly Bill 786 

To Whom It May Concern:

[Company/Individual Name] submits the following comments for consideration at the Committee's March 11, 2013 hearing regarding the the California Money Transmission Act of 2010.

We are aware that the Coalition for the Reform of Money Transmission Laws submitted comments supporting the Committee’s efforts to reconsider the Act.  [We/I] support the Coalition's comments and encourage the Assembly to strongly consider the Coalition’s suggested modifications to the law. Once these needed modifications have been made to the Committee's draft legislation, we urge the Assembly to act quickly to provide the relief that is necessary to ensuring that consumers derive the full benefits of a competitive payments marketplace.

[In addition, [ADD ANY ADDITIONAL COMMENTS THAT YOU WISH TO MAKE ON BEHALF OF YOUR COMPANY, IF DESIRED. IF YOU DO NOT WISH TO MAKE ADDITIONAL COMMENTS, PLEASE DELETE THIS SECTION.]]

Thank you for the opportunity to provide these comments and we strongly encourage the Committee to proceed to adopt the Coalition's proposed alternatives as soon as possible. 

Respectfully submitted,

[Name, Title and Company Name]

Thank you for your support.  Please note that input for the hearings is due by COB tomorrow, March 6.  Sorry for the late notice, but we only today finalized the text of the letter.

A simple solution to credit card fraud, part 6: It's the protocol, stupid

This is part 6 of a long series.  This post is another technical post.  Some people have been (justifiably) pressing me for more details on the "simple solution" I've been promising in the title.  That's what this post is about.

Let us start by observing that credit cards don't actually require either credit or cards.  What matters is not the card, but the information on the card.  This is particularly evident in e-commerce transactions.  If you possess the right information, you can type that information in to a web browser and a few days later stuff will magically appear on your doorstep.  The fundamental problem is that the information you have to type in is not bound to a particular transaction.  It is reusable.  So you have to trust everyone you do business with.  Sooner or later that trust will fail.  Some random e-commerce web site that you place an order from will turn out to be a well crafted phishing site, or their database will get hacked, or a waiter in a restaurant or cashier at the shop will skim your card or just write down the number on a Post-It note.  Something.  If you use credit cards, it is a question of when, not if, you will get hacked.

Despite consumer protections, getting a card hacked can be a major hassle, especially if, like me, you have a lot of your regular bills set up to auto-pay.  I get hacked every few years, and as you might imagine I am extremely careful.  The last time it happened I was just on my way out of the country for six weeks, so they couldn't even send me a replacement card.  I didn't lose any money, but it was a colossal pain in the ass.

Debit cards, of course, have all the same problems as credit cards, except that they lack a layer of protection.  When you authorize a transaction with a debit card, you authorize the merchant to reach directly into your checking or savings account and extract money.  There are two reasons you don't hear as much about debit card fraud as credit card fraud.  First, people use credit cards a lot more than they use debit cards.  And second, debit cards typically have an extra layer of protection: the PIN.  Consumers have been effectively trained to guard their PINs closely, but the fact that a compromised debit card gives the fraudster direct access to cash makes debit card fraud lucrative enough that fraudsters go to considerable effort and expense to steal them.

Regular paper checks, by the way, are even worse.  Unlike debit cards, they actually expose your account number, and they don't have a PIN.  Anyone to whom you have ever given a check could, if they chose to, take all the money from your account.  Electronic checks, of course, are the worst of all.  They are completely insecure.  An electronic check has no security at all.  Writing an electronic check is effectively the same as opening up your bank account and saying, "Here, help yourself to whatever you like any time you like."  This is the reason you don't see electronic checks as a payment option very often.  They are so insecure that you have to be carefully vetted before you can gain official access to the electronic check system.

All of these problems could be solved at a stroke using secure digital signatures.  Instead of making a payment by handing over your account details, you would instead write and sign a digital check (not to be confused with an electronic check).  A digital check would be just some text in some standard format, e.g.:

Transaction ID: 1234

Pay to the order of: Joe Merchant

Account ID: 4321

Amount: $123.45

Expires: 4 March 2013

The digital check itself could be generated either by you or the merchant.  To authorize the transaction you would simply generate a digital signature for that text and give that to the merchant.  The merchant would then "cash" the check by presenting the check and your digital signature to the bank.

That's it.  That's the simple solution to not only credit card fraud but check fraud and debit card fraud and just about any other kind of financial fraud that involves stealing credentials.  It works because digital signatures are unforgeable and non-reusable.  The merchant can't change any of the information on the check because that would make the signature invalid.  The merchant can't cash the check twice because it contains a transaction identifier.

Now, there are some real-world complications.  The most serious is that users have to be trained to manage their secret keys.  Keeping a secret key secret is not a trivial matter, but at least it is possible.  Keeping your credit card number secret is not possible because the protocol requires you to disclose it for every transaction.

So what would the user experience be like?  (Are you paying attention, pbreit?)  There are myriad possibilities.  The most straightforward is what is already out there.  Chip-and-pin systems in use in Asia and Europe already implement a similar protocol.  But it doesn't have to be a chip-and-pin card.  It can be a dongle, or a smartphone app, or a browser plug-in.

To give you some concrete examples, here is an actual digital signature for the digital check shown above:

---MSGID---
149302O5AAVHKAEC7N5IPIGDPJAC8MBOJ2T0E6M8LQ3M40BABREI
---PUBLIC KEY---
1RBNESSNAFFOD4G05MJPTK9TLGS95QHOEBK3CD6O1KIOV5GHKAQT
---SIGNATURE---
1EQEB9T51UDVGHFVGMTANQS3JQVLV17H5HAOECHSRDJ67H4MNT1M
29SDNR6V8VCH1C3TICVDDDIA67GTG0V46H4ST2Q7IP4LF8GM548

For you hard-core geeks, this signature was generated using the Ed25519 elliptic curve digital signature algorithm.  The message ID is the SHA512 hash of the ascii text of the check, truncated to 256 bits.  All values are rendered as base 32 big-endian numbers.  You can verify that this signature is valid here.  And you can generate your own Ed25519 signatures here.  As a proof-of-concept for a standalone security dongle, I have implemented Ed25519 on a Teensy3, which costs $19 in single quantities.  So no, pbreit, distributing new hardware is not hard, and it is not expensive.  Not any more.

The physical manifestations of this protocol are endless.  Here, for example, is the above signature rendered as a QR code:

You can scan this image with any QR code reader to verify that the signature is valid.  Or, if you don't trust my verification web site, you can use a standalone verification app written by someone else.  There is nothing at all proprietary about this protocol.  It is entirely open.  The only secret is your secret key.

Again I have to stress that what matters here is the protocol, not any of the implementation details.  I happen to like Ed25519 because it generates highly secure signatures that are short enough to render as reasonable-looking QR codes, but that is a detail.  The point is that by changing the protocol you can solve the fraud problem.

And you can solve lots of other problems too.  More on that in a future post.

Murray Rothbard was an Idiot

This post is not part of the series on credit card fraud.  I just felt the need to vent.  Some anonymous coward posted a comment that pressed one of my buttons.

I'd suggest: Rothbard

It just so happens I have read a bit of Rothbard.  About five years ago I took a deep dive into libertarianism (lower-case l) and anarcho-capitalism.  Both theories had always struck me as obviously utopian and unworkable, and yet a lot of people I respected seemed to subscribe to one or the other (or both) so I wanted to find out if I was missing something.

I wasn't.

On the recommendation of some of the members of a mailing list that contained the word "freedom" in its name, I read The Ethics of Liberty and found it completely, utterly, and transparently intellectually bankrupt.  I wrote up a critique back then, but never published it outside that mailing list.  The response from the list was not unlike the response I used to get when I debated with religious fundamentalists.  It was, in essence: we can't rebut any of your arguments.  But we believe it anyway.

Bah.

Here, then, is a lightly edited version of the essay I wrote back in 2008.

---


A couple of preliminary disclaimers:


First, I have not read even a small fraction of Rothbard's writings, and I never will.  Rothbard is too prolific, I'm too busy, and life is too short.  This is a critique of the work that [names deleted] pointed me to as representative of their positions [The Ethics of Liberty].  I've so far read about half of it thoroughly, and skimmed about another fourth.  A pretty clear picture emerges even from this incomplete perusal.  In particular, Rothbard bases his entire argument on premises which I reject.  So it is not necessary to look into all the details of his reasoning to know that he is wrong, just as it is not necessary to read the entire Bible to convince onesself that it is not the inerrant word of God.  Garbage in, garbage out.  But it is interesting to follow some of the lines of thought nonetheless.
To give Rothbard credit, he doesn't actually run off the rails until chapter 2:

The natural law, then, elucidates what is best for man—what ends man should pursue that are most harmonious with, and best tend to fulfill, his nature. In a significant sense, then, natural law provides man with a “science of happiness,” with the paths which will lead to his real happiness.

This, of course, begs the question of what "real happiness" means, and Rothbard struggles to define it because he doesn't want to use the common economic definition and thereby become a utilitarian.  The problem is, Rothbard gets it wrong.  It is hard to summarize Rothbard's definition of "man's nature" and "true happiness" because it is so incoherent, but it is easy to tell what it is not, and what it is not is the right answer.

Man's true nature is that he is an animal.  I mean that in the strictly scientific sense of the word, i.e. a living thing that is not a plant, the product of a few billion years of evolution.  Each instance of man is constructed by natural processes involving DNA being transcribed into RNA and thence into proteins by ribosomes, which then assemble themselves into a startlingly complex array of structures including a frontal cortex.  Which is where all the trouble starts.  :-)

The problem is that our capacity for rational thought is only a small part of our true nature.  Not only are we (at least potentially) rational, we are also alive, and our being alive is antecedent to our being rational, and therefore a much more fundamental part of our true nature than our rationality is.  We don't even know if being alive is even a prerequisite for being rational.  It is not out of the realm of possibility that there could exist rational entities that are not alive.  So there is no reason to believe a priori that being alive is just an incidental detail that is subsumed by being rational, and can therefore be safely ignored.  Indeed, there is reason to believe that being alive and being rational are in active conflict with each other, perhaps even necessarily so.  But this is a tangent.  If you're really interested in pursuing this line of thought, go read "The Robot's Rebellion" by Keith E Stanovich.  (I don't particularly recommend this book because I think what it says is patently obvious.  But if you don't agree you'll find extensive supporting arguments there.)

What is it, then, to be alive, and specifically to be an animal rather than, say, a plant or a fungus?  It means that sexual reproduction is fundamental to our nature.  And I don't just mean the act of sexual intercourse, I mean the entire end-to-end cyclical process of being born, surviving long enough to reach adulthood, and having and (usually, at least for mammals like us) raising children.

Rothbard completely ignores this aspect of our nature, basing his analysis largely on thought experiments involving one or two fully fledged and functional adult human beings capable of surviving and even prospering on desert island without any outside assistance whatsoever, not even tools and other vestiges of civilization salvaged from a shipwreck.  Having established the dynamics of such a fantasy world he then, with no justification whatsoever, extrapolates his results to the real world as if the principle of mathematical induction could be applied to humans.  He then tacks on children as an afterthought -- in chapter 14! -- continuing to completely ignore the fundamental role of children in human nature, and the fact that people have deeply rooted visceral -- which is to say irrational -- reactions when children come into play.  Because we are animals.

It is, frankly, a completely ridiculous line of argument.

[UPDATE in 2013]: I am re-reading chapter 14 now and it is every bit as -- words fail me -- untenable?  idiotic? horrific? -- as I remember it.  Here's a choice quote:

Applying our theory to parents and children, this means that a parent does not have the right to aggress against his children, but also that the parent should not have a legal obligation to feed, clothe, or educate his children, since such obligations would entail positive acts coerced upon the parent and depriving the parent of his rights. The parent therefore may not murder or mutilate his child, and the law properly outlaws a parent from doing so. But the parent should have the legal right not to feed the child, i.e., to allow it to die.[4] The law, therefore, may not properly compel the parent to feed a child or to keep it alive.  [Emphasis added.]

If I have to explain to you the problem with that then you are beyond help. [End update.]

Even if you ignore all that and accept Rothbard's premises at face value, his argument still falls apart because it hinges on two completely arbitrary and ultimately untenable definitions.  The first is his definition of property and ownership.  Rothbard defines the "natural" owner of a resource as the first person to transform that resource into something else.  So destroying nature is a pre-requisite to ownership.  One person's desire to enjoy the pleasure of hiking through virgin forest is axiomatically subjugated to someone else's desire to cut down the trees and burn them for fuel.

It's even worse than that.  Not only does the logger axiomatically get preferential treatment over the hiker, he also gets axiomatic preference over all other living beings on the planet.  Although Rothbard claims to be taking a scientific approach, he tacitly appropriates the Biblical license for man's dominion over the fish of the sea and over the fowl of the air and over the cattle and over every creeping thing that creepeth upon the earth.

Now, it is not the case that in Rothbard's world there will not be a single tree left standing, because (chapter 10):

Note that we are not saying that, in order for property in land to be valid, it must be continually in use. The only requirement is that the land be once put into use, and thus become the property of the one who has mixed his labor with, who imprinted the stamp of his personal energy upon, the land. After that use, there is no more reason to disallow the land’s remaining idle than there is to disown someone for storing his watch in a desk drawer.

So environmentalists do have a leg to stand on, but perversely, in order to stake their claim to a virgin forest they first have to cut down all the trees in order to stake their claim to the land.  Only then may they let the land rest fallow and let the trees regrow secure in the knowledge that they are the "rightful" owner of the land.

To prevent the history of anarcho-capitalism from being one of a single mad rush to cut down every tree on the planet as quickly as possible in one vast primordial land-grab, he introduces the concept of abandonment.  But now we are right back where we started because now we have to decide when "lying fallow" ends and "abandonment" begins, and such a delineation cannot be anything but completely arbitrary.

The second arbitrary and untenable definition upon which Rothbard's theory rests is that of "violence."  Violence is the axiomtic evil, and Rothbard never really defines it explicitly, but implicitly he seems to restrict the definition to direct physical violence against another person's property, which axiomatically includes their own body.  As an aside, Rothbard axiomatically precludes people from voluntarily selling themselves into slavery.  Exactly how this differs from, say, entering into a long-term contract for their labor is not clear, but even that aside, this is a very peculiar position to take from someone who presumably would not axiomatically preclude someone from selling off pieces of themselves -- like kidneys -- even if it lead to their death.  So people can voluntarily kill themselves, but they cannot voluntarily enter into long-term labor contracts.  Weird.

But the problem of what constitutes violence is very thorny even in Rothbard's oversimplified fantasy world.  He paints a picture of Crusoe happily fishing and Friday happily raising wheat and both of them happily exchanging wheat for fish, but what if Crusoe decides that his version of paradise is a high-rise condominium development that casts a permanent shadow over Friday's wheat field?  Or a dam upstream of Friday's fields that produces electricity, but stops the seasonal flooding that made Friday's wheat fields fertile?  Of such sticky situations we hear nothing.  It is possible that Rothbard deals with the problem of externalities somewhere, but I can find no hint of it.  The word "externality" does not appear anywhere in the book, and that's a pretty clear indication that Rothbard has simply swept this crucial issue under the rug.

On Rothbard's view, then, it is a perfectly moral act for Crusoe to cut a ring of trees around the island and thereby stake his claim to the land, and then deny Friday access to the sea (or, if he were clever, to start charging tolls) because Friday can no longer get there without trespassing on Crusoe's property.  On Rothbard's view this act is not just legal but moral.  Exactly what Friday is supposed to do to defend himself is not clear; perhaps cut down a few trees of his own before Crusoe gets to them in order to stake his own claim to a right-of-way.

But these difficulties pale in comparison to an even more fundamental flaw in Rothbard's theory.  The problem is that the idea of violence as the ultimate evil is not supportable on the basis of human nature.  It might be supportable on the basis of rationalism (relative to some quality metric, of course), but as I pointed out earlier, being rational is not the totality of our nature.  We are not only rational, but living animals with a powerful and altogether irrational drive to reproduce (inherited from our parents who, if they lacked this drive, tended not to reproduce).  When push comes to shove, and one is faced with a choice of starvation or doing violence against another person's person or property, violence will often -- indeed usually -- win, because the person who will starve to death rather than steal a loaf of bread will tend not to reproduce as well as someone who doesn't buy in to Rothbard's theories.

Now, Rothbard doesn't actually address this problem (as far as I can tell) so I'll do it for him: because rational people are aware that evolution tends to produce creatures that will resort to violence before they allow themselves to starve to death, they will recognize that it is in their own interest to prevent people around them from starving to death.  Hence, people will engage in charitable acts of gift-giving precisely to prevent the violence that Darwin predicts.  (Rothbard does not actually make this argument. The only justification that Rothbard can come up with for engaging in charitable gift-giving is the "psychic [sic] satisfaction" that such acts provide. [chapter 7])

The problem with this approach to dealing with the poor is that there is a reverse-externality.  If I feed a poor person and thereby prevent him from doing violence, everyone benefits from my good deed, and yet only I have borne the cost.  This is the classic prisoner's dilemma.  Individually, everyone's rational decision is to wait for someone else to feed the poor.  And yet, if everyone acts on this reasoning, the result is, at least potentially, food riots.

And this, I submit, is the fundamental reason why government is necessary from both a rational and a moral point of view.  The fact of the matter is that humans are more than just rational beings, society is more than just the sum of its parts, and nature has intrinsic value which is destroyed when someone transforms it for some other use.  As a consequence of these self-evident facts, there are things that humans must work on collectively if we are to live in peace.  I submit that the best mechanism yet devised for organizing such collective action is democratic government.  There is certainly room for improvement, but anarchism is throwing out the baby with the bath water.

All this brings me to an answer to the question [name deleted] posed: How much tax do you think Warren Buffet should be required to pay to make you say that he's not doing you harm?

This question is based on a false assumption, namely, that the reason for paying taxes is to mitigate the harm that my externalities cause other people.  It isn't.  The reason for paying taxes is to bear your fair share of the burden of conducting society's collective actions, whether they be feeding the poor to prevent food riots, or building transportation infrastructure, a pre-requisite for industrialization, by the way, that Rothbard completely ignores.

So the right question to ask is: how much tax should Warren Buffet pay to justly compensate for the benefits that receives from the state?  And I'll answer that question with the answer that Warren Buffet himself gives: more than he is currently required to pay.

---

Some day I'll write a sequel about Ayn Rand.

Cutting to the chase: Repeal the California Money Transmission Act

This is the fifth post in a long series.  I've gotten a lot of complaints about cliffhangers and hidden agendas so I'm going to cut to the chase here and then go back in later posts to fill in some details.  And I should probably say this up-front too: there is no "big reveal" at the end of this story.  I spent three years getting the runaround from various banks, and I don't know why.

However, there are some things that I did learn as a result of this experience.  I'm going to just lay them out here without a whole lot of support because there's a deadline looming.  For now I hope you will give me the benefit of the doubt that these are things that I have come to believe are true as a result of firsthand experience and some fairly extensive research.  If you want some of the gory details, you can find them here.  (Note: this is a very long document, well over 200 pages.  And it was not compiled by me.)

1.  The financial system in the U.S. is horribly inefficient.  Retail transactions conducted with credit cards cost 2-3%, which is a ridiculously high cost given today's technology.  Retail transactions (actually, any money transfer transaction) could be profitably brokered at 0.1% or less.

2.  In a normal free market, competitors would arise to undercut the credit card companies and drive costs down.  This is not happening.  There are a lot of new payment companies out there, but they are all (as far as I can tell) UI veneers over the existing inefficient and expensive infrastructure.  This is not to say that these companies aren't adding value; they are.  But none of them (again AFAICT) are addressing the really fundamental problem, which is that moving money costs much more than it should.

3.  One of the principal reasons that startups don't address this problem is that it is essentially illegal.  The regulatory framework in the U.S. makes it all but impossible for a startup to move money legally except by using the existing, broken, inefficient, expensive infrastructure.  (Just today, Square was hit with a cease-and-desist order in Illinois.)

A prime example of the regulatory framework that makes it impossible for startups to tackle this problem on their own is the California Money Transmission Act (MTA).  The MTA was enacted last year, and it put the final nail in an already pretty sturdy coffin for financial startups.

Why was this innovation-killing law passed?  Because a coalition of existing money transmission businesses formed a coalition called the Money Services Roundtable and convinced the California legislature that this law was needed in order to protect consumers.  It's a plausible theory (which is how they were able to bamboozle the legislature into passing it) but it is wrong.  The theory is that by requiring businesses that move money around on behalf of third parties to get licenses and post large bonds, that this will cut down on fraud.  This theory was almost immediately falsified by the discovery that Moneygram, a licensed money transfer agent, had engaged in a massive fraud.  And this was not an isolated incident.    So the MTA clearly does nothing to prevent fraud.  The only actual effect of the MTA is to make it all but impossible for new competition to enter the market.

My goal in writing all this is to try to enlist your help in getting the MTA repealed.  The California legislature is right now considering modifying the MTA.  Unfortunately, the draft legislation currently on the table is a total sham, and will likely end up making the situation worse.  The good news is that because this legislation is on the table there is a public hearing that will be held on March 11 in Sacramento, and so it is possible to get the draft legislation changed before it is voted on.  You don't have to attend this hearing to have your voice heard, you can submit written comments for the record as well.  I urge you, especially if you are a resident of California, to do so.

You can send your comments via email to Mark Farouk: Mark.Farouk@asm.ca.gov.  Here's some sample verbiage, but you should write it in your own words:

Dear Mr. Farouk: 

I would like to have the following comments entered into the record for the March 11 hearing on the California Money Transmission Act.  I believe that this act does nothing to protect me as a consumer.  To the contrary, it erects barriers to entry that favor existing players, suppress competition, and thus ultimately hurt consumers such as myself.  I urge the legislature to repeal the MTA.

Written input for the hearings is due on March 6.

If you want additional information please feel free to contact me: ron@flownet.com.  And if you do write a letter to Mr. Farouk, if you cc me and give me permission, I will also forward it to the relevant legislators and their staffers on your behalf.

A simple solution to credit card fraud, part 4: A primer on elliptic curves

(This is part 4 of a series.)

This post will be a geeky digression from the main narrative, because jonny said he wanted to hear more about elliptic curves.

Up-front disclaimer: I am not an expert on elliptic curves, and I wrote this post in some haste.  It's possible I made some mistakes in some of the equations.  Don't rely on what you read here for anything mission-critical.

The key (no pun intended) to cryptography is finding hard mathematical problems.  A "hard problem" is a term of art: it means a problem for which there is no known solution that is significantly less work than brute force.  The hard problem that RSA is based on is finding the factorization of the product of two large primes.  The hard problem that elliptic curve cryptography is based on is something called the discrete logarithm over point multiplication.  The purpose of this post is to explain what that means.

We'll break this down into two parts.  First, discrete logarithms.  Recall that an ordinary logarithm is the inverse of exponentiation.  If X raised to the power of Y is Z, then Y is the logarithm of Z base X.  Notice that the form of this definition is the same as the form of more familiar concepts like difference and quotient.

If X plus Y is Z, then Y is the difference of Z and X.
If X times Y is Z, then Y is the quotient of Z and X.
If X raised to the power of Y is Z then Y is the logarithm of Z base X.

A discrete logarithm is just like a regular logarithm, except that all the mathematical operations are done modulo some integer Q, which is typically a very large prime number.  Every time you add or multiply, you divide the result by Q and take the remainder.  (Another way to think of this is that all intermediate results are stored in a register than rolls over at Q, and overflows are ignored.)  A modulo B (often abbreviated A mod B) is the remainder when A is divided by B.

For the sake of illustration, let's pick Q=13.  (In practice Q would have hundreds of digits.)  And let's pick two numbers out of a hat, say, 7 and 9.  The sum of 7 and 9 is 16, so the sum of 7 and 9 mod 13 is 3.  The product of 7 and 9 is 63, so the product of 7 and 9 mod 13 is 11 (because the remainder when you divide 63 by 13 is 11).  7 raised to the 9th power is 40353607, which leaves a remainder of 8 when divided by 13, so the discrete logarithm of 8 base 7 (mod 13) is 9.

A discrete logarithm over an elliptic curve is just like an ordinary discrete logarithm, except that regular numerical addition is replaced with a mathematical operation called point addition over an elliptic curve.  An elliptic curve is just a regular old curve of the sort you learned to graph in high school algebra class.  The equation of an elliptic curve looks like this:

y^2 = x^3 + A*x + B

where A and B are constants.  The shape of this graph is not particularly important, but if you're interested you can find examples here.

Elliptic curves have the useful property that if you draw a line between any two points on the curve, that line is guaranteed to intersect the curve at exactly one additional point.  (That's not quite true, but a good enough approximation for now.  I'll fill in the actual details later.)  Using this fact, we can define an operation called point addition: to add two points, draw a straight line between them.  The sum is the third place where this line intersects the curve.  (Actually, the sum is this point with the Y coordinate multiplied by -1, but you can ignore this for now.  It makes an interesting exercise to figure out why the definition of point addition has this peculiar feature.)

Of course, you don't have to do this operation geometrically.  You can do it mathematically as well.  And if you do it mathematically, you can replace all the mathematical operations on real numbers with discrete operations on integers modulo Q, and all the results remain the same.

For the rest of this discussion, all arithmetic is done with integers modulo Q.

I've glossed over two details that you can safely ignore for now, but I'll describe them here just for completeness, because if you go read the literature on elliptic curves you will encounter these terms.

First, if you draw a line between two points on the curve with the same X coordinate, then this line does NOT intersect the curve.  To fix this, we add a conceptual "point at infinity" and define the sum of two points with the same X coordinate to be this point.  (To any mathematicians reading this: yes, I know this is not how the point at infinity is actually defined.  I'm trying to keep this simple.)

Second, if you try to add a point to itself you don't have two discrete points to define a line.  In this case we draw the line tangent to the curve at this one point, and find the second point where this tangent line intersects the curve.  The math is a little different in this case, so adding a point to itself is called point doubling instead of point addition.

If you're having a hard time visualizing all this from my description here are some pretty pictures.

So now we have this abstract mathematical "point addition" operation, and it turns out that this operation has the same algebraic properties as regular old addition: it is commutative (P1+P2 = P2+P1) and associative ((P1+P2)+P3 = P1+(P2+P3)).  It has an identity element (which turns out to be the "point at infinity").  So we can use this operation as if it were addition and define point multiplication of a point P by a number N in the usual way, as P added to itself N times.

We have to stop there.  We can't go on to define "point exponentiation" because we have a "type mismatch" error.  Exponentiation is normally defined as a number multiplied by itself N times.  But we can't multiply a point by itself, we can only multiply a point by a number.  But that turns out to be good enough, because the inverse of point multiplication turns out to be a Very Hard Problem.  Mathematicians call it a discrete logarithm even though it would more properly be called a discrete quotient.

There is a clever trick that allows the product of a point P and a (large) number N to be computed very efficiently.  It is in fact the exact same trick that allows you to multiply two ordinary numbers efficiently.  But there is no known way to solve the inverse problem efficiently if you're using modular arithmetic.  This is what makes point multiplication a useful building block for cryptography.  (Note: this is true for modular exponentiation of ordinary numbers as well, but not for modular multiplication of ordinary numbers.  There are ways to compute modular multiplicative inverses efficiently.)

As an example of how we can use point multiplication, consider the problem of key exchange.  You want to use an insecure communications channel (like the Internet) to send secret data to Bob.  You can encrypt the data, but then you have to somehow get the encryption key to Bob so he can decrypt the data.  You can do this with a technique called Diffie-Hellman key exchange (after the two people who invented it).  You and Bob each pick a large random number.  Say you pick N1 and Bob picks N2.  You also agree on an elliptic curve and a starting point P (called the "base point").  You compute P*N1 and send the result to Bob.  Bob computes P*N2 and sends the result to you.  Now you compute (P*N2)*N1 and Bob computes (P*N1)*N2.  Because point multiplication is commutative and associative, the results will be the same.  But an eavesdropper who only knows P*N1 and P*N2 cannot compute P*N1*N2 unless he knows N1 or N2, and to find either of those numbers he has to solve the discrete logarithm problem.  In this scenario, N1 and N2 are the secret keys, and P*N1 and P*N2 are the public keys.  So P*N1*N2 is a shared secret that you and Bob and use to encrypt data to send to each other.

Using elliptic curves to produce digital signatures is a little more involved, but here's the intuition behind it: suppose you do a Diffie-Hellman key exchange with Bob.  You send Bob P*N1.  But that doesn't prove that you know N1.  You might have obtained P*N1 by eavesdropping on someone else.  How can you prove to Bob that you actually know N1?  One way is for Bob to encrypt a message using the (supposedly) shared key P*N1*N2 and ask you to decrypt it and report the result.  If you can decrypt it, that proves you know N1, because that's the only way you could have computed the decryption key P*N1*N2.

That proves you know N1 to Bob, but what if you want to be able to prove you know N1 to anybody?  One possibility is to do Bob's side of the protocol for him: pick a random message M and a random private key N2 and publish the following:

1.  M
2.  N2
3.  P*N1 (your public key)
4.  M encrypted with the "shared" key P*N1*N2

Because you have published P*N1 and N2, anyone can now compute P*N1*N2.  So anyone can decrypt the encrypted message and verify that it matches M, which proves that you must have known N1.

That's a good start, but this version of the protocol has a fatal (and rather obvious) flaw.  See if you can find it before reading on.

The problem is that there is no way to know that the public key you published is in fact the result of *you* computing P*N1.  You could have obtained P*N1 by eavesdropping on someone else's Diffie-Hellman key exchange.  You could even have just picked a random number.  The only reason that the Diffie-Hellman protocol works is that both N1 and N2 are secrets held by two different people.  Diffie-Hellman only allows you to prove your knowledge of N1 to someone who knows N2 and who knows that you do not know N2.  So if you pick N2 the protocol collapses.

How do we fix this?  We have to roll N1 into the computation somehow in a  way that the result has the following properties:

1.  The result could only have been computed by someone who knows N1
2.  The result is verifiable by anyone
3.  The result does not reveal N1

We do this by choosing a random "message" (let's called it M) and "encrypting" it in two different ways that can be combined in a way that only works if the encryption was done with knowledge of N1.  I put "encrypting" in scare quotes because at this point we're not really encrypting, just slicing-and-dicing in a way that can't be easily undone.

I'm going to change notation a bit to make what comes next a little easier to follow.  What I have been calling N1 to now I am now going to start calling SK (for Secret Key).  What I have been calling P, I am now going to start calling BP (for Base Point, a constant, publicly known common starting point on whatever elliptic curve we are using).

Recall that our strategy is to slice-and-dice a random number M in two ways so that the results can be combined in a way that works only if they were produced with knowledge of SK.  First we compute our public key, PK, just as we did with Diffie-Hellman key exchange, but using our new notation:

PK = BP*SK (formerly known as P*N1)

Note that PK is a point on the curve, not a number.

Next we compute:

R = XC(BP*M)
S = SK*R/M

where XC(P) means the X coordinate of a point P.

The signature is the pair (R,S).  (Note that "dividing by M" really means multiplying by the multiplicative inverse of M (mod Q).)

To verify this signature, compute XC(PK*R/S).  If the signature is valid (i.e. was computed by someone who knows SK) this will be equal to R.  Verifying this is elementary algebra:

PK*R/S = (BP*SK)*R/S = BP*(SK*R)/(SK*R/M) = BP*M

So XC(PK*R/S) = XC(BP*M), which by definition is R.  QED.

This protocol still has a problem, but it's much more subtle than the problem with the first version we came up with.  For this protocol to work, M has to be kept secret, because if we know M we can trivially recover SK.  (Figuring out how is left as an (easy) exercise.)  So we can prove we know SK, but we can't yet bind that proof to a message (because we have to keep M secret).  To be a useful digital signature scheme we have to be able to associate that proof of knowledge with some known message.  To make this happen we have to tweak the protocol yet again.

At this point the story gets a little more complicated because there are two ways to do this final tweak.  There's the standard way, and there's the Right Way.  It is extremely rare for a deeply flawed standard to get established in cryptography, but in the case of elliptic curve digital signatures it has happened.  So I'll start with the standard way, explain what the flaw is, and then explain the Right Way.

To bind a signature to a document in the standard way we first generate a secure hash of the document, which we will call H.  As before, we also choose a random number M, which again we must keep secret.  We compute R just as before, but change the computation of S like so:

S = (H + SK*R)/M

The signature is the pair (R,S) as before.  The verification step also gets tweaked.  To verify, we compute:

XC((BP*H + PK*R)/S)

and verify that this is equal to R as before.  You can verify for yourself that this works by crunching through the algebra.

The flaw in this scheme is that not only must M be kept secret, but you also have to be very careful never to use the same random M to sign two different messages.  If you have signatures for two different messages generated with the same SK and M values, then you can easily recover SK, the secret key.  This is how the Sony Playstation was hacked.

The way to fix this problem is not to use a random M, but instead to use a hash of the message being signed plus the secret key as M.  This insures that different messages will never be signed with the same M value.  This brilliant trick was invented by Daniel J. Bernstein, commonly known by his initials, DJB.  [UPDATE: I was mistaken, this trick was not invented by DJB, it was invented by George Barwood and John Wigley in 1997.   Thanks to pbsd for pointing that out.]

I really wanted to write about a particular elliptic curve invented by DJB called Curve25519, but I'm running out of steam and I want to post this today, so that will have to wait.  Sorry about all the cliffhangers.

A simple solution to credit card fraud, part 3

This is part 3 of a long story.

One of the reasons this story is so hard to tell is that it's hard to know where to begin.  The situation I find myself in today can be traced back at least to 2006, and possibly earlier than that, but does anyone really have the patience to sit through a book-length memoir?  I wouldn't.

So I'll skip 2006 for now (though that makes a good story too, and timely too because that's when I worked with Jody Sherman) and start on March 20, 2008, when I sent out the following fateful email to a mailing list of ex-googlers interested in angel investing and other startuppy things:

I just got back from the Y Combinator Demo Day and there are more promising-looking early-stage startups there than you can shake a stick at.  We don't have enough money to invest in all the ones that looked good to us, which got me to thinking: someone ought to put together a fund or a syndicate so that you could diversify across a fairly large selection of YC startups so that you could diversify without having to invest a huge amount of money.  Is there any interest in this?

There was.  I was soon joined by a dozen other Xooglers, including Brian Singerman who became my co-founder in a small fund that we called XGYC (Ex Googlers investing in Y Combinator companies).  I volunteered to do the administrative work because I was very green and I thought I would learn a lot.  I did learn a lot, including the fact that administrative work sucks.  It's boring and it's repetitive, but it's necessary and you have to pay attention because if you miss a deadline or get something wrong then you have to go back and fix it and it's an even bigger pain in the ass.

By far the biggest PITA was (and remains to this day) actually managing the money.  The mechanisms that we in the U.S. have for moving money around are horribly antiquated, inefficient, and insecure.  I actually started learning this before XGYC, when a six-digit wire transfer was lost for two weeks because the sender had filled out the (paper) transfer form incorrectly.  And when I say lost I mean lost.  No one knew where the money was.  There was no way to track it.  The only reason it was found was because the person who received the money (some random stockbroker) contacted the sending bank and gave it back.  Yes, I know this is hard to believe.  I didn't believe it myself at the time.  Some day, if there's enough interest I'll write up the details.  (I keep telling you this is a long, complicated story!)

Anyway, for a high-tech entrepreneur there are no problems, only business opportunities, right?  I gazed into my crystal ball and saw a day when YC demo days would be much bigger, there would be a lot more angels out there dealing with the exact same problems I was facing, filling out the same forms over and over, dealing with the same accounting and legal BS over and over, and decided that there could be a market for a sort of "angel syndicate in a box" type product.  The idea was to integrate tools to simplify or automate all the standard repetitive tasks that I was doing by hand.  In particular, I wanted to streamline the accounting.  Standard SOHO accounting packages are not designed with investors (or even high-tech startups) in mind.  They're all about managing inventory, accounts receivable, yadda yadda yadda, and their UIs are a disaster.  Five years on and I still can't figure out how to make Quickbooks behave.

The key, it seemed to me, was to integrate the accounting with the money transfer somehow.  One of the biggest problems I was facing managing XGYC was keeping track of who had paid what when, particularly when wire transfers were involved.  An incoming wire would show up on the bank statement without any description of what it was for, only an indication of the bank that sent it.  Sometimes I could figure out what it was based on the amount, but often, particularly at the beginning when the syndicate members were making their capital contributions, there was no way to tell whose money had come in, and I had to send out emails asking people to send me the reference numbers for their transfers.  Later, after we started making money (The fund has done quite well, thank you very much!) I would send out distribution checks and people would fail to cash them.  Don't even get me started about the problems that causes!  (I will probably be writing a future entry about checks and the myriad problems they cause.)

The more I learned about how the financial world works under the hood the more shocked and appalled I became.  The whole system seemed (and still seems) to me like it was being held together with spit and bailing wire.  To this day I am amazed that it works at all, let alone that it works as well as it does, and it does work quite well considering how deeply broken it is.

Still, it was 2008, and there was (and still is) a lot of room for improvement.

I came up with a fairly detailed plan for an integrated banking and accounting service specifically targeted at startup companies and their investors.  I still think this would make not just a viable product, but a kick-ass company that could be the Next Big Thing.  But I gave up on it last March after working on it for three years.  The TL;DR version of why I gave up is that I was never able to find a satisfactory way of moving the money around.

Moving money turns out to be a very complex and subtle process.  It's conceptually very simple, and if you use cash it is very simple: I give you a dollar.  Now you have a dollar more, and I have a dollar less.  Alas, that is where the simplicity ends, because sooner or later that dollar ends up being deposited into a bank.  And that is where all the trouble starts.

(Some people think the trouble starts when you consider a piece of paper to be money in the first place instead of, say, gold, but they are wrong.  This is another tangent that I may write about some day, but for now suffice it to say that very few people actually seem to understand what money is or how it works, including many people who work in the banking industry.  But I'm getting way ahead of myself.)

Don't get me wrong, I think banking is a terrific idea.  The problem with today's banks is not that banking is inherently bad.  Modern technological civilization could not have been built without banks.  The problem with today's banks is that they have forgotten the business which they are supposed to be engaged in, which is to allocate capital and manage risk.  Notice that I said manage risk, not avoid risk.  To the contrary, when the banking system is working properly the banks willingly take on (managed) risk.  But today's banks avoid risk by any means necessary, including fobbing it off on third parties or the government.  This is great for the bank's bottom line, at least for a while, but it's an unmitigated disaster for society.  But again, I'm getting ahead of myself.

My plan was this: for every person or entity participating in my system, I would open an account for them at some bank who would become my partner in this business.  All of the initial capital would flow into this bank by traditional means.  But once the money was in the system, all "in-network" transactions could be conducted by initiating inter-account transfers within that one bank.  Moving money between two accounts at the same bank is a lot easier, safer, faster, and cheaper than moving money between banks.  Furthermore, it's a lot easier to undo mistakes.

The beauty of this business model is that it has a natural viral component: not only could investment syndicates use it, but the companies they invested in could us it too.  And their employees.  And their vendors.  And there could be a whole slew of ancillary services as well.  It could be Y Combinator, but on-line and with a nationwide or even global reach.  I called it Founders Forge.  And, of course, every participant would get a secret key with which to authenticate themselves to the system and authorize transactions. Eventually, as the user base grew we would gradually become the basis of a new, more efficient and more secure financial system that would eventually and stealthily squeeze out the older, less efficient system.

Now, those of you who like to shoot holes in people's ideas, before you take pot shots at this idea please keep in mind a couple of things.  First, what you have just read is a very abbreviated version of the actual plan.  In the interests of not turning this story into War And Peace I have left out a lot of detail.  Second, I am not an idiot.  I am well aware that banks operate under a very strict regulatory regime, that they are highly risk-averse, that they avoid innovation like vampires avoid the sun.  My plan took all this into account.  I had (still have) a detailed risk-mitigation strategy.  If you really want to know, I would be more than happy to go into excruciating detail.

None of that matters to the point I want to make with this story, as you will soon see.

I took this plan to my local Wells Fargo, which was the bank where XGYC has its account.  I figured it would be an easy sell.  I would be bringing them tons of new high-quality customers.  And it was an easy sell.  The idea got a very favorable reception from the branch manager, and the pitch started working its way up the chain of command.  I stopped worrying about the bank, and started writing code.

But a few weeks later something very peculiar and unexpected happened.  By that point I had been handed off to a regional management team, and I hadn't heard from them in a while, so I sent an email asking what was going on.  They replied that Wells had changed its mind and would not do business with me.

When I asked why, they said they couldn't tell me.  All they knew was that they had received marching orders to kill the deal.

Weird.  But OK, if at first you don't succeed...

Fast forward a year and a half, and half a dozen or so banks.  Same story, again and again and again: initial enthusiasm, followed by a sudden change of heart with no explanation.  The only exception was a small regional bank where I was able to pitch directly to the CEO.  He said he loved the idea, but was couldn't do it because their charter prevented the from having non-local customers.  That was the only time I got a straight answer out of a banker.

It gets worse.

By this point I was very discouraged, but far from ready to give up.  Still, I wasn't quite sure what to do because I didn't have a good model of what was going wrong.  I had no idea what to change to increase my chances of success.  I talked to everyone I knew who had even the remotest connection with the financial world and the reaction was always the same: This is really weird.  Your pitch sounds great.  I have no idea why a bank would not want to work with you.

I kept at it.  I tried everything.  I tried credit unions.  I tried Silicon Valley Bank (which turns out to be astonishingly backwards in its approach to technology even by banking standards).  You name it, I tried it.

Finally, I caught two breaks.  The first was a bank called Square1 (no relation to Square, which wasn't founded until a few years later) which was receptive to the idea.  For the nth time I worked my way up the food chain and got to the CEO, but before I could meet with him he had a heart attack and died.  No, I am not making this up.

My second break was First Republic Bank.  I got as far as face-to-face meetings with their CTO and other senior staff.  Then one day, many months in to the process, they all stopped returning my emails.  I found out later that everyone I was dealing with had left the bank.  As far as I know, all the departures were independent and had nothing to do with me.  I tried to resurrect the deal, and got as far as a face-to-face with the new CTO.  He told me he was interested, but was ultimately unable to convince senior management.

By now I was very discouraged, but still not ready to give up.  I tried one last strategy.  Maybe the problem was me.  Maybe I was too geeky.  Maybe I didn't know the secret handshake.  So I enlisted the aid of a friend of mine, a Harvard grad, a complete non-geek, strong business credentials, blue blood, comfortable in a suit and tie.  He had been interested in being a co-founder, so I delegated the job of closing a bank deal to him, and I gave him a strong lead.  We were both extremely careful, working our way step-by-step up the chain of command, getting everyone on board, until we got to the CEO.  We pitched him, and he said yes, but with one condition: he wanted us to be venture funded.

Up to that point I was self-funded, mainly because I didn't need the money, but also because the business case was immensely stronger with a bank on board.  The whole model lived and died on the ability to quickly, cheaply, and reliably move money around, and to do that we needed a bank.  (Yes, I know about ACH.  I'll write a whole nuther post on why that wouldn't work.)  But OK, if the difference between getting my key vendor and not was raising a round, I would raise a round.  I had good VC connections, and within a week I had lined up three of them.  I called the bank back and told them about my progress, and that these VCs would like to talk to them as part of their due dilligence.  That was when this bank, too, pulled out.  No credible explanation.

That was March of 2012.  That was when I decided to fold up the tent.

But, of course, that is not the end of the story.

[UPDATE:] Responding to some comments over on Hacker News, I am not drawing this story out because I'm trying to be cagey.  I don't know why all the banks did what they did.  It's a mystery to me.  That's one of the reasons it's hard to write about.

No, it's because he was behaving like a childish jerk

Liberal news outlets are gleefully reporting an incident on Fox news this morning:

Rep. Keith Ellison, D-Minn., was kicked off of Sean Hannity’s Fox News show during a segment that started out about the sequester, but which devolved into six minutes of the two yelling at each other [emphasis added]. Ellison called Hannity everything from "the worst excuse for a journalist I’ve ever seen" to "a shill for the Republican Party."

Except that if you watch the segment you will see that it was not six minutes of the two of them yelling at each other, it was six minutes of Eillison yelling at Hannity and generally behaving like a sixth-grader, with Hannity politely trying to get a word in edgewise.  I was cringing the entire time I watched it.  I am no fan of Fox news, so it's unfortunate that Ellison's childish conduct completely overshadowed the fact that what he was saying was actually true.  Hannity is a shill for the Republican party, and he is a pathetic excuse for a journalist.  But Ellison, at least for these six minutes, was a pathetic excuse for a leader, and that is the only thing that any non-Democrat is going to remember from this interview.

In the interests of full disclosure...

I'm back, and I'll be posting the next installment in my series tomorrow, probably early afternoon Pacific time.  I'm announcing this because I have an ulterior motive for writing this story, and in particular for writing about it now.  I'm hoping to draw attention to the problem of regulatory capture in the financial industry because there is a bill before the California state assembly that is likely to make a bad problem even worse.  But there's a narrow window of opportunity to get this bill amended so that it makes the problem better.  By the time I'm done, I hope to convince a those of you who are citizens of California that the problem is serious, and that you can help by sending a note to the relevant people in the Assembly.  I'll provide contact information before I'm done.

In the hopes of drawing attention to the problem I've been submitting these posts to Hacker News.  The first one got quite a bit of attention, the second hardly any.  There's about an hour-long window of opportunity between the time a link is submitted to HN to the time it falls off the New page and into the cosmic void, never to be seen again.  If you have a Hacker News account I would really appreciate an upvote tomorrow afternoon.

I'm being up-front about this because I anticipate getting a lot of flack when I publish the next installment.  It's the story of a failure.  Silicon Valley loves a failure, but it hates a whiner.  They want you to fail fast, fail quietly, and move on.  And I am mostly on board with that.  Dwelling on failure is usually counterproductive.  But in this case I think there's a valuable lesson to be learned from my failure, and so I'm going to take the risk of being labelled a whiner and a sore loser in the hopes that it might spur enough people to action to do some good and get a very bad law changed for the better.

That's my agenda.  I hope that by being up-front about this it will help shield me from some of the criticism that I'm pretty sure will come if I'm successful in drawing attention to tomorrow's post.

A simple solution to credit card fraud, part 2: a primer on public-key cryptography

This is part two (of many) of a long story.  This story is partly about credit card fraud, partly about other things, but I had to start somewhere.  In part 1 I made the claim that a technology called public key cryptography could be used to essentially eliminate credit card fraud.  This post is a primer about what public key cryptography is, how it works, and how it could be used to solve the problem.  This post was written for a non-technical audience.

Your on-line life revolves around keeping secrets: passwords, account numbers, your social security number, your mother's maiden name, etc.  The on-line (and telephone BTW) world revolves around the assumption that if you know these secrets then you must be you and not someone else.  One obvious problem with this assumption is that most of these "secrets" aren't very secret. An entire industry, identity theft, has grown up around this fact.

But it's even worse than that: the way that you normally prove to people that you know one of these secrets is by revealing it.  So anyone who can convince you that they have a legitimate need to verify your identity can coax these secrets out of you simply by tricking you into engaging in normal behavior.  That is the basis of phishing.

If only there were some way of proving that you know a certain secret without actually revealing what it is.  The world would be a better place.  You could eliminate (or at least severely curtail) phishing and identity theft.  You would have created real value, the proverbial better mousetrap.  Surely the world would beat a path to your door.  But is it even possible?  You might want to think about that and see if you can come up with any ways on your own before proceeding.

One possibility is to use a trusted intermediary.  Let's call her Tracy.  If we both trust Tracy, then I can reveal the secret to Tracy, and Tracy can tell you "Yep, Ron knows the secret" and you will believe her because you trust her (that's the definition of a trusted intermediary).  Many things in life are much easier if you have a trusted intermediary.  This is the basis for industries like notaries and escrow services.  (One of the reasons that Amazon is such a success is that it operates as a trusted intermediary between its customers and other merchants.)

But suppose we don't have access to a trusted intermediary.  Is it still possible?  Yes, it is, if we use some mathematical tricks.  The details are complicated and I'm going to skip over most of them, but the upshot is this: there are ways to take a secret number S and perform some calculations which produce a series of numbers called P, G1, G2, G3, etc. in such a way that anyone can verify that these numbers could only have been computed by someone who knows S.  So by producing P and one (or more) of these G's you can prove you know S without revealing what S is.  That's all there is to it at a conceptual level.

I have obviously skipped over a ton of details.  In particular I've skipped over how you actually do these calculations, but you can easily find that information if you really want to know.  Beware: this is a very deep rabbit hole, and it is fraught with peril.  I don't want to discourage you from pursuing this, but cryptography is one area where a little knowledge can be a very dangerous thing.  As a general rule you should never use a cryptographic algorithm for any mission-critical application unless you are an expert or have enlisted the aid of one.  But if you just want to noodle around to see for yourself how it all works under the hood, by all means, do it.  The more people understand this stuff, the better the world will be.

However, two of the details I have skipped over are very important even at a conceptual level.

First: why did I call the first result P instead of G0?  Because P is computed differently from all the G's, and it is used in the computation that verifies that the G's were computed by someone who knows S.  In the usual parlance, S is called the "secret key" and P is called the "public key".

Second: each of the G's (but not P) is associated with another number, N.  In fact, each G is computed from S and some N using the same computation.  So not only is each G proof of knowledge of S, but it is also associated with some particular number N.  This means that each G can be interpreted as a digital signature associated with N.  Moreover, this is a secure digital signature because only someone who knew S could have produced it.

We can use this to prevent credit card fraud by adopting a new protocol.  Instead of telling the merchant your (say) CVV code, you could instead use a secret key associated with your credit card to produce a digital signature for a number N that was unique to that particular transaction (an invoice number, for example).  To authorize the transaction you would take your secret key S and compute the signature Gn.  The merchant could show Gn to the bank as evidence that you authorized the transaction because Gn could only have been produced by you (since you are the only one who knows S).

Furthermore, Gn can *only* be used to authorize that *one* transaction.  It cannot be reused for any other transaction.  A fraudster might still be able to extract some money from you by getting you to authorize a fraudulent transaction (i.e. a purchase for an item that they don't send you) but they can't reuse the information to conduct any other transactions.  The black market in stolen credit card numbers would evaporate overnight.  It might be replaced by a black market in stolen secret keys, but this is still a significant improvement over the status quo because you can't easily phish a secret key.  In the normal course of events you never ever reveal your secret key to anyone, so anyone who asked for it would immediately arouse suspicion.  There are still ways that a secret key can be compromised (if someone installs malware on the computer where you store it, for example), but it is at least possible in principle to keep a secret key secret.  Keeping your credit card information secret is not possible even in principle because the current protocol requires you to hand it over for every single transaction that you conduct.

Again I must reiterate that I have skipped over a lot of details.  Making this actually work is not so easy, but a lot -- maybe even *most* -- of the things that are commonly done in the technology world are not so easy.  And yet they get done.  But this one hasn't.

Some technical details in case you're curious:

There are two main ways of performing public-key cryptography, called RSA and ECC.  RSA stands for Rivest-Shamir-Adelman, the last names of the people who invented it.  ECC stands for Elliptic Curve Cryptography, after the mathematical theory that underlies it.  RSA was invented in 1977, ECC in 1985.

RSA is based on large prime numbers.  The secret key S is not one number but two, and the public key P is the product of these two numbers.  (In RSA terminology, the two prime numbers are usually called P and Q instead of S, and the public key is called N instead of P.  There's another piece of the public key called E but you can safely ignore that at this high level.)

RSA has two main problems.  Neither of these are show-stoppers (RSA is in widespread use) but they are disadvantages.  The first is that the numbers involved are really big.  Nowadays a typical RSA key has at least 2048 bits, and the signatures are the same size.  So they can be a little unwieldy.

The second problem is that producing large random prime numbers to serve as RSA keys is not trivial.  If you are not technically savvy you probably have to get someone to do it for you, which means you have to trust them to 1) have enough technical knowledge to actually produce a strong key and 2) be trustworthy enough not to keep a copy for themselves, or to give to anyone else.  This is called the key provisioning problem.  It is very serious, and some (myself included) would say not completely solved.

ECC doesn't have either of these problems.  It uses keys that don't have to be prime numbers, and they can be a lot shorter for a given level of security.  In general, for a given level of security, an ECC key is less than a tenth the size of an RSA key.  And because they don't have to be prime numbers they are a lot easier to produce, so key provisioning is a lot easier.  But ECC is newer and less widely used, so it is not as battle-tested as RSA.

If there's enough interest I'll write up another post about the technical details of ECC, which is what Founders Forge was going to use.

An administrative note

I probably should have thought of this before I posted, but I'm at the airport on my way out of town.  My post on credit card fraud is generating a lot of feedback (thanks!) but I won't have time to respond properly until later today.  But I do appreciate the feedback, and I will respond.

Just a couple of points off the cuff:

1.  This is just the beginning of a pretty long story.  The events that led up to this unfolded over a period of nearly four years.  The issues involved are complicated, and they are complicated across multiple dimensions: technically, legally, and politically.  And I'm writing for a very broad audience that spans a very broad range of background and expertise.  So please bear with me, and cut me a little slack.

2.  The problem is not so much the failure of the banks and credit card companies to solve the fraud problem per se.  The real problem IMHO is the obstacles I encountered when I tried to start a company that would solve, not the credit card problem per se, but a related problem (that I believed, and still believe, would also solve the credit card fraud problem as a side effect).  Like I said, long story.  Bear with me.  [UPDATE: I would like to rephrase my statement of the problem: the problem is that the cost of fraud is hidden from consumers, and the industry has, through regulatory capture, erected all-but-insurmountable barriers to entry to competition.  And, by the way, when I started, Bitcoin didn't exist.  Bitcoin may well change everything.  But that is also a complicated topic in its own right.]

3.  I am not the only person to have encountered this problem, and public key crypto is not the only possible solution.  I just cited that as an example of an available solution that is not being deployed, or at least not being deployed as expeditiously as it could be.

More later.