As I said before, I think you have done this new thread just for proposing a permanent nonce address instead of an ephemeral sender’s nonce, because otherwise I do not see any difference with what was proposed. I would have loved that this variation would work. Unfortunately it is unsecure as is.
Bob receives some coins from Alice, using partial signature s1_b = z + b + e_1.x_1 (1)
Bob builds an unique output for this transaction with blinding factor r. We have r = offset_1 + x_1 (2).
Bob then uses this output to send it back (with no change output) to Alice or a party colliding with Alice. Using his permanent address B = b.B. His partial signature for this second transaction is s2_b = b + e_2.x_2 (3).
We also have -r = offset_2 + x_2 (4).
"e_1.(2) - e_2.(4)" gives: r.(e_1 + e_2) = e_1.offset_1 - e_2.offset_2 + (e_1.x_1 - e_2.x_2) (5).
(1) - (3) gives: s1_b - s2_b = z + b + e_1.x_1 - (b + e_2.x_2) = z + (e_1.x_1 - e_2.x_2) ie: (e_1.x_1 - e_2.x_2) = s1_b - s2_b - z (6).
Substituting (6) in (5) yields:
r.(e_1 + e_2) = e_1.offset_1 - e_2.offset_2 + s1_b - s2_b - z, i.e
r = (e_1.offset_1 - e_2.offset_2 + s1_b - s2_b - z).(e_1 + e_2)^(-1).
That’s the kind of funny thing you can get with permanent nonces. I strongly refrain from trying to use a permenant receiving-only nonce and a permanent sending-only nonce as well. Just use an ephemeral sender’s nonce as I suggested first long time ago. The same is true for my new scheme [1] (this attack would still apply).