10:07:46 "Seraphis meeting today at 18...." <- in which room was this meeting? 10:13:37 #no-wallet-left-behind:monero.social atomfried 14:29:36 Meeting 2.5hr 17:00:08 meeting time https://github.com/monero-project/meta/issues/786 17:00:08 1. greetings 17:00:08 hello 17:00:24 Hi 17:00:28 hello 17:00:39 Hello 17:00:40 hi 17:00:51 hello 17:01:27 Hi 17:03:12 2. updates, what's everyone working on? 17:04:29 Released my analysis of mining pools delaying tx confirmations: https://www.reddit.com/r/Monero/comments/10gapp9/centralized_mining_pools_are_delaying_monero/ . Already HashVault, MoneroOcean, and SupportXMR have started updating their block templates more frequently, according to the pool operators and sech1. 17:04:58 UkoeHB: I'm currently looking for a task 17:05:33 With P2Pool, which already had a frequent update policy, about 60% of Monero's blocks are now being mined with frequent template updates, decreasing the time to first tx confirmation. 17:06:03 Hello 17:06:24 I'm working on understanding the computational complexity issues of OSPEAD. 17:06:26 shalit[m]: Would you have time for a chat with me on Matrix in about 2 hours time? We could look at it 17:06:45 Fantastic news on the template updates. Very strange that this hadn't been noticed earlier. Any idea how long this has been an issue? 17:06:56 me: finished my cleanup/review pass on the seraphis library (took almost 2 months wow - over 50k lines is a lot) 17:07:22 right now doing some finishing touches related to practical enote store handling 17:07:55 rbrunner: yeap, sounds good, so in 19:00 UTC? 17:08:08 blankpage: I don't know how long it's been an issue. Possibly since the beginning of Monero. 17:08:45 I will probably finish the work on the knowledge proofs this week (at least a first functional version with basically all the functionalities that we have today and a bit more) but it will probably change a bit when we go to testnet as the integration with the wallet and new bugs may appear. I would like to thank Koe also for always taking the time for reviewing it thoroughly. 17:09:03 I have been working on my OSPEAD review. It is now at the point of completing the verite up. 17:09:03 I have provided Rucknium with timelines and preliminary results. 17:09:59 Im still working on bp++ implementation, mainly comparing the paper and the c code (not haskell code), hopefully something more tangible next week (this is definitely dragging too long, sorry) 17:10:31 Someone on Reddit suggested checking these repos and creating GitHub issues to change the default block template update time: https://github.com/oliverw/miningcore , https://github.com/zone117x/node-open-mining-portal 17:10:40 thanks vtnerd 17:10:54 Thank you, ArticMine ! 17:12:46 3. discussion 17:16:06 any topics anyone had in mind? on my end, these PRs could use more review https://github.com/monero-project/monero/pulls/UkoeHB 17:18:24 In "Avoid selecting coinbase outputs as decoys" https://github.com/monero-project/research-lab/issues/109 I say that this would be a wallet-level change. Now I am not sure if that's totally correct. Would monerod need to change what it sends to wallet software, i.e. exclude coinbase outputs from get_outs RPC call? 17:20:24 I'm not familiar with exactly how wallet2 does it.. but probably yes 17:21:32 This would require a separate call for coinbase outputs 17:21:49 Same here. But as it's only one software package, I don't think it would matter too much exactly where one changes code 17:21:58 Probably a good question for jberman , too 17:23:50 It could matter because a old-version wallet software could connect with a new-version remote node (or vice versa) and then...? And if I'm an old version wallet that wants to spend my coinbase output (from P2Pool, let's say), and I don't see my owned output in the reply from monerod remote node, what would I do? 17:24:24 This is if the change would happen outside of a hard fork boundary. 17:26:05 The RPC interface is somewhat flexible regarding compatibility, I think you could add something to the RPC answer of `get_outs` that tells the wallet what to expect 17:26:24 and then react accordingly 17:27:05 (the new wallet would find out whether it talks to a new or an old daemon) 17:30:25 Ok. I'm not sure of the next steps with this idea. I guess we can leave it open for a while longer and see if any arguments to the contrary surface. I've described the privacy risks of the status quo. 17:32:18 It would have to be implemented only at the wallet level unless it is done with a hard fork 17:33:13 it increases the complexity of making txs which basically increases dependency on the core wallet implementation 17:34:31 not that there are many txs being made with anything else, but it's still a cot 17:34:32 cost 17:36:22 anything else to bring up? otherwise we can end the meeting early 17:38:10 ok I'll call it here, thanks for attending everyone 17:40:16 Thanks for hosting 18:05:49 There's a bit of work involved at the monerod db level too in addition to changes to the RPC interface. Would need to start storing both the cumulative count of coinbase and count of non-coinbase outputs at each block, separately. Would need a db migration to store those counts for existing outputs 18:23:55 jberman[m]: idk if cumulative counts would quite work; without a hf coinbase and regular enotes would still share an address space 18:28:17 not sure I follow there 18:30:12 you could bucket coinbase and regular enotes separately in the db without a hf today 18:37:15 cumulative count is just a compact representation of the index, if you are bucketing the index then you need a different strategy; one possibility is just recording the number of coinbase enotes per block; if coinbase enotes are always ordered at the beginning or end of a block then you can infer their indices from the existing cumulative count 18:45:31 Ah, ya I see what you're saying. Ya I agree recording num coinbase enotes per block alongside total cumulative count is a better strategy 19:05:24 Welllll... nevermind. I think in theory, it would make more sense to start using different indexes for coinbase enotes + non-coinbase enotes separately when selecting a decoy. I agree that cumulative amounts aren't enough, the daemon would also need to store the coinbase index for each coinbase enote and non-coinbase index for each non-coinbase enote. You wouldn't need a hf this way though, the wallet could still ultimately 19:05:24 reference its chosen outputs by global index in the final ring 19:06:08 Why I think this is the way to go: let's say p2pool creates the last 90k enotes out of 100k in the chain. The way the decoy selection algo works.. a user spending a non-coinbase output is going to be heavily affected by p2pool into selecting those recent 10k non-coinbase enotes, versus older non-coinbase enotes in the chain 19:07:22 Considering the point of the change is to avoid the impact coinbase outs have on decoy selection, it makes sense to separate the 2 types completely when selecting decoys (I think it would probably even make sense to consider using a different distribution with different params for each type since spending patterns on coinbase enotes are going to be way different than normal enotes) 19:12:28 yeah if you don't want to have to 'reattempt' or hack the decoy selection algorithm a bunch then you can lens the index set to get separate views of coinbase vs non-coinbase, then map back into global space after decoy selection