01:52:36 https://usercontent.irccloud-cdn.com/file/S9RyzbCN/image.png 01:52:55 In many (but not all) of the rigs there's a band at ~80% to the right 01:52:59 Top 4 rows -> no band at 80% and does have newer outputs 01:53:03 Following half dozen rows -> band at 80%, no newer outputs 01:53:11 Almost looks like somebody tried to implement binning, but they only implemented it around the real spend 02:05:52 isthmus: Can you share a link to that transaction? 02:08:06 https://monero.hashvault.pro/explorer/tx/a2a77859ede9405b37f807f5a7798d5ba98403e2344c5fc214482f669f9f3f4d 02:08:37 (from ofrn in -dev) 02:09:52 Quite an unusual decoy selection method, both from an intra- and inter-ring perspective 02:20:35 The real spend appear to be the 3/5 ring sizes from 2017/18 (?).. 02:20:35 When spending a very old output (2017), are decoys selected from 2016/earlier? Or is spending these old outputs a privacy problem in of itself. 02:20:35 Its weird that some go 2018-2021 3yr, 2019-2022 3yr, then 2017-2021 4yr. 02:22:22 Also, those 0 ring membeds/0input are p2pool, correct? 02:22:22 I found a tx with 3 of those, essentially eliminating 30% of the potential spends. 02:22:22 Wouldnt it be a good idea to ignore coinbase tx when selecting decoys? 03:39:40 How realistic is this: 03:39:41 Maybe an exchange preparing for the hardfork by consolidating their bullrun transactions Maybe the "wallet maintenance" from exchanges like binance was actually them just being incompetent and constantly having to resync their wallets from 0 03:40:05 * Maybe an exchange preparing for the hardfork by consolidating their bullrun transactions. 03:40:06 Maybe the "wallet maintenance" from exchanges like binance was actually them just being incompetent and constantly having to resync their wallets from 0 03:40:30 And they want to speed it up with viewtags once they go live 03:41:28 Oh and they want to avoid the increased fees coming with the fork 04:38:21 "Oh and they want to avoid the..." <- Nah. They paid the highest fee possible 04:38:44 (The post-hardfork fee) 04:39:25 Well they obviously want to get home for dinner, still cheaper than doing it after the fork, no? 04:40:43 Nope, same price 04:40:43 5x the current average. 04:40:43 One of first things ooo noticed was the fee was 5x the current (hard fork fee) 05:01:17 Maybe testing their proprietary wallet software ahead of the fork? 11:46:08 Increased fees? Will there be any change to the dynamic block size? 11:51:43 "Maybe testing their proprietary..." <- No change to block size 12:31:24 "No change to block size..." <- Oh ok, so from where would the increased fees come? 12:51:58 Post hard fork (v0.18) fees are 5x current. 12:51:59 They are using the new fees 13:15:58 I believe what is being done is that the lowest tier of fees is being removed and instead of 4 teirs there will be 3. Is this correct? AIUI what is currently default is low priority and the 5x is normal 13:17:45 no, the fee code changed from "x/5" to "x*0.95" (plus more fee tuning), so it's 4.75x increase but there are still 4 tiers 13:18:47 Thx 13:52:14 And what's the purpose of increasing fees on base layer? Monero Cash incoming ? 😅 13:52:14 Is there somewhere where I can read more about this? 14:01:10 Spam mitigation. The fees go to miners, so I guess they'll get a bit more cash, but it shouldn't be a large increase I think. 14:02:02 The commit that made the change links to a PDF which lays out the changes with formulae. There's also an issue about this with discussion in the monero-project/meta repo. 14:07:29 The rise of the minimum node relay fee is required to allow scaling of the block weight at minimum fee. 14:07:30 The current 0.2x minimum node really fee is a historical artifact from when fees were much greater due to the 13.5 typical transaction weight resulting in much higher fees. 14:11:03 Good point. Right now blocks that are full barely go above 300k, they're usually 300k + 200-500 bytes, so median weight grows very slowly. 14:14:59 If the 100 block median were to remain above the 100000 block median for an extended period of time. The current minimum node relay fee would allow for a spam / DDOS attack against the nodes at little or no cost. 14:15:56 This is because this spam transactions would not get mined 14:33:59 Seems like fees would get to 3 or 5 cents no? Still good for micro-payments 👍 14:46:59 More like to 1 cent 14:57:37 meeting 2hr 16:25:40 ignoring coinbase TXes when selecting decoys has been discussed before but maybe it's time to revisit now that p2pool is producing a LOT more coinbase outputs than there were before 16:57:03 "Good point. Right now blocks..." <- block size (last 720 * 14 blocks): median - 37.6KB, mean - 66.6KB, max - 315.2KB 17:00:21 meeting time https://github.com/monero-project/meta/issues/715 17:00:26 1. greetings 17:00:29 hello 17:00:45 Hi 17:00:50 Hello 17:01:34 hi 17:01:37 hello 17:01:43 hiya 17:01:43 wave 17:02:29 hi 17:03:40 hi 17:04:08 2. updates, what is everyone working on? 17:06:11 Based on mj-xmr's Python implementation of the `wallet2` decoy selection algorithm, I wrote an R implementation. With one million draws, the R implementation passes a K-S test against the `wallet2` implementation when the number of outputs to draw from is large. https://github.com/mj-xmr/monero-mrl-mj/pull/3 17:07:58 monerkon presentation on seraphis/jamtis features went solid I think, finished the ledger integration for the hf, finishing up reviewing 8076, got help from TheCharlatan on lws static building finishing up testing his work, planning to submit a new CCS soon 17:09:20 me: Got some basic unit tests of enote scanning running. At this point there is enough code in my seraphis library to begin writing a wallet. I still have various todos: deeper/more comprehensive unit testing of enote scanning, implement seraphis coinbase txs, implement ringct/seraphis transition txs (need to decide if it's worth the effort to do mixed-input-type txs), and some miscellaneous library improvements (e.g. still need 17:09:20 to look closer at using Curve25519 to speed up scanning). Also, on sunday I did a monerokon presentation about seraphis balance recovery, hopefully the video becomes available at some point. 17:11:25 I did a monerokon presentation of environmental impacts and a the ramifications for 51% and big bang attascks 17:11:30 (tracking progress of auditors via twitter of their supervisor) 17:12:36 I am starting on a comprehensive overview of the whole fee, scaling, and related security and spam issues 17:13:12 More like a reference on how the penalty and related issue work 17:14:04 ArticMine: You may want to talk with endor00 if you haven't already, since they are working on an analysis of the Monero "security budget". 17:16:34 Sure thanks for lettign me know 17:16:34 3. discussion, anything to discuss? there are the persistent many-input txs that have been showing up since last fall... 17:18:40 hardfork 17:18:53 I didn't consider the ring caching possibility, jberman. Thanks for pointing it out. I think when I read about caching rings, I just assumed that users would re-submit a tx soon after the ring was constructed, so there wouldn't be such a time lag between the decoy selection and confirmation of the tx in the blockchain. 17:19:25 The tx in question would be an egregious case of it. 17:21:11 in the best case it was just txs from some wallet with a lot of failed attempts to relay txs, nothing suspicious or interesting except broken tx relay and harmful edge case for ring signature cache 17:21:25 nothing interesting to discuss from research point of view 17:22:03 I'm in to discuss the hard fork too though we're probably missing some people 17:22:26 I'm here, but I would prefer a separate dev meeting for it. 17:23:44 Is it correct to say that our current predicament is the result of the multisig audit taking longer than expected? 17:24:24 Rucknium[m]: I'd say so 17:24:32 The auditors planned to send a draft last Friday, I'm not sure if they gave an update since then. 17:24:40 Since the scope of audit is unknown it isn't clear whether it's expected or unexpected duration of proper audit 17:26:10 it's ok to do asynchronous audit in private, but it isn't ok to do synchronous audit that blocks everything else in private 17:26:17 I haven't heard anything either 17:26:48 If there is nothing else to discuss, we can end the meeting early 17:27:13 Cutting (time) losses is always an option. Sunk cost fallacy, etc. 17:27:45 At this point I think a 2 week HF delay is realistic. 17:28:49 no objection from me 17:29:02 me neither 17:29:36 2 weeks = 10,000 blocks, so we can move fork height from 2668888 to 2678888 17:30:19 I don't think we can settle on a date until we have better clarity on the path forward with multisig, which is tied up by a 3rd party now 17:30:31 I'm waiting to get feedback from someone who works at Trezor, they also need to do a firmware update before we HF. 17:30:33 settle on a delay* 17:30:46 Is the 2 week period realistic? 17:30:53 is there any postponed research that is required for Seraphis integration ? 17:31:29 or implementation is the only missing component ? 17:32:06 ArticMine: we can decide on it during the dev meetin 17:32:46 So we finalize the new HF time at dev? 17:32:51 yes 17:32:56 Sound good to me 17:33:10 is there a date for dev meeting? 17:33:14 I'm not a software developer, so my opinion means little, but I would support keeping the current date and delaying the multisig fix to a post-HF release. 17:33:41 UkoeHB: ooo had a question regarding Seraphis, in case you want to reply https://libera.monerologs.net/monero-research-lab/20220622 17:34:01 Rucknium[m]: the problem is we want to give everyone enough time to update 17:34:02 Rucknium[m]: +1 17:34:04 I just do not want the HF to keep dragging on. If we can set a time and then sitick to it 17:34:20 stick 17:34:35 HF date should be set after code is ready, not before 17:35:03 agree with ooo 17:35:47 the good news is code seems pretty close to ready though 17:36:31 yes the remaining things are 1) trezor firmware update date 2) ledger finishing integration 17:36:53 jberman[m] "helped" (or has done everything for them) with the ledger integration but they still have to do testing etc 17:36:57 My point is 2-4 weeks would be fine, but if we are looking at months then may wennd to consider 2 HFs 17:37:06 no, it's not months away 17:37:09 ooo123ooo12345[m: there are no new innovations required, although the paper still needs security modeling/proofs. Once I am satisfied with the implementation, then I will take some time to update the paper as much as possible (including coinstudent's contributions), then go looking for help with the missing parts. 17:40:37 What are the heaviest parts that would require 1-2 years for Seraphis deployment ? is it possible to do rough breakdown ? 17:42:28 luigi also said he will be unavailable for a bit so that also means we will have to delay for 2 weeks 17:45:32 "the good news is code seems..." <- judging by size of patches for ledger (~100 lines monero/menoro, ~130 lines ledgerhq/app-monero) their firmware is much simpler than trezor 17:46:43 ok I think we can end the meeting here, thanks for attending everyone; the dev planning stuff can continue in -dev if needed 17:47:02 ooo123ooo1234567: I merely started to think about everything that needs changes for seraphis and got dizzy. In case you don't know yet: https://github.com/monero-project/monero/issues/8157 17:49:30 Soon it's half a year I wrote that ... 17:52:14 That issues doesn't focus on list of technical problems to solve on they way to Seraphis integration, unrelated. 17:52:20 s/issues/issue/ 17:53:57 * That issue doesn't focus on minimum list of technical problems to solve on they way to Seraphis integration, unrelated. 17:53:57 It was more something towards your "What are the heaviest parts" question, not the research question 17:54:41 ooo123ooo1234567: Trezor implements bulletproofs in their firmware (core/src/apps/monero/xmr/bulletproof.py), Ledger doesn't (it reuses the Monero code) 17:54:55 There is current tx protocol and the next, there will be just 1 migration plan. It doesn't matter how many wallets are there if all of them must follow current monero tx protocol. 17:55:19 https://github.com/trezor/trezor-firmware/pull/2232/files#diff-3775c9ee79201b0a4f1ce794d77425e0032cf098c18c362e0ae1e54b3732c9e5 17:55:28 jberman: ledger has security problem due to poorly implemented firmware, so it's kind of their trade-off 17:55:35 s/has/had/ 17:56:23 Did you test those ledger patches or real device ? or it's more like a draft ? 17:56:36 * Did you test those ledger patches with real/emulated device ? or it's more like a draft ? 17:56:53 maybe I missed something in my patch, ledger dev seems to think so 17:57:00 but yes I tested 17:57:08 "It doesn't matter how many wallets are there if all of them must follow current monero tx protocol" Unrelated :) To the points I wanted to get accross in that issue 17:57:16 bp+ txs are on testnet created with my ledger 17:57:53 "That issues doesn't focus on..." <- Response in your private messages 17:59:50 (I'm just the monkey in the middle. Aka relaying the message) 18:00:24 rbrunner: I mean that kind of issue should be created by someone who is writing Seraphis implementation 18:00:29 Well, I am quite sure that at least so far ooo and I read each other. 18:00:45 rbrunner: Not from you or ooo, from koe 18:00:58 With enough mutes and ignores communicating becomes a routing problem :) 18:01:03 rbrunner: 👍 18:01:28 In the worst case current Seraphis implementation would be just reference implementation and there will be another which will be integrated into monero 18:01:44 In the best case current Seraphis implementation will consider all edge cases and will be integrated into monero as is 18:02:33 Yes, all true, but I was writing from a point of view where most devs, especially wallet devs, had not idea yet at all what will hit them 18:02:54 That issue wasn't written by wallet dev 18:03:15 Don't understand. That's a problem? 18:08:18 it depends on the balance between noise and useful info, currently there is no alternative so it may be useful 18:08:33 Lol 18:08:52 It isn't clear why there is no single entry point for Seraphis 18:09:22 What do you mean with "entry point"? 18:09:26 which would contain high level overview of required steps and current progress 18:09:38 ooo123ooo1234567: Check pm 18:09:57 Er ... such things don't spring up by themselves, fully formed? 18:13:05 If it's possible to implement something and it isn't R&D then there is already clear plan for actions, but it isn't public yet 18:14:13 Almost 90% of msgs here are unrelated to any research 18:15:45 Maybe, but as I see it, much more than 10% of the messages here are useful one way or another, so there 18:15:59 ok, 99% 18:16:35 My last message wasn't research, sadly. Neither is this one. It really gets worse and worse. 18:30:06 ArticMine is there a link to see your presentation somewhere? 18:31:09 "no, it's not months away" <- or it's 18:38:41 https://github.com/MoneroKon/meta/blob/main/slides/2022/talks.md, these slides ? 18:52:31 "Rucknium: the problem is we want..." <- there are many problems at once