Hi @olkurbatov . Thanks for the very substantive read and analysis! You had two distinct points, I’ll address the first one now and read the second one later.
You’re right - and funnily enough, it’s already in the code 
I just forgot that the protocol sequence in the paper is stale.
You’re also right that it’s really quite a big deal. The best thing about it is it (mostly) skips something I always disliked, and which I like to call “cross-block interactivity” (it’s the main reason swaps are harder for both devs and users, than coinjoins). In a nutshell we should (and do in the code repo, see setup.rs) prepare the whole tx graph, and also then have Alice prove a useful \sigma'_{A,P} so that Bob’s position is: OK, if I send a co-signature on the Payout and the Funding now, my only risk is that Alice broadcasts funding, putting the coins in U_1, and then walks away - and for that I need the RefundTx signature which she provided upfront.
So you still get the possibility of backout, but it’s a much less likely case than if you have both sides waiting half an hour and having to be online and talking, to avoid an unwanted fallback.
The remaining detail is CooperativeOverlayTx; for that, we need Alice to send Bob t out of band in case he lost (something she is only safe to do after PayoutTx edit: FundingTx confirms), so for that part we still need to be able to send a message post-confirmation (that’s if Bob loses; if Bob wins, it’s completely unnecessary, which is cool). (But to be clear you already said this! I’m just trying to make sure it’s clear both to me and other readers).
I’ll update the paper (but not the code ) with this correction, thank you for spotting it. Will answer the second idea later.