I wrote that before the 15%.

The other two points are good. Especially the first one; since they could take anything, it's a particularly good point.

The third one is not as clear cut, but definitely to be considered.

Good qualifications but I don't see how it equates to "No". I trust myself to keep a private key safe for a short period. And giving it back wasn't hard either, as has been demonstrated now.

'Wrong' was oversimplified on my part, though I stand by it.

What I was thinking about more was the risk. Taking a big chunk (as apparently they now have done) unilaterally puts them firmly in the criminal category from a legal perspective. IANAL but I think they could have very reasonably and ethically argued that they did not steal, if they hadn't done that.. Now, they cannot. Of course if their opsec is tight, they may avoid the consequence, but that's another Q.

Yes, that's what's happening. They're finding a way to return that bitcoin safely to control of the 11/15 federation multisig (if they're honest). Which they could do immediately *if* the signatories didn't have infrastructure that automatically sends it out on any "valid" Liquid transaction that has a peg-out.

So yeah if Liquid is currently 100% shutdown then it'd be safe to send, even without a bugfix. Maybe that's your point.

I don't know if the blockchain is totally or partly shutdown right now.

Yes, people should definitely be spooked! Not saying "definitely the guy has good intentions ".

...But them saying 'I'll send *most* of it back' instead of negotiating a bounty separately, is wrong.

I mean technically you're 100% right. But you can still argue that swiping it the second you realize you can, is the more correct choice.

I should really show the follow up paragraph:

"While I'm not the King of Monero, I am frustrated my approval was given to a PR on a faulty premise. I'm trying to funnel this frustration into not having to worry about this anymore. Yes, serializing the entire TX is overkill. That's the point. It may be less efficient. This offers a 5x perf boost. I'd rather hear we left .1x on the table than hear we had a double spend in the next release."

I hope more developers of bitcoin security code don't feel bad about "overkill", either!

A comment by Luke Parker (guy who's the main author of FCMP stuff) struck me on a PR to introduce such a verification cache:

"We could just serialize key images, and fix that issue. I suggested in #8707. The problem is how it's been pointed out there's yet another field with this behavior. I don't want to play cat and mouse forever. The TX's entire networked value, and the mix ring (via do_serialize and as tested by @jeffro256 ) is complete. **Considering this code disables almost every single line of meaningful TX validation code**, I'm not willing to settle for less anymore."
(emphasis mine).

Why the heck wouldn't they belt and suspenders with the transaction hash?

(They could also just not cache, full stop. Better choice for Liquid specifically imo, but easy to say in retrospect).