now | writings | rss | github | twitter | contact

trying to game (part 2)

posted to writings on mar 10th, 2009 with tags javascript and nerd, last updated on aug 12th, 2009 and commented on 33 times

in the first part of this story, i had created a greasemonkey (javascript) script to watch auctions on and log bidding activity to my server. after observing a few auctions, i altered my script to automatically place bids on my behalf every time the auction's counter ran down to 1 second.

the only way i could possibly lose in this scenario would be if some sort of network disruption occurred that prevented my browser from seeing the counter reach 1, or prevented my bid from reaching the server and being placed. my script would keep bidding until my account ran out of money to bid with, continually running the auction time left back up to 10 seconds, until i was no longer outbid.

the first auction that my script was bidding on was for a macbook. the script began watching the auction at $112.58 and 13 hours later, it ended at $172.84. during the auction, my script placed 37 bids, each when the auction counter dropped to 1 second remaining, costing me $27.75.

according to my data for this auction, the final seconds looked like this:

1236315801,bidding at $172.78
1236315802,00:00:01,00:00:10,$172.79,Chronowulf,Single bid
1236315802,00:00:01,00:00:10,$172.80,Swattie77,Single bid
1236315802,00:00:01,00:00:10,$172.81,Your bid!,Single bid
1236315803,00:00:10,00:00:10,$172.82,Womai09,Single bid
1236315804,00:00:10,00:00:10,$172.83,Montysdad,Single bid
1236315816,bidding at $172.84

so the price was $172.78, the counter reached 1, i bid (along with 5 other people at roughly the same time), and the price was then $172.84. the counter reached 1 again and i bid, but my bid was not counted. the auction ended at $172.84, with the "Issoacs" user winning after having bidbutler place his or her 1,435th $0.75 bid.

while it's possible that my connection suddenly got laggy and my bid got in late, the data tells a different story. the other 5 users that bid with me at 1 second remaining just 15 seconds before had previously been bidding every 10 seconds or so, every time the counter got low. am i to believe that five other users (or bots), who had all been watching the auction for at least the past hour and up to at least 15 seconds before the auction ended, and were reliably bidding every single time the counter reached 1 second, all suddenly stopped or had connection problems at the exact same time?

on this one particular auction that swoopo ended up making $12,963 in bids, plus the final $172.84 price, 5 users who were all manually bidding suddenly lost to the 1 user using swoopo's bidbutler service (which placed 1,435 75-cent bids for that user). seems a bit strange.

while this auction was going on, my script was simultaneously logging and bidding on another macbook which i began logging from the start of the auction. it ended 5 hours after the previous auction, at only $44.88.

the data looks very similar to the first:

1236335690,bidding at $44.76
1236335691,00:00:01,00:00:15,$44.77,Dara08,Single bid
1236335692,00:00:15,00:00:15,$44.78,Mykdn,Single bid
1236335692,00:00:15,00:00:15,$44.79,Your bid!,Single bid
1236335692,00:00:15,00:00:15,$44.80,Cg1234,Single bid
1236335692,00:00:15,00:00:15,$44.81,Invicta1698,Single bid
1236335694,00:00:15,00:00:14,$44.82,Twistedcandy,Single bid
1236335695,00:00:14,00:00:15,$44.83,Julev84,Single bid
1236335719,bidding at $44.84
1236335721,00:00:01,00:00:15,$44.85,Dara08,Single bid
1236335722,00:00:15,00:00:15,$44.86,Your bid!,Single bid
1236335722,00:00:15,00:00:15,$44.87,Invicta1698,Single bid
1236335740,bidding at $44.88

once again, a number of users were placing manual bids each time the counter reached 1 second, and again, my script saw the counter reach 1, placed a bid, and that bid was not counted. this auction ended at $44.88 and was won by another user using bidbutler, which placed 706 bids on his or her behalf.

in the first part of this story, i had mentioned that slight timing differences may have accounted for the data i was seeing, where the counter would reach 1, a number of users would bid, and then one or two bids would come in a second later. i presumed that those one or two last bidders were experiencing a delay, and were actually bidding after the counter had already gone back up to 10 seconds from the previous users but before their counter updated.

while watching another auction in real-time, i noticed that occasionally when the counter reached 3 or 2 seconds remaining, it locked up. the counter stayed on 3, a second passed, and another, and the next time the counter updated, it was back at 10 seconds.

while my data was always showing that the script saw the display read 00:00:01 and bid, i thought that bidding before that point may be helpful. bidding when the display read 3 or 2 would cost a lot more money, though, since i would always be the one to bump up the clock. waiting for 1 second cost much less, since other users would see 3 or 2 and make their presence known by bidding. in this scenario, while i would probably not win against the other manually bidding users, at least the auction would not be able to end. one of us would always be bidding at 3, 2, or 1 seconds remaining.

after thinking about it some, i changed my script to be able to do a "blind" bid. when the counter reached 3, it would start an internal timer and fire 1500 milliseconds later. if the counter had not updated to read 2 or 1 second (or something higher, indicating that another user bid), it would bid. if the counter updated before the 1500 milliseconds to read 2 or 1, the previous code would catch it and bid at 1. this way i would be covered if the counter ran down normally, but also catch the counter locking up.

i let this new code run on a third auction, but with the same results. it had to use the blind bidding routine twice, but again it saw the counter reach 1, placed a final bid for the amount that the auction ended at, and did not win. and again, i was joined by at least 6 other manually bidding users that had previously been bidding at 1 second remaining just before the auction ended that also did not win.

with all of this data available, i concluded that there is no way to reliably win an auction on without using their bidbutler service. there are delays on their network/servers in processing manual bids, whether intentional or just due to bad design, that cause manual bids placed with 1 or 2 seconds remaining not to be cast. users of their bidbutler service have an unfair advantage in that their bids are placed on the server side and are not subject to these delays.

since it is not possible to reliably place manual bids, the only way to guarantee that an auction can be won (while still coming out ahead) is to use the site's bidbutler service with high ceilings on the number of bids and amount that one will let it bid up to. those ceilings have to take into account the item's current price, and will be lower the longer an item is being bid on.

on a $1,299 macbook auction with each bid costing a user 75 cents and raising the auction price 1 cent, assuming a user has someone else raising his bid every time, the maximum number of bids for him to place would be 1,687 from the start of the auction. 1,687 bids * 0.75 = $1,265.25 in bids, plus the final value of $33.74 (the other user bid 1,687 times, too, for 3,374 1-cent bid increments, or $33.74) totaling $1,298.99. if the user is not the high bidder at that point, he must give up and lose $1,298.99, or continue and spend more on the item than it is worth.

if that user had started bidding when the auction price was already, say, $100, and allowed bidbutler to place the same 1,687 bids, it would top out the item price at $133.74 and result in the user paying more than its $1,299 value. so the later the user enters the bidding, the fewer amount of bids he can have bidbutler place to still come out ahead. eventually this will reach 0 when the item's price reaches $1,299 (when 129,900 total bids have been placed by other users).

since the original idea of always bidding at 1 second remaining proved to be ineffective, i have been thinking about how to make a script use bidbutler to its advantage. at any given point, the script could produce a probability of there being any other users still bidding with bidbutler, based on the historical data of bidding activity the script is maintaining. since bidbutler bids at random times and rarely with only 1 or 2 seconds remaining, it would "show itself" over the past few 10-to-2-back-to-10 second cycles. if there is a high probability of there only being one other bidbutler user (or none), then the script could activate bidbutler and allow it to place a small number of bids over the next few cycles, hoping to beat out the other manual bidders since they obviously can't win against bidbutler. if there ever appears to be more than one user using bidbutler, the script would cancel bidbutler, saving the remaining bids it would have cast, and allow the other two users' bidbutlers to battle it out until the probability goes back up that there is only one (or none) left.

i haven't written the code for this last concept. i spent $75 on the bids used during these experiments and since the only way to win is still a gamble that will probably end up costing many hundreds of dollars in bids (though still less than the value of the item), i'm giving up on trying to game joshua was right; the only winning move is not to play.

update: the greasemonkey script that i used for this now is available on github.

Comments? Contact me via Twitter or e-mail.


rich! (not authenticated) on march 11th, 2009 at 03:27:56:

game theory at its best? :P

sma (authentic) on march 11th, 2009 at 03:37:32:

it seems that using the bidbutler product requires the buyer to pay pretty much retail for the product. also, it's quite clear that swoopo is making a crapload of money off of this. is it also possible that the bidbutler users are fake, resulting in swoopo not really having to ship a macbook?

jro (not authenticated) on march 11th, 2009 at 04:45:00:

sounding more and more like a sham. i wouldn't be surprised if this ends up being some type of scam or rigged system where swoopo is placing artificial bids with fake accounts..

jro (not authenticated) on march 11th, 2009 at 04:49:32:

plus they seem to be based out of the UK..

Dan (not authenticated) on april 10th, 2009 at 00:30:01:

You saved me a lot of time there bro.
money too

Benjamin M. Strozykowski (authentic) on april 22nd, 2009 at 00:55:05:

This was a great read. I always hear about this site being evil, and here are some numbers to support that.

A $75 hit for humanity :)

James (not authenticated) on may 25th, 2009 at 16:43:32:

Really interesting article. Good analysis and thanks for your efforts!

Dan (not authenticated) on may 26th, 2009 at 04:42:33:

If you think it's frustrating that you can't win without BidButler, think of the guys at Swoopo knowing that they are selling an item when 5 people are still interested in bidding up the price.

TX CHL Instructor (authentic) on may 26th, 2009 at 11:17:43:

I wouldn't have spent the $75.

Dave (authentic) on may 26th, 2009 at 21:52:24:

Nice work.

I think that the solution is to try and win with high probability, rather than any one particular auction. So I gathered data from 10000 auctions to fish through for patterns: specifically looking at click-only auction where bidbutler isn't allowed.

Derek (not authenticated) on may 28th, 2009 at 12:45:22:

Thanks for your sharing. Actually I am thinking a better way to run penny bidding website: to have a fixed top price. When the current auction price reaches that fixed price, the bid ends immediately, and the bidder with the most bids in that auction wins. I think this will creates a little predictablity and fairness. What do you think?

BTW, I am also watching swoopo. I noticed there are a lot of people looking for designers to build a similar site like swoopo(on But I haven't seen much real site come out. Can you figure out any reason?

P.S. I would like to pay your bill for the experiencement if you can share your code of tracking and placing bid on swoopo:)

sdmurthy (not authenticated) on may 31st, 2009 at 03:24:24:

I think your last strategy sounds good. Enable the bidbutler to bid for you, via a script, only when ten seconds are remaining- so that it doesn't waste bids outside this time slot.

victim_of_butler (not authenticated) on june 13th, 2009 at 18:14:01:

I did a similar experiment, and my conclusion is the same: you cannot beat bidbutlers. Servers favor them in ways more than timing....

retr0rob (authentic) on june 23rd, 2009 at 11:49:27:

Really excellent work, and well written -- a rarity among programmers.
I have a question:
If auctions end after 10 seconds of no-bids, would it be better to try and bid directly after a bid-butler bid to try and sneak in after it? The only problem I see there is the fact that you have to "bid out the butler". Maybe it is best to avoid auctions when you see bid-butlers in use.
Of course, It's really best to avoid using Swoopo altogether.

rachel (authentic) on july 12th, 2009 at 18:24:56:

swoopo looks so so so tempting!!!
the technique you mentioned is the technique i was thinking of trying - but reading your article i see why it wouldn't work. thank you for your insight, creativity and work. seeing the data really brings everything home.
also, you're pretty cute too:)

Joe (not authenticated) on july 14th, 2009 at 07:17:49:

What about several bots that would collude?
You create 10 bots with 10 different accounts that communicate with each other. They would monitor the bidding until it got down to 1 or 2 bidders. It would send bids from all 10 bots to give the impression of high demand. You could do this for 2 or 3 more cycles and see if other bidders dropped out of frustration. Then stop all bots from bidding (assuming one bot holds the highest bid).
You are only allowed one account per house, but you can get a few friends to go in on it. It is more expensive per bid $7.50, but could "control" the market.

Karl (not authenticated) on august 3rd, 2009 at 20:03:17:

I've been using (playing) Swoopo a lot lately and have gained some basic insights - although it MAY be a scam, I don't think it is, for the simple reason that they're raking it in even without scamming, and if they ARE scamming and it ever got leaked, their entire business would implode. So why risk the scam?

However, there is definitely (imo) some server-induced lag - I have a rock-solid fiberoptic connection and get multi-second hangs just like he mentions. The reason for this is probably to prevent enterprising young coders from using scripts to game the system by always doing 1-second bids. It's correct that this server-induced lag, up to 5 seconds or so at random intervals, favors bidbutlers since they are server-side, but it's not a foregone conclusion. Bidbutlers win about 75% of the time but the players using them also shell out far more bids. If you hate the idea of bidbutlers, do nailbiter auctions only.

jeremy (not authenticated) on september 4th, 2009 at 09:35:38:

But if you lose an auction, you can apply all your lost bids towards purchasing the item, so there really is no risk here. If you win an auction, you get a killer price. If you lose an auction, you get the item for normal market price. Not a scam. Not gambling. It may be hard to win. But it is impossible to lose.

joshua (authentic) on september 4th, 2009 at 09:41:05:

i think you are referring to this new "swoop it now" auction style that must have been created after i last looked at the site. when i wrote these, that auction style was not implemented and whatever you spent on bids could not be recovered.

Jack (not authenticated) on september 5th, 2009 at 13:27:55:

Yea, now when you bidding a lot trying to win an item you're actually marrying their "killer price" aka MSRP. You already spent the difference between the MSRP and the deal on, let's say, Amazon - so why not buy it from swoopo anyway?! like Jeremey [from Swoopo] said - Can't lose!

Keith Shannon (authentic) on november 4th, 2009 at 16:38:32:

My theory is that they bid on their own products and intentionally cause that "freeze" that you see on the 3 or 4 second mark. I was playing around with Swoopo after my fiancee just discovered it a few days ago.

Think of the money swoopo would make if very few people actually won the auctions. If they won their own auctions by bidding and causing a "delay" in the traffic coming into their site then they could win guaranteed and no one would be the wiser. There have been so many times that I was bidding and I knew the auction was getting close to ending and I was actually gonna get an amazing deal. Using only 10 bids or so on a $200 item, with a sale price of about 15-20. Since a lot of times they lock out new comers I'll place one bid in the beginning then I would look at my charts of data I had gathered. It was the average sale price for a certain time of day on a certain day on a certain item.

And what would happen when I was close to winning a COMPLETELY new user would jump in... Place 1 bid, the system would lock and they would win. The moment I saw the counter freeze I would be clicking the bid button. And what really made me start to wonder is that during this bid "lockout" I could still bid on a different product.

I think swoopo is winning their own auctions so they can just re-list the item without selling it. Do you have any idea how this can be proven??

Also I was thinking a way to win (all though not legal) was let the auction go for a little bit. And right after a bid butler war had gone on adding a few minutes to the timer wait until the timer gets back to about 30 (people won't do the single bids until 5 seconds or so) then place your bid putting you as # one then unleash a DoS attack making it so no one else could place a bid. Because all the bid butler bids are gone and if there are anymore they are set to trigger at a different price range. I dunno if that would work but it sounds pretty reasonable to me.

Loved your article.. Great work with an amazing program like greasemonkey. Lemme know what you think about my post please.

iwononswoopo (not authenticated) on november 8th, 2009 at 03:21:50:

do you know if your greasemonkey script still works? i've been on the site with it, and it doesn't seem to be working...just for you doubters, i HAVE one a laptop on swoopo, so i really don't think it's a scam.

good work though :)

joshua (authentic) on november 8th, 2009 at 07:37:31:

i haven't used it since i wrote these articles, so i'm not sure whether it still works. if swoopo changed any of the html output on the auction pages, the greasemonkey script may need to be updated.

max (authentic) on november 15th, 2009 at 06:57:48:

there used to be a lowest unique bid auction system around.

greasemonkey can game some of them

Foam (authentic) on january 3rd, 2010 at 21:29:32:

It is also not working for me. I checked the html vs the code and it all looks ok, but there is no output in the div. I will try fix it and post the changes if I do.

joshua (authentic) on january 4th, 2010 at 01:58:13:

i just added some code to it to make it more clear when it's disabling itself because it can't find the proper code and html. if you are not logged in, it will not work. i just tried it on swoopo and it is logging data in the div for me.

n00854180t (not authenticated) on november 16th, 2009 at 21:55:02:

After looking at Swoopo some I figured the only way to win would be to use a bot system as attempted here, but quickly came to the conclusion that the BidButler thing would almost certainly have the advantage.

What I am curious about is if anyone has any data on the number of "auctions" that actually meet the "will end at the latest on" date, and if it would be effective simply set up a program that would activate either/or a BidButler or a manual bid at a precisely timed moment approaching the end of the "auction" at <1s (my thinking was that it would be best to do some tracerts at different times of day into a table, then use that to figure out the delay to get to the server (and possibly also try to figure out the delay for the server to actually process the POST that you sent)).

All in all though it seems like the better method of doing this stuff would be to simply write a Swoopo-esque system for Facebook, or something. Assuming one is evil enough to actually do so with a clear conscience. Swoopo certainly does seem to prey on the math-challenged.

Offshore (authentic) on january 5th, 2010 at 18:39:56:

Hi joshua..
i wish you a happy new year.
There is a little platform like swoopo, where I think it is much easier to play it :-).
And your are the one with the skills.
Can you please contact me via e-mail?
I tell you more.

Chester (not authenticated) on april 7th, 2010 at 23:03:17:

Interesting article.
I just checked out the swoopo website because my friend introduced it to me.
An ipad went for $4.49
Swoopo lost money on that one.

I don't think I'll ever try it, but I like watching the bids.

MacAttack (authentic) on january 19th, 2011 at 11:29:29:

Hello, I was woundering where I could get more info about how you saved the information on your server. You see after the auction is over, all the data is gone cleared from the box. So I have setup my localhost apache server.... now what?

Thanks in advanced,

hey (not authenticated) on march 10th, 2011 at 14:33:19:

hey. I'm from Korea, and lately there have been a ton of similar penny auction sites over here. I did the EXACT same strategy you did, obtaining a client-side time of the timer. Here, the CLOCK actually skips a second every time randomly. It is completely unpredictable, and there is no way that you can beat it. So if I set the script to bid at one second, there are times when it skips from 2 seconds to 0 seconds and I lose the bid. I can't set it to 2 seconds because that would cost me a lot of money in bids as well. I even tried the manual sleep() function, but that didn't work out well either. I ended up losing 200 bucks before I gave up. Your article is the EXACT same scenario i went through LOL! I never knew that the auto-bidders would be the ones who were to win, because in the site I used, the autobidders only seemed to bid at 7~8 seconds, which was very easy for me to beat out. But in other sites, i see auto bidders bidding at 0~1 seconds, and i'm afraid it would be impossible to beat them without using more money than them. I even get the thought that certain people connected to the site are getting unlimited amounts of bids just so that they can lure unsuspecting fools like us to bid even more and waste even more money. Anyways, the whole thing is a sham, and it can't be beat.

Rick (authentic) on march 24th, 2011 at 14:43:35:

Thanks for all your hard work Josua!! I recently tried it out and saw what you saw first hand as a manual bidder...alot of other shady things happen on the site..relaod the page and the actuion you are watching moves to another page or just disappears..items disappear as soon as its over so you cant tell who won,they have even removed the option for me to put an item on a watch list after sending them some emails questioning their legitimacy.the bid history wont show how many bids a user has made..there is no way to contact other users... Quibids is a SCAM. (authentic) on november 5th, 2012 at 08:21:16:

I spent a max of about $30 on a similar site before I realized it was a complete waste of time and money and have never looked back. I came across this article however and one thought came to mind to try, although I doubt it'd really help much in the long run since these sites are designed to make them money, exactly like gambling ... but you could try adding a ping server routine nto your GM script, to ping the bid sites' server during bids to help calculate how much ahead of time you should place your last 1 second bid, to (hopefully) overcome the lag advantage the bitbutlers have.