It seems that payment processing is the biggest issue here. People are very reluctant (rightfully so) to give up their financial information, so I think it is a good idea to start with an existing service like PayPal or amazon FPS. Next, I would select frameworks based on the development environment you're most familiar with. I might choose java/spring/hibernate/struts2 or even raw jdbc and servlets because I've spent so long in the java world, but many in this community would probably lean towards RoR or similar. I think it's almost always easier to go with what you know.
Implement some sort of secured cryptographic identity for members that is tied to a phone number and a personal presence at a given place and time (stop by any $foo to use our automated signup kiosk and receive your free picture ID membership card) this would vastly reduce opportunities for fraud.
...this would vastly reduce opportunities for fraud.
And vastly diminish your traffic, which in turn diminishes the universe of potential buyers, which probably results in lower sale prices for goods on your site relative to other sites. Particularly since even an "automated" signup kiosk will increase the cost of a transaction in a way that needs to be passed on in the form of higher fees.
I do like the idea, though. There might be some application where it's worthwhile.
One trick is to see if you can leverage some sort of existing "automated signup kiosk". If only you could, say, ask someone to authenticate by making a transaction at one of several specific local ATM machines, and then query the banks to make sure that transaction is made...
If it could be tied into the DMV/Post Office/National ID card that would be the best. As it is there are a number of retailers that implement something similar; Costco for instance has a memberID card that has a lowrez photo on the back.
Joining an existing ID system to a PKCS used with the website would be relatively straightforward.
Your point about it reducing the universe of available buyers is true up to a point the variable there is the value of the goods being traded. Confirmed trustworthy identities aren't important if you're selling relatively low value goods, but if you're buying and selling cars, houses or industrial goods it suddenly becomes much more attractive to reduce the pool of buyers to those to on whom some due diligence has already been performed. As always; risk carries a premium.
The basic problem of course is that our current monetary system is not well suited to todays internet.
Perhaps you could do something similar by having the person transfer a very small amount into the websites bank account - just a few cents, then link that transaction to their website user account --- you should be able to query banks on who owns the bank account if the owner of the web account does something dodgy.
You could achieve the same effect by mailing a confirmation number via snail-mail. This would not fix one of the fraud problems - the hijacking of valid accounts in good standing. It would only affect fraudsters psychologically, as the police would generally be unwilling to deal with crimes of less than $3000.
For a start I would actually try and do something different from eBay initially just to offer USP/differentiation.
However, assuming you want to create an eBay for use in your own site/society/community and competing with eBay is a non-issue, I would do it in the tools that allow building as easily and quickly as possible.
I would use python/django because of simplicity in code style and they are good opensource frameworks for building web apps that incorporate many good paradigms. Others may prefer what is in thier skillset e.g. RoR/.NET/PHP, but that is preference... the auctomatic guys started building in common lisp.
My approach would be KISS, working on the core essence i.e. an auctioning engine, and building iteratively there upon. I would also initially start by looking at what is broken in eBay and what people generally complain about and try to incorporate the learning into my roadmap but still focusing on the core competencies first.
I did something very similar a couple years ago. Details are covered by an NDA, but the software stack consisted of SBCL, TBNL (now Hunchentoot), CLSQL, CL-WHO, PostgeSQL and a few other random libraries. The archetecture was informally MVC.
