16:01:17 MRL meeting in this room in one hour. 17:01:03 Meeting time! https://github.com/monero-project/meta/issues/1063 17:01:05 howdy 17:01:09 1) Greetings 17:01:13 Hey 👋🏽 17:01:17 Hi 17:01:18 Hello 17:01:23 Hi 17:01:47

Hello. 17:01:56 Hi 17:03:08 *waves* 17:03:21 2) Updates. What is everyone working on? 17:03:42 👋 17:04:07 I spent a few hours drafting feedback on Carrot. Still trying to wrangle review. 17:04:44 Me: Wrote a comment on possible risks of current txpool queries and the new proposed transaction propagation methods: "[Proposal] Change how transactions are broadcasted to significantly reduce P2P bandwidth usage" : https://github.com/monero-project/monero/issues/9334#issuecomment-2307824031 17:05:13 Starting to get review quotes back from auditors regarding Carrot 17:06:17 me: continuing fcmp integration, next task is addressing init pr comments and trimming the tree on reorgs / pop blocks 17:06:39 And writing in feedback from kayabanerve 17:08:32 3) Stress testing monerod https://github.com/monero-project/monero/issues/9348 17:09:25 0xfffc made some edits to the dynamic block-size-sync PR: https://github.com/spackle-xmr/monero/pull/26 17:10:15 I tasked myself with writing more fuzzing targets to get better coverage. The current ones for oss-fuzz I believe were written a long time ago. Let me know If anyone has experience working with AFL++ and would like to help. 17:10:57 I think that's all for stressnet. 17:12:30 <0xfffc:monero.social> Thanks for mentioning it. My apologies for being absent from meeting. ( I am on road ). This PR is updated, there will be one or two other separated PRs related to this fix. Fixing issues that we found during implementing this. 17:12:52 4) Research Pre-Seraphis Full-Chain Membership Proofs https://www.getmonero.org/2024/04/27/fcmps.html 17:13:26 I don't have much to say on FCMP++s today and will defer to jberman for any integration news. 17:14:45 I will bring up Carrot. I spent a few hours with jeffro256 going over the documentation, with regards to its definitions, accuracy, layout, etc. While I haven't completely finished my review, and there's still a topic to discuss on the Generate Address tier, I did suggest and strongly endorse changes regarding key derivation. 17:15:42 The current version doesn't solve the burning bug without an additional consensus rule. While minor and likely fine, I don't support such consensus rules due to their unforeseeable implications on collaborative transactions (a niche use-case yet one which may become more relevant with L2 discussions). 17:16:35 Do you want to lay out the details here? I'd be happy to open the floor on this issue 17:16:42 We did successfully propose a scheme which didn't require a consensus rule while maintaining the same goals however. 17:16:56 If that's okay with everyone 17:17:32 I'll also note there wasn't enough entropy in the scheme, opening a multi-target attack under specific circumstances, yet jeffro256 proposed a solution without increasing the entropy/transaction size so thankfully no performance penalty there. 17:18:24 I don't personally have a need to be specific. That's my high-level overview of the fixes we worked on. The new schemes seem unequivocally better by my view? I don't believe I'm censoring any downsides, even inadvertently? 17:18:43 So while we can be specific, if everyone is fine with hearing "identified issues resolved", we can move on :p 17:19:33 Well, there will be reviews and reviewers to hopefully catch anything left. 17:19:45 Yeah, I guess the only real downside is that collaborative transactions might stick out on the chain due to duplicated output pubkeys, commitments, etc 17:20:06 Malicious signers can always make their TXs stick out. 17:21:07 True. So yeah it's not a huge deal and might not be worth going into here 17:21:49 Smart collaborative protocols are always free to add additional rounds/rules to their participants if they want to prevent this fingerprint 17:22:11 The existing protocol had a DoS which would require a commit-reveal scheme to avoid. Removing the consensus rule enables saving a round of complexity in theoretical collaborative protocols. 17:22:49 This specific fingerprint, of which there are still several others to cause non-uniformity :p 17:23:26 TXs will always only be as private as to those who know about them. The fact in a collaborative TX, someone else knows about it and can point it out, is unavoidable. 17:23:40 It will take a while until we get to implement any such collaborative scheme, I guess? 17:23:55 Much other stuff ahead on the way there 17:24:08 Oh, yes, we're not doing that. 17:24:23 I just noted there would be a problem if someone tried and we don't have to have that problem. 17:24:32 Making it easier to try doesn't mean we are trying. 17:24:51 I certainly see the worth of the approach to try to see far into the future with fundamental protocol decisions. 17:25:57 Considering we resolved it without penalty (opening fingerprintable behavior when we already fundamentally have that, so another flavor isn't impactful), I support the changes I proposed. 17:26:14 I already see people fret "Buuuuut ... is it quantum proof" :) 17:29:50 The other big point was the different key exchange. To do it efficiently, we will need a Curve25519 library with full scalar multiplication, distinct from mx25519 (unless that lib was updated to support that functionality) 17:30:31 So that adds tech debt, but at least it's optional tech debt. You can use the ed25519 scalar-point multiplication and then convert the y coordinate at the end 17:30:38 Oh yes. The proposed key exchange was pointlessly complex in theory and would slow down scanning by multiple percent. 17:32:14 The practical reason for it is to avoid this extra library. We should be able to use most of an x25519 library to avoid the "new code" being notable, or we can implement the optimal theoretic key exchange in an even-slower-than-prior-theoretic practical manner. 17:34:10 The prior key exchange mapped from Curve25519 to Ed25519. cc jberman on how much mapping between curves harms performance due to the performance costs of the inversion. 17:37:46 Is anything of this possibly relevant for the implementation of atomic swaps post-Carrot-introdution? 17:37:58 *introduction 17:38:35 Forgive if the question is not even wrong :) 17:38:40 Not any more than usual. 17:39:23 Ok 17:41:50 Also kayabanerve proposed removing the cofactor clearing multiplication by 8, which we do for the current key exchange. I can't see a problem with this on first glance since if the counterparty's pubkey is in the prime subgroup, multiplying by 8 does not yield a more "unique" result. However, I would like @vtnerd's opinion on this since he worked on the fast scalar-point multiplic ation code used in wallet2 17:42:12 *is *not* in the prime subgroup 17:44:47 I don't understand much of that, but I believe to remember that this was also discussed with UkoeHB at least once. Don't remember the outcome. 17:47:03 We have 15 minutes left in the hour. Let's more onto a new topic: 17:47:13 5) Change how transactions are broadcasted to significantly reduce P2P bandwidth usage https://github.com/monero-project/monero/issues/9334 17:48:05 I added a comment in response to Rucknium https://github.com/monero-project/monero/issues/9334#issuecomment-2315416552 17:48:08 Monero's current tx relay protocol is very wasteful with bandwidth. There could be a protocol that provides a good balance of bandwidth, propagation speed, privacy, and reliability. 17:48:38 jeffro256: https://raw.githubusercontent.com/UkoeHB/Seraphis/master/implementing_seraphis/Impl-Seraphis-0-0-4.pdf footnote 11 17:49:21 boog900: I agree that the attacks using txpool queries would be expensive for an adversary. Yet, Dandelion++ is designed to improve privacy over bitcoin diffusion when the adversary is wealthy. 17:49:35 My question here is how many times is a full node broadcasting the same tx including as part of a mined node. 17:49:54 Anyway, I am not necessarily opposed to boog900 's proposal unchanged. I wanted to investigate the possible risks and take a long-term view. 17:50:30 I wonder "Where are we going?" with the tx relay protocol. 17:50:55 jeffro256: I can see the argument for removing it. If a subgroup pubkey was provided, the result is going to limited anyway 17:51:09 Can we get this excess bandwidth to ideally between 1x and 2x the Tx size? 17:51:12 There are stacks of papers on gossip protocols. 17:51:45 FWIW I would be for adding similar rate limits to what Bit coin does: 17:51:46 > Bitcoin will only send 1 request for a tx every 60 seconds: https://github.com/bitcoin/bitcoin/blob/2c7a4231db35060fa1ab66d29e8139f04edc85a4/src/net_processing.cpp#L104 Although this attack would still be possible with RequestTxPoolTxs unless we limited that message as well. A simple way would just be to not allow more requests than TxPoolInvs that we have sent to that node. 17:52:49 ArticMine: Newer proposals Strokkur and Shrec are supposed to get in that 1-2x range. They are newer than Erlay. 17:53:50 That is close to the theoretical optimal 17:54:38 boog900: The method to get the missing txs when a node gets a fluffy block: Does a node check that the list is from an actual fluffy block, or does it respond to any list of txs? If the former, then the txs would have likely already propagated through the network because they were in a mined block. 17:54:40 Where does Early come in and where are we now? 17:55:17 This is critical for scaling. 17:55:38 The node does not do PoW checks before sending the missing tx request 17:56:38 erlay reduces the amount of tx-hash broadcasts needed, IMO erlay would not be as beneficial to us as our txs are much larger than Bitcoin's 17:56:45 boog900's proposal could be a stepping stone toward Erlay. In current bitcoin core, there is the check to see if the "receiving" node already has the tx. That method is assumed to exist in the Erlay proposal. Erlay also has a set reconciliation method that is not in boog900 's proposal. 17:57:01 Basically Monero is much more wasteful than even current-day bitcoin 17:57:35 With FCMP++ this gap would widen as well 17:58:09 Yes but not by much 17:58:11 Right. The ratio of tx hash to the full tx data is much smaller in Monero than bitcoin 17:58:22 UkoeHB: thanks for the link! 17:58:23 so the amount of data we could save in P2P broadcasts compared to the amount used would be significantly less than Bitcoin 17:58:29 double? 17:59:29 The figures I have heard are 3-4kB 17:59:37 The set reconciliation method of Erlay has quadratic time complexity in the number of txs that each node is missing. 17:59:51 So yes about double 18:00:44 For BTC-level tx volume, that is ok, but the Shrec paper did some experiments and found that 800 tx/sec volume would occupy four CPU threads just with the set reconciliations. 18:00:45 My concern is minimizing the number of the tx is transferred as opposed to tx hashes 18:01:49 Possible alternative set reconciliation methods with different-order time complexities are evaluated in Boskov, N., Trachtenberg, A., & Starobinski, D. (2022). "GenSync: A New Framework for Benchmarking and Optimizing Reconciliation of Data." 18:02:19 we should be close to optimal just looking at full tx blob transfers with the new method, I think 18:03:13 You mean under 2x including the mined blocks 18:05:12 I think so yes 18:06:32 We should probably look into what's eating the rest of our bandwidth as it seems pretty high 18:07:35 roughly 38MB in 2.5 hours excluding tx messages 18:07:41 Yes that would be very helpful 18:07:49 with 12 connections 18:08:40 Is that excess bandwidth tx dependent? 18:09:08 with the new method tx broadcasts including hashes and blobs would have used ~15 MB 18:09:36 It includes block broadcasts and everything except tx-pool broadcasts 18:11:30 Yes block broadcasting is another issue. Are we broadcasting the whole block or just the tx hashes to reassemble the block from the tx pool 18:11:33 UkoeHB's comment is correct in what was my failure to consider. Apologies. You can so probe the last three bits. cc jeffro256 vtnerd 18:12:15 just tx hashes although the miner tx is always included 18:12:46 and the block is sent to every node, even if they have already sent it 18:14:14 This attack mentioned in the Seraphis impl footnote is mitigated by checking the ephemeral pubkey is in the prime subgroup, yeah? Normally this would be too slow to consider, but if you do it after a view tag check, then you only do the check rarely or in the malicious case 18:14:29 Nodes consume GB of RAM when relaying KB of txs. Do we know why? 18:15:14 The relative scale doesn't make sense to me 18:15:27 duplicating txs in the fluff queue is my guess 18:18:55 Say that there are five 100-KB transactions in 100 fluff queues. That's 50MB. 18:19:20 IIRC, unexpanded `cryptonote::transaction`s requires at least `5 + m` allocations where `m` is the number of inputs. Then that class is copied into `p` peer fluff queues for a total of `p (5 + m)` memory allocations during relaying (as a lower bound). That's not counting all the allocations during {de}serialization and any reallocations of containers during processing 18:20:08 we weren't talking about 5 txs during the spam though 18:20:37 That's about how long the queues are going to last, right? 18:21:10 if a lot of re-broadcasts line up the queue could get _a lot_ longer 18:21:28 the queue is made of tx-blobs right? 18:23:45 Oh you're right, nvm my comment if so 18:24:42 re-broadcasts happen after 5 mins then 10, then 15 increasing the wait by 5 mins each time upto 4 hours where it is capped 18:25:34 and they only happen when the function is called not exactly at the time the tx should be re-broadcasted 18:25:36 This is the first time I'm hearing about re-broadcasts 👀. So if the txpool is congested, the re-broadcasts would multiply. 18:25:59 which I found to be every 2 mins IIRC 18:26:12 using my PoC 18:26:14 https://github.com/monero-project/monero/issues/9348#issuecomment-2170629015 18:26:34 and the logs from monerod 18:26:48 The re-broadcast is just to provide even more reliability of tx propagation. Or something else? 18:27:47 yeah that, if we had no connections we would need the tx to be broadcasted again 18:28:06 That would help explain why performance is much worse when the txpool is congested 18:28:55 Wait, is re-broadcast part of routine operation or just under special circumstances? 18:29:20 routine 18:30:00 only based on time IIRC 18:31:21 We are 30 minutes into the next hour. Maybe continue the conversation next meeting? Or is there enough info to say that the methods should be implemented as-is? 18:33:12 I think work can begin on the new protocol, but I am biased :) 18:34:50 I would say leave some room for noise to be injected into the timings, to avoid spaghetti code later, but there are already some methods that allow txpool querying that could/should be modified. 🤔 The risk of an adversary inferring network topology increases with tx volume. 18:35:10 i thought this was implemented because of tx that _failed_ to broadcast 18:35:57 Sounds like a bug if its rebroadcasting tx that did not fail 18:36:30 Does this assume no increase in network size? 18:37:17 The number of txs needed to infer network topology increases with log(n). n being the number of nodes. 18:37:18 not as far as I can see, it is re-broadcasting every tx 18:37:44 That sounds like a bug 18:37:46 if we add rate limits we should be fine right? 18:38:05 if we only had 1 connection that dropped the tx we would need to re-broadcast 18:38:25 We had issues with tx-proxy failing to relay tx, and then changed the behavior to attempt to retry the broadcast 18:38:30 https://github.com/monero-project/monero/issues/9334#issuecomment-2307824031 18:38:41 Iirc this was changed at or around the hardfork 18:38:50 > Under some conditions, an estimator needs O ( s log ⁡ ( n ) ) cascades, where s is the number of edges of the node with the most edges in the network and n is the number of nodes on the network. The O ( ) order estimate of the number of cascades is interesting because it suggests that network inference with transaction arrival timestamps would become more feasible as transacti on volume rises. Assume that the number of nodes on the network grows at the same rate as the growth of transaction volume. This assumption would be roughly true if (1) each user makes a constant number of transactions, (2) the growth of transactions is due to new users, and (3) new users boot up new nodes in the same proportion as old users. 18:40:19 I don't know if rate limits would eliminate the issue. There are papers on the amount of noise that network inference estimators can overcome. 18:40:44 When tx broadcasts are tx-hashes re-broadcasts should become less of a problem 18:41:08 MEETING END. Discussion can continue of course. 18:41:28 But this is also the case when the adversary just listens for tx messages without probing 18:42:00 with enough connections/txs you could perform a similar attack 18:42:53 With more connections you can multiply your rate-limited queries :) 18:43:41 Sure but if we removed that possibility this attack is still possible 18:44:05 and the rate limits should at least help 18:44:37 And there are many methods to query txpools. Could be better to feign ignorance of specific txs. Ignorance could apply globally to all txpool query methods. 18:46:30 Bitcoin developers implemented diffusion since they thought it was probably good enough. The Dandelion++ creators showed that it was not good enough. 18:46:53 Maybe? maybe not? we need definitive numbers on how effective different attacks are before deciding on countermeasures that effect the protocol in that way IMO 18:46:54 And it took them two tries to get a robust protocol 18:47:56 how would we handle double spends? 18:48:32 if we ignore knowledge of txs 18:48:38 I can try to work on those numbers, but it will take a while since there are other things to do. I decided to look into this tx propagation issue instead of finishing up some black marble research since I knew devs were eager to get started on it. 18:49:27 The node knows it has txs, but it doesn't indicate to its peer that it knows. The node dumps the double spend. 18:49:29 Fair IMHO these attacks are extremely expensive/impossible so not a priority 18:50:00 dumping is what happens when the tx is known 18:50:29 unless we are going to ignore new txs randomly as well, I guess that would work 18:50:52 Does the node have to tell the peer that it's dumping the tx? I thought a recent change made it so a double spend was not a droppable offense? 18:51:28 no, it drops the tx before doing all the checks: 18:51:28 > Double spend checks, we check for tx-pool double spends before checking other consensus rules. It would be possible to create an invalid tx which uses a key-image of a tx you want to check for, send this tx to a node, then if you disconnect they didn't have the tx, and if you stay connected they had the tx (the invalid one was ignore for being a double spend). Although this atta 18:51:30 ck was added in tx_memory_pool: make double spends a no-drop offense #9218, 9218 is needed for network security and it would still be possible to perform a timing attack based on the time to disconnect. This attack also exposes the stem pool. Preventing this attack would require checking all consensus rules before checking for double spends, although this would allow a DOS, where 18:51:32 the attacker could spam a node with double spends that wont be accepted but the node will still do all the expensive crypto checks. It's also not just a statistical attack, this can be performed on a single tx to expose the nodes in the stem path it took. 18:51:47 jeffro256: Really interesting trade off. When using halvings (we don't), I believe the torsion check is roughly half a scalar mul. Without halvings, it's a scalar mul and three doublings. Over 100 TXs, we'd have 18:51:48 100 * 3 doublings 18:51:50 Or 18:51:52 3 doublings + 1 mul 18:51:54 1 mul will presumably be more expensive than 297 doublings. It's inherently 256 doublings. 18:52:07 The halving version may be more performant but that requires we impl and bench it 18:52:12 I'd just do the cofactor clear 18:52:27 AFAIK, feigning ignorance in push methods would increase bandwidth use. (The node sends us the full tx even though we already know it.) Feigning ignorance in a pull method like reconciliation would slow tx propagation. 18:54:20 seen as we are already using D++ the main problem I think would be learning the P2P graph as that could make certain attacks more easy by targeting certain nodes. 18:54:22 Knowing if a peer has a fluff tx is not a problem otherwise IMO. 18:54:44 so it would be good to know how effect diffusion is at preventing graph learning 18:54:50 effective* 18:55:29 which as far as I seen wasn't in your right up? except for a note it would be harder than Bitcoins old protocol 18:55:39 which as far as I seen wasn't in your write up? except for a note it would be harder than Bitcoins old protocol 18:56:01 You saw my comment that the original paper authors of the bitcoin-network-influence-through-tx-relay paper said it would be harder, but they didn't say how much 18:56:53 Exercise left to the reader I guess :D 18:57:50 AFAIK, it won't be simple because their original statistical method was tailored to the earlier "trickle" protocol. Somehow that would have to be modified. 18:59:32 Or maybe it would be easier to start with one of the papers that does network inference from cascades with noisy data. 19:00:24 Yeah probably 19:03:03 It could be nice to set up a tx propagation simulator one day. There are a couple of them from some papers. 19:04:50 I tried to run the one from D++ but I ran into a few issues and struggled to follow the code 19:05:45 Especially since now the fluff timers are set by a Poisson distribution instead of exponential. AFAIK almost all gossip papers with continuous time use exponential timers. None use Poisson. One used truncated normal I think. But then the protocol could be put into alignment with the theory, instead 19:06:18 In July the maintainer updated the D++ code to Python3 IIRC 19:07:03 The memorylessness of exponential timers helps with theoretical analysis a lot. 19:07:29 Yeah I definitely think we should move fluff timers to the exponential distribution 19:08:08 I don't see any downsides to doing that. Probably a good idea. 19:08:16 I would expect the first spy estimator to be a lot better using the Poisson distribution 19:08:27 maybe not a lot but at least better 19:10:08 You've seen it, but here is my comment on that for reference: https://github.com/monero-project/monero/pull/9295#issuecomment-2260998091 19:10:09