Hello Isis,

I need to read through what you are proposing a couple more times before I completely get it but it comes over much more "bitcoin-ey" than before which I think will make it easier to implement.

One thing I wanted to clarify - currently MultiBit is not a full node so it only uses the user-agent when it connects to a Satoshi node. It does not currently announce itself as a peer as it cannot accept incoming requests for anything.

Were you planning to add (Open Pay) transaction relaying ?
Matt Corallo has been working on getting bitcoinj closer to a fully validating node so you might want to talk to him (if you have not already done implemented it) as I would expect he would be beefing up the networking of bitcoinj in this area.

It still would not be a validating peer so I do not think it could announce itself as such without messing up other users.

Also, am I right in thinking that the card reader can send out multiple requests for the same amount of BTC (either maliciously or by design) ? Previously the private key was on the card and the card signed it but is now the backend MultiBit doing the actual signing ?
That changes the potential attack vectors quite a lot as previously if the card was not in a device there was no way the private key could sign anything. If the backend MultiBit is sitting connected to the network 100% of the time listening for relevant OpenPay transactions its attack surface is much higher.

Hope those questions make sense.

:-)