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

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

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

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

Hello

<v​tnerd:monero.social> Hi

<a​rticmine:monero.social> Hi

<j​effro256:monero.social> howdy

<k​ayabanerve:matrix.org> 👋

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

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

<0​xfffc:monero.social> Hi everyone

<r​ucknium:monero.social> me: Wrote "Required possession duration of malicious hashpower for successful double-spend attack with a _z_ stopping rule." gist.github.com/Rucknium/37d772f7232aef3989bfd5b9c6d99596

<j​effro256:monero.social> me: Carrot balance recovery handling and getting updated quotes from auditors which include security proofs for Janus attacks

<v​tnerd:monero.social> Me: converted lws rest server to boost::beast and going to finish up some monerod stuff today hopefully

<k​ayabanerve:matrix.org> I made my library for calculating divisors constant time to avoid any concerns there. I'm now working on redoing the data flow for FCMP++ prove/verify from the current shims to what we actually need in a production context.

<0​xfffc:monero.social> 1, Fixed the pop blocks, submitted the PR. 2. Fixed rpc limit ( not pushed yet ). 3. Breaking dynamic bss code to different PRs ( smaller PR and will submit it tomorrow ). Spent a little bit of time on a new problem about public nodes.

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

<r​ucknium:monero.social> There's a problem with the txpool limiter that appears rarely. Sometimes the node sets a low txpool limit arbitrarily, like 10-50MB. The trigger for the bug is unknown.

<r​ucknium:monero.social> This could be a problem for mining nodes. It also slows down block verification since the nodes have to ask for the txs they are missing when they get a fluffy block

<j​berman:monero.social> me: working on wallets sync the tree locally for fcmp++ (to avoid needing to reveal any statistical trace to daemons which outputs are the users when spending)

<j​effro256:monero.social> So the pool just shrinks dramatically, dropping txs without the txs showing up in the chain?

<r​ucknium:monero.social> I don't know if it keeps the old ones and throws the new ones out, or throws out old ones to fit the new ones

<j​effro256:monero.social> How long does it stay at this reduced size?

<r​ucknium:monero.social> The node that's actively having this problem now has the "Sync data returned a new top block candidate..." message for almost every block

<r​ucknium:monero.social> AFAIK, until node restart

<r​ucknium:monero.social> It has happened at least to my node and spackle's node on stressnet. Maybe other people's nodes, but they may not have noticed.

<r​ucknium:monero.social> 4) Research Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot. github.com/jeffro256/carrot/blob/master/carrot.md

<j​effro256:monero.social> I've been receiving updated quotes for including Janus resistance in scope of properties for which we want security proofs. I plan to invite them to the next MRL for a quick schpeal if that's okay with everyone

<j​berman:monero.social> good with me

<r​ucknium:monero.social> Sounds good :)

<k​ayabanerve:matrix.org> I'm still trying to work things out with veridise. Should be done next week. I also saw Rucknium's request and have to do the book keeping

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

<j​effro256:monero.social> By "work things out", are you referring to allocating more budget to Veridise with their current audit?

<k​ayabanerve:matrix.org> No, confirm scope and quote.

<j​effro256:monero.social> Oh, for which audit?

<k​ayabanerve:matrix.org> The remaining work on divisors prior discussed.

<r​ucknium:monero.social> Anything more on FCMP++?

<j​effro256:monero.social> Nothing here

<k​ayabanerve:matrix.org> I have one topic

<k​ayabanerve:matrix.org> Helioselene (my lib for Helios/Selene) is multiple times slower than other EC libs. My CCS explicitly states my impl is not expected to be prod grade. The fact it happens to be usable in prod is more commentary on how well I did my work on the proofs.

<k​ayabanerve:matrix.org> I have an EC divisor library which is functional. It's also the most computationally expensive part of the proving. Thankfully, it can be done asynchronously. Before a user signs a TX, or even does a membership proof, the wallet can create divisors to be used.

<k​ayabanerve:matrix.org> So wallet UX should be able to make the time to calculate divisors a complete non-issue in practice EVEN IF we don't have wallet trees and do use RPC calls to fetch path information (as the divisors can have their calculation started before committing to making a TX and starting to send RPC requests).

<k​ayabanerve:matrix.org> I have some degree of interest in organizing a contest for anyone to develop more efficient implementations. I think they're clearly defined, concise parts of the codebase, amenable to such incentivization.

<k​ayabanerve:matrix.org> That's actually all I have to say on this for now, I just wanted to have the idea noted.

<j​berman:monero.social> I figure tevador would also be a good candidate here, perhaps we can put up the bat signal for tevador / see if they're interested? and if not, then go with bounties?

<k​ayabanerve:matrix.org> I'll also clarify the divisors should be a fraction of a second on a modern laptop. We need more than ten of them for a FCMP so it can become seconds depending on the device hardware. I'm not concerned about it because threads exist (I've only used single threads) AND again, they can be calculated at any time. Even when you open a wallet, it can start 10 sets in the background for<clipped message

<k​ayabanerve:matrix.org> the hell of it. If a user does start to make a TX, the time for them to enter the address/amount/review/hit confirm should be longer than the calculation time.

<r​ucknium:monero.social> Does that scale linearly with the number of inputs?

<k​ayabanerve:matrix.org> tevador prior agreed to do an optimized version of Helios/Selene. tevador hasn't been seen in a while AND tevador being able to do an optimized version doesn't mean they'd do the best implementation.

<r​ucknium:monero.social> And does not depend on the merkle tree "anchor"?

<j​berman:monero.social> to be clear, there's also all the other Helioselene ec arithmetic that affects tree building that has room for optimization, right? not just divisors

<j​effro256:monero.social> If the total time is less than a few seconds , that cost will likely be dwarfed by scanning times anyways and there might not be a very compelling reason to put a ton of effort into optimizing it IMO

<k​ayabanerve:matrix.org> It's necessary per input, it's not bound to the input nor the tree. The amount of divisors necessary for an input is variable to the tree depth.

<k​ayabanerve:matrix.org> Yeah, ideally, a new Helioselene lib gets 3x across the board jberman

<j​effro256:monero.social> Can divisior generation can be done without access to spend or view opening of tx outputs?

<k​ayabanerve:matrix.org> Jeffro256: I'm concerned on phones it'll become tens of seconds, but including the divisors lib may be reasonably not worthwhile for such a contest (limiting this discussion to Helioselene)

<k​ayabanerve:matrix.org> jeffro256: It doesn't need any keys but would leak sender privacy

<j​berman:monero.social> a contest sgtm. with community buy-in, since it looks like some of the research funds will be leftover, could perhaps allocate some of what looks like leftovers toward seed funding a contest

<k​ayabanerve:matrix.org> If tevador comes back within the next month or so and delivers a 3x faster Helioselene, we can say this isn't sufficiently worthwhile. I think this contest format can attract fresh talent and is our best chance at the highest performant library possible.

<k​ayabanerve:matrix.org> I would want to do it on a new CCS.

<k​ayabanerve:matrix.org> The research funds can't be used for this (I don't hate the idea but they're earmarked otherwise). Upon research completion, the leftover funds turnover to MRL and would be eligible, yet that only occurs at the end of the road. I'd ideally propose this contest around EOY (not end of the road for the research tasks).

<k​ayabanerve:matrix.org> It's an idea. I'm months away from being able to actually put it forth. I'd need to spend weeks organizing it due to the development time of an evaluation framework.

<r​ucknium:monero.social> 5) 10 block lock discussion monero-project/research-lab #102 github.com/AaronFeickert/pup-monero-lock/releases/tag/final

<r​ucknium:monero.social> I wrote "Required possession duration of malicious hashpower for successful double-spend attack with a _z_ stopping rule."

<r​ucknium:monero.social> Direct link to table: gist.github.com/Rucknium/37d772f723…k-success-probability-of-50-percent

<r​ucknium:monero.social> IMHO, the relevance of this table depends on the threat model. If the cost to the attacker to acquire more hashpower is a roughly linear function of the desired malicous hashpower, then it is best to go big or go home: Get a majority of hashpower.

<j​berman:monero.social> maybe a comment on here may be a good place to try to contact tevador gist.github.com/tevador/d3656a217c0177c160b9b6219d9ebb96

<r​ucknium:monero.social> So, if the equation is `total_budget = duration * hashpower_share`, then it is best to put the money into hashpower share instead of duration. But if the threat actor is a hacker who acquires control of a large mining pool, then it's more relevant, since the hacker isn't spending a linear amount of money to acquire hashpower.

<k​ayabanerve:matrix.org> For 15m USD of opportunity cost (assuming zero TX fees), 10% of the hash power can likely perform a 8 block reorg from my reading of that table.

<r​ucknium:monero.social> 15m USD can do a 720-block re-org if they possess hashpower for 24 hours.

<r​ucknium:monero.social> A much smarter move by an adversary.

<r​ucknium:monero.social> The risk of collateral damage from a deep re-org also depends on the chosen full confirmation time of potential suitable victims. The best suitable victim type IMHO is an exchange. Kraken requires 15 blocks: support.kraken.com/hc/en-us/article…tocurrency-deposit-processing-times

<r​ucknium:monero.social> Most of Trocador's instant swap partners require 10-15 blocks.

<k​ayabanerve:matrix.org> Rucknium: Can you please clarify?

<k​ayabanerve:matrix.org> 15m USD isn't the cost to acquire 51% of hash power for 24 hours, is it? Is the suggestion by bribing the top pools as that'd be profitable for them?

<k​ayabanerve:matrix.org> (15m exceeds a day's block rewards by farrrr)

<r​ucknium:monero.social> The durations in that table are probably an upper bound because the simple _z_ stopping rule isn't optimal. A smart adversary would halt an attack and re-start from scratch sometimes before the _z_th block is reached, and even sometimes after. A paper (Hinz (2020). "Resilience Analysis for Double Spending via Sequential Decision Optimization.") could be useful for analyzing optima<clipped message

<r​ucknium:monero.social> l stopping rules, but their solution algorithm requires a parameter for the value of the double-spent tx.

<r​ucknium:monero.social> I get `720 * 0.6 * 170 = 73440` Am I wrong?

<r​ucknium:monero.social> Oh, you were saying that it exceeds the block rewards

<k​ayabanerve:matrix.org> No, but if this is your premise, we have two different discussions

<r​ucknium:monero.social> Yes, that's my point. Much better and cheaper to acquire hashpower for a shorter period of times

<k​ayabanerve:matrix.org> I'm unsure in practice that top mining pools would accept such bribes.

<k​ayabanerve:matrix.org> If they wouldn't, one would have to acquire new hash power. New hash power is much more expensive to require.

<k​ayabanerve:matrix.org> Eh. There's enough social engineering/illegal methods the multiple is probably small enough we can drop it from being an issue/consideration.

<r​ucknium:monero.social> Drop what?

<k​ayabanerve:matrix.org> Drop my concern about the difference in price of existing and new hash power.

<j​effro256:monero.social> But potentially the resale value it still very good if only used for a 24 hour attack

You mean use a warehouse full of PCs ready to go to shops for 24 hours :)

<k​ayabanerve:matrix.org> '1000 Threadrippers, lightly used, BTC only'

<r​ucknium:monero.social> nanopool has more than 30% of hashpower usually. If a hacker got control of their hashpower for 1/3rd of a day, the hacker could achieve a 10-block re-org with 50% probability.

<o​ne-horse-wagon:monero.social> Does anyone know the percentage of Monero users that need to reduce the 10 block lock mechanism because it is cramping what they are trying to do?

<k​ayabanerve:matrix.org> We have evidence at scale, RISC-V boards are most efficient *from a production/new hardware acquisition standpoint*.

Well, we could come to the conclusion that this Nanopool hacked scenario is too dangerous and go *higher*, e.g. to 15 blocks ...

<k​ayabanerve:matrix.org> We'll always fundamentally have a 1 block lock fwiw

<k​ayabanerve:matrix.org> I'm unsure user experience is notably different for 8 vs 10 (as an example)

Yeah, and data sure does not seem to point towards 5 blocks or so, right?

<r​ucknium:monero.social> By the way, the table is an upper bound of the required possession duration. The _z_ stopping rule isn't optimal, because a smart attacker would end an attack and re-start at less than _z_ blocks sometimes, and continue past _z_ sometimes, too, depending on how far behind they are in the race against the honest chain. A paper (Hinz (2020). "Resilience Analysis for Double Spending <clipped message

<r​ucknium:monero.social> via Sequential Decision Optimization.") has an algorithm that could help compute a better bound, but it depends on a parameter for the value of the double-spent tx.

<k​ayabanerve:matrix.org> The unfortunate discussion is that if we want lower confirmations, the solution is PoS at least as a secondary layer.

<k​ayabanerve:matrix.org> That's unfortunate not because of my opinions on PoS, yet because I can't imagine that discussion being well received.

You can bet :)

<r​ucknium:monero.social> rbrunner: Depends on the threat actor. If the adversary is just buying hashpower at a linear cost, then the adversary will probably just perform a 51% attack. Then any block lock is irrelevant. If the threat model is a mining pool operator, then the risk table is relevant.

<k​ayabanerve:matrix.org> As a secondary layer, we'd still be PoW. We'd just have some declaration of validators (with transparent stake) who cement the PoW blocks.

<r​ucknium:monero.social> Or...rolling checkpoints! :D

I think that table is at least a nice new tool to direct people to and have them check the results if they vote for lowering from 10

<r​ucknium:monero.social> If a minority-hashpower attack is assumed to be unlikely, then evaluation of a safe N block lock would analyze benign re-orgs. Which are pretty shallow in the empirical record. (There are papers on the theoretical benign re-org depth that we could look at)

<r​ucknium:monero.social> I will probably clean up the gist and put it in the 10 block lock GitHub issue.

<r​ucknium:monero.social> Or one could say that the risk of tx invalidation from a rare, shallow re-org caused by a malicious double spend attack is an acceptable risk

<r​ucknium:monero.social> If an attacker cannot earn money from a DS because any of the big targets have high confirmation times, then there will not be the collateral damage to other users, anyway.

I think inflicting "reputational damage" is also a possible motivation for people with money to burn through

<r​ucknium:monero.social> And the 10 block lock doesn't prevent a victim from accepting a tx at 5 confirmations, then getting double-spent against. It just prevents collateral damage of txs necessarily being invalidated because they referenced a now-invalid merkle tree.

<r​ucknium:monero.social> More things to think about. We can end the meeting here.

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

<a​leenor:matrix.org> imo if you use monero regularly it's just something you learn to account for ahead of time

<a​rticmine:monero.social> Thanks

<k​ayabanerve:matrix.org> If we pad outputs, we can make standard practice for a payment to X to be to use multiple outputs for the one payment.

<o​ne-horse-wagon:monero.social> Which is why I wonder how big of a problem is the 10 block lock? It has served Monero well all these years.

<r​ucknium:monero.social> Everyone hates the 10 block lock.

<a​leenor:matrix.org> I've often wondered too. it used to bother me in the beginning, but then I adapted. it seems that it mostly bothers newbies and infrequent users, it's probably a decent percentage

<a​leenor:matrix.org> of course, I would also prefer if it wasn't there

<r​ucknium:monero.social> In most cryptocurrencies, you can spent an output from a tx that is in the mempool/txpool. You can chain them together.

<r​ucknium:monero.social> In Bitcoin Cash, some services were hitting their limit of 50 chained txs in the mempool. Programmers changed an algorithm from O(n^2) to something faster and eliminated the limit a few years ago.

<a​leenor:matrix.org> yeah. it doesn't make intuitive sense either, like being handed change in cash and not being able to get it out of your pocket for 20 mins. it catches people by surprise

<a​leenor:matrix.org> but with the current ring size arrangement I also appreciate why it's there

<k​ayabanerve:matrix.org> Rucknium: I have scheduling code to avoid exactly that bound on Bitcoin (and derivatives).

<r​ucknium:monero.social> If you added BCH to Serai instead of BTC, you wouldn't have had to worry about it :P

<k​ayabanerve:matrix.org> Silence shill D:

With FCMP++ churning / "PocketChange" and similar mechanisms to produce outputs for oneself are much less of a privacy problem than today with rings, right? While they still can bloat the chain, of course

<k​ayabanerve:monero.social> Correct