1997-11-02 - Kyl’s internet gambling bill

Header Data

From: “John Kelsey” <kelsey@plnet.net>
To: “cypherpunks” <cypherpunks@Algebra.COM>
Message Hash: 414bfee2edde7b2f273bacb4e87ef3b7b9577beb61ff80f3f073e7350b2825a5
Message ID: <199711021810.MAA30056@email.plnet.net>
Reply To: N/A
UTC Datetime: 1997-11-02 18:15:13 UTC
Raw Date: Mon, 3 Nov 1997 02:15:13 +0800

Raw message

From: "John Kelsey" <kelsey@plnet.net>
Date: Mon, 3 Nov 1997 02:15:13 +0800
To: "cypherpunks" <cypherpunks@Algebra.COM>
Subject: Kyl's internet gambling bill
Message-ID: <199711021810.MAA30056@email.plnet.net>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

[ To: cypherpunks ## Date: 10/30/97 ##
  Subject: Kyl's internet gambling bill ]

>Date: Wed, 29 Oct 1997 13:31:21 -0800
>From: Steve Schear <azur@netcom.com>
>Subject: Re: Kyl S-474 Anti-Gambling Bill passes committee

[Stuff about Kyl's anti-internet gambling bill.]

>Prediction: this bill will be about as effective as
>outlawing spring.

>About 20% of gamblers are 'problem' types who now regularly
>game illegally and could careless about the penalties.  Once
>all on-line casinos offer real and 'play-money' wagering and
>strong crypto it will be neigh impossible for the Feds to
>know or prove which players are wagering real money and
>therefore gambling.  Once Onion and Crowds routers are
>operational and widespread the Feds won't even be able to
>find the casinos, and even if they do they may not be able
>to shut them down (especially if they are built in a
>distributed fasion).

I always find these laws entertaining.  In Missouri, we have
state-run gambling in the lottery system, and state-licenced
gambling on the riverboat casinos.  Our Attorney General has
been very vocal about shutting down internet casinos, to
protect Missouri's citizens from being exploited.  His
concern for the welfare of problem gamblers in our state
is touching.  Odd that he isn't worried about those same
citizens being taken advantage of by the in-state
operations.

Of course, the real issue here isn't about protecting
citizens from themselves, or even about keeping citizens
from being cheated by the electronic equivalent of weighted
dice.  It's about protecting the financial interests of
those who now benefit from having local gambling monopolies.
The state gets quite a bit of money from the lottery, and
the companies that have invested in building riverboat
casinos here are surely concerned about potential
competition via the internet.  The cities that have
riverboat casinos typically get some part of the money made
from them, which nicely brings those city governments into
line.  Presumably, something similar is happening with
various states' Indian Reservations opening casinos.

It's an interesting side-point that really anonymous
communications and payment systems applied to gambling
systems mean not only that *governments* can't shut down
competing gambling schemes, but also that organized crime
can't shut them down, whether through influencing corrupt
governments to try to shut them down, or through direct
action.


Ob Crypto:  There are cryptographic gambling protocols that
can be verified (given some set of assumptions about
underlying operations) to be fair.  Thus, it's possible for
a gambling operation to make their client software freely
available in source, and allow people to see what it does
and review it for fairness.  If you find a reviewer or two
you trust, you can ask them to digitially sign the
executable they got when they compiled the code, and refuse
to use any other code.  This gives you a level of certainty
that you're not being cheated by weighted dice that you
simply can't get in physical casinos.  (Sure, government
agencies inspect those casinos, but the inspectors aren't
incorruptible, and they can't be everywhere at once.)

For a simple example, consider a situation where Alice and
Bob need to agree on a shared seed.  Assume they already
have established a secure (encrypted and authenticated)
session. They can easily generate a new shared seed by doing
something like this:

1. Alice generates random R_0 and sends hash(R_0) to Bob.
2. Bob generates random R_1 and sends hash(R_1) to Alice.
3. Alice sends R_0 to Bob.
4. Bob sends R_1 to Alice.
5. Alice and Bob each generate their shared seed, R_0 XOR R_1.

If the hash function doesn't leak information about its
inputs, and if it is collision-resistant, then this protocol
should work.  If either party generates a random number,
then the resulting seed is random, regardless of the other
party's input.  (You still have to work out administrative

issues, like what happens when communications fail
conveniently just after Alice sends Bob R_0, but these are
easy enough to solve.)

>--Steve

   --John Kelsey, Counterpane Systems, kelsey@counterpane.com
 PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNFje6UHx57Ag8goBAQEsZQP/TWqpL70gThhETuqDlrTJsCCy5PeTMNte
t0tzg8fwPFK3cESSN+5ndRAjUXmdS8dmNZW1U8RcDFpH8YRd1uAfJ4CdmMrK8zgk
OGcegYoSDgwtdLw43Zslx88nl7OgkfvyQqzZZmDkWwyXn0g1RMLcTVt8nyccm6O+
WPH3VLc+7Ho=
=H+YB
-----END PGP SIGNATURE-----


   --John Kelsey, Counterpane Systems, kelsey@counterpane.com
 PGP 2.6 fingerprint = 4FE2 F421 100F BB0A 03D1 FE06 A435 7E36






Thread