15:01:50 MRL meeting in this room in two hours 17:00:58 Meeting time! https://github.com/monero-project/meta/issues/1138 17:01:07 1) Greetings 17:01:26 hello 17:01:33 Hi 17:01:35 Hello 17:01:49 Hi 17:02:44 *waves* 17:03:45 2) Updates. What is everyone working on? 17:03:49 Hello 17:04:31 me: Finishing up milestone 3 of my OSPEAD CCS. 17:05:01 jeffro256 in case you need a meeting time reminder. 17:05:30 working on typing another ccs, I’ll likely finally do another one soon 17:07:41 3) Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography https://github.com/monero-project/research-lab/issues/131 17:09:15 I think jeffro256 wanted to discuss something about Carrot and its extra bits when self-sending. 17:09:16 Last time Jeffro talked about https://github.com/monero-project/research-lab/issues/106, as being a quick solution to get post quantum security for monero. However, i still agree with kayabanerve, i hate this UX 17:09:30 my update: continuing integrating FCMP++ prove 17:12:01 I think compared to december meeting, we stoped talking about economic viability/amount security with a QC. Afaik FCMP++ doesn't prevent a QC to double spend, iiuc the switch commitment revision for Carrot doesn't address this or help at addressing this? 17:15:00 I thought that the Carrot switch commitments were proposed to help prevent quantum counterfeiting, in combination with more steps that would have to be taken. 17:17:07 I don't remember anything so specific about these things, thus I am no help there ... 17:18:37 With the proposal in MRL issue 106, all transactions would have to have off-chain communication, right? It could not be opt-in like Carrot, correct? 17:18:55 FCMP++/Carrot *alone* can't prevent quantum counterfeiting. I think Jeffro talked about modifying Carrot to prepare the future introduction of switch commitments. 17:20:40 Chaser Rucknium, yes, switch commitment is here to prepare a migration to a pq resistance for amount. But I don't remember it addressing the double spend issue, since a QC can forge two outputs with the same key image. 17:21:20 why the sudden concern about QC? the hype over recent Google claims? Haven’t they always over-stated QC capabilities (scammers)? Anyway switch commitments don’t really help with counterfeiting unfortunately. They simply allow us to safely “reveal” amounts as we transition to a new system 17:21:39 Yes. 17:22:36 Anticipating worst case scenario. Kayabanerve and other share these concerns. We also have to assume governments might have better advancements in quantum computing than private companies. 17:22:41 vtnerd: From what I've observed, you can almost draw a separating line between those who are concerned about QC and those who are not, based on age. 17:23:43 Based on age? Indeed? 17:24:06 This is my observation as a social scientists hahaha 17:24:33 Age is strongly correlated with experience, of course 17:24:36 So old people must mostly not fear those QC, because I am firmly in that camp :) 17:25:54 So sorry I'm late.... 17:26:01 But well, what was described seemed like a pretty cheap thing to have, in comparison, which would help just in case they do arrive 17:26:07 To copy what i said in my mrl issue. It's not a matter of "will we be ready for QC era" but also "we should be ready N years prior to avoid people being in trouble in face of law retroactively, as the current blockchain will be transparent" 17:26:51 In most countries the statute of limitations is of minimum 10 years 17:27:06 vtnerd: I think Kayaba's recommendation in their stepping-back note is what created this momentum for the QC theme. personally, I was always concerned, and I think any opportunity is the best yet to start tackling the potential threat. 17:27:08 so we should be PQ 10 years before 17:27:40 and to clarify on my previous comment, old amounts are “statistical bound” (via hash) to a value, so you cannot create money in old transactions, assume hashes are not broken by QC. IIRC, you could theoretically inflate _just before_ the turnstile/reveal was made mandatory 17:28:24 so presumably this is why some people dont like switch commitments, a secret ECDLP solver is still wrecking havoc 17:28:34 I don't see a reason for panic, but given the likely timelines on our, realistically ~ 5 years minimum for a QC main chain HF starting the research and work now is just prudent. 17:29:00 Our end 17:29:41 Carrot has a 16 byte field per enote called the anchor which is required for normal transfers, but is unused for change outputs and other selfsends (when using the new Carrot key hierarchy). We can use this field to send encrypted transaction memos for free. The question is whether or not we should expose this feature to users to put arbitrary data in there, since a quantum comput er may come along and decrypt it at some point 17:29:46 this is insane, we stopped seraphis for fcmp++ to suddenly just drop all the work? 17:30:02 ? we're not planning on dropping fcmp++ 17:30:39 ok, I guess just some people dropped out (temporarily), not the entire thing stopping. Misread the room a bit 17:31:30 just skimmed through the Ruffing paper on QC, my understanding seems correct if others could follow it 17:31:35 FCMP++ is still full steam ahead, from what I gather. 17:31:38 *on switch commitments 17:32:36 AFAIK, the plan is still to activate FCMP, hopefully this year. kayabaNerve suggested that after its activation, non-QC-resistant cryptography should not be on the Monero research agenda. Instead, QC-resistant cryptography should be researched. 17:33:35 I would be for not exposing that field for such. broken crypto and security bugs could both make a lot of privacy mess out of on-chain memos. 17:33:47 Switch commitments alone can't prevent counterfeiting in Monero, we also nee the key images to be intact. However, they are a crucial component of preventing counterfeiting in the future 17:34:05 vtnerd: The issue today is to set up integrity even against a QC. There's minimal changes which can be made now which prevent a QC from counterfeiting years from now, and means anyone who uses a wallet made next year won't be at risk at having their funds burnt. 17:34:32 Yes, the old protocol has to be turned off before a QC becomes active for integrity. The migration scheme would withstand a QC. 17:34:57 I don't remember, was the hope that we could get those switch commitments into "the" hardfork to FCMP++, in about a year? 17:35:15 If we don't take too long to research and decide of course ... 17:35:21 yes, I think the plan was to incorporate switch commitments into the fcmp++ fork 17:35:43 The rest can be done without a hard fork. 17:36:01 This is correct: mainly switch commitments + key image binding proofs would prevent counterfeiting. Then, we also need PQ resistant proofs of opening of pubkeys to prevent theft 17:37:04 But strictly speaking, if we didn't care about theft, just inflation, we just need switch commitments and key images to be statistically binding 17:37:46 jeffro256: If the 16 bytes is only for change outputs and uses a key not at risk to a quantum adversary who has your address, I don't see the issue. 17:37:46 If a quantum adversary with your address can recover these messages, I don't believe we should represent Monero as a private messenger, even njst to yourself. It's reckless and unsafe. 17:38:05 *just to yourself 17:38:17 Maybe it will be a bit hard to become *really* sure those switch commitments do what we hope for, but maybe we could ask the opposite question: Could something go seriously wrong if we add them? 17:39:13 Right now we don't have any candidates for something else to add instead, do we? 17:39:59 jeffro256: Say I'm a merchant. My database gets corrupted and I have to sync my wallet from its seed words. I hope to recover my accounting records as much as possible. Could those 16 bytes help me at all? AFAIK, the status quo is that I lose the addresses that I sent funds to. 17:41:20 By "database" I mean wallet cache file and associated records in my payment system. 17:41:34 rbrunner: it's an additional hash of the randomness. It can't go wrong. We also can prove the scheme secure for an adversary who can't find preimages to a hash function (chosen collision). 17:41:39 Or maybe just the wallet cache 17:42:02 Switch commitments could definitely be part of a solution that DOES allow for mitigating of counterfeiting theoretically. And the changes that we have had to make to FCMP / Carrot aren't all that big IMO. For example, for our switch commitments, in Carrot, we just changed how the blinding factor was bound to certain information. 17:43:11 The changes to output pubkeys will likely be similar: hash them a certain way that guarantees opening it and providing a preimage to the opening is computationally intractable even for a QC 17:44:12 I definitely am not proposing we try to stuff PQ proving systems with actual PQ cryptography into the upgrade at the moment 17:44:53 But cheap stuff like this which may (or may not) give us security in the future is just low hanging fruit IMO 17:45:33 CARROT already implements the necessary output key derivation, no? It's changes to *address derivation* we'd need? 17:45:59 > I don't remember, was the hope that we could get those switch commitments into "the" hardfork to FCMP++, in about a year? 17:46:00 Much shorter than than, and it doesn't have to be a hard/soft fork decision, it can be completely off-chain loose consensus 17:46:16 Yes 17:46:39 > Maybe it will be a bit hard to become really sure those switch commitments do what we hope for, but maybe we could ask the opposite question: Could something go seriously wrong if we add them? 17:46:40 Not AFAIK 17:48:02 Thanks for the clarifications. So I guess we go for them? (Maybe the decision was already taken, I just was too busy mentally to really get that) 17:48:06 We can't change output derivation without synchrony across wallets? Wouldn't we need a hard fork to ensure that? 17:48:11 Reasking what i said at the end of last meeting. Would a PQ addressing protocol using KEM be possible? Afaik, serpahis-pq only made use of DSA, so i wonder. 17:49:13 The point is switch commitments in this HF, as they need a HF, and the new address derivation later, as that doesn't need a HF. 17:49:37 SyntheticBird: Completely different discussion to supply integrity. 17:49:55 Ah yes you are right, sry :p 17:50:33 It couldn't help with this specific problem without adding additional data. We could derive the ephemeral private keys deterministically, which is also a piece of data that gets lost after a wallet cache is lost. The ephemeral private keys can be used to proving that you *sent* payments to another address. However, you still need the public address on-hand. If your wallet cache ge ts corrupted, and you don't know the address, then you're in the same position. But if you would've known the address, just not the ephemeral private keys, then deterministic derivation of those keys would help you on a corrupted wallet cache 17:50:53 But that doesn't require this 16-byte field 17:51:07 And the field is too small to put a full Monero address in it 17:51:20 So TLDR no 17:54:04 I think we should leave those 16 bytes in peace. Yes, they are there for free, but using them would complicate things, and it could entice some people to do unfortunate things 17:54:42 yeah i agree, no compelling reason to use them, more risk 17:54:49 As far as I remember we intend to carry the "traditional" tx_extra forward, so people can still play with that. 17:55:16 With those 16 bytes we would have two mechanisms then, right? 17:57:12 The 16 bytes are fixed, unavoidable, and would be encrypted under CARROT so it isn't immediately the same. 17:58:01 Yeah, but also unused, unless I think of something for me personally? 17:58:27 So it's encrypted by default to your view-balance secret, which is PQ resistant, as it is a uniform 32 byte secret only used in key derivation functions. But it's a 16-byte field, so it could be encrypted to anything, hence it's usability for transaction memos. It would have the same privacy implications characteristics as normal transfers: if a quantum computer could see your pub lic address, then they could calculate your private view-incoming key and decrypt the memo, as they can the amount received, the address received to, the payment ID, etc. I wonder if the temptation for doing it, with it being indistinguishable on-chain, will be so high that some wallets will implement it anyways. 17:59:15 Quantum computers can already decipher which subaddress the payments go to even knowing just one address in the account 18:00:11 I think it will still make a difference how we label and comment that field, and what we "officially" recommend 18:00:42 ACK for internal memos if we care, NACK external memos. Those schemes already largely suck in that they generally assume 2-output so the output the receiver didn't receive is the change output. 18:02:47 so, practically, is this only about how the field is labeled? 18:03:30 Basically. It's completely possible to use it this way, and we can't really stop it, it's just a matter of official support 18:04:07 Is there any benefit from officially supporting the 16 byte arbitrary data that will discourage "third-party" wallet implementors from doing it "badly", if it can be done badly? Or maybe the benefit is that I don't have to add the Nth private memos paper to moneroresearch.info because some researchers needed to "discover" another way to add private messaging to Monero. 18:04:24 Yes, like many other things that we could not stop. But what we can do is stating clearly that we don't recommend to use it, if we can agree on that. 18:05:07 I generally assume all crypto to be broken on a long-enough time frame, so I encourage putting as little data into quasi-permanent storage as possible. 18:05:44 *16 bytes of arbitrary data, we recommend not using them and relying on tx_extra. This will be decrypted by a quantum adversary. cordially, Monero Project.* 18:06:02 Exactly :) 18:06:58 Recommending tx_extra over this field is objectively worse since the memos would be *possibly* decrypted BUT guaranteed to be distinguishable on-chain trivially 18:07:02 I think one of the first references to public key crypto was someone in the 19th century assuming that factoring a 10-digit number is intactable. we are those people for cryptographers in 2150 18:08:29 well, it's always a matter of buying time 18:08:38 I wait for people to produce 10 change outputs to have 160 bytes to use ... 18:08:55 SyntheticBird I think that will do 18:10:50 rbrunner: not under the max 8-out regime :) 18:11:51 Mordinals did something clever with brunt outputs and ring signatures, to show transfer of them. I guess Mordinals in the 16 bytes is unlikely since you could only put a hash there, not a full image, but is there anything about the 16 bytes that is not being considered that could make it more attractive to a Mordinal revival? 18:11:52 Duh ... 18:12:09 But moving memos to a different part of the transaction doesn't magically make the encryption stronger, it just signals that you're definitely using this feature 18:14:17 Oh no no, i didn't meant that this would be safer, at the opposite; just signaling in the recommendation that they shouldn't expect a stronger encryption. You're still right on the deniability of extra data use. 18:16:00 Not AFAIK over the 1060 bytes we already allow in tx_extra 18:16:23 1080* 18:16:53 The 16 bytes is provably linked to a key, right? That's a little different from the data in tx_extra 18:16:55 could this field be multiple times larger and then tx_extra, assuming some tweaks to the tx format, be deprecated? 18:18:07 But it's encrypted with a secret key? The receiver can't read it? 18:18:09 this would fall back into the discussion of whether deprecating tx_extra. What size should user be expecting. Also whether you are using it or not doesn't change the tx will be N time larger than it needs 18:18:53 If a lot of people were using tx_extra it would make sense to make every tx 64 bytes larger for uniformity, but right now tx_extra is rare 18:18:58 Its 1060 18:18:58 If a lot of people were using tx\_extra it would make sense to make every tx 64 bytes larger for uniformity, but right now tx\_extra is rare afaik 18:19:00 https://github.com/tevador/bitmonero/blob/3771641fc5f40cee20df297f49f0dc2213947a45/src/cryptonote_config.h#L212 18:19:07 oh, can of worms. 18:19:22 Isn't the receiver always yourself? So you could always read it. And if you give they key to someone else, they can read it 18:19:39 thx I literally looked at it yesterday but misread 👓️ 18:19:54 I mean that tx_extra is a lot more flexible in this regard. You can even send things in the clear there 18:20:06 I am just trying to get some adversarial thinking about what a Mordinal reviver might want to do. 18:20:34 FWIW unless there's an explicit use case posited here, I'd say no official support, acknowledgement of potential for *internal use*, but no endorsement. 18:20:38 Depends on what you mean by "provably linked". Its just space in some enote that can be written to by anyone signing the transaction 18:21:30 Its not necessarily "linked" by any force greater than convention 18:21:36 SyntheticBird: I considered advocating for a fixed, encrypted blob in TX extra and decided against it for how much of a mess it'd be. Making TX extra larger to provide uniformity to bad TXs doesn't change how we shouldn't be encouraging bad TXs which are fundamentally bad. 18:22:21 Can't we tweak the format of change enotes a little bit and get something that we *must* put into those 16 bytes? So they are not free anymore, discussion closed? 18:22:42 jeffro256: but the only idea officially posited, and safely posited, is to encrypt with the sender's key which is symmetric and not recoverable by a QC 18:23:02 (I am about 50% serious with this question) 18:23:11 So while yes, it's not ZK proven to be encrypted to that key, and is arbitrary, that's not the use-case posited here today 18:25:23 > Can't we tweak the format of change enotes a little bit and get something that we *must* put into those 16 bytes? So they are not free anymore, discussion closed? 18:25:24 Like any regular encrypted data, we can't enforce the contents without adding some kind of verifiable encryption scheme which would put compute load on the nodes and probably make transactions sizes bigger 18:26:33 No, I mean we add some short key, or some hash, or whatever, that is needed for processing change enotes 18:26:47 So the statement "Those 16 are unused" becomes false 18:27:39 If I'm a third-party wallet dev and I put the same thing in those 16 bytes every time instead of random data, e.g. `000000`, is there any cryptographic risk of re-using plaintext again and again? Just trying to understand how things could go wrong. 18:28:19 maybe add something that only the one doing the enote scanning has to compute, not all full nodes. 18:28:37 Yes 18:30:09 But well, maybe that whole idea could be just nonsense ... 18:30:30 Rucknium: You'd create a fingerprint 18:31:23 I am always thinking about mistakes wallet devs can make since I see them on the blockchain too often 18:31:28 Which is ... unfortunate, but can happen easily? 18:31:50 > No, I mean we add some short key, or some hash, or whatever, that is needed for processing change enotes 18:31:50 Hmmm I will think about this more but probably not. The field is on an internal selfsend enote , not the transferred one, so it would mean that enotes can fail to scan based on the contents of other enotes which is kind of gross 18:32:02 Maybe the thing that they want to put in there really does not change much, or hardly at all? 18:32:36 Also if the check is trivial and I lose money adhering to it, I'm probably going to run a wallet which let's me recover those funds even if it means breaking some trivial rule 18:33:45 If one part of the change enote is encrypted with the key that is in those 16 bytes? How would you circumvent that and still (ab)use the field? 18:34:03 But I agree that goes pretty far, just to prevent use of the bytes 18:34:08 I think Rucknium meant 0s BEFORE encryption to self, right ? 18:34:40 Yeah I do mean that. But also after "encryption" if a wallet dev can somehow get around that encryption step 18:34:49 Oh, sorry if I misunderstood Rucknium 18:34:56 A wallet dev can do whatever they want there 18:35:51 *if they sufficiently fork the stack 18:36:43 IMHO, it is best to have the path of least resistance (least dev work) to be the safest. So if the path is to enable an "easy" API to add data, but make it add no data by default, then maybe that is best. 18:37:02 And good docs are needed. Don't forget that :) 18:37:31 yeah Docs are the key here 18:38:03 Yeah it could be a fingerprint if they screw it up and put the 0s into the tx without fingerprinting 18:38:32 Remember, recently Siren (comfy) was adding a fingerprint to their MoneroPay txs accidentally because the docs were not clear. 18:38:46 Sorry got behind on the list. Probably want to do it a hardfork though, otherwise people might use wrong version and get locked out of the switch phase 18:40:14 If we do it now, then there won't HAVE to be any fork 18:40:17 The meeting has gone pretty long. I think the 16 free bytes can be put on next agenda's meeting, unless people think that everything is settled. 18:40:52 Out of curiosity, What was the fingerprint ? 18:41:13 Unlock time 10 18:41:24 Should be 0 18:41:54 I'm fine for now not officially supporting external memos until it comes back up again downstream 18:43:00 does this mean no payment id like functionality? I assume thats what you mean by memo? 18:44:25 I need to re-read your carrot proposal I think, things have changed since I first looked 18:44:45 Payment IDs are separately supported 18:45:55 They also have the same PQ privacy issues 18:46:47 Except that they're smaller so they allow "less" arbitrary data 18:48:16 --- Meeting end --- 18:48:18 Feel free to continue discussing :) 18:49:06 a remark re: Carrot address format. AFAIK it's he first change in Monero's history where the same mnemonic will be able to resolve to two different key chains (barring a potential feature bit flipping for *newly generated* Polyseeds, but that's out of scope for my point here). 18:49:25 this seems like a good opportunity to unify prefixes, doing away with the 4/8 (primary/subaddress) distinction for Carrot addresses. 18:50:11 IMHO, ideally all becoming 8... addresses, so Carrot users can blend into the already existing crowd of legacy subaddress users. 18:50:31 *the 18:55:37 You have to have a signifier between main/integrated addresses and subaddresses because the sender handles them differently. Namely, they construct the ephemeral pubkey differently. But Carrot addresses will already be indistinguishable from legacy addresses 18:55:48 Thanks everyone for the meeting BTW! 19:03:40 thanks delicious meeting as always 19:06:31 jeffro256 got it, thank you. so is this is a requirement on the consensus side, not related to the derivation scheme? 19:06:35 and, likewise, thank you all! 19:14:59 No not a consensus requirement at all. The ephemeral pubkey is indistinguishable as belonging to either a main address or a subaddress, but if you try to make an enote ephemeral pubkey like you would for a subaddresses, when the address is actually a main address, then the payment simply won't be scannable by the receiver 19:18:37 And vice cersa 19:18:46 versa 19:20:35 There is also an important cultural benefit in China by moving entirely to all becoming 8... Addresses 19:24:14 TIL ArticMine is not only knowledgeable on scalability 19:37:44 I once listened to Artic speaking 2 hours about the dynamic block size algorithm, and they eventually drove it back to how holes were arranged on punched cards for 1960s' computers. so, yeah, pretty much. 21:46:38 I _think_ this may have been asked+answered before, but what happens to the existing ring-ct outputs if we transition to switch comittments? Those outputs have to move before the “switch” occurs, otherwise they have to be locked out. Any existing pre-ringct outputs can still be converted. Anyway, it’s an unfortunate that the only mitigation is a PSA to move outputs, etc. 21:48:56 Yes they will need to transition during the pre-QC period. And after a reasonable amount of time (2~3 years?) the migration will be completed and old outputs will be locked. Pre-ringCT outputs will have to transition too. Kayabnerve argued that most of these outputs are probably lost/burnt. 22:02:34 yes, I remember the prior discussion now. 22:08:04 Previously, I mistakenly stated that we could migrate pre-RingCT outputs, since they have a cleartext amount, but I didn't take into account how FCMP++ will interact with key images for those outputs 22:21:48 Hypothetically, we might be able to make them spendable if we chose the `T` generator for FCMP++ in a way that is cryptographically verifiable that guessing the generator before some point in time, after the RingCT hard fork, is intractable 22:23:47 Because the problem with making them spendable is that if pre-RingCT outputs are constructed O = x G + y T with a known y value known s.t. y != 0, then the key image spending in a FCMP++ is L = x Hp(O), which is different than what we expect them to be, which is L = dlog(O, G) * Hp(O) 22:25:03 But if `T` isn't guessable until some point in the future, then it would be impossible to create a valid key image in a FCMP++ for that output that ISN'T L = dlog(O, G) * Hp(O) 22:26:17 Then, during the PQ migration, we can check that if-and-only-if the originating height of the spent output is < v6 hard fork height, we allow the output to be migrated if the key image is exactly L = dlog(O, G) * Hp(O) 22:31:27 If we made the `T` generator a function of the current Monero block ID, then the trust assumption for preventing inflation would be 1-of-N honest participants, where N is the number of total transaction creators on the Monero blockchain, ever 22:42:36 Actually, not ever, just sincev6 23:06:26 jeffro256: FYI, non-RingCT outputs can still be created today. 23:07:13 Yes, namely "unmixable sweep" txs. Hence, the height requirement 23:07:37 We'd need a HF banning non-RingCT outputs, then to decide T via the blockchain if that's considered secure, then to activate FCMP++. 23:08:01 Or at least a designation height for which non-RingCT outputs won't be migrateable. 23:08:15 I'd vote the latter 23:08:24 I'd vote none of this mess. 23:09:25 TBF It's a small tweak to a single value and we don't actually have to handle the implications *now* 23:09:31 Also, AFAICT, your security analysis is wrong. 23:11:14