Currently outputs get locked for 10 blocks. If I remember correctly moneromooo mentioned in the past the we could reduce this to 7. Is this the possible?

That would definitely give better UX. if there are no security downsides, +1 from me.

IIRC smooth was definitely against lowering it without careful prior consideration.

The downside is that anyone using a recent output gets their tx invalidated if there is a reorg past it.

This means they cannot be mined again in the new chain (unless that new chain happens to allocate them the same output index).

A way out of this is to make txes refer to output pubkeys rather than output indices. Larger txes.

ie, 32 bytes per input instead of ~2.

For ring size 11 and 2 outs, that's an extra 30*22 == 660 bytes.

Extra 660 bytes but we could remove the lock altogether or only reduce it?

As far as the invalidation thing is concerned, remove it. There might be other considerations I'm forgetting.

It might be possible to get clever and refer to outputs by the first 16 bytes of their pubkey, say.

In case of collision, the tx would become invalid.

Or maybe try all actually.

In this case, only 8 bytes ought to do.

175 bytes.

Adds some complexity in tx verification.

A lot of people hate the 10 block lock so this might be an interesting research topic.

I am assuming that there'd be no slowdown in LMDB lookup here.

175 bytes but no verification increase?

165, I got the calc wrong.

Usually size is not too much of a problem.

It's in the unprunable part too.

It's also incompatible with procedural ring generation.

(at first glance)

Also if we have ring size 32 / 64 with Triptych things would also get large...

(not sure what procedural ring generation is)

Creating rings with a formula rather than an explicit list.

it also provides protection against massive reorgs due to network isolation stuffs

well, not protection. but robustness

i think thats the more useful and valuable output of such a rework. the 10 block lock - maybe it gets reduced, but afaiui that allows for the output to bake a bit in the chain. perhaps the output selection distribution would need tweaking along with increased ringsize.