<elongated:matrix.org> Will proof of reserves be possible after fcmp++ ?

I appreciate that. The problem with text is that tone is lost, so it's difficult to determine which of the dozen different intonations the same text might be carrying.

I'm still not grokking whether you think the KES is an absurd idea, or what. So I'm having some trouble identifying what to hone in on to try and clarify, or alterantively understand where the absurdity lies.

So as you know, the KES holds an (encrypted) adapter signature offset for the initial channel state for each party. If we put aside the issue that kayaba pointed out around securing the decryption key in a trustless/trust-minimized manner, then I'm of the belief that the design of Grease+KES is sound. This design includes the understanding that either channel party can claim,

without proof, at any time, that the counterparty has become unresponsive. The KES will then release the counterparty's adaptor signature offset after the dispute window closes (say 24 hours, or 720 blocks, or whatever). The claimant can then close the channel using any state the channel has been in in its history. On the other hand the defendant (counterparty) can submit a channel

signature with a more recent state within the dispute window, in which case the KES will release the claimant's adapter sig offset to the defendant. It's a pretty straightforward design, and while not perfect, fells wholly sufficient for the types of applications payment channels are meant to address.

So kayaba, I guess I'm asking, putting the decryption key issue aside, do you have any issues with this part of Grease's design?

<kayabanerve:matrix.org> The absurdity lies in any discussion re: iO. The above description of unidirectional channels doesn't sound problematic, but actually instantiating the KES does.

<kayabanerve:matrix.org> As a weird sketch, if you could have a time service which publishes the output of a PRF every epoch, but allows you to calculate or otherwise reveals a commitment to the output of the PRF in advance, that could be an interesting KES.

<kayabanerve:matrix.org> For Alice -> Bob, where Bob is expected to close and Alice to force-close, you can have Bob send Alice a proof the key was verifiably encrypted to the PRF commitment (such as 256 ElGamal ciphertexts, each for a single bit). Here, the KES is actually unaware they're performing this role.

<kayabanerve:matrix.org> But when the PRF output is revealed, anyone can decrypt those ciphertexts, and Alice can recover the necessary key to force close.

<kayabanerve:matrix.org> Something like Serai, if Serai revealed the threshold signing key it historically used at the end of each session, would work to that end _if_ Serai had a sufficiently consistent schedule.

<kayabanerve:matrix.org> It still had the trust assumption about the lack of collusion. It just allows a decentralized network to be the KES while being unaware, unless informed, of their role and having minimal overhead to fulfill such a role.

<kayabanerve:matrix.org> I'm unsure if any platform has a week-long PRF commit/reveal scheme that could be hijacked to this end.

<reedmarin:unredacted.org> Pardon the intrusion. As far as I understand, the plan for Monero development in the short-to-medium term is:

<reedmarin:unredacted.org> 1. FCMP++

<reedmarin:unredacted.org> 2. Post-quantumWith that in mind, I was wondering if there are any plans to deal with the 10-block lock and slow node sync.This is fully anecdotal, but I've been observing the community for half a year, and it would seem that these two points are often brought up most often as pain-points when it comes to Monero usability. I s [... too long, see mrelay.p2pool.observer/e/xNjv-P0KNFhoTVVX ]

<sgp_> I would not say that the 10 block lock is "blocked" by PQ research. The challenge has been community consensus of picking a reasonable alternative option to allow faster finality

<sgp_> monero-project/research-lab #136

<sgp_> you can see of those options, a finality layer is the main option to reduce it. But there isn't consensus on adopting something like that