00:00:04 <selsta> .merges
00:00:04 -xmr-pr- 8061 8232 8239 8240 8241 8245 8246 8247 8254
00:51:58 <moneroextremist[> any update on seraphis release date
01:04:40 <selsta> luigi1112: pls pls pls cli + gui merges
01:12:15 <UkoeHB> moneroextremist[: far in the future
02:04:09 <jeffro256[m]> > restricted-rpc is to avoid fingerprinting and also disable things like start/stop mining and stopping the daemon
02:06:28 <jeffro256[m]> selsta I meant that MD5 is not safe for authentication because its so easy reverse an MD5 hash, so any password is not safe and anyone could start/stop mining if they had challenge data and the hash
02:06:59 <selsta> oh ok, I see
02:07:30 <jeffro256[m]> Also how does restricted-rpc prevent fingerprinting?
02:07:55 <selsta> it removes specific data from get_info that can be used for fingerprinting
02:09:36 <jeffro256[m]> Ahh yes I forgot about that good point
02:10:20 <jeffro256[m]> selsta do you know of anyone working on TLS for RPC or the levin protcol?
02:10:51 <jeffro256[m]> I know vtnerd was doing something called the Noise protocol, which adds a bunch of noise to Levin packets
02:11:06 <selsta> jeffro256[m]: did you do ./monerod --help and grep for ssl?
02:11:29 <selsta> there are already options that's why I'm confused
02:11:44 <selsta> Noise protocol is for P2P traffic and not RPC
02:13:58 <jeffro256[m]> Oh wow how did I not know about ssl for rpc
02:14:10 <jeffro256[m]> thats cool
02:15:25 <jeffro256[m]> i did know noise was for p2p
03:12:50 <luigi1112> whoa triple plx
03:12:53 <luigi1112> pls
03:13:04 <luigi1112> .merges
03:13:04 -xmr-pr- 8061 8232 8239 8240 8241 8245 8246 8247 8254
03:31:09 <luigi1112> .merges
03:31:09 <xmr-pr> Merge queue empty
03:41:10 <gingeropolous> look at all them merges!
04:18:37 <selsta> .merge+ 8248 8249
04:18:37 <xmr-pr> Added
09:41:03 <mj-xmr[m]> Hey, Management, which channel is for https://repo.getmonero.org/ ? I'm getting error: 500
10:01:50 <moneromooo> It ran out of disk :S I'll see if I can find what's filled it.
10:28:40 <moneromooo> Looks like it's 149 GB of website tarballs for some reason. Not sure if deleting most of them would break it...
10:29:01 <moneromooo> All dating from today so I can't even nuke old ones.
10:40:43 <moneromooo> There's more space now. If anything breaks, let me know, so I know even if I have nfi how to fix :)
10:41:04 <moneromooo> Especially to do with the site repo, since it's the one I nuke stuff in.
10:41:41 <moneromooo> It's also a temp solution, since I don't know why these things have been accumulating in the first place...
10:43:02 <ErCiccione> tarballs for the website should be in their dedicated box IIRC
10:43:23 <ErCiccione> binaryFate ^
10:43:49 <moneromooo> It's tarballs made by gitlab.
10:44:08 <moneromooo> I suspect test "builds".
10:52:46 <moneromooo> lol, 1.7 million users. Such spam.
10:53:21 <moneromooo> Sad gitlab doens't make a one click nuke button for these gobshites.
11:31:29 <kayabaNerve> How is mask normalization handled with BP+? I see where output keys are normalized for comparison against the pseudoOuts yet I don't see where it normalizes the pseudoOuts.
11:33:42 <kayabaNerve> And is that the only consensus change introduced besides the BP format itself? I looked over the diff and just wanted to confirm that was it.
11:46:28 <moneromooo> Oddly, it looks like gitlab itself removed those cache files now. I guess it was a temporary "need a lot of disk right now".
11:47:03 <moneromooo> Or my removing some stuff made it reset the cache. Either way, there's ample free space again and it seems to still work.
17:37:16 <gingeropolous> xmrchain node uptime 48 days. just started current master
18:12:58 <UkoeHB> kayabaNerve: IIRC the pseudoOuts are not normalized. Pre-multiplying the output commitments by 1/8 is a time-saving measure since BP+ wants to multiply them by 8.
18:13:25 <kayabanerve[m]> ... right.
18:13:39 <kayabanerve[m]> Except they still do the equivalence check
18:14:16 <kayabanerve[m]> Which means that the inputs, which are either of form 1 or 1/8, are checked against the outputs multiplied by 8 to 1
18:14:40 <kayabanerve[m]> Doesn't that mean amounts get nuked with only 1/8th being spendable?
18:15:20 <UkoeHB> hmm good question
18:15:20 <kayabanerve[m]> ... and since that's a multiplicative inverse, doesn't that mean the input amounts become incredibly high and effectively an infinite mint?
18:15:31 <moneromooo> I don't know about any normalizing (unless that means reduction ?) but the 1/8 is to make sure the verifier can't ever get anything not in the main subgroup.
18:15:55 <kayabanerve[m]> I'm referring to the multiplication by cofactor 
18:16:24 <kayabanerve[m]> Because I understand it's done here to ensure the correct subgroup is used but it still effects the b value directly
18:17:02 <moneromooo> Well, if you think there might be an exploit, you'd ask luigi1111 (or, if still around somewhere, sarang).
18:17:21 <kayabanerve[m]> I also understand this never would've made it to prod but I'm pretty sure this is on master with a stagenet height usable for testing?
18:17:59 <kayabanerve[m]> moneromooo: My comment is the second anyone tries to use this they'll be spending commitments multiplied by INV_EIGHT which isn't feasibly valid in the slightest
18:19:23 <kayabanerve[m]> I'll rebuild my node later (possibly tomorrow) and try it out. If it immediately breaks then... Yeah. Else I'll try to figure why it isn't breaking and what line I'm missing.
18:20:38 <luigi1112> the equivalency check is after multiplying by 8 no?
18:20:54 <luigi1112> amount -> *inv8 -> *8 -> check
18:20:57 <sethforprivacy> IIRC rbrunner has this running on a private testnet without issues sending transactions kayabanerve 
18:20:58 <kayabanerve[m]> luigi1112: Right but the issue isn't with the outputs 
18:21:01 <kayabanerve[m]> It's with the inputs
18:21:41 <luigi1112> that was my assumption
18:21:45 <kayabanerve[m]> Because the outputs are saved as *inv8 and not *8 again when used as inputs...
18:22:25 <kayabanerve[m]> luigi1112: I know saw a mul by cofactor on the outputs 
18:22:31 <kayabanerve[m]> * I only saw a mul by cofactor on the outputs 
18:22:58 <luigi1112> oh I see
18:23:15 <kayabanerve[m]> Not to mention if it was on the inputs, we'd have to know which form they were (1 or 1/8)
18:23:46 <moneromooo> kayabanerve[m]: maybe you could add a test showing how to exploit that (and then if the test fails, we have a guide for fixing it).
18:24:07 <kayabanerve[m]> So then the thing is we have to get them from the block as 1/8 yet save them to disk as 1 yet I didn't see code doing that. They looked to be copied but I may have just missed the pointer handling.
18:24:10 <moneromooo> Granted, the core tests are a bit of a pita to write...
18:26:19 <kayabanerve[m]> moneromooo: I do hear you. It's just not an exploit. It's "this shouldn't work even without any trickery, with an honest wallet". Seth For Privacy: suggested it was running on a local net
18:26:25 <kayabanerve[m]> So I'm more curious what I'm missing then...
18:27:41 <moneromooo> OK, I'm not sure what you're talking about exactly, but I know where there's one *8 to match a 1/8, miht be the one you're missing:
18:27:56 <kayabanerve[m]> luigi1112: https://github.com/monero-project/monero/blob/master/src/ringct/rctSigs.cpp#L1483-L1503
18:27:58 <moneromooo> in expand_transaction, in cryptonote_core.cpp IIRC
18:28:12 <moneromooo> That's when loading a tx from serialized format.
18:28:18 <kayabanerve[m]> moneromooo: This would be it if I'm just missing it, thanks :)
18:28:43 <UkoeHB> kayabanerve[m]: https://github.com/monero-project/monero/blob/9f814edbd78c70c70b814ca934c1ddef58768262/src/ringct/rctSigs.cpp#L1490
18:29:10 <moneromooo> Hrm. I remembered wrong actually...
18:29:16 <kayabanerve[m]> UkoeHB: Right, for outPk
18:29:42 <moneromooo> It's a mul by 1/8.
18:30:08 <kayabanerve[m]> But when that outPk is saved to disk, and eventually loaded as a ring member... It'll be aG + bH * INV_EIGHT
18:30:15 <UkoeHB> oh hm
18:30:21 <kayabanerve[m]> Which means that the pseudoOut will need to be for bH INV_EIGHT
18:30:23 <kayabanerve[m]> Which means you'll be spending a completely disparate amount 
18:30:48 <luigi1112> seems like that should fail any test param
18:31:26 <kayabanerve[m]> Which means either it's saving to the disk the *8 form, yet the line you quoted is on a copy, or it has to check every ring member it loads for normalization and repeat *8, voiding any performance savings
18:31:41 <kayabanerve[m]> luigi1112: Right EXCEPT this will pass BP just fine
18:31:58 <UkoeHB> this mul 1/8 optimization added so much spaghetti, I don't think it was worthwhile (probably <1% speedup)
18:32:05 <kayabanerve[m]> It just won't generate a spendable ring member which is why it may have been an oversight 
18:32:35 <luigi1112> UkoeHB rip it all out
18:32:45 <luigi1112> half serious
18:33:03 <kayabanerve[m]> UkoeHB: This was my stance and why I was here asking about it. AFAICT, it's not correctly implemented, creates disparate block/disk representative when done successfully, and doesn't have testing as of right now which makes the code living on master broken.
18:33:19 <luigi1112> is this for the next fork/bp+?
18:33:27 <kayabanerve[m]> Yeah
18:34:01 <kayabanerve[m]> Which is why it wasn't noticed. I don't think anyone actually tried spending the BP+ outputs yet :p This would've been caught in a few weeks at worst 
18:34:24 <luigi1112> wait so I'm understanding: is it proposed that new outputs post fork are stored *inv8, then when loaded *8? But no distinction is made vs pre fork outputs which are obviously not stored that way?
18:34:52 <UkoeHB> luigi1112: apparently that's what the bp+ pr did
18:34:53 <kayabanerve[m]> luigi1112: But they're not currently loaded *8 so even if that was the intent...
18:35:10 <kayabanerve[m]> kayabanerve[m]: .
18:35:11 <UkoeHB> good work kayabanerve[m] noticing this issue
18:35:23 <luigi1112> woof
18:35:32 <luigi1112> plz keep investigating :)
18:35:42 <kayabanerve[m]> You can have it with performance. You just need to save the *8 form and keep INV_EIGHT limited to serialization 
18:35:59 <kayabanerve[m]> But I'm not sure it's feasible to effectively pass it around and I don't recommend the headache
18:36:08 <luigi1112> doesn't seem worth at all to me
18:36:25 <UkoeHB> I think the 1/8 adds too much complication. This is the reason I did not implement 1/8 for key images in seraphis (even though it would be a speedup).
18:37:00 <kayabanerve[m]> Happy to :) I clicked on it when I reviewed Ukoe's next standing multisig PR (impeccable except for one comment I have yet to hear back on) and it stuck out to me, so figured I'd bring it up
18:37:20 <sethforprivacy> Phew nice find kayabanerve 
18:37:24 <sethforprivacy> Surprised that wasn't caught in audits...
18:37:27 <UkoeHB> I think:
18:37:27 <UkoeHB> 1) see if we can get errors in test to confirm the failure
18:37:27 <UkoeHB> 2) rip it out
18:37:49 <kayabanerve[m]> UkoeHB: Some dude called Kayaba should probably submit a Ristretto encode and fix this once and for all :p
18:39:14 <UkoeHB> sethforprivacy: I don't think audits cover the full protocol from that higher vantage point
18:39:30 <kayabanerve[m]> sethforprivacy: It's an optimization tacked on outside of the BP+ code yet only halfway implemented. It would've immediately created invalid results and broken any testnet it ran on, unless we all are missing where it saves to disk in the proper form (keeping the 1% performance gain)/corrects it on load (worsening performance)
18:39:52 <luigi1112> yeah agreed it would fail immediately
18:40:05 <luigi1112> (if it exists how we think)
18:40:15 <kayabanerve[m]> Technically you can still create valid proofs under it.
18:40:25 <luigi1112> yeah but naively you wouldn't I would think
18:40:29 <kayabanerve[m]> luigi1112: want a few million xmr? 👀
18:40:36 <luigi1112> probably a lot more than that :P
18:40:46 <kayabanerve[m]> Well I have to keep some for myself
18:41:00 <luigi1112> ^_^
18:41:13 <luigi1112> this is like the key image thing all over again
18:41:18 <kayabanerve[m]> But yeah, Monero wallet would've immediately errored
18:42:16 <kayabanerve[m]> So Ristretto is
18:42:16 <kayabanerve[m]> 1) marginally slower to encode/decode
18:42:16 <kayabanerve[m]> 2) faster to check equality
18:42:16 <kayabanerve[m]> But I'm still expecting a marginal performance decrease with its introduction. I'm still advocating for it though because it fixes all of this. The end
18:42:57 <UkoeHB> mul8 when decoding amounts: https://github.com/monero-project/monero/blob/9f814edbd78c70c70b814ca934c1ddef58768262/src/wallet/wallet2.cpp#L11357
18:43:06 <UkoeHB> (during view scanning)
18:43:32 <kayabanerve[m]> We just never have this discussion or concern again. Seraphis will already force new keys. We can change curves without issue. We can even promote existing points to Ristretto if we absolutely need to so there truly shouldn't be consensus issues
18:44:23 <jberman[m]> I've got a local test env of the lastest master including bp+ set up sending and receiving bp+ tx's, spending outputs created from bp
18:44:43 <UkoeHB> Are we missing an integration test that mines rcttypebpp to chain then tries to spend them out of the ledger?
18:45:04 <kayabanerve[m]> jberman[m]: In that case we're all missing something and I have no idea where it is. I'm guessing it's saving to disk in mul8 and we just have multiple mul8s 
18:45:36 <moneromooo> core_tests/bulletproof_plus.cpp ought to do that, but they're really GGGHNNN to write...
18:46:01 <jberman[m]> Is this possibly the line you're looking for? https://github.com/monero-project/monero/blob/9f814edbd78c70c70b814ca934c1ddef58768262/src/blockchain_db/blockchain_db.cpp#L248-L249
18:46:01 <jberman[m]> this is called right before saving to disk
18:46:12 <UkoeHB> jberman[m]: did you confirm the tx types produced are bp+?
18:46:59 <UkoeHB> jberman[m]: that line must be doing all the work, nice find
18:47:28 <kayabanerve[m]> blockchain_db does perform this
18:47:39 <kayabanerve[m]> > <@jberman:matrix.org> Is this possibly the line you're looking for? https://github.com/monero-project/monero/blob/9f814edbd78c70c70b814ca934c1ddef58768262/src/blockchain_db/blockchain_db.cpp#L248-L249
18:47:39 <kayabanerve[m]> > 
18:47:39 <kayabanerve[m]> > this is called right before saving to disk
18:47:39 <kayabanerve[m]> Yep, also just found it
18:48:43 <UkoeHB> considering how much more difficult it is to reason about the protocol with this change, I'd advocate a PR to undo the 1/8 stuff
18:49:15 <kayabanerve[m]> ... are we keeping this or can we agree
18:49:15 <kayabanerve[m]> 1) this headache is proof it's not worth it
18:49:15 <kayabanerve[m]> 2) if we're already doing this mul 8 multiple times (signature verification, save to disk, AND wallet scanning) we're nuking the performance benefit
18:49:15 <kayabanerve[m]> 3) it's confusing to change the commitment communication format (the one committed to in hashes) midway through the chain with no need to
18:49:26 <kayabanerve[m]> UkoeHB: Ditto
18:49:53 <luigi1112> support
18:50:06 <moneromooo> FWIW I don't really care about wallet scanning here, just node verification.
18:50:12 <UkoeHB> undoing this would require a hard reset of any testnet running this
18:50:27 <kayabanerve[m]> I thought I was just missing it when I started, but then everyone here also agreed this seemed missing, and yet here it was in blockchain_db .-.
18:50:27 <moneromooo> That happened before, not a problem.
18:50:49 <jberman[m]> the hardfork isn't scheduled in the testnet yet
18:50:50 <luigi1112> kayabanerve[m] it did seem too obvious to miss haha
18:51:10 <moneromooo> Hey, I coded this, I forget things as a matter of course :/
18:51:36 <UkoeHB> any volunteers to write the PR? otherwise I can do it (would rather focus on seraphis stuff tbh)
18:51:47 <kayabanerve[m]> luigi1112: Right. I legitimately thought if it was missing, it would've have to been the BP+ code was the tail result so it was never built off of in the tests :p I thought that may technically be possible?
18:52:07 <kayabanerve[m]> I'll work on it now. First time doing a PR that matters so will be nice
18:52:17 <UkoeHB> cool thanks kayabanerve[m] 
18:52:19 <luigi1112> is the estimate really like 1%?
18:52:27 <UkoeHB> probably just need to go through the original pr and find all instances
18:52:32 <moneromooo> I suppose I should write it. I owe more work to the community and I wrote it... Kinda still in burnout mode though.
18:52:48 <kayabanerve[m]> moneromooo: I'm excited for the opportunity so don't worry ;)
18:52:51 <moneromooo> Thanks kayabanerve[m] :D
18:53:16 <kayabanerve[m]> It's not every day you get to say you helped decide and implement xmr consensus rules :p
18:53:25 <moneromooo> Would be nice to see the chain verification speed change too.
18:54:33 <kayabanerve[m]> It's replacing 6 doublings with a scalar mult and equality check, if we do actually need to force BP points to be in the main subgroup (which would be implemented the same way the key image check is)
18:54:37 <UkoeHB> luigi1112: on average, each output in a tx corresponds to ~80-100 variable base multiplications, so avoiding one mul-group-order per output is pretty small
18:55:05 <UkoeHB> (back of the napkin)
18:55:18 <moneromooo> It does remove a exponential to group order, no ? IIRC. Maybe.
18:55:25 <moneromooo> To check the thing is in the right subgroup.
18:56:07 * moneromooo feeling almost angry all the crypto didn't stick
18:57:36 <UkoeHB> yeah, mul-group-order = exponential to group order
18:58:08 <moneromooo> Hrm. ISTR this is fairly slow...
18:59:48 <UkoeHB> in the context of a tx, which has a bp+ proof and clsag proof per output on average, it's not that bad
19:00:08 <moneromooo> Alright, fair enough.
19:00:26 <moneromooo> IIRC it seemed like a free win...
19:01:04 <WillMorrison[m]> just making sure I'm not missing something, monero-wallet-rpc's --tx-notify only gets called when the transaction is first seen and when it has one confirm, right?
19:01:21 <WillMorrison[m]> I was hoping it would call a third time when the funds unlocked, but I'm not seeing that
19:01:39 <moneromooo> It's definitely not calling when it reaches 10 confirmations.
19:19:49 <rbrunner> For what it's worth, that earlier question whether I am running a testnet: Yes, for weeks already, jberman's view tags branch, to test that. Not BP+ in any case
19:19:56 <WillMorrison[m]> <moneromooo> "It's definitely not calling when..." <- so to watch for when transactions hit 10 confirms, I need to first add transactions to a group from tx-notify when they hit 1 confirm and then poll them?
19:20:41 <moneromooo> Well, poll the height I guess. But yes, polling the txes would also work.
19:20:50 <moneromooo> IIRC tippero polls the height.
19:21:14 <moneromooo> Jeez. Did I really write that 8 years ago :D
19:21:39 <WillMorrison[m]> what would polling the height do?
19:23:46 <moneromooo> Tell you current height, which you can compare to the height at which the received outputs may be spent.
19:24:14 <moneromooo> Not quite, in case of reorg, but close enough I guess.
19:24:43 <WillMorrison[m]> Ah I see, where do I get the height that they can be spent at?
19:24:53 <WillMorrison[m]> and is that a better method of checking than watching for 10 confirms?
19:25:26 <moneromooo> Good point, they might have an unlock time. In that case, polling the txes is better indeed
19:25:46 <WillMorrison[m]> ok thanks
19:25:59 <WillMorrison[m]> unfortunate that polling is required to do this, I was hoping I could avoid it
19:26:05 <moneromooo> (polling height was just lightweight)
19:27:52 <cryptogrampy[m]> The monero-javascript library has some nice wallet transaction query methods that may be worth digging into.  Not sure what rpc methods they're wrapping: https://moneroecosystem.org/monero-javascript/MoneroTransferQuery.html
19:27:55 <WillMorrison[m]> moneromooo: just making sure I'm not missing some better way, tx-notify is what I should be using for making a monero payment processor, right?
19:28:38 <WillMorrison[m]> thanks, I'll take a look
19:31:19 <cryptogrampy[m]> example query from a project i'm messing with :)... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/0bb4a1c47248c57788546fe8a8439fd4eefcb3eb)
19:35:29 <cryptogrampy[m]> Also, in the monero-javascript library, the onOutputReceived event is called 3 times - once when unconfirmed, once when confirmed, and once when unlocked.  
19:36:11 <WillMorrison[m]> cryptogrampy[m]: ah that's definitely useful, I'll look now to see how they do that
20:01:35 <selsta> rbrunner: could you reapprove the ring size 16 PR? it got rebased
20:11:29 <rbrunner> Done.
20:11:46 <selsta> ty
20:35:47 <nioc> wow has been running BP+ for 10 months
20:36:27 <nioc> not sure if what you are discussing was included in that version 
20:38:41 <kayabaNerve> nioc: Really interesting to hear. I don't know the full history (the PR is only 4 months old) yet I'd assume it has this optimization. It does, technically, work. It just mutates transaction state vs effective state and redefine commitment formulas which makes it... problematic. It's a hassle not worth it overall.
20:40:01 <kayabaNerve> I did get the presumed patch ready. I've been stuck building for a bit and may go to sleep soon though, so probably looking at publication tomorrow. It's pretty simple overall.
21:13:35 <selsta> .merge+ 8178
21:13:35 <xmr-pr> Added
23:49:26 <GuruJi[m]> Hello everyone. Can I have a question about a specific issue with monerod in this channel?
23:52:36 <w[m]> If not dev related, ask in #monero:monero.social and ill try to answer you there
23:54:22 <GuruJi[m]> w[m]: Ok thank you