<f​r33_yourself:monero.social> My opinion regarding the idea of limiting maximum inputs to 8 is that it could be bad for merchants when they want to consolidate. I read what kayaba wrote up on github and the conversation here. I'm not so sure that having a function in the wallet that automatically consolidates will be good enough. Because even if you have this it will still be troublesome and slow (20 min wait <clipped me

<f​r33_yourself:monero.social> time for each consolidation) to consolidate and sweep their received coins. Monero has the best privacy at the moment IMO, and sure FCMP++ give even greater privacy but if the coin is very troublesome to accept as medium of exchange (impossible to spend or consolidate many received inputs into an output) then the privacy gains are all for not. If merchants decide it's too much of <clipped me

<f​r33_yourself:monero.social> a pain to deal with then that is no bueno.

<f​r33_yourself:monero.social> My opinion regarding the idea of limiting maximum inputs to 8 is that it could be bad for merchants when they want to consolidate. I read what kayaba wrote up on github and the conversation here. I'm not so sure that having a function in the wallet that automatically consolidates will be good enough. Because even if you have this it will still be troublesome and slow (20 min wait <clipped me

<f​r33_yourself:monero.social> time for each consolidation) to consolidate and sweep their received coins. Monero has the best privacy at the moment IMO, and sure FCMP++ give even greater privacy but if the coin is very troublesome to accept as medium of exchange (impossible to spend or consolidate many received inputs into an output) then the privacy gains are all for naught. If merchants decide it's too much <clipped me

<f​r33_yourself:monero.social> of a pain to deal with then that is no bueno.

<k​ayabanerve:matrix.org> fr33_yourself: It's 20 minutes for each layer of consolidations, not 20 minutes for each consolidation.

<k​ayabanerve:matrix.org> I'll also repeat how only 3% of TXs would be affected per Rucknium's recent analysis of the last five years, and how merchants already have to consider this as the current MAX_INPUTS is high, but not high enough it's unreachable.

<f​r33_yourself:monero.social> How many inputs per 20 minutes or consolidation layer? I thought you said only 8 per 20 min. What is upperbound on inputs per 20 min that can be consolidated

<k​ayabanerve:matrix.org> There's a logarithmic amount of layers.

<k​ayabanerve:matrix.org> If you have 1 million outputs, you can consolidate them in (log_MAX\_INPUTS(1 million) - 1) * 20 minutes.

<f​r33_yourself:monero.social> I saw your comment. I'm just thinking about how merchants that receive a few hundred tx per day can consolidate when they want to move funds? How would consolidation and sweeping in a reasonable timeframe work post FCMP++ hardfork?

<k​ayabanerve:matrix.org> So for MAX_INPUTS = 8, 2 hours.

<k​ayabanerve:matrix.org> (for an absurd amount of inputs)

<k​ayabanerve:matrix.org> 1m -> 125k -> 16k -> 2k -> 250 -> 32 -> 4

<f​r33_yourself:monero.social> Ok, I'm not sure I fully understand the logarithmic nature of the math, but I'll take your word for it

<k​ayabanerve:matrix.org> It's that final line I just sent.

<k​ayabanerve:matrix.org> 1m outputs is consolidated into 125k outputs, each consolidation transaction only having 8 inputs.

<k​ayabanerve:matrix.org> Then the 125k outputs is consolidated into just ~16k outputs, each consolidation transaction only having 8 inputs.

<f​r33_yourself:monero.social> Let's say someone has received 7,000 separate transactions (inputs) into one wallet in a week. At the end of the week they want to sweep those coins into another wallet. What would this process look like after FCMP++ ?

<k​ayabanerve:matrix.org> So if you have 50 outputs, it's literally just 20 minutes. You make 7 transactions (7 * 8 = 56, which is more than 50) and then end up with 7 outputs 20 minutes later.

<k​ayabanerve:matrix.org> They make ~900 transactions aggregating 7000 outputs into 900 outputs. Then they make ~115 transactions aggregating 900 outputs into 115. Then 15 aggregating 115 into 15. Then they finally sweep two outputs in two TXs to the other wallets. It'd take one hour.

<k​ayabanerve:matrix.org> Under the current MAX_INPUTS, which I cited as 220 in practice yet ofrnxmr says is 120 (which I believe is correct), it'd not be 7000 -> 900 -> 115 -> 15 -> 2 but 7000 -> 70 -> 1. It'd be only 20 minutes but this would still need to be programmed and considered.

<f​r33_yourself:monero.social> And I guess they would write some sort of software to do that? Kinda seems pretty difficult manually performing all of those transactions though

<k​ayabanerve:matrix.org> Yes, as they _already_ do.

<f​r33_yourself:monero.social> How do they do that just curious

<f​r33_yourself:monero.social> Sorry I am a bit of a n00b\

<k​ayabanerve:matrix.org> Eh. You can flood your destination wallet with 70 outputs (per the prior example). It'll just need to do its own consolidation after the second week.

<k​ayabanerve:matrix.org> I'm saying they already have to.

<k​ayabanerve:matrix.org> I can't comment on if/how literal services do.

<k​ayabanerve:matrix.org> I'm noting that today, in Monero, you cannot spend 7k outputs in one TX and already need to consolidate as I describe here.

<f​r33_yourself:monero.social> How do you know that they already have to navigate this challenge?

<k​ayabanerve:matrix.org> Because there's already a MAX_INPUTS in practice?

<k​ayabanerve:matrix.org> I'm not introducing this. I'm just proposing adding an explicit, lower value than the current implicit one.

<f​r33_yourself:monero.social> What's the practical max input again?

<k​ayabanerve:matrix.org> 120 AFAIK

<k​ayabanerve:matrix.org> So for your example of 7000 outputs a week, yes, those have to be consolidated if you want to spend your entire wallet balance at once.

<f​r33_yourself:monero.social> Do you have any guesses how merchants currently handle it? I mean 120 input max per tx is still a lot more than 8 though

<f​r33_yourself:monero.social> so if they are manually performing the transactions by hand in the command line or gui wallet then it probably wouldn't be too atrocious currently

<k​ayabanerve:matrix.org> No idea. I am not privy to the inner workings of centralized exchanges re: a privacy coin which makes trying to reverse-engineer this on-chain near impossible.

<k​ayabanerve:matrix.org> Centralized exchanges are the primary affected group IMO. They're the group I'd see with the most volume who also regularly needs to make transfers out.

<k​ayabanerve:matrix.org> Monero already has some code to handle the case where your outputs don't fit within MAX_INPUTS. `transfer_split`.

<k​ayabanerve:matrix.org> I also noted how transaction chaining allows a wallet running in the background, without the private keys, to handle consolidation (if a user comes online once to initialize it).

<f​r33_yourself:monero.social> Yes I saw that. And it all sounds nice in theory. I just wonder if it will really get implemented that quickly after a FCMP++ hardfork

<k​ayabanerve:matrix.org> So from a UX perspective, this should still be resolvable. More users will have to leave their wallet open in the background, and there will be higher latency for anyone wanting to spend a large value of their wallet funded from a bunch of small inputs, but that's about it. I'll also point out how UTXO consolidation is a frequent topic within the Bitcoin community. This is somethi<clipped message

<k​ayabanerve:matrix.org> ng exchanges and users already face over there, and Monero already faces (even if we don't discuss it as much).

<k​ayabanerve:matrix.org> Agreed wallets needs to take the step after. Wallets needing to do that isn't enough of a problem to justify the fundamental DoS issues with keeping MAX_INPUTS at 120.

<k​ayabanerve:matrix.org> If we did one FCMP per proof, minimizing the computational base cost and allowing as much batch verification as possible, we'd only support 16 inputs under the current implicit limit FWIW.

<f​r33_yourself:monero.social> Thanks for taking the time to address some of my concerns. If it's really not that big of a deal for merchants or exchanges that are receiving tons of transactions, then my concerns are unwarranted. I just worry about kicking those types of people off the network by making it super hard to use. As Monero's use-value is dependent on online merchants or vendors being able to accept <clipped me

<f​r33_yourself:monero.social> lots of fairly small "chunks" inputs, and being able to move them in a reasonable timeframe and with minimal headache.

<k​ayabanerve:matrix.org> I have mixed feelings. I completely agree with you in that Monero has to be usable.

<k​ayabanerve:matrix.org> I also just believe there's risks to the protocol itself without this and we can't risk protocol stability for usability.

<k​ayabanerve:matrix.org> I do agree this will be another annoyance. I fear the risks otherwise would be far more annoying. If TXs did take 2 seconds to validate, free RPCs would disappear or require you spend tens of seconds on PoW to justify even listening to your RPC request.

<f​r33_yourself:monero.social> What's the DOS problem with max inputs at 120? I didn't catch this?

<k​ayabanerve:matrix.org> Right now? None, it's just a large TX. Under FCMPs++? 120 * 15ms = 1.8s verification time

<k​ayabanerve:matrix.org> (assuming a linear growth in proof time from 1 input to 120 inputs)

<f​r33_yourself:monero.social> What are the implications of 2 second verification time per tx?

<k​ayabanerve:matrix.org> I also do believe the usability concerns here *should be mitigatable at the wallet level* and that's where *they should be mitigated*.

<f​r33_yourself:monero.social> That it requires more bandwidth to keep up to date with current blockheight?

<k​ayabanerve:matrix.org> No, we'd presumably lose free RPCs

<f​r33_yourself:monero.social> or is the problem with the initial blockchain sync verification

<k​ayabanerve:matrix.org> If I can trigger your server to spend two seconds verifying a transaction it takes me 20ms to upload, I can DoS you for ages.

<k​ayabanerve:matrix.org> It's a massive asymmetry which allows trivially occupying any free Monero nodes.

<f​r33_yourself:monero.social> Ahhhh I see. So that is what you mean by DOS.

<k​ayabanerve:matrix.org> I believe it would lead to paid RPC access in some form, either explicitly monetary, via PoW (the whole credit system we currently have with calls to deprecate), or via anti-spam PoW (which will be tens of seconds on mobile devices to publish any transaction).

<f​r33_yourself:monero.social> So the game theory would be that people would remove their publicly available nodes or nodes like cake wallet's would get DOS'd

<k​ayabanerve:matrix.org> That's not even to discuss the risk to the P2P layer itself where any node can send you a TX which takes multiple seconds to validate.

<f​r33_yourself:monero.social> Yeah the P2P layer seems like a bigger deal

<f​r33_yourself:monero.social> I mean power users should be running their own nodes anyways.

<k​ayabanerve:matrix.org> It's just an outrageously easy burden to trigger on any publicly accessible node and will likely lead to nodes not being publicly accessible.

<k​ayabanerve:matrix.org> Yeah, such a large computation time has a burden in a lot of places...

<f​r33_yourself:monero.social> It's great for there to be free RPC, but if that went away I don't know how much it would effect Monero's core user base

<k​ayabanerve:matrix.org> Also, I may be somewhat biased as I wrote the code to handle this years ago and don't need to make any adjustments.

<k​ayabanerve:matrix.org> But also, I wrote this code years ago because it was necessary years ago. My proposal to reduce MAX_INPUTS doesn't change its necessity.

<k​ayabanerve:matrix.org> That's a recent proposal

<f​r33_yourself:monero.social> What are the implications of 2 second verification time for the peer to peer layer? Also for bandwidth and staying up to date? And for initial blockchain sync?

<k​ayabanerve:matrix.org> But that also means I've accepted this, been ready for this, and have had years to cope with this. Y'all are only just facing it :p

<k​ayabanerve:matrix.org> If the network got DoSd, any node publishing/relaying a TX would need to include an associated PoW to justify it most likely? I'm not a P2P net person so I can't comment how this would ideally be solved.

<k​ayabanerve:matrix.org> We're likely back to whoever makes the TX spending tens of seconds on an anti-spam PoW *after signing it and proving for it* to justify it.

<k​ayabanerve:matrix.org> But it's such an outrageous burden it isn't 'how do we cope with it', it's 'let's ban that by reducing MAX_INPUTS'

<k​ayabanerve:matrix.org> Setting MAX_INPUTS to 8 actually shouldn't hurt the computational burden of the network. Outlier TXs pay a base cost. Non-outlier TXs share a base cost.

<f​r33_yourself:monero.social> I mean I'm not a high volume merchant, so it's not the end of the world for me personally. My main concerns about FCMP++ are related to bloat in tx size, sync time, and the issue we are discussing about limiting max inputs. I guess making sure the code is sound and no inflation during the hard fork are also important points of focus. I'm kinda neutral on the FCMP++ upgrade. I unde<clipped me

<f​r33_yourself:monero.social> rstand the benefits, but the costs are harder to get my head around. \

<k​ayabanerve:matrix.org> Forcing more TXs to not be outliers, by limiting how far they can be outliers (MAX_INPUTS=8, not MAX_INPUTS=120) means more TXs share a computational cost.

<k​ayabanerve:matrix.org> Also, the cost to verify the Bulletproof for 8 inputs vs 120 inputs is largely linear? It's technically `O(n / log n)` due to the multiexp but I've been handwaving that out.

<f​r33_yourself:monero.social> This seems like a nightmare to implement, so I can see why it would be desirable to keep verification time per tx low

<k​ayabanerve:matrix.org> So verifying 15 8-input TXs vs 1 120-input TXs *independently, not in a batch* should be largely the same.

<k​ayabanerve:matrix.org> The one consideration is that the 15 8-input TXs produces 15 outputs and the 1 120-input TX produces 1 output. That means we do pay a logarithmic cost for the inevitable consolidation of those 15 outputs.

<k​ayabanerve:matrix.org> So it goes from a giant O(n / log n) cost -> an incremented O(n * log n) cost

<f​r33_yourself:monero.social> I'm following

<k​ayabanerve:matrix.org> It's generally always better to handle things incrementally than at-once, even if the at-once cost is cheaper overall.

<f​r33_yourself:monero.social> So what is difference in projected verification time with max inputs = 8 versus max inputs = 120 post FCMP++ hardfork

<k​ayabanerve:matrix.org> (and we do still have a `/ log n` when verifying a one-input proof, it's just less notable as it matters more when n is large)

<k​ayabanerve:matrix.org> was my handwaved estimate though I've not prior benched 120 inputs (solely the one input case)

<k​ayabanerve:matrix.org> 15ms an input

<k​ayabanerve:matrix.org> So with a limit of 8 inputs, each TX can only cause ~120ms of burden.

<k​ayabanerve:matrix.org> The code is sufficient someone can run the benchmark for the 120-input case though, I just find that not productive and haven't bothered

<k​ayabanerve:matrix.org> ofrnxmr: github.com/monero-project/monero/bl…rc/wallet/wallet2.cpp#L11076-L11085

<k​ayabanerve:matrix.org> The full reward zone is 300000. That, div 2, minus 600 (coinbase blob reserved size) is the 149400 value I quoted.

<f​r33_yourself:monero.social> Ok so what again are the exact issues that having the much lower verification time (15 x 8 = 120ms) solve?

<k​ayabanerve:matrix.org> Are you sure there's a further 66% applied ofrnxmr ?

<f​r33_yourself:monero.social> What is the verification time currently for an 8 input transaction? Just out of curiosities sake

<k​ayabanerve:matrix.org> fr33_yourself: It prevents being able to get an arbitrary node to spend 2s, a massive amount of CPU time, off a P2P/RPC request as I said.

<f​r33_yourself:monero.social> versus post FCMP++

<k​ayabanerve:matrix.org> No idea. I referred to the rationale for MAX_OUTPUTS in which this discussion follows, not the current premise with MAX_INPUTS.

<k​ayabanerve:matrix.org> I'm returning to my work so please refer to my post or do your own benchmarking for more information.

<f​r33_yourself:monero.social> max_outputs isn't so worrisome for me personally, I defer to the judgment of you and the others. I was curious about max_inputs only as that has an impact on large merchants

<k​ayabanerve:matrix.org> ofrnxmr: github.com/monero-project/monero/bl…53c454/src/wallet/wallet2.cpp#L9597

<k​ayabanerve:matrix.org> I really think wallet2 is the 149,400 value, per my re-review of the code I prior reviewed when working on monero-wallet, despite my historical belief it was 100kB and your active belief it was. Would appreciate you citing the further 67% rule or acknowledging we were wrong about 100kB (or someone else with wallet2 experience chiming in, this probably is better for monero-dev though...)

<c​haser:monero.social> all the better!