Beyer on Pick 6

[cj]

http://www.washingtonpost.com/wp-dyn/articles/A43094-2002Oct30.html

CJ

[justin]

The bottom line here is that regardless of whether it was a legitimate hit or not, this whole situation has exposed the flaws in the way wagering information is relayed to the host track. Personally, I would accept all wagering being cutoff at 2 MTP or whatever it takes to 100% ensure that no data is coming in after the race has begun. This obviously won't help the Pick 6, Pick 4, etc unless they change the way those wagers are dealt with.

Sure, this would probably require some operations to have to do a serious upgrade to their hardware/connection, but that's not my concern. In light of what may have happened this Saturday, restoring bettor confidence should trump any financial concerns, because with no bettors, there is no business. Considering the huge advances we have seen in computer hardware and the speed of internet connections in the last few years, there is no good reason for there to even be an opportunity for this to happen.

Justin

[ranchwest]

Beyer:

>It must ensure that nobody can ever again tamper with computer systems that handle wagers. <

I don't think it has to go that far or that we should expect it will. There is always the possibility that someone can outsmart computer security. We just need to see a much more sophisticated assessment of the situation and a major upgrade in security measures. I'd like to see a 99.9% secure system, but I'll always realize that there is the possibility of fraud. That's the case with any computer system.

[so.cal.fan]

JM writes:

"Personally, I would accept all wagering being cutoff at 2 MTP or whatever it takes to 100% ensure that no data is coming in after the race has begun".

I agree, JM, I think they have to do this, at least off track.
If you are betting online, or by phone , or at a simulcast facility, you must accept this. If you don't like it, go to the host track you are playing.
It would sure help restore confidence in the system.

[highnote]

I agree. If the final odds are posted before the gates are open bettors will have a more confidence in the tote system.

[MikeDee]

Sorry, but I don't think moving the stop time fixes anything. When the betting stop time is reached the odds should stop changing, period. It doesn't really mater if the betting stop time is 5 min before post, 2 min before, or at the post, if the odds change after the stop is reached, there is still the appearance that bets are being made after the fact.

The real fix is to process bets in real time, it can be done, they just don't want to spend the money it would take to do it. Maybe this latest embarrassment will shame them into it.

[ranchwest]

Whether bets come in after the betting ceases is not a concern. The problem arises when the bets come in after the race starts. There will always be some lag time between when bets are made and when the bets are transmitted and accepted. There can always be a glitch that will take a short while to correct.

[Dave Schwartz]

Mike,

Actually, a pre-post closing of the wagering would solve much of the problem, albeit not the pick6 problem we have been discussing.

What needs to happen, IMHO, is that the tracks need to stop taking wagers two minutes to post and any simulcast wagers transmitted to the home track after (say) 30 seconds to post need to be rejected by the system.

It would work like this:

1. You buy a ticket for Santa Anita at Catskill OTB (or Wyoming, or AP). If the track/otb is derelict in communicating that data to SA inb a timely manner, they will have to refund your ticket and, hence, lose the commission on it.

2. We, the bettors, gain the knowledge that the pools are locked completely BEFORE the gate opens as the gate cannot open until the "last flash."

Just my opinion.

Dave

[so.cal.fan]

I'll bet this is under serious consideration right now, Dave.
I'll be surprised if they DON'T do it.

[highnote]

If they want my action, they better do it.

[David McKenzie]

Originally posted by so.cal.fan
I'll bet this is under serious consideration right now, Dave.
I'll be surprised if they DON'T do it.

With so much money coming in after post time, I'd be shocked if they DID do it!

It's a self-serving glutton with a ravenous appetite.

[highnote]

It shouldn't make any difference whether betting is stopped 2 minutes before the gate opens or as the gate opens. The only ones who won't like it are the criminals.

[smf]

Originally posted by Dave Schwartz
Mike,

Actually, a pre-post closing of the wagering would solve much of the problem, albeit not the pick6 problem we have been discussing.

What needs to happen, IMHO, is that the tracks need to stop taking wagers two minutes to post and any simulcast wagers transmitted to the home track after (say) 30 seconds to post need to be rejected by the system.

It would work like this:

1. You buy a ticket for Santa Anita at Catskill OTB (or Wyoming, or AP). If the track/otb is derelict in communicating that data to SA inb a timely manner, they will have to refund your ticket and, hence, lose the commission on it.

2. We, the bettors, gain the knowledge that the pools are locked completely BEFORE the gate opens as the gate cannot open until the "last flash."

Just my opinion.

Dave

Dave,

Won't work.

Let's say I have a bet on a horse that looks professional in every way coming to the gate. One mtp and he throws the jock. Obviously the horse gets spooked or mistreated, otherwise he's a calm runner from my past observations (for example).

When I see a horse dump a rider, the FIRST thing I do if I'm at the track is get my refund on that ticket. That hoss ain't running his best after an incident of that nature.

If I'm at home, I'm screwed and curse the walls. I don't mind bad racing luck, but I'll be damned (not directing anger towards you personally, btw) if I'm going to make bets that can be affected by PRE-RACE bad luck. THat's not fair, and that's why I always wait till they begin to load on the tv before sending my bets over the net/ phone.

Rules like the one you pointed out are the kind that w/ run some smart bettors out. I'm no whale, but the tracks like whale money and they bet late.

I hope they keep the bet cut-off time the same, but crack down on the cheats.

[highnote]

smf,
Good point. However, change can be difficult. We adjust. I think I'd have a big advantage if I could bet with bookmakers, but they outlawed them in the US. I deal with it.

There might have to be other rules put in place, such as if a horse throws a jock after wagering has ceased all bets on that horse are void. I'm not saying this should be a rule. It's just meant to be an example of how new rules might have to be created.

To my thinking, displaying final odds before the race begins would be of greater benefit to more people than displaying final odds after the race has begun.

Just my opinion, but I am interested in knowing what people are thinking.

js

[ranchwest]

I know this is shaking everyone's confidence. It has shaken mine.

However, I do think that it is possible to have an adequately secure system and keep the windows open until the gates open. There just needs to be a lot of auditing going on.

The states may have to settle for a smaller piece of the pie in order for there to be money to ensure the entegrity of the wagering process.

[PaceAdvantage]

I agree ranchwest. I would be terribly disappointed if they decide to close pools before post time.

The technology exists to process these bets more efficiently. It HAS to. NO WAY is racing that data intensive that TODAY'S technology can't keep up.

If they cut wagering off at 2mtp, it would be like cutting off your arm to get rid of a pimple....much easier and efficient remedies DO exist...


==PA

[GameTheory]

I doubt anyone (with the power to do so) is seriously considering locking the pools before post time. I think it would take a law to get it to happen, and it would be a state by state thing. We have no body with a system in place for creating national policy. All we've got is NTRA and Go Baby Go. (And I'm still holding a grudge for using Lori Petty -- what were they thinking?)

Now if some brave track out there decides it is going to stop accepting bets at 2mtp and display final odds before the start of the race as an experiment, AND they see their handle go up along with the new system, then maybe others would be motivated to follow suit. Otherwise, it will take a law, and laws don't get passed quickly. The dust will already have settled. The only quick change we're gonna get is some re-evaluation of the computer system where they change unspecified details of the system and then re-assure us that all is ok again.

Unless of course the amount of people that REALLY are gonna stop ALL betting on throughbreds do so right now, and the number of such people is significant. Then maybe they'll sit up and notice. But let's do a quick non-scientific survey:

Last Thursday's handle at Santa Anita, two days before the BC:

pick 6 pool: $160,579
on track: Handle $1,056,059
intra-state: Handle $2,335,438
inter-state: Handle $3,719,810


This Thursday at Santa Anita, now that we are in the middle of this crisis of confidence:

pick 6 pool: $146,612
on track: $1,102,322
intra-state: Handle $2,619,983
inter-state: Handle $3,731,620

The pick 6 pool is actually slightly less this week, but was made up other places, and the total handle is in fact higher.


Do you think the muckity-mucks at SA are considering changing *their* policies? Absolutely not -- they're just waiting for this to blow over...

[Dave Schwartz]

PA,

I understand why they currently send the ticket summary after the 4th race... it is because the technology will not support sending (and receiving) that much data before.

WHen the track sends the win/place/show pool summary they need to send (say) 16 horses times the 3 pools... 48 variables max.

For a daily double they are sending at most 16 x 16 summaries of how much money was wagered on each combination.

In a Pick 3 that jumps up to 16 x 16 x 16 or 4096 items.

For the BC, there is the potential for 16^6 (or, even if you cut it down to the number of actual horses) or perhaps something like 10^6. This is 1,000,000 records! That is a huge amount to transfer. Even if they just send the ones actually bet, they cut down the bytes to transfer, but increase the records as now they must also send a descriptor of the actual permutation.

Imagine that the data to be sent is 1,000,000 x 5 bytes that equeals 5mb. At a transfer rate of T1 speed (about 150k per second) that would take over 30 seconds per track for just this pool!

Remember that many smaller tracks likely do not have T1 access and are sending their data via something akin to DSL speed which could well be 1/2 of the T1 or less. In other words, it might take a minute or more for the Pick6 data for Wyoming to reach the track in NY. Then the data has to be processed for each track.

It is a much bigger problem than people realize.


Regards,
Dave Schwartz

[highnote]

smf made a good point about wanting to see the horses load into the gate before he bets as a reason to keep the pools open until the gate opens.

What other reasons are there to keep the pools open until post?

js

[rastacio]

Dave,

Your not taking into account that the bets should be sent as soon as they are made. So in your T1 example the facility would be able to send 30,000 bets a second. Perhaps I'm wrong but that seems like a ton of bets. The entire pool should not have to be sent. It should be a constant stream being sent to the host facility.

[BillW]

Originally posted by Dave Schwartz
PA,

I understand why they currently send the ticket summary after the 4th race... it is because the technology will not support sending (and receiving) that much data before.

WHen the track sends the win/place/show pool summary they need to send (say) 16 horses times the 3 pools... 48 variables max.

For a daily double they are sending at most 16 x 16 summaries of how much money was wagered on each combination.

In a Pick 3 that jumps up to 16 x 16 x 16 or 4096 items.

For the BC, there is the potential for 16^6 (or, even if you cut it down to the number of actual horses) or perhaps something like 10^6. This is 1,000,000 records! That is a huge amount to transfer. Even if they just send the ones actually bet, they cut down the bytes to transfer, but increase the records as now they must also send a descriptor of the actual permutation.

Imagine that the data to be sent is 1,000,000 x 5 bytes that equeals 5mb. At a transfer rate of T1 speed (about 150k per second) that would take over 30 seconds per track for just this pool!

Remember that many smaller tracks likely do not have T1 access and are sending their data via something akin to DSL speed which could well be 1/2 of the T1 or less. In other words, it might take a minute or more for the Pick6 data for Wyoming to reach the track in NY. Then the data has to be processed for each track.

It is a much bigger problem than people realize.


Regards,
Dave Schwartz

Dave,

Why is it necessary to break out the combinations at the originating end? Why can't WYO just send their 10 p6 wagers in raw form i.e.:

$2 1,2,3/4,3,2/2,1/5,6/4,7,3/8,7,9

thus keeping the data compressed and put the load on the destination system to sort out the combinations at its leasure, after the pools have been securely locked?

Bill

[Dave Schwartz]

That is exactly the problem... They are sending the "summary data of how much has been wagered in the pool" and not the individual permutations of the picks...

That is, "how much was bet on #2-#3-#4-#2-#1-#2." (or whatever combinations were bet)

That is how this scam worked. They bought a ticket then went in later and edited the actual selections. Since those actual selections (or actually the money wagered on each combination) were not sent, there was nothing to check against.

Dave

[Tim]

Dave,

You make some interesting points but I don't quite agree with you. It's not the early 90's but 2002. Data transfer problems and bottlenecks are more of a management and budget authorization problem than a technical one. The pool for the BC pick 6 was about 4.5 million dollars. If every pick 6 ticket was for $2 then that works out to be about 2.3 million records. That shouldn’t be a big problem. Bets are transferred from betting centers to regional hubs to the host track. If the type of track that hosts a Breeders Cup and the regional hubs are not communicating at T3 speed or better then the people managing these events are idiots. And if all 300 people at Wyoming Downs bet the Pick 6, the track should be able to transfer to the regional hub on a 56K modem in a minute or less. Processing the bets at the host track is not an issue unless you are going to try for real time tote board odds. You have 2+ hours to calculate payoffs before the last race is official.

You’re right in that it’s a bigger problem than people realize but for the national thoroughbred betting system to need 2 hours (4 races) to collect and process what the NYSE can process in a couple of minutes is an embarrassment. I make the case that the timing issue with collecting bets is not a technical problem but a management one.

Tim

[BillW]

Dave,

I understand how it is done now and that it is flawed. My point is that the solution of each track shipping raw data for each ticket would be at most a few hundred bytes per ticket purchased, with protocol overhead. That is quite a bit less than shipping a 6 dimensional array of every permutation and should be no problem for even a T1 or DSL.

This of course would not prohibit alteration of the ticket at the host track, but would put the vulnerability at a single point, rather than spread over the simulcast network.

Bill

[MarylandPaul@HSH]

In this day, there's no excuse for any wagering facility to not have dedicated T1 or greater bandwidth. Combine that with data compression, and it seems to me this info can move pretty quickly.

Hell Dave, YOU have T1 bandwidth. Can I just send my bets through you?? You might not want to book them though, I'm using some pretty good software. :D


Paul
MP

[Dave Schwartz]

I am not suggesting that the have to send each ticket. Sending the SUMMARY of each permutation is enough to create the bottleneck. You simply can't send that much data over the web that quickly. Do the math. It is more than the bandwidth will support.

That is why they chose to do it the way they did.

And that way is not working.

Dave

[Dave Schwartz]

Paul,

Bookmaking would be such a great alternative. Too bad it is illegal.

Of course, it would be like switching sides.

Dave

[MikeDee]

Dave I just can't agree with you. Tim makes some excellent points. The technology is available. Feature length digital quality movies can be transferred over today modern high speed networks. Billions of voce and data transmissions are transmitted in real time over today’s modern networks 24/7. The volume of data transferred to process racing information is a thimbleful compared to other real time networks.

If you need a T3 then buy one. If you can't afford a T3 and one is needed then get out of the business. Why should a national wagering network be brought down to the lowest common denominator to placate the smallest OTB site with the cheapest management organization?

[GameTheory]

Yeah, I still didn't get it. I tried to do the math. 2.3 million combinations (roughly) to transmit TOTAL (that includes all locations) on the biggest racing day of the year. Most days would be much much less.

So how big is each record? If it is not 100 bytes as I guessed earlier, how much is it? 400, 500? That's still not that much data. Only around 1 GIG total. Split that up over all the outlets in the country taking bets.

For instance:

<track><race number><wager type><amount of bet><combination><timestamp><various id's of the wager taker, computer codes, etc.>

No encrypt it, which may make it larger. You can easily fit all the above in 100 bytes. Now add a bunch of headers, id numbers, etc. so they can keep track of thing. It still isn't a very big record. What the hell are they transmitting?

[Dave Schwartz]

Game Theory,

I think you are missing it. They are (at minimum) sending an array of 4-byte variables (longs). The dimensions of the array could be as much as 16^6 but probably more like ABOUT 12^6 or 3 million records.

3 million x 4 bytes = 12 million bytes. (Note I have left out any delimiters.)

call it 12mb transferred at T1 speed takes about 80 seconds.


Or, on the low side, as I said before, about 5 million bytes at T1 speed about 33 seconds.


Dave

[GameTheory]

Obviously I don't get it. Why in the world do they need to send the whole array? It will be mostly empty. We can't they send only the bets that are actually placed where they can be plugged in to the "master array" at the host track?

Based on the size of the pool, we can say there were roughly 2.3 million combinations bet total. Not more than 2.3 records need be transmitted.

If they need to send the whole grid, the system is not only insecure, but retarded. They should have vetoed that idea at the design table without another thought.

[PurplePower]

My A1 brain has short circuited with all this data tranfer.
One big problem with all of this is that the person or people that "fix" this will know how to "beat the fix". I reckon we'll have to have two people with "red keys" that have to be turned at the same time to enter a read only database - and then assign the keys to adminsitrators at random - then -- oh shoot -- someone at a OTB hub would probably launch a nuclear warhead,

Man, another skunk runs out from under the feed room with every new article.

[Dave Schwartz]

GT,

They could send the bets instead, but the overhead for the extra bytes would likely make it a wash.

In that case you would need 10 bytes for each permutation. This would cut it down but still leave it in the megabyte range.

Dave

[Tim]

Dave,

I’m confused. Are you saying that the data transfer is laid out like an archaic Fortan matrix. I can’t believe that. The transfers have to be at the level of the betting record.

A betting record has to be treated like any other financial computer record. It’s the same as an ATM, check or credit card transaction. At the start of the event (making the bet) and the end of the event (in this case the result of a race) money is going to change hands. There might even be a tax liability. An audit trail starting from the betting terminal to the host track mutual pool has to exist. I can’t believe an EDP auditor would validate a system that didn’t know where the money came from or where it went. While the transfers might occur in batches, the detailed betting records have to be there.

[GameTheory]

Originally posted by Dave Schwartz
GT,

They could send the bets instead, but the overhead for the extra bytes would likely make it a wash.

In that case you would need 10 bytes for each permutation. This would cut it down but still leave it in the megabyte range.

Dave


I would think it would be much much less data.

A) If they send the whole matrix, that means that each outlet taking bets has to send the whole matrix, whether they took 1 bet or 10,000 bets. If they just send the bets, each outlet is only responsible for the bets they actually take. Keep in mind in an average pick 6 pool there are only 80,000 or so combinations total.

B) There would be no reason to send it in a big block -- they would send the bets every 60 seconds or whatever they usually do for other pools.