Monero Research Lab Meeting - Wed 28 February 2024, 17:00 UTC

[Rucknium]

Location: Libera.chat, #monero-research-lab | Matrix

Join the Monero Matrix server if you don't already have a Matrix account.

Time: 17:00 UTC Check in your timezone

Main discussion topics:

1. Greetings

2. Updates. What is everyone working on?

3. Discuss: Removing/Fixing/Encrypting monero's timelocks

4. @jeffro256 "In short, I want to make Blockchain::get_adjusted_time() monotonic (barring reorgs) on the next network upgrade."

5. @jeffro256 I'd like to discuss disallowing v1 transactions for "unmixable" input amounts in the next network upgrade.

6. @jeffro256 I think we can improve how the nodes handle alternative blocks in a way that might naturally reduce the number of reorgs on the network.

7. Any other business

8. Confirm next meeting agenda

Please comment on GitHub in advance of the meeting if you would like to propose an agenda item.

Logs will be posted here after the meeting.

Meeting chairperson: Rucknium

Previous meeting agenda/logs:

#970

[Rucknium]

< r​ucknium:monero.social > Meeting time! #973

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

< rbrunner > Hello

< j​effro256:monero.social > Howdy

< v​tnerd:monero.social > Hi

< d​angerousfreedom:matrix.org > hi

< h​into.janaiyo:matrix.org > hello

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

< r​ucknium:monero.social > me: OSPEAD. I think I will complete Milestone 2 in two weeks.

< v​tnerd:monero.social > Me: working on too many files open bug in LWS - the first attempt at a fix segfaults but I cannot reproduce

< 0​xfffc:matrix.org > me: understanding the wallet code, to add lmdb as its cache.

< h​into.janaiyo:matrix.org > working on cuprate's 2nd DB backend, the actual DB used has been changing around

< j​effro256:monero.social > Working on the Seraphis lib serialization and tx handling

< r​ucknium:monero.social > 3) Discussion. I think jeffro256 has an item or two to discuss.

< j​effro256:monero.social > Yeah I wanted to bring up the issue we missed last week which is that there isn't a way to break "ties" between alt chains of the same difficulty

< r​ucknium:monero.social > How do other blockchains handle it?

< rbrunner > Also my first thought, together with "how probably this may be"

< rbrunner > *probable

< rbrunner > (that such a tie occurs)

< j​effro256:monero.social > Very probable: everytime there is a 1 block difference in the chain

< r​ucknium:monero.social > Doesn't it happen almost every time there is an orphaned block?

< j​effro256:monero.social > Yes basically everytime, unless it skips from 0 to more than 1 orphaned block

< rbrunner > Hmm, and why don't we run into problems with that all the time, half of the daemons running this way and the other half that way?

< r​ucknium:monero.social > BLOCK ADDED AS ALTERNATIVE is the evidence, right?

< j​effro256:monero.social > It resolves after 2 blocks, which is why you never see reorg messages that say that the alt chain was 1 block deep

< j​effro256:monero.social > yup

< r​ucknium:monero.social > Probably the status quo reduces the effective network hashpower

< j​effro256:monero.social > It'd be better if it resolved after 1 block tho to prevent as much PoW being lost and to help merchants be more confident accepting 0-conf

< j​effro256:monero.social > Here's the condition where we switch to an alt chain: https://github.com/monero-project/monero/blob/7b7958bbd9d76375c47dc418b4adabba0f0b1785/src/cryptonote_core/blockchain.cpp#L2122

< j​effro256:monero.social > Right now, we only switch if the PoW of our current chain is strictly less

< rbrunner > Regardless of how many blocks that may take?

< r​ucknium:monero.social > IMHO, we should research best practices. I worry that certain tiebreaking rules could provoke undesirable miner behavior. Block withholding for selfish mining, etc.

< j​effro256:monero.social > I'm not sure I understand the question

< rbrunner > Say, the two "second" competing blocks have again the same difficulty - waiting for a third block starts which hopefully brings a difference

< j​effro256:monero.social > Yes

< rbrunner > "Research best practices" sounds good. We are hardly the first ones with this question, one would think.

< j​effro256:monero.social > In reality, since the difficulty is calculated as a function of the last 60 timestamps, usually ties are naturally broken up by a second alt block, but if the timestamp of the 1st differing block is the same, then the second blocks will have the same difficulty

< rbrunner > I really wonder what second or third criterium you could possibly look at to break ties already at the first pair of competing blocks

< rbrunner > beyond difficulty

< rbrunner > Do you already have any candidates there, jeffro256?

< j​effro256:monero.social > I propose something pretty simple: the BlockID. Since block hashing is a one-way function, you can't "cheat" by adding certain input bytes to get an expected output without trying it (AKA the whole basis of PoW). And trying to change the BlockID will invalidate the PoW with a probability of (difficulty-1)/difficulty

< j​effro256:monero.social > The lower blockID wins the tie breaker

< rbrunner > Sounds somehow almost too easy ...

< rbrunner > But I can't come up with an argument against it.

< v​tnerd:monero.social > Why does the existing code for this need to change?

< 0​xfffc:matrix.org > I think I have to ask this question after the meeting since I am not sure I have a firm grasp of this. But wouldn't something like that fundamentally change our consensus algorithm?

< rbrunner > I think that needs a hardfork to intruce

< j​effro256:monero.social > Because the status quo makes orphan chains stick around for 1 block longer than they normally would and divides the network temporarily. This wastes PoW and makes the recent block order more uncertain

< b​oog900:monero.social > difficulty is calculated using 720 block timestamps with a delay of 15 btw

< j​effro256:monero.social > A hardfork is not needed since it is already an undecided problem which "side" the network takes based on ephemeral timings for two competing blocks with the same PoW

< rbrunner > I don't understand. Don't tell me we don't have deterministic consensus, if that even exists

< j​effro256:monero.social > You're right, I'm getting mixed up with the timestamp 60 block median from the other issue I was discussing last week. Same issue applies tho

< j​effro256:monero.social > It's deterministic after a one block delay

< rbrunner > Yes, and wouldn't it be a problem if half of all daemons see the question already as decided after one block, and the not-updated other half not?

< j​effro256:monero.social > (most times unless the timestamps are the same)

< r​ucknium:monero.social > IIRC Satoshi originally wrote bitcoin to follow the chain with the most blocks. That was a mistake. The bitcoin code was changed to follow the most PoW. It seems Monero has the "corrected" method for competing chains when the alternative chains have block length greater than 1, but the old rule when the block length is 1.

< a​js:matrix.org >_ How would the BlockID be generated?

< j​effro256:monero.social > I'm just talking about about the current block id we already use (e.g. you can see the hash on xmrchain.net)

< a​js:matrix.org >_ The block hash?

< j​effro256:monero.social > rbrunner7: that's exactly the problem: for 1 block (most of the time) reorgs, the network gets "sticky" and splits into 2, with both halfs not switching to the other's until another block comes on top of one side and breaks the tie

< j​effro256:monero.social > Yes, block ID and block hash mean the same thing in this context. I use the term blockID to differentiate it from the PoW block hash

< r​ucknium:monero.social > Why isn't it a good idea to use the PoW block hash? Lowest hash would win.

< j​effro256:monero.social > That's also a good option

< a​js:matrix.org >_ How would two different hashes be compared to determine the “lower” one?

< rbrunner > Just take them to be numbers

< rbrunner > Very long numbers

< j​effro256:monero.social > Rucknium: any deterministic property that is a result of a one-way function should work. I think I like using the lower PoW hash because it feels cleaner and can't be pre-scanned like the BlockID can

< rbrunner > So a hardfork would not strictly be needed, but as long as miners are around that stubbornly continue to build on top of a chain the others already kind of discarded, it does not really work, seems to me

< rbrunner > Because sometimes they will win

< r​ucknium:monero.social > AFAIK, lower PoW hash also would not create any contradiction between the rule for +1 chains and +2,3,4 etc. Probably we don't want a block to be considered more valid at one point in time and less valid in another.

< j​effro256:monero.social > Well yes, a miner can always happen to jump ahead of others doing weird things, but the idea is to reduce the amount of lost work under normal circumstances. Right now, nodes and miners which are being completely honest can have a temporary split and waste PoW

< rbrunner > Anyway, that's probably a minor question whether this would or would not need a hardfork

< r​ucknium:monero.social > jeffro256's proposed change also would give a little bit more safety margin to the N block lock on spending outputs

< rbrunner > compared with the decision to try it at all

< j​effro256:monero.social > rbrunner7: a minor question or a miner question?? ;)

< rbrunner > You can't already say at some early point in a hash calculation that the resulting hash will be "big", if seen as a number, and stop early, right?

< rbrunner > Only the very last step probably decides that

< j​effro256:monero.social > Correct

< j​effro256:monero.social > Last step is Blake2b of the register file

< r​ucknium:monero.social > sech1: Do you have an opinion about jeffro256 's proposal?

< sech1 > tldr? what proposal?

< rbrunner > Maybe, surprisingly, nobody thought about this yet, because Bitcoin can't change anything anyway, and everything else is not that important, or sophisticated

< j​effro256:monero.social > Using "lesser" top PoW hash as tiebroker between 2 chains with equal cumulative PoW

< rbrunner > or already went PoS, like ETH

< sech1 > so using some arbitrary random data (it is random) to resolve a tie?

< sech1 > doubtful

< sech1 > ideally, miner with better latency to the rest of the network will win

< sech1 > and it will benefit the network as a whole - everyone will try to improve their latency and connectivity

< sech1 > this random "tie break" rule can result in someone finding the alternative block a minute later and everyone else switching to it

< sech1 > so first seen block is better solution

< v​tnerd:monero.social > Yes, sech1, my thoughts here were mainly just if it's working now, don't break it

< sech1 > plus some malicious miners can "steal" already mined blocks by trying to find better hash

< j​effro256:monero.social > You could argue that, but you can already do that by mining an "old" blocks. You're wasting valuable compute time unless you have 51%

< sech1 > it can open some new ways for 51% attacks

< j​effro256:monero.social > Ostensibly the rest of the network is mining on the "better" block so you're racing against the network

< j​effro256:monero.social > Same as if you're doing selfish mining

< sech1 > current solution (first seen block) incentivizes miners to improve their network

< sech1 > with random tie break rule, they can just ignore it and mine through Tor or whatever else slow network

< r​ucknium:monero.social > But doesn't that give advantage to mining pools over solo miners?

< sech1 > it will result in many more alternative chains, and possibly some more ways to attack

< rbrunner > Not sure I understand the argument. Now it's also possible to arrive a full minute late with an alternative block, if there is no second one yet, no?

< j​effro256:monero.social > They're still incentivized to mine through a fast network with random tie break because if they don't, then they're wasting mining time through network latency

< sech1 > rbrunner if second block arrives a minute late, no one will start mining on top of it and it will lose

< sech1 > with new system, it can disrupt the whole network and everyone will switch to this late block

< rbrunner > I see

< sech1 > plus I don't know how it will affect the difficulty adjustment

< sech1 > if we start getting a lot of late blocks, so overall slower blockchain progress (more than 2 minutes per block on average)

< sech1 > maybe it will spiral down into lower and lower network difficulty even if miner hashrate doesn't change

< rbrunner > Interesting that nobody saw this arguments so far. Tricky stuff, only looking simple

< r​ucknium:monero.social > AFAIK, mining on top of the most recent block you see has been PoW's principle from the beginning. I don't fully believe sech1's story, but he is more expert than me!

< r​ucknium:monero.social > We don't know what the research papers say. Do we even know what bitcoin and its cousins do?

< sech1 > not the most recent, the opposite

< sech1 > I mean, the rule is to mine on top of the block with most PoW

< sech1 > what to do in case of a tie - I haven't seen papers on that

< sech1 > why is the current solution bad?

< j​effro256:monero.social > 2 miners submit block at roughly equal time, network gets split in 2 undecided pieces until next block comes around

< r​ucknium:monero.social > The meeting has gone past the hour mark. We'll end here. jeffro256 : Maybe make a GitHub issue on this?

< j​effro256:monero.social > Thanks everyone!

< 0​xfffc:matrix.org > And it is good idea to have related paper list to this issue. I believe there should be a substantial amount of papers with detailed data about this behaviour. Maybe we can do a literature review.

< 0​xfffc:matrix.org > Thanks everyone.

< j​effro256:monero.social > I'd react with a thumbs up but emoji banned

< sech1 > currently, network splits don't happen too often - once every few thousand blocks only https://paste.debian.net/hidden/a8e8591e/