17:00:01 meeting time https://github.com/monero-project/meta/issues/776 17:00:02 1. greetings 17:00:02 hello 17:00:23 Hi 17:00:24 Hi 17:00:42 hi 17:01:33 Hi 17:03:04 2. updates, what's everyone working on? 17:04:10 me: continued cleanup/review of the seraphis lib. I am at least 2/3 done, and finding plenty of things to tweak, optimize, and generally clean up. I also reviewed tevador's updates to the jamtis spec, and his new URI spec (both looking good to me). 17:04:32 More data analysis of p2pool outputs. Also looking at tx confirmation latency. And writing responses to isthmus's comments on OSPEAD. 17:04:52 I've been working on Jamtis URI schemes: https://gist.github.com/tevador/500d5d32d5ecc73b56997e12a9d2b20e 17:05:42 not much to report again :/ there is a c version of bp++ for reference that will definitely help. otherwise its been doing stuff on other projects or vaca time 17:05:59 also @vtnerd all the seraphis PRs have been updated based on your comments if you want to review again :) 17:06:31 yeah will circle back through that list again 17:06:37 thanks 17:06:49 vtnerd: where can I find the C code? 17:06:59 vtnerd: Do you have a reference for that C version? 17:07:17 https://github.com/ElementsProject/secp256k1-zkp/pull/207/files 17:07:52 Thanks 17:08:00 its written for a different crypto lib so it cant be used directly, but rough numbers can be used and compared against bp (I think) 17:08:14 it's a pretty huge diff for a proof, BP and BP+ are only 1k lines 17:08:20 Thanks. Much more readable than haskell. 17:08:50 I've just been working on a project to analyze rings that differ by only one ring member https://github.com/Mitchellpkt/ringxor 17:08:50 That implementation runs in ~O(N^2) and based on benchmarks this will take about a month to exhaustively check ring pairs. However, I have a ~O(N) solution in mind which will probably bring it down to sub-day on a decent machine. 17:08:50 h/t @rucknium shared a transaction with me that kicked this whole thing off, @neptune is going to help with the data, and @gingeropolous has been helping me get set up on research infra 17:09:35 I guess this one is 1k lines src/modules/bulletproofs/bulletproofs_pp_rangeproof_impl.h 17:10:50 3. discussion 17:13:11 anything to discuss today? 17:13:51 I have number on the bytes added by p2pool coinbase txs. Over Oct-Dec the p2pool coinbases added 23 MB. That's 0.53% of the total bytes added to the blockchain over that period. p2pool found about 7% of blocks. 17:14:25 makes sense 17:14:47 p2pool miners would generally have to consolidate the payouts before making them spendable. That would cause X bytes to be added for each ring signature. 17:15:07 X is...something that someone could tell me 17:16:01 Nowadays, every tx input has 2-3 p2pool decoys, which stick out like a sore thumb. 17:16:34 should be 640 bytes per input 17:17:26 Would it be possible to get a rough estimate how much those consolidations will add to the blockchain? 17:17:36 They seem to be much, much heaver at first sight. 17:17:58 IMHO, it would make sense to implement a no-coinbase decoy selection algorithm at the same time as (hopefully) the new decoy selection algorithm from OSPEAD is implemented. For implementation simplicity and so not to cause so many "anonymity puddles" in the ring member distributions. 17:19:13 rbrunner: Yes. Best way would be to just multiply the number of outputs in each p2pool coinbase tx (which I already have) by 640 bytes. That would be missing the weight of the output side, but that may be ok as a good approximation 17:19:15 with seraphis binned ref sets you need to select from a contiguous integer range, you'd need to segregate coinbase from normal enotes 17:20:51 With this idea, you would spend coinbase enotes with rings that only consist of coinbase stuff? 17:21:13 with "a no-coinbase decoy selection algorithm" 17:21:17 you could implement a coinbase consolidation tx type that only allows coinbase inputs without ring signatures and only range proofs on outputs 17:21:52 Yes, somehow you must be able to spend coinbase enotes :) 17:22:19 coinbase ownership is largely public information, so consolidating without ring signatures wouldn't necessarily be terrible 17:23:08 "That implementation runs in ~O(N..." <- That's quite interesting. Can you elaborate if that's okay? 17:23:13 With quick calculations, I am getting 373,068,160 bytes from just the inputs/ring sigs on consolidation txs. p2pool had 582,919 payout outputs during this period. 17:24:21 Coinbase consolidations without ring signatures sounds like a reasonable solution. 17:25:20 Sure @ghostway[m] happy to elaborate, here's what I have in mind: 17:25:20 I was thinking of it like this: Each output on the chain is a letter. Each ring signature is a word, with the letters [outputs] in chronological order (“ACBDE” –> “ABCDE”). 17:25:20 We eat the cost once to sort the list of words (rings) lexicographically. Then you make two fast passes over it, one where you compare each ring that starts with the same letter, and then a second pass where you compare against every ring whose first letter is my second letter. 17:25:20 In other words, Let l_{i,j} be the jth letter of the ith word. The "first letter" pass only compares words x and y if L_{x, 0} = L_{y, 0}. And the “second letter” pass only compares words x and y if L_{x, 0} = L_{y, 1}. Because we’re looking specifically for “differ by one” rings, you don’t need to make any further passes! I think this is kind of a pigeonhole principle thing. 17:25:20 And the reason this doesn’t subtly become O(N^2) for checks in the passes is because of the initial lexicographical sort (arguably the real magic here). If you’ve got the dictionary open to words that start with F and you want to check against other words that start with F, you already know where they are! You only need to thumb pages until you hit a word starting with an E or a G. 17:25:42 According to this total blockchain growth in those 3 months was between 4 and 5 Gigabytes: https://localmonero.co/blocks/stats/blockchain-growth 17:25:46 Combining that with the 23 MB from the p2pool coinbase txs, that's 9.2% of all bytes added to the blockchain during this period. 17:26:15 Right. 10% only to "digest" those enotes. Hmmm. 17:26:16 rbrunner: I have 4,302,893,381 bytes in my data 17:26:31 sgp_: iirc you have been advocating about coinbase enote issues for years 17:26:44 https://github.com/monero-project/monero/issues/6688#issuecomment-1190753103 17:26:46 sgp[ 17:26:55 sgp[m]: ^ 17:27:02 sgp: 17:27:44 would this be wallet or consensus enforcement? 17:27:55 Coinbase consolidations without ring signatures will also help reduce fees for consolidations which is a problem for small miners 17:28:14 Cool trick isthmus,, had to guess that it's about ordering :) 17:28:26 that github comment neglects the fact that real p2pool spends are easily recognized in practice 17:28:53 Agreed 17:28:57 But the problem may come back with the binned approach of Seraphis, if we are not careful, do I understand that correctly? 17:29:05 gingeropolous: Changes to decoy selection could happen at the wallet level. Changes to allow coinbase outputs to avoid ring sigs would require consensus changes (hard fork) AFAIK. 17:29:09 ty ghostway[m] ^_^ 17:29:54 rbrunner: no, if you want coinbase consolidations then coinbase enotes should be completely segregated from normal enotes (only spendable by consolidating) 17:30:22 lower p2pool consolidation fees would be a big plus for mining decentralization 17:31:01 Right. It would also decrease the tx fee that p2pool miners pay for consolidations :) 17:31:08 isthmus: I thought you had to compare it as a set of the people in the ring though? 17:32:48 "with seraphis binned ref sets you need to select from a contiguous integer range": So you number the two types of enotes independently, somehow? 17:33:05 yes, just dump them into two different lists 17:34:11 That could possibly have some repercussions in the codebase ... but yeah. 17:34:36 yeah it causes some wallet-side headaches especially 17:34:57 because there is a segregated balance 17:35:04 Yep, @ghostway[m] when it "compares words x and y" in the analogy that corresponds to taking two different rings and comparing their ring members, to see if they overlap by all but one ring member (in which case it gets marked as a DBO ring pair, otherwise it moves on to the next two rings to compare) 17:35:30 s/DBO/"differ-by-one" 17:35:43 That doesn't sound O(N) though... 17:35:48 So would probably good to know early if we really start to march into this direction with Monero transactions 17:36:25 ghostway[m]: it should be O(kN) 17:36:35 We probably should, wishing for p2pool becoming the largest pool. 17:36:42 Sure, ok 17:37:38 Will probably be the horror to put this into `wallet2` still. 17:38:01 rbrunner: probably better to wait until seraphis 17:38:32 So maybe wallet3 specification should be there (and also wait for seraphis) 17:38:34 it's also easier with seraphis because membership proofs are separate from ownership proofs 17:38:34 Yea koe said it 17:40:11 Well, yes, dev time going into this with the "old" codebase would probably delay Seraphis 17:40:13 rbrunner: I pretty much agree. If nothing is done, then either we believe that p2pool has little chance of getting larger or that we don't care much about effective ring size shrinking. 17:40:14 Decoy selection for non-mining users can be changed before Seraphis. Doesn't require a hard fork. 17:41:34 Is it hard to exclude coinbase outputs in the old codebase? There is no binning, so you can avoid those issues. 17:41:45 And what then for miners? I am a bit confused 17:42:34 Haha yea +1 @UkoeHB O(kN) better notation than "2 ~O(N) passes". Though to be thorough it is true that *within a given letter* if there are F words starting with the letter 'f' we have to make (F^2-F)/2 checks. It's just that there's a huge number of letters (66921481 at time of writing) and only a handful of words starting with each letter, so those go by very quickly and zooming out it's effectively O(kN) 17:42:35 They don't select coinbase outputs as decoys either. They use the coinbase outputs as the real spend :D 17:42:58 So coinbase consolidations would be even more obvious than they are now. 17:43:02 Ah, ok. 17:43:02 Hard now than coinbases have more than one output. Otherwise, not hard. 17:44:12 So that's no contribution against any size saving, just the "nonsense" decoys get avoided, right? 17:44:41 Right. To address the privacy issue 17:44:52 Ok. I think now I get it. 17:45:26 But now the rings that do have coinbase enotes become somewhat nonsensical :) 17:45:45 Actually, probably not too hard, since the node can tell wihch outputs are locked, so it probably has access to the amount, and can thus see which outs are coinbases. 17:46:14 "sgp_ (New Account: @sgp:..." <- https://medium.com/@JEhrenhofer/lets-stop-using-coinbase-outputs-da672ca75d43 17:50:01 Well, and now, any volunteers to code that ... :) 17:50:15 ok made an MRL issue for comments https://github.com/monero-project/research-lab/issues/108 17:50:30 Initially the focus was that the behavior of users never conceivably spent coinbase outputs, but that's no longer the case. "Normal" people (not just pools) now spend them. It may be tempting to sever these coinbase outputs from the normal decoy set if they grow large, but the benefits are less clear to me 17:50:36 I will let it marinate for 1-2 weeks then implement it in the seraphis lib if there seems to be consensus 17:50:37 Thanks UkoeHB , will review 17:51:08 I guess it's less than trivial to put that into the library, for some newcomers? 17:51:19 *more 17:51:34 adding coinbase tx type only took around 15hrs I think, this may take a bit more due to balance segregation 17:51:46 For you as the author. 17:52:09 Can they use the current decoy selection algorithm code and reroll on coinbase enotes? Or does that introduce second order effects? 17:52:10 yes a newcomer would take quite a while, since you need to learn how the library is put together 17:52:36 Ah I think there is a second order effect if the ratio of normal enotes to coinbase enotes is not a constant. And I would NOT assume it to be constant. 17:52:50 🤔 17:53:14 (it'd be OK to re-roll the whole ring. I just mean you can't throw out and re-roll one output) 17:53:23 isthmus: shouldn't be constant since p2pool is a minority of blocks 17:53:36 * isthmus nods 17:53:51 Yea that's probably not the right approach then 17:54:00 * isthmus walks back the suggestion 17:57:06 ok we are approaching the end of the hour, are there any final comments or questions to address? 17:59:30 I'll call it here, thanks for attending everyone [post-meeting discussions: https://libera.monerologs.net/monero-research-lab/20230104#c186007]