You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
< xFFFC0000 > me: finished the fast pop_blocks and flush_txpool. Will submit for review. Finishing the issues jeffro mentioned for rpc limit fix right now.
< Rucknium > There has been discussion here about how to put wallet-monerod RPC calls in "chunks", which is important when the txpool is large: spackle-xmr/monero#32
< Rucknium > Thanks to patches from plowsof and tobtoht, the stressnet repo's builds and tests are all passing with green checkmarks
< plowsof > (i changed a few chars of a regex to make a version string pass ^^)
< jeffro256 > 0xFFFC0000: for the record, were there actual instances of hitting the LEVIN_DEFAULT_MAX_PACKET_SIZE limit during the get_blocks call or was this precautionary?
< jberman > I haven't fully read that PR code, but to avoid that issue of gaps in the request, the restricted endpoint serves all of the pool's tx hashes in the first response respecting the time of the request, then the client will then fetch all the blobs in chunks
< xFFFC0000 > jeffro256: there was. When I was debugging I was getting failure if I don’t introduce that limitation
< xFFFC0000 > jberman: that totally makes sense. Strange I didn’t notice it. If we serve hashes in first request, then technically we will be consistent in response.
< xFFFC0000 > s/request/response/
< jeffro256 > jberman: are you saying that that is what it should do, or what the wallet currently does? AFAIK the wallet just repeatedly calls /get_blocks with incremental pool updates
< jberman > when pointing to a restricted rpc that's what it does. the restricted daemon will serve tx hashes in a field remaining_added_pool_txids on the first request, then the client requests those in chunks
< jberman > just piggy-backing off that logic i think may be simpler
< rbrunner > Ah, that's some of the stuff you built on top my own PR
< xFFFC0000 > The restricted and unrestricted are same algorithm fundamentally?
< jberman > then m_node_rpc_proxy.get_transactions requests in 100 tx chunks
< jberman > yes so current wallet2 wallets using this endpoint should automatically know to get chunked requests even if a non-restricted daemon updates to use this logic
< jeffro256 > Hmmm that's weird that I didn't notice that before. Technically, this is not guaranteed to be consistent if I understand that code correctly; txs may leave the pool between calls to /get_blocks and /get_transactions
< xFFFC0000 > Exactly what I was thinking. Thanks a lot.
< xFFFC0000 > jeffro but you get the hashes of all txis at the time of first request.
< rbrunner > Well, if you get anything in chunks it's impossible to avoid that, no?
< jeffro256 > rbrunner: not necessarily, if you obtain the transaction data in a way that respects pool update times
< jberman > if it's not in the pool then read_pool_txs won't add it
< rbrunner > Right.
< jberman > and the request shouldn't fail since it's using /get_transactions which includes both pool and non-pool txs
< jeffro256 > It could in the pool, then served in remaining_added_pool_txids, and then pushed out of the pool before the follow-up call to /get_transactions, right?
< jberman > right, in which case read_pool_txs won't add it to the struct the pool logic uses to process pool txs
< jeffro256 > If it's served in added_pool_txs, that should be fine as long as the packet size isn't too big
< jberman > fwiw I still don't think there's a perfect way to do this, since prior txs you already read may also exit the pool by the time all chunks are complete
< jeffro256 > Okay so we just need to adjust the balancing between added_pool_txs and remaining_added_pool_txids on the daemon side then?
< jberman > I think this is a reasonable approach (and it also mirrors what wallets did before the incremental time logging change)
< jeffro256 > ... Assuming the the TXIDs don't take up up the max packet size
< jberman > ya it won't work if txids take up max packet size
< jeffro256 > That's like, what 3 million txs added in the pool since the last fetch?
< jberman > haha what's the size again?
< xFFFC0000 > 100mb for max levin package size.
< jberman > yep ~3mn txs
< Rucknium > Do we need more time for discussion on this?
< jeffro256 > I followed up with some more firms since the last meeting, one has responded back and said that they will have a proposal soon
< jeffro256 > A couple of minors changes to the spec also
< jeffro256 > Not much other than that at the moment, though
< Rucknium > Different FCMP topic: From what I understand, monerod will still provide an RPC endpoint that would allow wallets to construct the FCMP input proofs, as a backup to wallet-side merkle tree cacheing. Therefore, a decoy distribution is still needed.
< Rucknium > Is that correct, as of current plans?
< jeffro256 > Yes
< jberman > It has been then plan, but the more I'm thinking on it, the less I think it needs to be there. Even light wallet servers would be able to keep track of owned paths today using just the view key
< jberman > It's only when we have that "filter-assist" light wallet tier when light wallets would definitely need that endpoint
< Rucknium > My short-term plan is to finish up some of the black marble research items, finish the OSPEAD estimation with current data, then possibly work on fee uniformity and/or evaluation of Clover.
< Rucknium > Which the OSPEAD estimate would provide the decoy distribution if it is needed in the final FCMP codebase.
< Rucknium > It would be good to get fee uniformity and Clover investigated before the FCMP hard fork, too
< jeffro256 > I worry about pushing some mobile wallets (or wallets with lazy devs) into becoming de-facto light wallets if they are either forced to implement wallet-side tree building in a short time or become a light wallet
< rbrunner > Hmmm, I was thinking most of them use wallet2 at their core
< jberman > ya and wallet2 will do it
< jeffro256 > Yes, the ones that use wallet2 would be fine
< rbrunner > And the rest MyMonero or MyMonero tech
< Rucknium > AFAIK, Exodus has custom code that works with remote nodes.
< jberman > isn't Exodus a light wallet too?
< jeffro256 > Rucknium: we might add an additional daemon output distribution that covers all the outputs that FCMP would be able to spend from (which is everything not malformed), as opposed to the RingCT distribution. I don't know if that would affect your research
< Rucknium > No. You can choose your own remote node with Exodus Desktop at least. And I think Mobile, too (check with tobtoht)
< jberman > I think switching a full wallet to a light wallet is way more work than using the new client-side tree building algo when syncing
< jeffro256 > You might be right
< rbrunner > Well, Exodus is multi-coin, and not open source, last time I checked.
< Rucknium > Basically, it wouldn't because non-RingCT outputs are spent verry rarely. Just ned to make sure that the support of the distribution has positive probability to the beginning of the chain. Basically every distribution I am working with has unbounded support, so they satisfy that
< Rucknium > IIRC Exodus produces about 5 percent of Monero txs
< rbrunner > Yeah, and I was the one coining the motto "No wallet left behind" :)
< jberman > if Exodus isn't using wallet2 and implemented their own syncing logic, they should be more than capable of porting the tree building sync algo
< rbrunner > That RPC call would not be very expensive to implement, I guess?
< jeffro256 > Probably not
< jberman > no it's a very simple endpoint
< Rucknium > There were a bunch of wallets that missed the Aug 2022 hard fork deadline, including Exodus. AFAIK the main change was view tags.
< jeffro256 > We also need an RPC endpoint that compresses the tree before a certain client-specified height anyways unless we want to force every user to resync their wallet from height 0
< Rucknium > I have been working on kayabaNerve's query from last meeting, which I thought would be "easy". I am still not completely satisfied with my probability model, so I don't have computations to share yet.
< chaserene:matrix.org > FYI, the availability of the monero.social Matrix is very spotty on my end. I still haven't received Rucknium's 15:08 UTC reminder either on my monero.social or my matrix.org account, I only see it on https://libera.monerologs.net/monero-research-lab/20240918
< basses:matrix.org > there are issues with monero.social currently
< Rucknium > Does anyone have access to this paper? Jiang & Zhang (2024) "Profitability Analysis of Time-Restricted Double-Spending Attack on PoW-Based Large Scale Blockchain With the Aid of Multiple Types of Attacks" https://ieeexplore.ieee.org/document/10644062
< Rucknium > Published just last month
< rottenwheel:kernal.eu > PSA. monero.social Matrix homeserver is down. If you still want to participate in today's MRL meeting, use a different homeserver or join through IRC.
< chaserene > (^I guess monero.social is back.)
< chaserene > (old messages incoming)
< rottenwheel:kernal.eu > Or perhaps it'll be postponed till homeserver is back up. We'll find out soon.
< rbrunner > If you think it can't get any worse ... then you are bombarded with hours' old messages
< Rucknium > 6) Chainalysis capabilities video.
< Rucknium > Any more thoughts on the video?
< chaserene > back on topic: IMHO if we were to use Kayaba's requirement from the last meeting, 10 blocks seem to be...too low
< Rucknium > There is a huge difference between an adversary having 10 percent and an adversary having 30 percent of hashpower
< rbrunner > I don't think that anything more than 10 is viable for "political" reasons - I don't think will swallow that.
< rbrunner > *people will swallow that
< rbrunner > Not that this should disturb any research, of course
< chaserene > Endor's table is interesting, would be even more useful w/ reorg depths (in hour terms)
< Rucknium > At least with this research we can say for some N lock time, chosen by heuristics, politics, or otherwise, this is the risk profile.
< rbrunner > Fully agree, that's very useful in any case
< Rucknium > I think we can end the meeting here. Thanks everyone.
< jeffro256 > Thanks everyone!
< chaserene > Rucknium: no doubt about that. I'm curious though to understand, what parameters would such a risk profile include?
< chaserene > BTW, thank you all
< Rucknium > Adversary's hashpower share and how long they possess it. Any ideas on any other ones to include?
< chaserene > got it, so this is similar to the table you presented last week. Endor's table made me think that the security budget [dollars/sec] is a factor. I'm unsure how to incorporate it though.
< kayabanerve:matrix.org > I've realized and am willing to concede I don't have a clear view of what powers should be conceded to an adversary and what probability we want to reduce to at this time. I appreciate Rucknium doing the work I asked for on the feasibility of DoSs with limited hash power over time, and look forward to that number in order to influence our decision making process (though off-hand I<clipped message
< kayabanerve:matrix.org > 'd guess they'll be so unlikely they won't matter). I apologize if my request for those calculations are too burdensome.
< Rucknium > IMHO, the problem with saying that the adversary has X budget to spend it any way they want is that it's always better to rent a lot of hashpower for a very short period of time than to rent a little hashpower for a long period of time.
< Rucknium > No, it's fine. That's what I'm here for.
< chaserene > ok, I think I get it. then, as I see it, the adversary hash power share value (the column headers in https://gist.github.com/Rucknium/da1e57b1864aca477dfa3b4e02e86e26) is about what we assume to be the upper bound on what share an adversary can get access to, regardless of their budget.
< chaserene > it's more about "how much of the current hash power is controlled by rogue entities who can urn malicious at any time" + "how much potentially rentable/buyable hash power is out there that's currently not used for mining Monero". is that correct?
< chaserene > *turn
< rucknium:monero.social > IMHO, that's a valid interpretation. The probability calculations don't tell you how the adversary acquired the hashpower.
< rucknium:monero.social > I like this passage from Rosenfeld (2014): "There is nothing special about the default, often-cited figure of 6 confirmations [for bitcoin]. It was chosen based on the assumption that an attacker is unlikely to amass more than 10% of the hashrate, and that a negligible risk of less than 0.1% is acceptable. Both these figures are arbitrary, however; 6 confirmations are overkill for<clipped message
< rucknium:monero.social > casual attackers, and at the same time powerless against more dedicated attackers with much more than 10% hashrate.
< chaser:monero.social > yeah. Satoshi was really good at coming up with arbitrary values that stick with people.
< chaser:monero.social > do I sense it correctly though that that's not the interpretation underlying your table?
< rucknium:monero.social > daybreak: Big changes to the decoy selection algorithm at a time that is not a hard fork means that some users will be using the old version and some would be using the new version. The new Chainalysis video confirms that adversaries are using these types of transaction uniformity defects to reduce user privacy. See my discussion note here for some risk tables: https://github.com/<clipped message
< rucknium:monero.social > If there are no major problems with FCMP (which it looks that way right now), then an OSPEAD-derived decoy distribution would likely be used for wallet-daemon RPC calls as a backup to the in-wallet merkle tree cache as discussed in today's MRL meeting. If for some reason major problems with FCMP are discovered, then a hard fork to increase ring size with current RingCT tech could <clipped message
< rucknium:monero.social > occur. An OSPEAD-derived distribution would likely be implemented at that hard fork.
< rucknium:monero.social > chaser: The table is agnostic about that. These calculations start to get anchored when merchant and services use them. For example, I as a merchant weight how much my goods/services cost me, how much an adversary woud have to spend, etc. The calculations are made more complicated by the fact that an adversary can double-spend against more than one target. IIRC one paper suggested<clipped message
< rucknium:monero.social > that merchants look at the total value being exchanged on the honest, visible blockchain to determine total risk (i.e. as if all txs were going to be double-spent). Of course, you cannot do that with Monero since amounts are confidential.
< rucknium:monero.social > But most merchants and services won't and don't make such complicated calculations. They just set a single confirmation number for everything, maybe arbitrarily chosen, and let it be.
< rucknium:monero.social > AFAIK, today the biggest value that is being exchanged is just other cryptocurrencies against each other, not real goods and services. Peer-to-peer electronic cash....?
< endor00:matrix.org > The security budget is the amount of money "generated" by the network over time. If we assume miners are rational (i.e. they never mine at a loss, i.e. they pay for electricity no more than they earn from mining), then that is also the maximum amount of money spent on electricity
< chaser:monero.social > Rucknium I see. the shitcoin casino averted the double-spend threat :)
< rucknium:monero.social > chaser: I think it enabled the double-spend threat, just not with real goods/services, but with cryptocurrency exchanges. AFAIK most of the incidents in endor00 's table involved transferring other cryptocurrency coins out of the exchange as part of the double spends.
< endor00:matrix.org > By playing around with the security budget, the electricity cost, and the efficiency of the mining devices, we can calculate an approximate size of the mining network (number of devices of a given model, total power consumption, profitability, ROI time, etc.) - which allows us to estimate on how much it would cost to acquire a given amount of hashrate (and thus, own a given % of the nethash)
< chaser:monero.social > Rucknium yes, that's correct. however, I'm almost sure that the trading on on-chain DEXes (think Ethereum, Solana) outweighs CEX deposit/withdrawal volumes.
< chaser:monero.social > to be honest (this is an answer to endor00 too), I may have misunderstood this discussion. my unconscious assumption was that the threat model includes adversaries with extra-protocol incentives, who mine alternative chains even if only for disrupting Monero (for which, admittedly, "double spend risk" is not the right term). a budget-based analysis makes a lot more sense there.
< rucknium:monero.social > It's potentially both types of adversary motivations IMHO. A targeted double-spend beyond the N block lock would cause collateral damage to other users who have their txs invalidated under FCMP. And for an adversary that just wants to cause disruption, the collateral damage is the motivation.
< endor00:matrix.org > Any incentive is a good incentive - the problem is quantifying it.
< endor00:matrix.org > With a simple double-spend attack, it should be fairly straightforward (some % probability of success within a fixed timeframe, vs. a given "reward").
< endor00:matrix.org > If the goal is pure disruption, you can frame it in terms of cost vs. effect (spend X $ to cause some amount of reorgs with some % success, and disrupt some number of txes worth some $ amount).
< endor00:matrix.org > With other types of attacks, it's a bit more complicated, and requires some/a lot of assumptions about the attacker's costs and access to resources, or a more detailed model of what they're doing exactly
< chaser:monero.social > yes, if we want to account for adversaries with extra-protocol incentives, cost and resource access are key.
< chaser:monero.social > we could/should assume the attacker's priority will be to control as much hash power simultaneously as possible. these's a lot of compute in existence that's currently not mining Monero, could profitably mine it, and is accessible, so the share will be (100-ε)%.
< chaser:monero.social > then, even if we pick a double spend attack success probability that we're comfortable with, for a good answer, we need to:
< chaser:monero.social > 1) define a curve that estimates how much non-Monero-mining hash power can be simultaneously acquired at what cost, and
< chaser:monero.social > 2) pick a budget for the adversary.
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:
Greetings
Updates. What is everyone working on?
Stress testing
monerodResearch Pre-Seraphis Full-Chain Membership Proofs. Reviews for Carrot.
10 block lock discussion: Investigate possibility of reducing 10-blocks lock research-lab#102 (comment) , Monero output lock analysis
Chainalysis capabilities video.
Any other business
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:
#1070
The text was updated successfully, but these errors were encountered: