<r​ucknium:monero.social> MRL meeting in this room in two hours.

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

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

Hello

<0​xfffc:monero.social> Hi everyone

*waves*

<v​tnerd:monero.social> Hi

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

<0​xfffc:monero.social> (1) Fixed a bug, (2) working on start up speed up: 0xFFFC0000/monero #26

<r​ucknium:monero.social> me: Helping with stressnet. Reading papers about gossip networks and analyzing the Monero p2p transaction gossip messages.

<j​effro256:monero.social> howdy

me: completed first pass at growing and trimming the tree (db and tests implemented, tests passing)

<v​tnerd:monero.social> Not much to report, between work contracts atm

<j​effro256:monero.social> me: Jamtis-RCT. Specifically, the conversion functions between X25519 and ed25519 points for legacy address support. If anyone knows a way to find the ed25519 (x, y) values from X25519's x value without doing explicitly finding the y value for X25519 by performing a square root op, please let me know

<s​gp_:monero.social> Hello

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

("the tree" = fcmp curve trees merkle tree

<r​ucknium:monero.social> I think we found another problem that could prevent block sync. Sometimes a valid block can be placed on the `m_invalid_blocks` list. It looks like a node can get on a short alt chain. Then it marks one of the main chain's blocks as invalid. Because the block is "invalid", it stops syncing to the main chain and bans nodes that send the "invalid" block.

<r​ucknium:monero.social> I guess that nodes are applying the alt chain's rules for validity to the main chain, and think it's invalid. Probably it has something to do with the 100 block median block size, the penalty area, and how much miners can pay themselves. Maybe miners pay themselves too much on the main chain's block when the alt chain's rules are applied.

<r​ucknium:monero.social> The nodes can start syncing again if they shut down and restart or if the node operator inputs `flush_cache bad-blocks` into the monerod console.

<r​ucknium:monero.social> In the incident that I analyzed closely, the alt chain was 2 blocks long

<r​ucknium:monero.social> I guess the problem is the block size computation because AFAIK this type of thing doesn't happen on the mainnet, but mainnet usually doesn't increase the 100-block median block size.

<r​ucknium:monero.social> AFAIK, there is no plan yet to try to debug this

<r​ucknium:monero.social> This week I started spamming 144in/2out txs to see if the out-of-memory issue that some people saw on mainnet would happen. I've seen a modest increase in RAM usage, but nothing that would cause a major problem. Most nodes on stressnet have 30 connections or fewer, so the OOM issue may be due to number of connections more than how many inputs txs have

<r​ucknium:monero.social> But the CPU usage of nodes has increased because verifying inputs requires more CPU per byte of data than verifying outputs.

<r​ucknium:monero.social> A low-end node (4GB RAM, 2 CPU threads) took 30 seconds per block recently to catch back up with chain tip with 4MB blocks mostly filled with 144in/2out txs.

<r​ucknium:monero.social> Any more comments on stressnet?

sounds like a nice list of daemon issues has formed for would-be takers to pursue further

<r​ucknium:monero.social> Here's the relevant part of the log file when the nodes fail to sync, by the way:

<r​ucknium:monero.social> D [<IP>:<PORT> INC] first block hash <f6a9bcee7e02c2aa0da480de70f0d1369bda37d6aaab48a5cb55880a9101f192>, last <b7dfc5fbe7570a7cb61e0f9db175a235ee2b83e286c983f3d973435c1dcd27c7>

<r​ucknium:monero.social> D block <f6a9bcee7e02c2aa0da480de70f0d1369bda37d6aaab48a5cb55880a9101f192> found in main chain

<r​ucknium:monero.social> D block <33a5c86ea4a291ddf810df8620784ec8c9fea4014280a0d14f4bb6f6e0c17348> found in alternative chains

<r​ucknium:monero.social> D block <4a76385a6ddb03134ce72d88c8e08c26737f43a5fb88ca2f278ef067e39fbaf2> found in m_invalid_blocks

<r​ucknium:monero.social> E [<IP>:<PORT> INC] Block is invalid or known without known type, dropping connection

<r​ucknium:monero.social> 4) Potential measures against a black marble attack. monero-project/research-lab #119

<r​ucknium:monero.social> I don't have much to report on this issue today except I found a paper that proposes an alternative to Dandelion++:

<r​ucknium:monero.social> Franzoni, F., & Daza, V. (2022). Clover: An anonymous transaction relay protocol for the bitcoin p2p network. moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=222

<r​ucknium:monero.social> I just skimmed the paper. It claims that Clover is as good as D++, simpler, and works well for nodes that have no incoming connections (i.e. its ports are closed).

<j​effro256:monero.social> Hmmmm that's a really interesting issue. I wonder what the value of even having a running "invalid blocks" list is, realistically. Obviously it would speed up failing known repeated bad blocks for honest peers, but the PoW check should be the very very first check performed on block data. This will mathematically limit the number of non-trivial bad blocks that can exist. An unhone<clipped messag

<j​effro256:monero.social> st peer, however, can send any number of garbage blocks that don't pass PoW verification.

<r​ucknium:monero.social> The last part is interesting. A few months ago we discussed a potential issue with D++ when nodes have no incoming connections. D++ treats incoming and outgoing connections differently for its graph theory to work.

<r​ucknium:monero.social> jeffro256: In the log files I found an error message about the "invalid" block pointing to this line of code: github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L1217

<r​ucknium:monero.social> Right above that is a comment: "FIXME: Why do we keep invalid blocks around? Possibly in case we hear about them again so we can immediately dismiss them, but needs some looking into."

Waiting for a fix for 4 years :)

<r​ucknium:monero.social> I've only skimmed the Clover paper. The D++ paper looks at a lot of different threat models. It is a dense paper. On a skim, the Clover paper looks like it analyzes fewer threat models. Anyway, I will keep the paper and come back to it later.

Ah, now, that remark is 9 years old.

<r​ucknium:monero.social> My naive view is to try to fix the miscalculation of the block validity first.

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

<r​ucknium:monero.social> kayabanerve, kayabanerve

<r​ucknium:monero.social> By the way, I've listed "Uniformity of Monero's hash-to-point function" as a separate agenda item. (It's next on the list.)

<k​ayabanerve:monero.social> I have no updates on either.

<k​ayabanerve:monero.social> But thank you :)

<r​ucknium:monero.social> I skimmed a few related papers on the hash-to-point function. One of them proves that a different hash-to-point function is approximately uniformly distributed. I wonder: would it be useful to do some preliminary statistical tests of the uniformity of Monero's function? If it fails one or more tests, that's a good reason for a researcher to look at its potential biasedness more formally.

<r​ucknium:monero.social> Diehard-like tests.

<r​ucknium:monero.social> kayabanerve: What do you think? ^

<k​ayabanerve:monero.social> I'm honestly unsure the methodology for testing. If you have learned it and want to, I'd be happy to comment as I can, but my expertise on the subject only went as far as to know to hire someone to ensure we're not messing up :p

<r​ucknium:monero.social> AFAIK, what I would need would be a large number of the points to test if they are uniformly distributed or (even better) an easy-to-use function that I could use to generate points at will.

<r​ucknium:monero.social> I would have to look into this more, but that's what I think would be required.

<r​ucknium:monero.social> And then I would have to understand elliptic curves a little if the test is actually uniformity on the curve instead of just uniformity on the set of integers

<j​effro256:monero.social> Rucknium: you probably know this already, but it's important to note that a random ed25519/X25519 public key (and therefore key images) as we serialize them will NOT look like a uniform random string since not all (X, Y) combos are valid. And of those (X, Y) combos, we only really use 1/8 of them (the one's without cofactor)

<r​ucknium:monero.social> If it doesn't fail any tests, that doesn't necessarily mean that it's unbiased. But if it does fail tests, then that could make a researcher more interested in it.

<k​ayabanerve:matrix.org> There's a C++ and a Rust impl

<k​ayabanerve:matrix.org> They explicitly shouldn't be uniform over the byte array.

<k​ayabanerve:matrix.org> Presumably, the field element should be

<b​oog900:monero.social> the original CryptoNote whitepaper claims the hash to point function, as used for original ring signatures, does not need to be perfect: `None of the proofs demands Hp to be an ideal cryptographic hash function. It’s main purpose is to get a pseudo-random base

<b​oog900:monero.social> for image key I = xHp(xG) in some determined way.`

<b​oog900:monero.social> do our other usages?

<k​ayabanerve:matrix.org> The original proof's implementation does allow forgeries of you can predict the HtP IIRC.

<k​ayabanerve:matrix.org> ... if you can control its output to a solved for point?

<k​ayabanerve:matrix.org> I'm unsure how to phrase it. I don't think that's the risk, due to it using keccak to start, and I wouldn't be surprised if it's fine if it offers a notably reduced bit count than desirable for a hash fn of its length.

<k​ayabanerve:matrix.org> But I wouldn't take that informal comment at face value.

<r​ucknium:monero.social> Any other comments on this or agenda items?

<j​effro256:monero.social> I believe I know of a way that that a valid block could be added to the invalid blocks list. In `Blockchain::switch_to_alternative_blockchain`, if `handle_block_to_main_chain` returns `false` for any reason, we add the alt block and its children to the invalid blocks list. However, `handle_block_to_main_chain` can fail for temporary non-deterministic reasons, one of them being tha<clipped messag

<j​effro256:monero.social> t the transactions of that block are not found inside of the mempool. This might have happened during the stressnet because the mempool got full. So if the node attempts reorging from a worse alt chain to the main chain, but a transaction is missing, the main chain block permanently gets added to the invalid blocks list

<j​effro256:monero.social> I haven't confirmed it yet, so take it with a grain of salt, but that's maybe a possibility

<r​ucknium:monero.social> "one of them being that the transactions of that block are not found inside of the mempool" If that's true, that is a strange design decision.

<r​ucknium:monero.social> Transaction propagation on stressnet is not perfect.

<j​effro256:monero.social> Well the node inherently can't determine the validity of a block if it doesn't have each tx on hand

<r​ucknium:monero.social> Doesn't the fluffy block protocol ask nodes for "missing" txs from the node that sent the block?

<r​ucknium:monero.social> There are log messages about requesting the missing txs

<j​effro256:monero.social> Yes, usually

<r​ucknium:monero.social> I mean, not necessarily in this specific bug, but one of the log categories will give you that log message sometimes

<r​ucknium:monero.social> Maybe the sending node doesn't have the tx in its txpool either?

<r​ucknium:monero.social> But it would have it in its blockchain

<j​effro256:monero.social> But if a block gets added as an alt block, and the txs were ALREADY in the pool, then the txs aren't forced to stay in the pool like they are with a normal fluffy block directly to the main chain.

<r​ucknium:monero.social> We can end the meeting here. And continue the debugging discussion after the meeting

<j​effro256:monero.social> So this sequence of events could happen: 1) TX T gets propagated, 2) alt block B1 gets added as alt block, 3) full mempool causes TX T to get pushed out 4) alt block B2 has B1 as previous block and gets added as an alt block 5) we attempt to reorg to block B2 6) TX T is not present 7) blocks B1 and B2 get added as invalid blocks permanently

<j​effro256:monero.social> (B1 contains TX T btw)

<r​ucknium:monero.social> I think this was happening even when the tx pool wasn't full by the way.

<j​effro256:monero.social> Would you be able to send me the full log please? I would like to see which reason is logged as the initial failure for `handle_block_to_main_chain`

<r​ucknium:monero.social> Yes. When the bug occurred I just had log level 0. But the bug seems to happen about once every 3 days per node. Is there a log level I should set on nodes to get more info?

<j​effro256:monero.social> 3 days is actually the interval after which old txs are dropped from the mempool. That might have something to do with it

<j​effro256:monero.social> For logging consensus verification errors, you can use log category "verify" and on ERROR level