1. the bank may frown upon the payer logging into his bank from random IPs. But we discussed this earlier and it seems not to be a serious weakness.
2. The payer can flood the p2p pool from which the gateway users get selected by his accomplices. If the payer and gateway user are in cahoots, they can spoof the whole SSL session.
3. To mitigate #2, the gateway user should be the beneficiary of the payment. (The beneficiary has no interest to defraud himself), which leads to ...
4. If the beneficiary is the gateway user and over time has a lot of those who pay him, the bank will flag the beneficiary's IP because there will be many users of that bank logging into their accounts from the same IP.
The problem which you describe in #2 applies also to the selection of the escrow agent. How would you make sure that the escrow agent is really a third party and not in cahoots with either the seller or buyer? Probably by some mechanism to randomly choose the escrow. So if it works there, why not use the same mechanism for the gateway? So I would say your point #3 doesn't make sense, especially if you think about the problem that they both have to be online at the same time it is better to select a random user from the pool?
The only risk left once we move to the model I describe in post 61 is the collusion between the escrow and either the buyer or the seller. This is mitigated by (a)random choice, possibly more than once and (b) prevention of Sybil attack by cost of identity creation.
Would you not agree that this has all been covered in posts 65 and 67-71?