<r​ucknium:monero.social> MRL meeting in this room in one hour.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1063

<j​effro256:monero.social> howdy

<r​ucknium:monero.social> 1) Greetings

<x​mrack:monero.social> Hey 👋🏽

<b​oog900:monero.social> Hi

Hello

<v​tnerd:monero.social> Hi

<o​ne-horse-wagon:monero.social> Hello.

<a​rticmine:monero.social> Hi

<j​berman:monero.social> *waves*

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<k​ayabanerve:matrix.org> 👋

<k​ayabanerve:matrix.org> I spent a few hours drafting feedback on Carrot. Still trying to wrangle review.

<r​ucknium:monero.social> 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" : monero-project/monero #9334#issuecomment-2307824031

<j​effro256:monero.social> Starting to get review quotes back from auditors regarding Carrot

<j​berman:monero.social> me: continuing fcmp integration, next task is addressing init pr comments and trimming the tree on reorgs / pop blocks

<j​effro256:monero.social> And writing in feedback from kayabanerve

<r​ucknium:monero.social> 3) Stress testing monerod monero-project/monero #9348

<r​ucknium:monero.social> 0xfffc made some edits to the dynamic block-size-sync PR: spackle-xmr/monero #26

<x​mrack:monero.social> 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.

<r​ucknium:monero.social> I think that's all for stressnet.

<0​xfffc: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.

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs getmonero.org/2024/04/27/fcmps.html

<k​ayabanerve:matrix.org> I don't have much to say on FCMP++s today and will defer to jberman for any integration news.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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).

<j​effro256:monero.social> Do you want to lay out the details here? I'd be happy to open the floor on this issue

<k​ayabanerve:matrix.org> We did successfully propose a scheme which didn't require a consensus rule while maintaining the same goals however.

<j​effro256:monero.social> If that's okay with everyone

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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?

<k​ayabanerve:matrix.org> So while we can be specific, if everyone is fine with hearing "identified issues resolved", we can move on :p

Well, there will be reviews and reviewers to hopefully catch anything left.

<j​effro256:monero.social> Yeah, I guess the only real downside is that collaborative transactions might stick out on the chain due to duplicated output pubkeys, commitments, etc

<k​ayabanerve:matrix.org> Malicious signers can always make their TXs stick out.

<j​effro256:monero.social> True. So yeah it's not a huge deal and might not be worth going into here

<j​effro256:monero.social> Smart collaborative protocols are always free to add additional rounds/rules to their participants if they want to prevent this fingerprint

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> This specific fingerprint, of which there are still several others to cause non-uniformity :p

<k​ayabanerve:matrix.org> 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.

It will take a while until we get to implement any such collaborative scheme, I guess?

Much other stuff ahead on the way there

<k​ayabanerve:matrix.org> Oh, yes, we're not doing that.

<k​ayabanerve:matrix.org> I just noted there would be a problem if someone tried and we don't have to have that problem.

<k​ayabanerve:matrix.org> Making it easier to try doesn't mean we are trying.

I certainly see the worth of the approach to try to see far into the future with fundamental protocol decisions.

<k​ayabanerve:matrix.org> 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.

I already see people fret "Buuuuut ... is it quantum proof" :)

<j​effro256:monero.social> 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)

<j​effro256:monero.social> 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

<k​ayabanerve:matrix.org> Oh yes. The proposed key exchange was pointlessly complex in theory and would slow down scanning by multiple percent.

<k​ayabanerve:matrix.org> 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.

<k​ayabanerve:matrix.org> 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.

Is anything of this possibly relevant for the implementation of atomic swaps post-Carrot-introdution?

*introduction

Forgive if the question is not even wrong :)

<k​ayabanerve:matrix.org> Not any more than usual.

Ok

<j​effro256:monero.social> 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<clipped messag

<j​effro256:monero.social> ation code used in wallet2

<j​effro256:monero.social> *is *not* in the prime subgroup

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.

<r​ucknium:monero.social> We have 15 minutes left in the hour. Let's more onto a new topic:

<r​ucknium:monero.social> 5) Change how transactions are broadcasted to significantly reduce P2P bandwidth usage monero-project/monero #9334

<b​oog900:monero.social> I added a comment in response to Rucknium monero-project/monero #9334#issuecomment-2315416552

<r​ucknium:monero.social> 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.

jeffro256: raw.githubusercontent.com/UkoeHB/Se…ng_seraphis/Impl-Seraphis-0-0-4.pdf footnote 11

<r​ucknium:monero.social> 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.

<a​rticmine:monero.social> My question here is how many times is a full node broadcasting the same tx including as part of a mined node.

<r​ucknium:monero.social> Anyway, I am not necessarily opposed to boog900 's proposal unchanged. I wanted to investigate the possible risks and take a long-term view.

<r​ucknium:monero.social> I wonder "Where are we going?" with the tx relay protocol.

<v​tnerd:monero.social> jeffro256: I can see the argument for removing it. If a subgroup pubkey was provided, the result is going to limited anyway

<a​rticmine:monero.social> Can we get this excess bandwidth to ideally between 1x and 2x the Tx size?

<r​ucknium:monero.social> There are stacks of papers on gossip protocols.

<b​oog900:monero.social> FWIW I would be for adding similar rate limits to what Bit coin does:

<b​oog900:monero.social> > Bitcoin will only send 1 request for a tx every 60 seconds: github.com/bitcoin/bitcoin/blob/2c7…edc85a4/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.

<r​ucknium:monero.social> ArticMine: Newer proposals Strokkur and Shrec are supposed to get in that 1-2x range. They are newer than Erlay.

<a​rticmine:monero.social> That is close to the theoretical optimal

<r​ucknium:monero.social> 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.

<a​rticmine:monero.social> Where does Early come in and where are we now?

<a​rticmine:monero.social> This is critical for scaling.

<b​oog900:monero.social> The node does not do PoW checks before sending the missing tx request

<b​oog900:monero.social> 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

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Basically Monero is much more wasteful than even current-day bitcoin

<b​oog900:monero.social> With FCMP++ this gap would widen as well

<a​rticmine:monero.social> Yes but not by much

<r​ucknium:monero.social> Right. The ratio of tx hash to the full tx data is much smaller in Monero than bitcoin

<j​effro256:monero.social> UkoeHB: thanks for the link!

<b​oog900:monero.social> so the amount of data we could save in P2P broadcasts compared to the amount used would be significantly less than Bitcoin

<b​oog900:monero.social> double?

<a​rticmine:monero.social> The figures I have heard are 3-4kB

<r​ucknium:monero.social> The set reconciliation method of Erlay has quadratic time complexity in the number of txs that each node is missing.

<a​rticmine:monero.social> So yes about double

<r​ucknium:monero.social> 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.

<a​rticmine:monero.social> My concern is minimizing the number of the tx is transferred as opposed to tx hashes

<r​ucknium:monero.social> 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."

<b​oog900:monero.social> we should be close to optimal just looking at full tx blob transfers with the new method, I think

<a​rticmine:monero.social> You mean under 2x including the mined blocks

<b​oog900:monero.social> I think so yes

<b​oog900:monero.social> We should probably look into what's eating the rest of our bandwidth as it seems pretty high

<b​oog900:monero.social> roughly 38MB in 2.5 hours excluding tx messages

<a​rticmine:monero.social> Yes that would be very helpful

<b​oog900:monero.social> with 12 connections

<a​rticmine:monero.social> Is that excess bandwidth tx dependent?

<b​oog900:monero.social> with the new method tx broadcasts including hashes and blobs would have used ~15 MB

<b​oog900:monero.social> It includes block broadcasts and everything except tx-pool broadcasts

<a​rticmine:monero.social> 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

<k​ayabanerve:monero.social> UkoeHB's comment is correct in what was my failure to consider. Apologies. You can so probe the last three bits. cc jeffro256 vtnerd

<b​oog900:monero.social> just tx hashes although the miner tx is always included

<b​oog900:monero.social> and the block is sent to every node, even if they have already sent it

<j​effro256:monero.social> 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

<r​ucknium:monero.social> Nodes consume GB of RAM when relaying KB of txs. Do we know why?

<r​ucknium:monero.social> The relative scale doesn't make sense to me

<b​oog900:monero.social> duplicating txs in the fluff queue is my guess

<r​ucknium:monero.social> Say that there are five 100-KB transactions in 100 fluff queues. That's 50MB.

<j​effro256:monero.social> 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

<b​oog900:monero.social> we weren't talking about 5 txs during the spam though

<r​ucknium:monero.social> That's about how long the queues are going to last, right?

<b​oog900:monero.social> if a lot of re-broadcasts line up the queue could get _a lot_ longer

<b​oog900:monero.social> the queue is made of tx-blobs right?

<j​effro256:monero.social> Oh you're right, nvm my comment if so

<b​oog900:monero.social> 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

<b​oog900:monero.social> and they only happen when the function is called not exactly at the time the tx should be re-broadcasted

<r​ucknium:monero.social> This is the first time I'm hearing about re-broadcasts 👀. So if the txpool is congested, the re-broadcasts would multiply.

<b​oog900:monero.social> which I found to be every 2 mins IIRC

<b​oog900:monero.social> using my PoC

<b​oog900:monero.social> monero-project/monero #9348#issuecomment-2170629015

<b​oog900:monero.social> and the logs from monerod

<r​ucknium:monero.social> The re-broadcast is just to provide even more reliability of tx propagation. Or something else?

<b​oog900:monero.social> yeah that, if we had no connections we would need the tx to be broadcasted again

<r​ucknium:monero.social> That would help explain why performance is much worse when the txpool is congested

<r​ucknium:monero.social> Wait, is re-broadcast part of routine operation or just under special circumstances?

<b​oog900:monero.social> routine

<b​oog900:monero.social> only based on time IIRC

<r​ucknium:monero.social> 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?

<b​oog900:monero.social> I think work can begin on the new protocol, but I am biased :)

<r​ucknium:monero.social> 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.

<o​frnxmr:monero.social> i thought this was implemented because of tx that _failed_ to broadcast

<o​frnxmr:monero.social> Sounds like a bug if its rebroadcasting tx that did not fail

<a​rticmine:monero.social> Does this assume no increase in network size?

<r​ucknium:monero.social> The number of txs needed to infer network topology increases with log(n). n being the number of nodes.

<b​oog900:monero.social> not as far as I can see, it is re-broadcasting every tx

<o​frnxmr:monero.social> That sounds like a bug

<b​oog900:monero.social> if we add rate limits we should be fine right?

<b​oog900:monero.social> if we only had 1 connection that dropped the tx we would need to re-broadcast

<o​frnxmr:monero.social> We had issues with tx-proxy failing to relay tx, and then changed the behavior to attempt to retry the broadcast

<r​ucknium:monero.social> monero-project/monero #9334#issuecomment-2307824031

<o​frnxmr:monero.social> Iirc this was changed at or around the hardfork

<r​ucknium:monero.social> > 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<clipped message

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<b​oog900:monero.social> When tx broadcasts are tx-hashes re-broadcasts should become less of a problem

<r​ucknium:monero.social> MEETING END. Discussion can continue of course.

<b​oog900:monero.social> But this is also the case when the adversary just listens for tx messages without probing

<b​oog900:monero.social> with enough connections/txs you could perform a similar attack

<r​ucknium:monero.social> With more connections you can multiply your rate-limited queries :)

<b​oog900:monero.social> Sure but if we removed that possibility this attack is still possible

<b​oog900:monero.social> and the rate limits should at least help

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Bitcoin developers implemented diffusion since they thought it was probably good enough. The Dandelion++ creators showed that it was not good enough.

<b​oog900:monero.social> 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

<r​ucknium:monero.social> And it took them two tries to get a robust protocol

<b​oog900:monero.social> how would we handle double spends?

<b​oog900:monero.social> if we ignore knowledge of txs

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> The node knows it has txs, but it doesn't indicate to its peer that it knows. The node dumps the double spend.

<b​oog900:monero.social> Fair IMHO these attacks are extremely expensive/impossible so not a priority

<b​oog900:monero.social> dumping is what happens when the tx is known

<b​oog900:monero.social> unless we are going to ignore new txs randomly as well, I guess that would work

<r​ucknium:monero.social> 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?

<b​oog900:monero.social> no, it drops the tx before doing all the checks:

<b​oog900:monero.social> > 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<clipped message>

<b​oog900:monero.social> 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 <clipped message>

<b​oog900:monero.social> 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.

<k​ayabanerve:monero.social> 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

<k​ayabanerve:monero.social> 100 * 3 doublings

<k​ayabanerve:monero.social> Or

<k​ayabanerve:monero.social> 3 doublings + 1 mul

<k​ayabanerve:monero.social> 1 mul will presumably be more expensive than 297 doublings. It's inherently 256 doublings.

<k​ayabanerve:monero.social> The halving version may be more performant but that requires we impl and bench it

<k​ayabanerve:monero.social> I'd just do the cofactor clear

<r​ucknium:monero.social> 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.

<b​oog900:monero.social> 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.

<b​oog900:monero.social> Knowing if a peer has a fluff tx is not a problem otherwise IMO.

<b​oog900:monero.social> so it would be good to know how effect diffusion is at preventing graph learning

<b​oog900:monero.social> effective*

<b​oog900:monero.social> which as far as I seen wasn't in your right up? except for a note it would be harder than Bitcoins old protocol

<b​oog900:monero.social> which as far as I seen wasn't in your write up? except for a note it would be harder than Bitcoins old protocol

<r​ucknium:monero.social> 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

<r​ucknium:monero.social> Exercise left to the reader I guess :D

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> Or maybe it would be easier to start with one of the papers that does network inference from cascades with noisy data.

<b​oog900:monero.social> Yeah probably

<r​ucknium:monero.social> It could be nice to set up a tx propagation simulator one day. There are a couple of them from some papers.

<b​oog900:monero.social> I tried to run the one from D++ but I ran into a few issues and struggled to follow the code

<r​ucknium:monero.social> 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

<r​ucknium:monero.social> In July the maintainer updated the D++ code to Python3 IIRC

<r​ucknium:monero.social> The memorylessness of exponential timers helps with theoretical analysis a lot.

<b​oog900:monero.social> Yeah I definitely think we should move fluff timers to the exponential distribution

<r​ucknium:monero.social> I don't see any downsides to doing that. Probably a good idea.

<b​oog900:monero.social> I would expect the first spy estimator to be a lot better using the Poisson distribution

<b​oog900:monero.social> maybe not a lot but at least better

<r​ucknium:monero.social> You've seen it, but here is my comment on that for reference: monero-project/monero #9295#issuecomment-2260998091

<b​oog900:monero.social> just by following the logic of what must happen for the first spy estimator to fail. The node must broadcast to a connection and then that connection has to broadcast to the adversary, before the node broadcasts to the adversary

<b​oog900:monero.social> (many hops could happen in the middle but that's unlikely)

<b​oog900:monero.social> with the Poisson distribution the chance of this is less

jeffro256: it's not really relevant if you're using X25519 for the ecdh.

<j​effro256:monero.social> But doesn't X25519 solve that by clamping the private key, so that all private keys are divisible by 8? If we wanted to use legacy keys (anything mod `l`), then we still need to clear cofactor, right?

<j​effro256:monero.social> (and/or otherwise ignoring the bottom 3 bits of the key)

<v​tnerd:monero.social> Yes @jeffro I see what you mean. The view pubkey used by the sender needs to be computed with the clamping, or the shared secret will differ. You'd have to add a new "tag" to addresses to know whether a mul8 was needed at the end. It's probably not worth the hassle, otoh I don't know the specific timings of the mul8 operation

jeffro256: yes, Ed25519 keys need to clear the cofactor

mul8 is quite fast compared to a full multiplication