10:39:11 <selsta> 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?
10:59:11 <ErCiccione[m]> That would definitely give better UX. if there are no security downsides, +1 from me.
11:00:00 <moneromooo> IIRC smooth was definitely against lowering it without careful prior consideration.
11:00:32 <moneromooo> The downside is that anyone using a recent output gets their tx invalidated if there is a reorg past it.
11:00:57 <moneromooo> This means they cannot be mined again in the new chain (unless that new chain happens to allocate them the same output index).
11:01:30 <moneromooo> A way out of this is to make txes refer to output pubkeys rather than output indices. Larger txes.
11:01:56 <moneromooo> ie, 32 bytes per input instead of ~2.
11:02:20 <moneromooo> For ring size 11 and 2 outs, that's an extra 30*22 == 660 bytes.
11:02:44 <selsta> Extra 660 bytes but we could remove the lock altogether or only reduce it?
11:03:15 <moneromooo> As far as the invalidation thing is concerned, remove it. There might be other considerations I'm forgetting.
11:04:24 <moneromooo> It might be possible to get clever and refer to outputs by the first 16 bytes of their pubkey, say.
11:04:50 <moneromooo> In case of collision, the tx would become invalid.
11:04:58 <moneromooo> Or maybe try all actually.
11:05:08 <moneromooo> In this case, only 8 bytes ought to do.
11:05:16 <moneromooo> 175 bytes.
11:05:25 <moneromooo> Adds some complexity in tx verification.
11:05:46 <selsta> A lot of people hate the 10 block lock so this might be an interesting research topic.
11:05:47 <moneromooo> I am assuming that there'd be no slowdown in LMDB lookup here.
11:05:59 <selsta> 175 bytes but no verification increase?
11:06:25 <moneromooo> 165, I got the calc wrong.
11:06:31 <selsta> Usually size is not too much of a problem.
11:06:46 <moneromooo> It's in the unprunable part too.
11:07:14 <moneromooo> It's also incompatible with procedural ring generation.
11:07:23 <moneromooo> (at first glance)
11:08:49 <selsta> Also if we have ring size 32 / 64 with Triptych things would also get large...
11:09:06 <selsta> (not sure what procedural ring generation is)
11:09:24 <moneromooo> Creating rings with a formula rather than an explicit list.
12:44:11 <gingeropolous> it also provides protection against massive reorgs due to network isolation stuffs
12:44:23 <gingeropolous> well, not protection. but robustness
12:51:48 <gingeropolous> 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.