15:48:53 Any progress on checkpoints ? or is it in cold storage 16:00:13 it is still on the last update as last time. blocked by bugs on monero and these have not been able to be worked on 16:01:51 the other parts around it were built and tested, that's how this was discovered within testnet 16:10:14 IMHO, the appeal of using checkpoints was that the logic was already in the codebase and could be deployed quickly. With testing, it was discovered that the code logic was flawed (or at least, it was flawed when used as a rolling checkpoint). Therefore, it became less appealing. And less urgent when Qubic stopped disrupting the blockchain. 16:12:30 I understand it’s not urgent right now, but it should be worked upon to avoid major chain rollbacks of at least 10+ ones which can invalidate txs. 16:13:23 focus is on FCMP++ atm but it'd be even more important there afaik 16:13:44 maybe the long-term discussion can be reopened or mentioned at least? 16:39:41 I have a question about current view keys and key images. (Yes, this is sparked by the Reddit discussions on the topic.) Is there anything stopping you from getting the same information with the status quo view keys plus key images as with the Carrot Outgoing View keys (OVKs), just with a much worse UX? 16:39:54 Say that I am an employer and I want to monitor the management of my funds by my employee. My employee has the spend key, too. I ask my employee to give me the view key and the key image of every inbound output. Whenever one of those outputs is spent, I would know that it's spent because I see the view key appear on the blockchain. 16:40:04 If I get a change output in the spending tx (which I can see with the status quo view key), I request that my employee export the key image of the change output. Therefore, no funds are unaccounted for and I have a complete view of the wallet receipts and expenditures. My employee does not have any plausible deniability about [... too long, see https://mrelay.p2pool.observer/e/tLPMgN8KbUJKX05s ] 16:40:49 The employee cannot hide anything if these rules are enforced. I always see when the employee has taken action. 16:41:36 @rucknium:monero.social: If you are bound to your single wallet, regular selective disclosure (even if selecting everything that's happened so far) allows stopping disclosure in the future. 16:41:45 Just to play devil's advocate on the absurdity. 16:42:23 Now, obviously the employer would be able to notice this and have cause to fire the employee. 16:47:57 @kayabanerve:matrix.org: While you're here, do OVK improve the UX a lot for your FROST multisig protocol? Or would the OVK mostly just improve the "standard" Monero multisig? 16:50:44 @jeffro256:monero.social: With CARROT OVK, the actual address that you spent to is not detectable by the OVK, right? The actual address is saved in the wallet cache of the actual wallet that spent and would be lost if the cache is wiped, and unrecoverable if restoring from seed/keys? 17:00:23 @rucknium:monero.social: Serai doesn't require OVKs as it's explicitly modelled around verifiable fulfillment of intents rather than verifiable spending of outputs to verifiably fulfill intents. 17:01:05 The FROST part is relevant to the Spend-Auth proof, currently CLSAG and soon the GSP. The GSP is a Generalized Schnorr Protocol. FROST is for Schnorr signatures. 17:01:37 CLSAG's final response is still Schnorry, hence the existence of FROSTLASS, but the idea to use FROST with a GSP is much more straightforward. 17:02:53 FROSTLASS does create and prove the key image though in its first round. With the explicit OVK, it is solely proven for, and that arguably simplifies things a bit? The fact that you know key images beginning transaction construction, not only midway through? 17:03:21 But it's largely about the UX improvements than any cryptographic benefits. All flows I did avoid this problem. 17:03:40 Though new wallets have a more efficient multisig protocol. It's like, three elements instead of four. 17:03:56 (so marginal, but still pleasant) 17:05:38 Do OVKs reduce the number of communication rounds for multisig at all? Would you have to write less code from scratch for an application that uses multisig if OVK exist? 17:13:48 Rucknium, we use two rounds. 17:13:55 That's effectively optimal. 17:14:21 :( when you use an effectively-optimal round count and Rucknium asks about reducing them :( 17:14:44 I already had an academic breakthrough when I published on 2-round threshold ECDSA, as I presented at ACM CCS 17:14:50 When will it be enough for you :((( 17:16:45 You do need clever TX construction when you don't have OVKs. specifically, featured addresses (my own proposal that didn't go anywhere) are immune to the burning bug via hashing the key images to the shared secret (the same technique CARROT uses). 17:16:45 That means deriving outputs requires knowing the key images. That means you have to defer TX construction to round two because you don't know the key images at the start, only after the first round of communication (as probing key images is a one-round protocol). 17:18:24 You may get better preprocessing with FCMP++? 17:18:24 FROST allows performing the first round, then later deciding the message signed. This allows you to do the first round whenever, and ideally, even independently of the key being signed with later. 17:18:24 I don't implement that for my CLSAG multisig code because the preprocess is output-specific. Because the first round proves for the key image of that output, the first round is only usable with that specific output. 17:19:13 But with OVKs, key images are now no longer part of the protocol. This would imply one can do a preprocess (the first round of the protocol, saved for usage as desired later) _without_ it being bound to a specific output. 17:20:41 This would mean when you create the multisig, you make 10,000 preprocesses, and then you scan outputs, and then when you finally decide to spend them, you only have to communicate once more (to do the second round alone). That would work for up to 10,000 times (as you made 10,000 preprocesses), but with each second round you do, you can also do a new preprocess in parallel to replenish them. 17:21:27 TL;DR it's simpler and enables output-independent preprocesses which may offer a signing UX of exchanging just a single message, though that may be a bit of UX hell due to all the footguns, caveats, and gotchas. 17:21:55 Thank you :) 17:22:31 *as proving key images is a one-round protocol 17:27:09 I personally dislike message-independent preprocesses (in general, here we're discussing message-and-output-independent preprocesses) as while the keys may be usable by a threshold, a preprocess is generally only used by the specific set which made it. This means if Alice, Bob, and Charlie have a 2-of-3, and Alice and Bob make [... too long, see https://mrelay.p2pool.observer/e/pOT4gd8Kay11amlI ] 17:27:34 There are signing protocols without these caveats, but they're historically much more expensive or requite additional cryptographic assumptions.