Monero Research Lab Meeting - Wed 24 April 2024, 17:00 UTC

Logs:

< rucknium:monero.social > Meeting time! https://github.com/monero-project/meta/issues/995

< rucknium:monero.social > 1) Greetings

< rbrunner > hello

< one-horse-wagon:monero.social > Hello.

< chaser:monero.social > Hello

< tevador > Hi

< weechat2 > hi

< articmine:monero.social > Hi

< rucknium:monero.social > weechat2: Are you vtnerd?

< weechat2 > ah this again, soryr

< rucknium:monero.social > 2) Updates. What is everyone working on?

< hinto.janaiyo:matrix.org > hello

< rucknium:monero.social > me: I have a draft framework for evaluating the ringsize-fee tradeoff to defeat black marble flooding. I can discuss in the black marble agenda item.

< vtnerd > I focused on a fewbbugs in LWS, and a bug in the p2p ssl patch

< tevador > I'm working on a Jamtis version compatible with the FCMP++ key format.

< rucknium:monero.social > 3) Discuss: Potential measures against a black marble attack https://github.com/monero-project/research-lab/issues/119

< hinto.janaiyo:matrix.org > me: nearing the end of Cuprate's db impl, reader/writer threads + request/response handling

< rucknium:monero.social > I am working on estimating the best combination of raising ring size and/or increasing the tx fee to defeat black marble flooding. Any input is appreciated. Of course feedback can be included if given later, but sooner is better :)

< rucknium:monero.social > Here is my idea: Compute the cost effectiveness of the alternatives and pick the alternative with the best cost effectiveness. Cost effectiveness is the cost of some option divided by the quantified desired outcome. Lower is better.

< rucknium:monero.social > In our problem, it is the cost of raising ring size and/or fee divided by the effective ring size that a flooding adversary could achieve with some specified budget per day. The formula for effective ring size is equation (3) on page 7 of https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-flood.pdf

< rucknium:monero.social > What is the cost of raising ring size and fee? My proposal: (1) Aggregate fees paid by transactors plus (2) the cost to store tx data by all node operators. To compute (1) take an average block's transactions and recompute tx size and fees with different ring sizes and fees/byte. I think we should use the four weeks of tx data before the March spam occurred.

< rucknium:monero.social > My proposal for (2) is take the median price for a consumer 1TB SATA SSD, divide by one tera to get the cost to store one byte, then multiply by the estimated number of nodes on the network at https://monero.fail/map (about 20,000 now). Does that sound reasonable?

< one-horse-wagon:monero.social > Rucknium: Did the recent flooding attacks hurt anything at all in Monero?

< rucknium:monero.social > You mean the March one or the two-day one in April?

< one-horse-wagon:monero.social > Some transactions were delayed but was there any real damage?

< rucknium:monero.social > Read the linked PDF

< rucknium:monero.social > Spam by an adversary can reduce the privacy of ring signatures. This problem has been known since 2014.

< tevador > I think we could raise the ring size to match the future FCMP++ tx size, pending some perf analysis. That would also raise the min fee.

< rucknium:monero.social > What I see in my preliminary results is that raising the ring size is much more cost effective than raising the fee. Of course, if the assumptions are very different, then a fee increase looks better.

< rbrunner > I don't understand yet what you mean with this: "quantified desired outcome"

< rucknium:monero.social > For example (preliminary), if the budget of the adversary is much, much higher than the March suspected flood and the cost to the node operators is assumed to be much higher than the simple SSD cost computation, then a fee increase can be more cost effective.

< tevador > The "outcome" is probably the effective ring size for the black marble attacker

< rucknium:monero.social > Our "quantified desired outcome" is effective ring size if an adversary floods the blockchain with black marble outputs.

< chaser:monero.social > sounds reasonable to me. would you agree that the increase in tx creation and verification time is also a cost, although hard (or impossible) to properly quantify? qualitative factors like climate, etc.

< chaser:monero.social > * I should say computation cost, time is only a part of that

< articmine:monero.social > There is another factor here namely the surge factor. How much the short term median can grow without an increase in the long term median

< rucknium:monero.social > chaser: Yes. This leaves out some costs. There are some benefits to higher fees like larger mining security budget, for example, too. And this simple storage cost assumes that there are no pruned nodes and all the nodes on monero.fail are real nodes (some are suspected spoofed nodes)

< rucknium:monero.social > ArticMine: Right. My current draft does not try to analyze the short-term block size ceiling. I can try to model that, too.

< jeffro256:monero.social > Howdy sorry i'm late

< kayabanerve:monero.social > 👋

< articmine:monero.social > Essentially if the ring size is greater than the surge factor a black marble attack is theoretically not possible

< rucknium:monero.social > By the way, with current numbers on SSD price and number of nodes, Monero's minimum fee/byte (20 nanoneros) is almost exactly the aggregate node storage cost. An astonishing coincidence. (This might be a Pigouvian fee on an externality.)

< plowsof > M.

< rbrunner > Over all those many nodes? Wow.

< kayabanerve:monero.social > Re: what I'm working on, I published a PDF for FCMP++ with background, proper pacing, and details. Ill refrain from further comments until a relevant topic comes up. Sorry for being late to attend.

< rucknium:monero.social > Eventually a spammer could raise the block size large enough, but it may take a lot of time.

< rbrunner > Because it was an often-heard argument, that the spammer can store gigabytes in our blockchain for much to low a price. Does not seem like that?

< rucknium:monero.social > 1TB SATA SSD is about 1XMR now. Divide 1XMR by a tera gets you 1 piconero. Min fee/byte is 20,000 piconeros (20 nanoneros). Unless I did something wrong with this simple arithmetic.

< articmine:monero.social > I consider 16 to be the minimum surge factor possible based upon the historical VISA data

< articmine:monero.social > Especially the ratio between the maximum capacity of the VISA network and average TPS

< rucknium:monero.social > I will title this section "How i learned to stop worrying [about storage costs] and love big rings"

< rbrunner > :)

< kayabanerve:monero.social > Bad time to mention how larger rings increase data storage capabilities?

< rucknium:monero.social > Good time to mention it. Storage is cheap! And most ring data is removed when you prune :)

< kayabanerve:monero.social > I don't think that's an issue here, I just have to note :p

< rucknium:monero.social > Run the numbers. Have people been worrying about nothing for so long, without running the numbers?

< articmine:monero.social > This is critically important in order to understand why Monero can scale and Bitcoin cannot.

< rucknium:monero.social > I want to get to the next agenda item on FCMP at 17:30.

< rbrunner > Well, lack of space for the blockchain on older computers is real. And never mind a 1TB SSD, over USB that may not be really fast, again depending on the USB variant available

< rucknium:monero.social > Here are more questions to think about: We need a set of options to consider. Does ring size 16-60 and fee 1x to 10x current min fee sound reasonable? Should going below a specific effective ring size be avoided at all costs? What range of the adversary's budget should we assume? The estimated expenditure of the March spammer was about 2.5 XMR per day. Should we look at 1x to 100x that budget?

< jeffro256:monero.social > Well it depends on if you only care about storage costs. You might also want the fees to cover aggregate CPU time to verify, bandwidth of broadcasted txs, other p2p communication costs, opportunity cost of RAM usage, etc

< articmine:monero.social > If the computer does not support USB 3 replace the hard drive.

< rucknium:monero.social > jeffro256: You are right, yet those things are harder to get reliable estimates about. I can multiply the storage costs by some factor to approximate those other costs.

< kayabanerve:monero.social > Actual Q. Are we factoring DB reads into CLSAG 40 evaluations?

< rucknium:monero.social > kayabanerve: I think we should. I would prefer to have good benchmarks for larger rings. With actual monerod code instead of theoretical benchmarks

< rucknium:monero.social > Since the read time affects total verification time.

< kayabanerve:monero.social > Right. The cryptography alone isn't enough if we need notable time to prepare the statement.

< tevador > Another big advantage of FCMP++: no DB reads needed to verify a tx.

< rucknium:monero.social > I may try to do those benchmarks by myself, but t is probably not my comparative advantage to figure that out.

< kayabanerve:monero.social > tevador: I was waiting to say it :p

< rucknium:monero.social > 4) Research Pre-Seraphis Full-Chain Membership Proofs https://gist.github.com/kayabaNerve/0e1f7719e5797c826b87249f21ab6f86

< kayabanerve:monero.social > I published a PDF quite comprehensive in that regard.

< kayabanerve:monero.social > I am eager for jeffro's thoughts.

< chaser:monero.social > FYI, link: https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf

< rucknium:monero.social > kayabanerve: Could you link the PDF here for the meeting log?

< kayabanerve:monero.social > jeffro, koe, and tevador all support the development CCS now.

< kayabanerve:monero.social > chaser has it correct :)

< jeffro256:monero.social > Kayaba: that is a good point, although I suspect that the DB read time is pretty insignificant compared to verify run time for CLSAG or FCMP. I used to have the same thoughts, but after spending a lot of time trying to optimize LMDB and doing benchmarks, its surprisingly much faster than you would expect. TBF I did do those tests on an NVME

< jeffro256:monero.social > LMDB really just is ridiculously fast

< kayabanerve:monero.social > I'm not expecting it to be notable. I'd use a SATA SSD as a midpoint and ask how many ms it is for 100 * 16 decoy reads (decoys selected per distribution) from the mainnet set.

< jeffro256:monero.social > The Blockchain class has bad concurrency but that's a different issue

< kayabanerve:matrix.org > Regarding the research CCS, I have to reply on the CCS itself but I'll immediately call jeffro256 out for asking for scope creep D:

< kayabanerve:matrix.org > To be clear, I support the F-S secret variant and was planning to impl the non-F-S variant per the PR, then branch and do the F-S variant for free. Its minimal extra work.

< tevador > I'm starting to favor going with the forward-secret version of FCMP++ and adopt the key format for Jamtis.

< kayabanerve:matrix.org > If tevador is dropping scope creep concerns, I'd be incredibly happy to move forward the F-S variant.

< rucknium:monero.social > On the FCMP++ Development CCS koe said "I am fine with the current proposal as a valuable research endeavor. Regarding auditing and implementation, I expect it would take 1.5-2.5 years to reach a hardfork after this CCS is complete. Just the multisig integration on its own I expect to be a glacial review/auditing process, and then there are the substantial changes needed to suppor<clipped message

< rucknium:monero.social > t full-chain reference sets. If Monero had less tech debt, then it would probably be 0.5yr faster."

< rucknium:monero.social > https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/448#note_24260

< rbrunner > Favor over what? Over the non-forward-secret version?

< jeffro256:monero.social > If we are going to go with FCMP++ (not saying it's a given at this time) I think we should skip right to the forward secret variant. The jump in complexity compared to doing FCMPs is minimal IMO and uses basically the same cryptography

< tevador > Yes, over the non-foward-secret version. The tree proof is the same, they only differ in the GSP.

< kayabanerve:matrix.org > The one concern is over the usage of a BP+ for spend authorization + linkability (SA+L). It's not a BP+ as in range proof, it's literally 1/64th the work (1/128th for a 2-output TX), but it puts as at half as small a CLSAG, not a quarter as small.

< kayabanerve:matrix.org > rbrunner: Yes

< rbrunner > That would also carry over to a later switch to Seraphis+FCMP, I assume?

< kayabanerve:matrix.org > tevador: Technically, we need one more PoK of DLog in the first layer in order to output a blinded randomness commitment (and not a randomness commitment).

< kayabanerve:matrix.org > But effectively, yes. Same principles, same gadgets.

< rucknium:monero.social > "Forward-secret" in these discussions always means maintaining secrecy even against a theoretical future quantum adversary that can break discrete log cryptography, correct?

< jeffro256:monero.social > yes

< kayabanerve:matrix.org > Rucknium: I define it as an adversary with a discrete log oracle, which a PQ adversary satisfies.

< jeffro256:monero.social > Usually assuming the attacker does not have knowledge of your cryptonote/Jamtis public addresses

< kayabanerve:matrix.org > By showing an adversary with a discrete log oracle can find numbers ('forging' them) for any output to be the output spent, we show you can't find the actual output/the evidence for the found output is worthless (as it could be forged by the adversary).

< tevador > Question: how much work would it be to adapt the existing Seraphis codebase to the new key formats?

< kayabanerve:matrix.org > rbrunner: The first layer changes. Seraphis defines its own SA+L proof. This doesn't develop anything novel though.

< kayabanerve:matrix.org > It's basically an extra function call to an already defined function.

< rucknium:monero.social > But prevention of XMR counterfeiting by a quantum adversary is still not possible with any of the options that are being considered, right?

< kayabanerve:matrix.org > Rucknium: You'd need PQ cryptography for that.

< kayabanerve:matrix.org > Across the board.

< kayabanerve:matrix.org > The most we can do now is tevador's prep commentary which extend the time it's safe to migrate from the old system to the theoretical new system.

< tevador > I will publish the Jamtis-compat specs this week. It has the same features as Jamtis-Seraphis, but the addresses are backwards compatible with old CryptoNote addresses (or rather CN addresses are forward compatible).

< chaser:monero.social > relevant gist: "Zero-cost post-quantum mitigations for Seraphis" https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a

< tevador > That means there would be less disruption after the fork (users could still use old addresses).

< jeffro256:monero.social > tevador: regarding adapting Seraphis to the new key formats, do you mean supporting an older version of the protocol inside the Seraphis lib, or changing the Seraphis lib to itself use those changed pubkeys in its protocol?

< kayabanerve:matrix.org > Mind clarifying tevador? I thought the compatible version was 'Jamtis 0.5', with less features yet backwards compatibility.

< kayabanerve:matrix.org > Are you just referring to not banning old addresses and having two address protocols at the same time?

< tevador > The features are the same.

< kayabanerve:matrix.org > With the two-key address protocol currently defined, you can accomplish all the features of the three-key Jamtis????

< UkoeHB > tevador: Janus mitigation?

< tevador > It will be clear from the specs. Most features of Jamtis stem from: having multiple DH key exchanges and the OVKs.

< kayabanerve:matrix.org > So it's defining a new sending protocol over the existing 2-key address definition? 🤔 I'll wait for the gist yet very eager to see.

< tevador > I mean, only Jamtis addresses would have the new features. Old addresses would obviously not have them, but they would still work.

< kayabanerve:matrix.org > That sounds like my comments on F-S/OVKs

< kayabanerve:matrix.org > Very eager to see.

< tevador > Old addresses: no Janus mitigations, no filter-received wallet tier etc.

< kayabanerve:matrix.org > Also, jeffro256, tevador is interested in the Seraphis codebase yet with FCMP++ replacing the Seraphis protocol (when the Seraphis protocol is concisely defined as its linking tag format)

< tevador > But old addresses would still produce forward-secret transactions.

< jeffro256:monero.social > tevador: nice. I assume by simply adding another generator component to the onetime address derivation?

< kayabanerve:matrix.org > Obviously, the modern Seraphis work is a new transaction protocol, a new wallet protocol, so on. It's keeping all of that, yet removing the original basis of the protocol (the enote structure and linking tag definition).

< tevador > jeffro: yes, exactly

< kayabanerve:matrix.org > Changing the address derivation, instead of the address, is a great idea I'm extremely happy to see being explored ^_^ If that enables F-S on old addresses, I'd be amazed and love it.

< rbrunner > Are you people just busily adding more possible variants of ways into the future? :)

< kayabanerve:matrix.org > rbrunner: I can promise my current proposal is still just FCMPs on RingCT

< kayabanerve:matrix.org > but with forward secrecy

< kayabanerve:matrix.org > but don't worry there's no wallet changes and that's it, I promise

< kayabanerve:matrix.org > ;p

< rbrunner > Right now I just worry a bit about a possible more complicated decision process what it finally will be.

< rbrunner > The more options and variants, the harder to find consensus, maybe.

< tevador > The most important advantage of sticking with FCMP++ is that we get one huge anonymity pool that starts with the genesis block.

< kayabanerve:matrix.org > The JAMTIS evolution which is being discussed would be an amazing upgrade which can be done in a distinct hard fork. I'd likely support doing all of the wallet work in a hard fork after. The PDF I wrote details the minimal deployment plan where we don't do a new TX, the Rust is treated as a black box, and the only wallet change is fetching decoy info -> fetching paths, CLSAG sign to FCMP++ prove.

< rbrunner > We had almost 2 years of a lull - "Seraphis will it be" and now we almost have an explosion of options. Surprising.

< one-horse-wagon:monero.social > It's really more enhanced options.

< jeffro256:monero.social > definitely most of the Jamtis code is reusable, all of the legacy scanning code is reusable, the optimized Pippenger verification code is reusable, and probably some more things that I'm not thinking of rn

< tevador > I'm also incorporating the 4-key variant of Jamtis since there was consensus on that. With flexible view tags.

< rbrunner > If people can stay on the short addresses if they really want, those even longer addresses probably are not so hard anymore :)

< kayabanerve:matrix.org > While I can say that makes us appear running all over the place, I'm personally excited about the revolution here, and will reiterate my PDF has a firm actual deployment plan made to be concise. It also seem to has agreement re: developers. This meeting seems to show that I need to tweak it to be the F-S variant, which I am fine with, and that's minimal text changes.

< kayabanerve:matrix.org > *It, my CCS. Sorry.

< rbrunner > We are running all over the place, but it may turn out to be worth it, IMHO.

< tevador > I think it will stabilize soon.

< kayabanerve:monero.social > I believe the PDF, noting the F-S variant, is stable.

< kayabanerve:monero.social > tevador: Clarifying, this is all expected to be a following releasr, right?

< kayabanerve:monero.social > I would say HF except it doesn't explicitly modify the on-chain protocol.

< kayabanerve:monero.social > (Though it should be deployed with one)

< tevador > We can deploy FCMP++ in one hard fork and then deploy the Seraphis codebase (with new addresses) later.

< jeffro256:monero.social > Regardless of the FCMP-RCT development CCS proposal, I think we should have a contingency plan for if Seraphis is ready for deployment much sooner than expected, and FCMP-RCT isn't. In that scenario, should we simply go directly for Seraphis, as the stated reason for FCMP-RCT is expected time-to-release?

< jeffro256:monero.social > s/development CCS proposal/research CCS proposal

< kayabanerve:monero.social > I don't believe it relevant?

< jeffro256:monero.social > why's that?

< UkoeHB > IMO the timeline for Seraphis vs a FCMP-RCT/adjusted-Jamtis is probably the same if we aren't doing a major wallet rewrite (seems likely).

< kayabanerve:matrix.org > With a decision to not deploy FCMP++s, only two milestones are dropped from the dev CCS.

< kayabanerve:matrix.org > I believe it's ~15%.

< jeffro256:monero.social > I'm talking about what we do with the network protocol

< kayabanerve:matrix.org > UkoeHB: It's FCMP++ without any JAMTIS that I'm proposing.

< kayabanerve:matrix.org > I don't mind a contingency for that 15%. I'm just noting almost all of the work is still relevant to Seraphis.

< tevador > I don't think we should plan to deploy the Seraphis key image format anymore if FCMP++ works.

< jeffro256:monero.social > Well yes, sorry I worded it wrong. Regardless of any CCS developments / sunk dev costs anywhere, can we agree that we should deploy on the network Seraphis+FCMP if it is ready before/around the same time as FCMP-RCT?

< UkoeHB > Yes I'm not pushing against your CCS work. The question is whether to stick with cryptonote key images or continue on to Seraphis, and I think those two are on similar timelines.

< kayabanerve:matrix.org > If it'll let us move forward, I'll note if the Monero protocol decides to evolve in a way that invalidates the purpose of a milestone in its entirety, then the milestone won't be paid out and the coins yielded to the Research fund? And if the Research fund has a milestone invalidated, those coins would become remaining and part of a MRL fund?

< kayabanerve:matrix.org > Oh. That's a very distinct discussion jeffro256.

< jeffro256:monero.social > tevador: it that because of the privacy implications of the enote migration?

< kayabanerve:matrix.org > Do we want a unified privacy pool, no migration, no invalidation of addresses or efficiency? That's the question.

< kayabanerve:matrix.org > The Seraphis first layer is smaller, and the Seraphis SA+L proof is smaller. We'd also have the option of any curve cycle, not any curve cycle with 2**255-19.

< kayabanerve:matrix.org > That may end up, in total, ~2x faster. That'd be my favorable estimate.

< kayabanerve:matrix.org > Also, UkoeHB, I didn't even mean to invalidate your timeline estimate. I solely wanted to clarify your timeline estimate noted something not being included at this time. I don't feel you're pushing back at all, and do ack your timeline estimate.

< tevador > Yes, the migration has privacy implications and also the disruption to the Monero ecosystem would be much larger if we invalidate old addresses.

< rbrunner > That "2 address types in parallel ad infinitum" remains to be seen, I am still a bit sceptical.

< rbrunner > This has anyway also potential for confusion.

< kayabanerve:matrix.org > To be clear, without a breakthrough in how the proof is written, we have 4 PoK DLog proofs in Seraphis FCMPs. In FCMP++s, we have ... 7 PoK DLogs and 1 DLog? The reason that alone isn't 50% is because the set membership is the same. If we want a set of at least 4 billion, we need to do 256**4, and that means we need at least 1024 in-circuit multiplications. We can't get below that :/

< rucknium:monero.social > How would the non-mandatory new addresses work in practice? Would the new wallets have the ability to produce the new and old address versions? But only be able to use OVK features with coins sent to the new addresses?

< kayabanerve:matrix.org > 1024 + 4 PoK DLogs = ~1640. 1024 + 7 PoK DLogs + DLog = ~2000.

< jeffro256:monero.social > New wallets might just want to make the new addresses, so they don't have to scan for enotes to the old format

< rucknium:monero.social > SegWit addresses took a long time to get adopted in BTC.

< kayabanerve:matrix.org > It's within the same power of 2, from my napkin math here I'd need to triple check.

< tevador > There would be a bit flag set in the Polyseed phrase that determines if the wallet produces old or new addresses.

< rbrunner > Sometimes a hard cut and break with the past, even if painful, is better than endless agony, to put it a bit bluntly.

< kayabanerve:matrix.org > So at best, I'd hope for Seraphis FCMPs (and its SA+L proof) to be 2x faster.

< UkoeHB > rbrunner: There is a certain endless agony in the need for backward compatibility.

< rbrunner > True.

< kayabanerve:matrix.org > And sorry, I know that's scattered. I hope my intent gets across.

< kayabanerve:matrix.org > Also, isn't tevador's proposal for the new addresses to be indistinguishable from old addresses?

< rucknium:monero.social > rbrunner: I think you may be correct. The lack of mandatory address upgrade means that there is a circular chicken-and-egg problem for adoption: no one creates the addresses since no one send to them, and vice versa.

< kayabanerve:matrix.org > If we lift all old addresses and not just internally, yet their communication is identical, then it's a vastly distinct discussion from Bitcoin SegWit.

< jeffro256:monero.social > don't think they can be: they are different sizes

< tevador > On-chain, they are indistinguishable.

< kayabanerve:matrix.org > Oh. On-chain, they're indistinguishable :/ That was my confusion earlier and why I asked about your JAMTIS 0.5 work.

< kayabanerve:matrix.org > (as that was the off-chain indistinguishable version)

< rbrunner > Only think how much confusion those lowly "integrated addresses" sometimes produced ...

< tevador > No, old addresses would stay the same, 2 keys and base58.

< kayabanerve:matrix.org > I am curious how far we can go with off-chain indistinguishability. I believe we may able to do better than prior posited. I'd have to see tevador's proposal and do some further thinking.

< rbrunner > And would we get hardware wallets to support two very different address types?

< UkoeHB > IMO there is a risk that if FMCP doesn't pan out and we don't migrate to Seraphis key images, we won't see any ring size improvements maybe ever. Seraphis gives Grootle proofs as a fall-back.

< kayabanerve:matrix.org > If we don't do FCMP++s, we definitely should do Seraphis. No question there.

< tevador > If FCMP++ doesn't pan out, we can still migrate to Seraphis key images later. But we can't migrate back to the compatible version.

< kayabanerve:matrix.org > If they do work out, Seraphis theoretically may offer 2x performance, the newer codebase now (not in a follow up deployment), and explicitly migrates addresses (though technically, we can have wallet2 refuse to send to old addresses to force that migration? So that's not unique to Seraphis?)

< tevador > There can be a gradual phase-out of old addresses instead of a sudden invalidation.

< kayabanerve:matrix.org > tevador is correct Seraphis would forever prohibit the unified pool proposal. If the current FCMP proposal is fundamentally flawed, I'd still support Seraphis however.

< UkoeHB > The problem comes with implementation. Refactoring the Seraphis library to support a different approach might be a substantial effort, so once you fork it needs to be a solid plan.

< rbrunner > Anyway, overall I think nobody finds something that prevents us to at least start work on those FCMPs as soon as possible.

< rbrunner > Where we will finally end is another question, quite some time in the future.

< rucknium:monero.social > IMHO, having a unified privacy pool is not a huge benefit because tx outputs turn over so frequently. Maybe there is tech debt reasons to do it, but I don't see a really strong privacy reason if there is a longer delay and/or worse performance with a unified pool.

< one-horse-wagon:monero.social > kayabanerve: So what is the next step you need to take to get the FCMP protocol underway today?

< kayabanerve:monero.social > Personally, I am fine waiting to see tevador's address format and continue the discussion next week. We don't need an immediate answer.

< UkoeHB > tevador: Are you starting a new gist for Jamtis-C (Jamtis over Cryptonote)?

< kayabanerve:matrix.org > Merge my CCS?

< tevador > Yes, new gist.

< kayabanerve:matrix.org > Ideally both of them?

< UkoeHB > Ok, I will read when you are ready

< kayabanerve:matrix.org > I'd be really unhappy if I can't start talking to auditors now, cash in hand, and have those slowdowns and bureaucracy.

< kayabanerve:matrix.org > But there's no technical blockers to my work and I already started the first milestone.

< tevador > At least the Development CCS should be merged ASAP.

< rbrunner > I mean seems to me nobody is seriously considering anymore a future Monero without FCMPs - given they "work out" of course.

< jeffro256:monero.social > why development before research?

< rucknium:monero.social > Can some of the gist links be posted to https://github.com/monero-project/research-lab/issues/100 ? Gists never have memorable URLs.

< kayabanerve:matrix.org > Immediately after my gist, I started a circuit specification. I had a milestone for the circuit specification, and that become a milestone for a protocol specification per tevadors comments. I then made a PDF detailing various aspects, which I published now for the group's clarity on the work. It's not yet a specification, yet I will edit it to be the specification.

< tevador > The "Research" is basically audits.

< jeffro256:monero.social > fair

< kayabanerve:matrix.org > jeffro256: Because the research CCS is actually more auditing than actual research (and proofs for the existing research).

< chaser:monero.social > will do so after the meeting

< kayabanerve:matrix.org > To be clear, not funding the research CCS impedes us ensuring we're on the right track and not developing components which have difficulty proving/auditing that cause us to use a fallback. It also adds to 'when completed' due to the delays of the bureaucracy :/

< chaser:monero.social > rbrunner: the long-term future of Monero has to be FCMP, one way or another. I can envision ring size increases as short/mid-term temporary stepping stones to improve privacy until we get to FCMP.

< kayabanerve:matrix.org > To be clear, my specific FCMP proposal may not be the inevitable upgrade to full-chain membership proofs.

< rucknium:monero.social > You already added two pluses to FCMP. Another proposal will have to be called something else. Three pluses are against the rules AFAIK :P

< articmine:monero.social > I agree

< chaser:monero.social > well, we did discuss that this path may have terminal obstacles, e.g. not being able to prove the soundness of GBPs.

< jeffro256:monero.social > Just like how valve isn't allowed to make a game with a 3 in its name

< kayabanerve:matrix.org > No, I've written two alternatives to that.

< kayabanerve:matrix.org > One 25% slower, one a few times slower.

< kayabanerve:matrix.org > So there may be terminal obstacles per our current ability, but GBPs alone are not.

< kayabanerve:matrix.org > Rucknium: I can go back to FCMP+SA+L if that's less wordy and acronymy for you ;)

< chaser:monero.social > got it, I stand corrected (and happily so). what are some actual terminal ones?

< kayabanerve:matrix.org > And before anyone claims I didn't document those two alternatives, they're both in the PDF. Please read the PDF. It is the comprehensive overview to the proposal.

< rucknium:monero.social > kayabanerve: Your PDF says that the two alternatives still need security proofs, right?

< kayabanerve:matrix.org > The GBPs and the fallback and the fallback's fallback failing.

< kayabanerve:matrix.org > Yes, all three would need proofs. The second one actually may be quite trivial?

< kayabanerve:matrix.org > I believe it can be formally argued as a prior proof before the existing Bulletproof.

< chaser:monero.social > having a plan C sounds like a good level of assurance

< kayabanerve:monero.social > Hm. Matrix.org has stopped sending to monero.social.

< kayabanerve:monero.social > > Or rather, a prior modification to how the statement is formed, independent of the Bulletproof itself.

< kayabanerve:monero.social > > If the divisors fail, we fallback to incomplete addition with a window size of 2 (nothing novel, truly already understood, already widely used, 2x slower than divisors for proving DLogs)

< kayabanerve:monero.social > And no, that 2x wouldn't compound with other things such as the 25% number I'd gave. They share some inefficiencies.

< kayabanerve:monero.social > So yes, it's definitely meant to be robust.

< kayabanerve:matrix.org > Or rather, a prior modification to how the statement is formed, independent of the Bulletproof itself.

< kayabanerve:matrix.org > If the divisors fail, we fallback to incomplete addition with a window size of 2 (nothing novel, truly already understood, already widely used, 2x slower than divisors for proving DLogs)

< kayabanerve:monero.social > The concern would become performance, not theory, yet I've also worked to dramatically increase performance from my initial Monerokon estimate.

< kayabanerve:monero.social > Shall we call the meeting here, Rucknium? I'm unsure if there's active conversations and not just whatever will trickle.

< rucknium:monero.social > Yes, meeting called

< chaser:monero.social > thank you everyone, I really appreciate all this work and coordination that we see here.

< articmine:monero.social > Thank you all

< mrwonderland:tchncs.de > I second this! Really appreciate all of your guys work ❤

monero-project / meta

Monero Research Lab Meeting - Wed 24 April 2024, 17:00 UTC #995

992