A few days back, Hive account@biophil wrote a post "The first 5 days of the EOS token sale will be unfair. Here's how to fix it" describing similar objections to those I found with the upcoming EOS Token Sale on Ethereum. In his own words, this was one of his main contentions:

Bob cannot be sure that he'll pay less than his maximum price. It's mathematically impossible for him to be sure. The only way he'd know for sure is if he could somehow wait until after everybody else has bid, check to make sure that the implied price is below his max, and then decide whether to contribute.

The only way Bob can protect himself is to contribute less than he'd like to. So a side-effect of this auction format is that people should self-limit their contributions to mitigate the pricing uncertainty. I don't know how much FOMO will counteract this.

At first, Dan's response was the following:

Unfortunately ethereum cannot implement this algorithm due to gas constraints and lack of sorted database.

However, this didn't quite sit right with me. Now, granted I'm not well versed in Solidity or ERC20 tokens (though perhaps, a bit better now after research more about it the past few days). But my first response to this was as follows:

This example by Vitalik Buterin is from 2014, but he does show an implementation of a generic quicksort algorithm that can sort object pairs. Now, I'm not sure of the "gas constraints" involved, but with a sorted object pair it should be relatively straightforward to sort by "limit price", "database ID".

For added utility, we will make our sorting function generic: we will sort pairs instead of integers. Thus, for examples, [30, 1, 90, 2, 70, 3, 50, 4] would become [ 30, 1, 50, 4, 70, 3, 90, 2 ]. Using this function, one can sort a list containing any kind of object simply by making an array of pairs where the first number is the key to sort by and the second number is a pointer to the object in parent memory or storage.

Link: Advanced Contract Programming Example: SchellingCoin
Link: GitHub SchellingCoin implementation from Ethereum Repo

I admit I'm not well-versed in EC20 contracts or serpent/solidity, but technically, shouldn't we also be able to see all the current bidders and make an outside calculation of what the expected price would be before the window closes? If so, even better if someone could "cancel their order" before the window closes if they are displeased with the expected closing price.

Even this didn't quite seem to be the best approach, not to mention it was an old post from back in 2014. It seems most contracts are now fully written in solidity, and that code was in serpent,.

After even more research, I came across these terrific resources on writing contracts for Ethereum:

Link: Solidity by Example, with great examples, including ones for Voting and for Open Auctions

Excellent Video Tutorials by Will Warren and Jordan Leigh...

This first video is good for newbies just dipping their toes into the Ethereum / Solidity world.

Introduction to Ethereum Smart Contract Development with Solidity (Part 1):

If you already have a background in Solidity, you may prefer to jump straight to the second video, where the real "meat" lies.

Introduction to Ethereum Smart Contract Development with Solidity (Part 2):

Okay Great... So get to the GOSH DARN Point!

Well, as I was doing this "research", I went back to visit the ERC20 code for the EOS Ethereum Contract to better understand what was going on, at which point I noticed a recent Pull Request that's being evaluated: buyWithLimit!

So it seems the EOS team was in the process of trying to add that "functionality" after all! More interestingly, is that they seem to have come to the same conclusion I had after watching the videos linked above. Using Solidity's "mapping" and "memory" functionality were probably the best "tricks" to help get there. And perhaps even more importantly, to "get there" in a relatively efficient manner without blowing too much Ethereum "gas" in the process.

With that functionality underway, it also shouldn't be that much more of a stretch to allow bidders to update their bids, as well as cancel their orders in the "daily pool" altogether if necessary.

For those interested in "diving in deeper" into the proposed changes and updates, here is the link to the github pull request.

Link: EOS-Token-Sale github Pull Request: test buyWithLimit

Cheers, and as always (WOW, to all 600+ of you!!), I appreciate your upvote, your follow and all your comments!

UPDATE: Hive account@eosio responded in the comments: "The limit only applies to the total received plus your funds; however, if others add after you the limit does not protect you." For more details, check the full thread in the comments below!