Anyways, you're asking for attacks on only the Bitcoin side of your idea (which is not the weak part) - in essence you want us to break multisig. Imho the weakness of your protocol is not the stuff that happens on the block chain, it's what happens besides that.
Also your announces are not signed, you should include that as a step (Alice could list ANY transaction on the chain as "hers" and Bob might tie up funds because of that). The TXID of the escrow TX is only final once it has been mined and buried a few blocks - so adding that to the protocol might be a wise thing to do. Again these messages need to be clearsigned by their private key at least.
You can wait until its out and then scam people if you like. I was just asking for help of people who like to support.
I described above the limited scope of that attack test. I think that part is not only to break btc multisig, that is pretty clear that nobody will break that, but there could be some other flaws in the protocol or usage of some rpc commands.
The double spend attack scenario when Alice has published the deposit tx is described in the paper (it was recently added).
The communication between the peer is done via bitmessage (or twister) so thats a secure channel already.
Regarding the offer: Yes Alice need to sign her msg, so Bob can verify with her pub key. I will add that to the paper, thanks for pointing to that.