Are you still working on this dansmith?
Not development-wise. I simply put out the idea. After I discovered that "colored coins" will get us faster to a decentralized exchange, as opposed to SSL dumps which is a temporary crutch, I am totally immersed with colored coins.
Can colored coins address this fiat transfer problem in any way? My rudimentary understanding is that it's a way of using coins to represent property. I can't see how it would help with the problem being discussed in this thread?
(First let me define the terms. The person who will be selected from a P2P group should not be called "escrow agent", but rather should be called "the gateway user". The gateway user works on behalf of the escrow agent. The gateway user will submit SSL logs to the escrow agent when the banking session is finished.)
OK, that's another model. I can see why it might be preferable. Not sure, but it's not a critical issue either way.
Yes, if it is randomly chosen from a p2p group, then it will fly.
The caveat is that eventually the same member of the p2p group will be chosen multiple times. The bank may flag such a member as a potential participant in a p2p exchange.
Yes, but to me that's the essential ingenuity of the P2P aspect; as the network grows it becomes more and more impossible for the bank to find anything to attack (no CPOF etc etc). I don't see a negative here, only a positive.
Another caveat is that altruistic bitcoiners will not subscribe to be added to a pool of potential proxies unless they have an incentive. The incentive will be that those who add themselves to the pool are themselves participants in a p2p exchange. But again, there may not be a significant amount of participants and so the participants will be proxying bank sessions many times a day which will get them flagged by the bank.
Quite, incentive is key. The software can help us provide the appropriate incentive.
EDIT: to answer your point more fully, your "gateway user" could be anyone on the network, and your "escrow agent" could be a special class of user (that little bit of quasi-centralization might be safer if thus abstracted from the direct bank connection).
And in that version (#2) how exactly would a user spoof the bank's side of the connection? I get that they have the master key to encrypt data, but if the escrow is sending requests to the bank IP, surely the response has to come from there too?
Correct me if I misunderstood what you are asking.
with #2 spoofing of the bank-side traffic by the payer is impossible indeed. The escrow receives the traffic from the bank.
With your p2p pool idea though, if the payer and the gateway user are in cahoots, then the user can give the gateway user the encryption key. Then the gateway user can spoof the SSL dumps as if they were coming from the bank and submit those spoofed dumps to the escrow agent.
Feel free to ask for further clarification.
This doesn't look like a problem realistically.
If the gateway user (in your terminology) is not chosen by each counterparty in the transaction, but by the P2P software, there is no realistic chance of collusion. (Any escrow model is of course broken if the escrow is colluding with one side of the transaction.)
I'm feeling more and more positive about the feasibility of this, *except* that from a technical standpoint it's really pretty complex.