12:34:27 Hi everyone, just curious if the implementation of FCMP++ could potentially lead to improvements or modifications to the 10-block time lock? If so, is there anywhere I could find discussion related to this? Cheers. 12:37:22 From Ruckniums open research item list https://github.com/monero-project/research-lab/issues/94 12:57:02 johnfoss68: AFAIK, no. Arguably makes it worse since txs are guaranteed to have referenced the most recent available outputs instead of having some low probability of doing so: https://github.com/monero-project/research-lab/issues/100#issuecomment-1608082485 12:58:26 Given some security model, it is possible that a lower lock time would be better. But that's a question of probability of re-org, malicious behavior, etc.: https://github.com/monero-project/research-lab/issues/102 https://github.com/monero-project/research-lab/issues/95 13:07:28 Erm, to the "arguably makes it worse" comment would refer to a proposal to reference recent ring members by output public key instead of confirmed-on-the-chain index. Then a re-org deeper than the N block lock would not necessarily invalidate txs with rings constructed in such a manner. 14:43:44 I asked kaya, and kaya said no. Different set of risks 14:43:47 Thanks guys. And thanks for all your hard work on Monero! 14:44:29 >The aspects of what would happen if it was removed change with FCMP(++)s, yet it still makes sense to have. 14:44:31 > Thankfully, pocket change is no longer such a privacy issue and some payment channel designs open up. 16:23:44 Has there been any payment channel designs worked on ? I must have seen 3 different paper on MRL repo 16:24:13 I also remember some people saying Tari was one, but im doubtful 16:33:29 I'd again argue the n-block lock duration should be the same n recommended to exchanges for effective finality on payments. 16:34:59 Tari is not one and no one has actually worked on any AFAIK. All enabled designs still rely on PoW puzzles AFAIK which are a mess.