11:16:40 <atomfried[m]> <narodism[m]> "there's also accumulator schemes..." <- the problem with unkown order groups, is that you cannot create such a group trustless, ergo needs a trusted setup. Did this got solved somehow?
11:18:35 <atomfried[m]> As far as i know/remember all the methods to create groups of unkown orders trustless were just assumed to work and not realy proven
12:29:09 <tevador> Trustless accumulators can be constructed from class groups. https://eprint.iacr.org/2020/196.pdf
13:02:03 <atomfried[m]> yes, but the quality of the group is non-deterministic i think
15:41:02 <one-horse-wagon[> Is there a meeting today?
15:45:39 <Rucknium[m]> Yes: https://github.com/monero-project/meta/issues/773
16:05:21 <one-horse-wagon[> Rucknium: Thanks
16:21:17 <UkoeHB> I won’t make it to the meeting on time, can someone else lead? My update is I’m continuing seraphis library cleanup, and I made a new ccs.
16:27:22 <Rucknium[m]> I can lead
16:59:47 <one-horse-wagon[> Hello.
17:01:02 <tevador> Hi
17:01:10 <rbrunner> Hello
17:01:17 <Rucknium[m]> Meeting time: https://github.com/monero-project/meta/issues/773
17:01:21 <Rucknium[m]> 1) Greetings
17:01:22 <isthmus> Hallo
17:02:07 <one-horse-wagon[> Hello
17:02:59 <Rucknium[m]> 2) Updates. What is everyone working on?
17:04:26 <blankpage[m]> Hello
17:06:16 <tevador> I've been updating the Jamtis specs and finalizing the checksum algorithm. I'm working on new URI schemes for Jamtis (payment URI and wallet export/import URI for the various tiers).
17:06:44 <Rucknium[m]> Me: Wrote reproducible code for collecting data on p2pool payout outputs: https://github.com/Rucknium/misc-research/tree/main/Monero-p2pool-Output-Stats . My initial calculations were correct. Over the last three months (heights 2721396-2786779), p2pool has found 7% of blocks. 15% of all outputs on the chain during this period were p2pool payout outputs.
17:08:46 <isthmus> I sent over my first round of OSPEAD review notes to Rucknium. Something like six pages of questions and comments. My impression is very positive! The work is very thorough, the research is well-executed, and I believe the approach proposed will improve the safety of Monero and its users.
17:08:48 <isthmus> Now poking around at some misc Monero side projects, we’ll see which turn out to be interesting
17:09:41 <blankpage[m]> 15% seems like a lot of chain bloat 
17:10:31 <blankpage[m]> I suppose this was to be expected with p2pool's tiny payouts
17:11:02 <rbrunner> Well, at least size-wise the chain does not get bloated because those transactions are still small
17:11:14 <rbrunner> Have a look at a sample tx that was mentioned last week: https://xmrchain.net/tx/f6c1cfcce9e531d3147f249638233e40a71153f47cac253c45d3f5d1fd06d7dc
17:11:19 <tevador> coinbase outputs are tiny (under 40 bytes) compared to normal outputs
17:11:25 <Rucknium[m]> Thanks, isthmus! I am reading through the comments and questions and I will respond soon. Next steps on OSPEAD are: ArticMine sends me his review, I do any necessary modifications to the OSPEAD proposal, then I do initial estimations, then share initial estimates with the committee, then revise.
17:12:19 <blankpage[m]> Oh I see. So the problem is mostly "what are the impacts of 15% of decoys being from p2pool" rather than chain size
17:12:40 <rbrunner> That's how I understood it
17:13:59 <Rucknium[m]> Coinbase tx outputs may be small, but those tiny p2pool payouts have to be consolidated, which implies a full RingCT for each one.
17:14:04 <rbrunner> And of course how things would look should p2pool get wildly successful :)
17:15:09 <tevador> There have been suggestions to remove ring signatures from transactions that just consolidate coinbase outputs.
17:15:13 <Rucknium[m]> IMHO, the main research question is how to handle decoy selection when there are all these p2pool outputs are now being selected for rings.
17:17:00 <blankpage[m]> Seems to also imply we would hit large majority of outputs (in a given window) being p2pool at p2pool adoption hit 50% (which is itself very desirable)
17:17:37 <Rucknium[m]> Just a reminder: changing consensus rules on how to construct txs with coinbase inputs would require a hard fork. Changes to the standard decoy selection algorithm to avoid coinbase outputs would not require a hard fork.
17:20:41 <tevador> After the Seraphis update, coinbase outputs will become significantly larger. Something too keep in mind.
17:21:11 <rbrunner> What gets added?
17:21:31 <rbrunner> Just the larger addresses?
17:21:38 <tevador> One DH pubkey and the encrypted address tag. Total of 50 bytes per output.
17:23:31 <atomfried[m]> i just wanted to inform you that the firo research team is currently looking into [curve trees](https://eprint.iacr.org/2022/756.pdf)
17:24:02 <blankpage[m]> I suppose there are two fundamental directions to take:
17:24:03 <blankpage[m]> 1) Not including coinbase in rings
17:24:03 <blankpage[m]> 2) changing p2pool in some way so that it does not produce such an overwhelming number of outputs
17:24:03 <blankpage[m]> The tradeoffs are not clear to me, but it is an interesting problem
17:24:29 <Rucknium[m]> I should write some calculations on the number of bytes that p2pool adds to the chain as a percentage of total chain bytes.
17:25:56 <rbrunner> I followed some discussions that included sech1, the author of p2pool, somewhere recently, and got the impression that 2) is quite a tough nut to crack
17:28:36 <tevador> The p2pool payout consolidation transactions offer practically zero privacy because the ring signatures all contain one member that is a payout to one specific address from the p2pool sidechain.
17:29:30 <tevador> Those outputs can be marked as spent in practice, so using them as decoys is pointless.
17:29:30 <Rucknium[m]> I would lean toward (1), but it requires more research. In the abstract, it would reduce the privacy of p2pool miners. Given the very distinctive consolidations of p2pool outputs, I'm not sure it's much of a material reduction in privacy. And mining is pretty private, anyway. The coins have no prior history.
17:29:45 <isthmus> I'm still working on wrapping my head around the dynamics, variance tradeoffs, etc. Definitely does seem like a tough nut
17:29:45 <isthmus> Mooo said something a few days ago that I've been wondering about; would it make sense to have different p2p chains for different scale entities (small one for low hashrate high payout rate, and another one for big mining operations with more hashrate and a longer timeframe (not going to drop off the network after 4 hours of mining)
17:30:33 <Rucknium[m]> isthmus: There is already the main p2pool side chain and p2pool "mini" for low hashrate miners
17:30:43 <isthmus> 👍
17:32:16 <rbrunner> Yeah, and making even more seems to be quite easy, basically write a config file and then go look for miners.
17:32:34 <sech1> each p2pool output has a wallet address attached to it in sidechain data, so using them as decoys is pointless. They will all either use the same address in all inputs, or different random addresses - both cases can be used to eliminate all p2pool decoys
17:33:10 <sech1> miner consolidation -> all inputs use the same address in decoys, random transaction -> random non-matching addresses
17:33:33 <sech1> so it makes sense to treat coinbase output differently in all transactions
17:33:54 <blankpage[m]> It looks like the idea of excluding coinbase tx from rings has been raised before in 2019:
17:33:54 <blankpage[m]> https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43
17:34:00 <sech1> I often see some transactions not using coinbase decoys at all. It's some modified decoy selection algorithm.
17:35:05 <isthmus> Woah, really?
17:35:09 <isthmus> cc: neptune
17:35:28 <isthmus> That could be interesting to look into
17:36:00 <sech1> yes, these transactions also avoid selecting old (> 1 year) decoys
17:36:10 <Rucknium[m]> For a low number of inputs, there is a random chance that no coinbase outputs get included in a tx, right?
17:36:16 <sech1> someone (probably an exchange or a swap service) is running modified wallet
17:36:42 <sech1> no, I've seen transactions with dozens of inputs and no coinbase decoys
17:36:55 <blankpage[m]> Also Justin gave a presentation on the idea:
17:36:55 <blankpage[m]> https://www.youtube.com/watch?v=Z0P7rWsSGLA
17:36:55 <blankpage[m]> I guess this was all before p2pool though
17:37:48 <Rucknium[m]> There is this paper (I haven't read it) Wijaya, D. A., Liu, J. K., Steinfeld, R., & Liu, D. 2021, "Transparency or anonymity leak: Monero mining pools data publication." https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=37
17:38:15 <isthmus> @sech1 do you happen to have any of those txns bookmarked? 
17:39:51 <sech1> https://xmrchain.net/tx/2e85d9b813be04abae6e10094e1bef79c1dd43154c2af97ac21bf0fb79f9d0fc
17:40:25 <sech1> it's even bigger than 100 KB, wallet2 can't create it
17:40:46 <isthmus> 👀 tyty
17:40:49 <sech1> https://xmrchain.net/tx/8adc65b0e6f422fe30ff90edec5836cb89adc17387eada48bbcb55bbcc284f44
17:41:34 <Rucknium[m]> sech1: Wow. Thanks!
17:43:07 <Rucknium[m]> The MAGIC Monero Fund committee has three seats open for elections. Voter and committee member (self-)nominations close on December 31. Only two people have nominated themselves for committee seats so far. The fund now has about 50,000 USD equivalent, split roughly evenly between XMR and USD: https://github.com/MAGICGrants/Monero-Fund-Elections
17:43:47 <Rucknium[m]> koe submitted a new Seraphis CCS proposal: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/369
17:47:22 <Rucknium[m]> It is great that he is planning to continue Seraphis work. My suggestion would be do the Seraphis paper update first so that the necessary math work can continue on that. We had discussed asking CypherStack to create a road map of what math work needs to be done to guarantee the safety of Seraphis on mainnet. IMHO, we should wait to ask them to create the road map until after koe is done with the paper update.
17:53:06 <Rucknium[m]> Any more comments? If not, we can end the meeting now.
17:57:58 <blankpage[m]> Thanks for the interesting discussions everyone
18:02:01 <isthmus> gg
18:13:18 <atomfried[m]> Hey tevador i think i found another pretty nice generator:
18:13:18 <atomfried[m]> ```
18:13:18 <atomfried[m]> 142A04VA: max4=210 max5=210 max6=28 err5=0.000000 err6=1.028801 avg5=0.000000 avg6=0.814462 GEN=[0x904a013ea, 0x12094022f4, 0x24101040e1, 0x42602025c2, 0x8492404b84]
18:13:18 <atomfried[m]> ```
18:34:46 <blankpage[m]> Chain bloat seems to generally be an unsolved problem for Monero
18:49:24 <fr33_yourself[m]> In my opinion it is Monero's greatest flaw, but tx-size decreases has helped significantly
18:49:39 <fr33_yourself[m]> I can't imagine how thing's would've turned out without bulletproofs
18:52:59 <fr33_yourself[m]> Does anyone have any approximates on tx-size after Seraphis? how many kb?
18:53:07 <fr33_yourself[m]> now it's between 1.5 and 2 kb right
18:56:18 <tevador> around 3KB for 2/2
18:57:52 <fr33_yourself[m]> so they could actually be larger than now?
18:58:43 <fr33_yourself[m]> What about long term chain growth though?
19:00:08 <tevador> slightly larger, but the ring size will increase from 16 to 128
19:07:15 <narodnik> atomfried[m]: yes you can create them trustless
19:07:24 <narodnik> that's why i said binary quadratic forms
19:08:04 <narodnik> there's also hyperelliptic class groups, but the security level barely passes
19:09:07 <narodnik> but you already have bulletproofs, so i don't see why not just adding some simple arithmetization scheme on top
19:09:25 <narodnik> so you dont need rings which is sketchy
19:41:49 <tevador> Curve Trees (https://eprint.iacr.org/2022/756.pdf) are not compatible with Monero's elliptic curve (they require elliptic curves with special properties).
19:42:25 <xenu[m]> I don't see any indication that P2Pool growth will slow. If that many outputs are already being created it would be unnecessary to have ring signatures when outputs are consolidated. From a practical standpoint, having consolidations without ring signatures make the most sense. Could this perhaps include more than one (or two) outputs to protect the real consolidated output?
19:59:10 <narodnik> tevador: do they need curve cycles, right?
20:01:00 <tevador> yes
20:29:21 <atomfried[m]> so we would need an extra curve just for the membership proofs?
20:42:22 <atomfried[m]> just out of interest, can someone explain to me why that would be a problem?
22:43:21 <theking[m]1> Question: p2pool's window is 2160. Could this be optimized? The window size is approximately the number of coinbase transactions that need to be made, so if it's lowered to 32 is that acceptable? There technically is a benefit to the pool; less coinbase transactions means less sweeping fees.
23:12:22 <UkoeHB> atomfried[m]: the membership proof has to be compatible with everything else (which is ed25519 right now)