First of, thanks again for looking into this. Much appreciated.
you seemed to imply the lockbox signature mismatch issue could happen in any lockbox (I think you claimed to have produce it with a fresh lockbox).
Sorry, no - I've never tested it with a fresh lockbox. The lockbox worked fine for over a year and the issue is a relatively fresh discovery.
1) Can you create fresh lockboxes that display this bug using the current state of the testing branch? Please do this on the testnet. If you need testnet coins, post your address here, I'll send you some.
I've never tried anything on testnet, but I'll certainly put the time and energy to do that now. I'll post a funding address when I figure out how to setup the needed environment.
2) If yes, is the issue with SegWit lockboxes only? This thread seems to imply that. I do not remember testing specifically for lockboxes back in August, this could be a key factor.
I've had plenty of lockboxes usage (still do), but this one is the only one that got this behavior, and the only one involving segwit as a second funding address (due to an oversight, actually. I had the 'Segwit' checkbox checked by mistake). Took me a while to single that out, but causality-wise, I think it is highly probable that it is tied to the segwit address. You writing that you did not test for that scenario only raises that probability. But we'll know soon enough once I learn how to setup and run testnet environment.
3) If you manage to reproduce this on testnet lockboxes, I would like to see those.
Of course I'll share all findings.
But if I won't be able to reproduce it, I would very much appreciate your help going through the steps with the lockbox I've sent.
You will get stuck in the signature collection phase, not the broadcasting phase, it can be seen with any offline signer that imports the two parties keys I've sent, so I cannot possibly see how that risks any funds. I've made the video using the testing branch built in a unix env that didn't even have a bitcoin node build.