02:37:50 <jberman[m]> <carrington[m]> "Other than the Paymo paper (..." <- Here's another approach by Sarang/Surae/others (unless you were implying DLSAG isn't in the cards for Monero): https://www.reddit.com/r/Monero/comments/bvz97k/dlsag_noninteractive_refund_transactions_for/
02:39:14 <jberman[m]> Small comment on Lelantus compatibility: https://www.reddit.com/r/Monero/comments/bvz97k/dlsag_noninteractive_refund_transactions_for/epwg0z1/
02:42:25 <jberman[m]> Note that approach would require a pretty significant change to the protocol and they also recommend hidden time-locks. So still not seeing a case for clear unlock times on-chain
02:43:45 <jberman[m]> And clarifying on how PayMo recommends a lock time lock-like feature, it recommends the use of time-lock puzzles that are solved off-chain looks like
02:48:57 <coinstudent2048[> <jberman[m]> "And clarifying on how PayMo..." <- I remembered that this is the homomorphic time-lock puzzle (HTLP). Afaik HTLP relies on RSA groups. However, I don't quite understand when I first read it if the "trusted setup" in RSA groups is "bad". I might take another look on that paper.
02:55:17 <coinstudent2048[> Also my interpretation of Paymo is that they _settled_ on the offchain timelock puzzles, _because_ Monero "doesn't have time-locks". Quote:
02:55:17 <coinstudent2048[> "One of the main challenges that we face in constructing a fully-compatible PC for
02:55:17 <coinstudent2048[> Monero is the lack of a time-lock functionality of its scripting language. To “simulate” this functionality
02:55:17 <coinstudent2048[> off-chain, our constructions will resort to the usage of time-lock puzzles (p. 6)"
02:57:35 <jberman[m]> Weren't lock times a thing when they wrote this? November 2020
02:59:07 <coinstudent2048[> jberman: I don't know. I just arrived here around April this year.
03:02:14 <jberman[m]> I assumed they meant a more expressive lock-time contract that allows you to spend before the lock expires by that like an HTLC
03:10:25 <coinstudent2048[> jberman: Yeah. I think HTLP looks something like this. Is the "monero timelock" not like this?
03:13:02 <jberman[m]> No an output gets locked and can’t be spent until the time expires
03:13:22 <jberman[m]> In Monero’s today
03:36:29 <coinstudent2048[> Oh that's different. Time-Lock Puzzle is like the classic RSA encryption, except that I give the private key, BUT the decryption computation can take an "arbitrary", but controlled, time.
03:40:47 <coinstudent2048[> Now I don't know about the Monero's timelock feature. If the discussion here is about removing it, I'm sorry I am not knowledgeable enough for that.
06:40:20 <ferretinjapan> sirs?
07:03:13 <Halver[m]> I don't know well the whole Monero algorithms (my apologies) so I have a little question :
07:03:13 <Halver[m]> Monero nodes (monerod) makes several verifications concerning the block to add to the blockchain (valid format etc), 
07:03:13 <Halver[m]> but does monerod also verify (at least basically) the quality of the decoys used in each transaction inside the block ?
07:08:22 <jberman[m]> This is the validation it does on quality of decoys: https://github.com/monero-project/monero/blob/a39b1d56c8835798e2f5e3cc43c33b5f2d8e13da/src/cryptonote_core/tx_sanity_check.cpp#L87-L99
07:12:27 <jberman[m]> It's very basic and doesn't assess whether the selection of decoys matches the expected distribution. Reasons I've seen mentioned for not doing deeper validation: (1) added complexity, (2) potential for non-uniform floating point calculation to cause a chain split, (3) edge case scenarios such as delayed tx broadcasting that would fail
07:13:17 <jberman[m]> Doing deeper validation in that area is something Rucknium and myself are giving more thought, talked about it in point 4 of this MRL post to improve decoy selection algo: https://github.com/monero-project/research-lab/issues/86
07:18:11 <Halver[m]> I see it's indeed very basic. Thanks for pointing to the piece of code.
07:22:10 <jberman[m]> np :) this is also a great vid by isthmus discussing the topic if you're interested: https://youtu.be/XIrqyxU3k5Q could be mistaken but I believe the validation was added after that research
08:22:20 <Halver[m]> For those who don't want to use youtube :
08:22:20 <Halver[m]> https://invidious-us.kavin.rocks/watch?v=XIrqyxU3k5Q
09:30:55 <moneromooo> This is not part of the consensus. You can't do meaningful statistical tests on small numbers of data points.
09:44:33 <jberman[m]> Ah true, I see, it's just on tx submission and can be bypassed
11:39:45 <atomfried[m]> in regard to the decoy selection, could the distribution to which the decoys are selected be dynamically addapt? like the probability of a decoy selected from a block n nodes before the current transaction is calculated based on the blockchain and updated every block and then for a new transaction according to this distribution the decoys are getting sampled. I dont know much about the security of this approach, but wouldnt the
11:39:45 <atomfried[m]> guarantee that the decoys are sampled perfectly?
11:39:55 <atomfried[m]> s/addapt/addapted/
11:42:57 <jberman[m]> this is an approach Rucknium is looking into, but as far as security goes, a challenge with it is that it would allow an attacker to get the decoy selection algo to mold towards selecting their own outputs in higher frequency, thereby making a flood attack easier
11:43:30 <atomfried[m]> ahh ok i see
12:13:43 <sethsimmons> <ferretinjapan> "sirs?" <- Wow, long time no see!
12:43:16 <ferretinjapan> :)
14:09:20 <Rucknium[m]> moneromooo: I used to think this too. In another channel someone brought this up again and i decided to just run a K-S test comparing a uniform selection of 11 observations against the current gamma distribution. 
14:10:28 <Rucknium[m]> Result: K-S test strongly rejects, at p-value < 0.001 . I think the reason for this is that the gamma tails are just so long and thin. A uniform selection is just too different from the long and thin tails. 
14:11:25 <Rucknium[m]> So right now with only 11 ring members, a mixin selection algorithm that is extremely out of sync with gamma (e.g. uniform) could be rejected.
14:12:08 <Rucknium[m]> And as the number of ring members rise in the future, as planned, the statistical power of the K-S test (or a similar test) would only rise.
14:12:54 <moneromooo> I assume the spurious rejects would lead to a re-roll.
14:13:27 <moneromooo> Do you have a better way ? If not, do you think those re-rolls would by themselves bias the distribution ?
14:13:53 <Rucknium[m]> Yeah, I don't see much danger in a re-roll. It can be almost instant if the check is also done at the wallet level
14:14:58 <Rucknium[m]> moneromooo: We already did that simulation with rejection at the p < 0.05 level . Result is variance, mean, and skew change by about 1 percent.
14:15:55 <moneromooo> I suppose this can be pre-corrected by biasing the distribution in the other direction anyway.
14:15:59 <Rucknium[m]> A "better way" just requires more research. Rome wasn't built in a day. New statistical techniques can be developed just like new cryptography can be developed. Or, more likely, just adopt something that already exists in the vast statistics literature.
14:16:36 <Rucknium[m]> Yeah, probably. I see these things as pretty surmountable obstacles.
14:17:44 <moneromooo> The thing tail is a good point. Though it also means the actual spend being old would bias the pick a lot.
14:18:07 <moneromooo> So you might have to bias the distribution on purpose if the real spend is old.
14:18:55 <Rucknium[m]> ...in order to properly hide the real spend. Yeah, possibly
14:19:43 <Rucknium[m]> As ring size rises, that would become less important.
14:23:05 <Halver[m]> <Rucknium[m]> "moneromooo: I used to think this..." <- "I used to think this too" ... what is this thing you think too ?
14:23:05 <Halver[m]> (... matrix muddle is sometimes hard to follow)
14:23:49 <atomfried[m]> > <@hoverhalver:monero.social> "I used to think this too" ... what is this thing you think too ?
14:23:49 <atomfried[m]> > (... matrix muddle is sometimes hard to follow)
14:23:49 <atomfried[m]> thanks for asking, i was afraid to ask hahaha
14:24:53 <moneromooo> That statistical tests on small number of data points are not very useful.
14:25:01 <Rucknium[m]> Halver:  atomfried  "You can't do meaningful statistical tests on small numbers of data points."
14:25:37 <moneromooo> (but the thin long tail is a convincing argument for why it can work in this particular case)
14:26:08 <moneromooo> (though I think it's still likely to let triangular picks pass a lot)
14:26:26 <Rucknium[m]> Or, more specifically, that the Kolmogorov-Smirnov (K-S) test would never be able to reject that an empirical distribution was substantially different from some specified theoretical distribution with just 11 observations.
14:26:58 <Halver[m]> moneromooo: Thanks. And by "small number" you mean the 11 outputs ?
14:27:11 <Rucknium[m]> The K-S test is a general, nonparametric test, and is considered to have weak statistical power. (typically, the more general a test is, the lower statistical power it has)
14:27:27 <moneromooo> Also, it would not reject static makeups (ie, all rings use the same fake outs). We've seen that happen before IIRC.
14:27:39 <moneromooo> Halver[m]: yes.
14:29:12 <moneromooo> And this matters because it's not about rejecting random things that just are unlucky, but rejecting wallets doing the wrong thing.
14:29:21 <Rucknium[m]> moneromooo:  A simple test would not. About to get into computation expense nightmare territory: One could think about checking ancestor rings for the same static makeup, and reject if it is the same static mixins.
14:30:35 <Rucknium[m]> In any case, I do agree that these are tricky things, but it is work the expense in labor and capital to investigate the possibilities.
14:34:56 <moneromooo> The thing I'm worried about it how much it'll slow down tx verification.
14:35:33 <moneromooo> I guess we'll know when it's done :)
14:35:42 <jberman[m]> I feel like this approach with working code is under-appreciated in this discussion: https://github.com/monero-project/research-lab/issues/86#issuecomment-921805298
14:36:24 <Halver[m]> <moneromooo> "And this matters because it's..." <- before rejecting (online) random unlucky patterns, 
14:36:24 <Halver[m]> I suspect that an extensive offline analysis of the blocks for say the last 6 months could give informations about what and how Monero attackers are doing.
14:36:24 <Halver[m]> Does somebody know if such an analysis has been done in 2021 ? or in previous years ?
14:37:26 <Rucknium[m]> jberman:  "People are remiss for not taking into account this code, which I just released an hour ago" 😜
14:37:49 <jberman[m]> hehe, I mean I brought up the approach in the original post too
14:38:22 <Rucknium[m]> Halver:  Yes, in the last 2 weeks there has been extensive work done. It will probably be published within the next few days and it will know everyone's socks off.
14:38:47 <Rucknium[m]> * will knock everyone socks off
14:40:09 <atomfried[m]> jokes on you, i never wear socks
14:40:53 <Rucknium[m]> The analysis is about this:
14:40:53 <Rucknium[m]> https://www.reddit.com/r/Monero/comments/pe4qto/transaction_volume_is_back_to_normal/
14:40:53 <Rucknium[m]> isthmus  has been leading the analysis, with jberman, myself, neptune, carrington, and gingeropolous helping
14:41:21 <Halver[m]> <moneromooo> "The thing I'm worried about it..." <- maybe before doing complex verification, some simple verifications would already suffice to catch some fish.
14:41:21 <Halver[m]> Also, alternatively to rejecting suspect txs, maybe there could be some alert messages published saying "hi, there is suspect txs atm" ?
14:41:21 <Halver[m]> So if there are 100 messages in a row, we could know that something is happening.
14:41:35 <Halver[m]> * doing complex statistical test verification, some
14:42:24 <Rucknium[m]> Halver:  "Something" being an attack by an adversary?
14:43:51 <Halver[m]> yes, what else ? 
14:45:31 <Rucknium[m]> I think that the work on the July-August 2021 tx volume anomaly will eventually lead into an effort to have continuous monitoring for a FloodXMR-style attack. 
14:46:04 <Rucknium[m]> Which can be done by just examining the on-chain data without any changes to Monero's code or consensus rules.
14:49:17 <Halver[m]> I was thinking exactly the same thing.
14:49:50 <Halver[m]> * same thing. Continuous monotoring.
14:50:02 <jberman[m]> also agree I think some simpler verifications would be an improvement if complex don't make the cut and/or are delayed a long time Halver 
14:51:18 <Rucknium[m]> And, further, one could imagine launching a counterattack to a FloodXMR attack. The de-anonymizing risk of FloodXMR only really exists if a single entity (who has knowledge of the specific txs that are fake volume) is causing the volume rise. If it is multiple entities, then the attack is basically defeated.
14:52:30 <Halver[m]> With a continuous monitoring we would have some knowledge about what our adversaries are doing,
14:52:30 <Halver[m]> and thus, instead of guessing if we must try to impeach this or this (unknown)  pattern, we could have a better idea about the patterns to survey.
14:52:41 <atomfried[m]> something like a call to action to the community if a FloodXMR attack is detected?
14:54:07 <Rucknium[m]> atomfried: Yeah. Or spend some of that Monero Core General Fund XMR on tx fees. I mean, for a distributed approach we could write software that could be used by individual users to mount a counterattack.
14:54:16 <Rucknium[m]> It would be so exciting!
14:54:45 <moneromooo> Paying people to spam the network is really time for people to bug out.
14:55:34 <Rucknium[m]> Yeah, but as far as I know there is no defense against FloodXMR. It seems to be an inherent vulnerability.
14:55:51 <jberman[m]> could also backfire if the attack is actually a big bang attack
14:56:18 <Rucknium[m]> And, it could be the case that by just having the counterattack plan available, it would deter an attack itself. Like nuclear mutually assured destruction.
14:58:23 <Rucknium[m]> Isn't the big bang attack somewhat mitigated by ArcticMine's work (and moneromooo  's coding work)?
14:59:37 <spackle[m]> General thought: If you want to use statistical test, I'd think you'd tie it directly into fees to punish the attacker immediately.
15:00:45 <Rucknium[m]> spackle: Wow. I love this idea. Would be complicated, though.
15:02:40 <moneromooo> I kinda thought it was neat at first, but then I thought if you can detect it, why allow it in the first place, it just gives one more degree of freedom to an attacker.
15:03:21 <moneromooo> It *might* work if you can only give non 0 or 1 probabilities that this is an outlier, with a fee slope.
15:03:46 <moneromooo> But if you do this, you'll end up with most people rerolling until they get lowest fee. And some people who won't.
15:04:11 <moneromooo> So you get anonymity puddles again, and leave the degree of freedom.
15:11:30 <gingeropolous> aw, thats sweet you consider me helping :)
15:12:26 <Halver[m]> Anyway, unless I understand wrongly, nothing can be done at the wallet level.
15:12:26 <Halver[m]> (Because, if I'm an attacker, I'll simply program my own wallet script which will let me do everything I want).
15:18:24 <spackle[m]> <moneromooo> "But if you do this, you'll end..." <- I'm assuming that we are discussing probabilities that are almost always non 0 or 1. Would it not be possible to ramp fees for everyone if a statistical test is failed? There would be no incentive for changing individual action, just a recognition that the current network activity is strange and therefore more costly to participate in.
15:19:20 <moneromooo> Do you mean ramping up consensus fees if stat test of the recent blockchain as a whole gets too much out of kilter ?
15:19:47 <moneromooo> That's interesting, and possible. Though it might open up a DoS.
15:19:55 <moneromooo> That would moot my point yes.
15:21:53 <Rucknium[m]> I will say that for the recent July-Aug tx volume anomaly, the "Flood" was extremely obvious. If that's the best they can do, there is no problem with detecting it. I do not think that's the best they can do, however.
15:25:07 <sech1> wait, it was confirmed flood attack?
15:25:13 <carrington[m]> sgp_ @sgp_:monero.social  had some spreadsheets at some point showing how the effectiveness of flooding outputs falls off a cliff as ringsizes go up. Can't find it now though
15:25:28 <selsta> sech1: it definitely didn't look like organic tx volume
15:25:43 <selsta> not sure if their goal was floodxmr or something else
15:26:04 <gingeropolous> there was a similar event in dec 2020
15:26:08 <spackle[m]> Just thinking out loud... I imagine you'd limit the potential effect of the statistical test on fees.
15:26:08 <Rucknium[m]> sech1:  Unclear if malicious or for "research purposes". isthmus  should have a nice little article posted in the next 5 days or so.
15:26:28 <gingeropolous> Rucknium[m], did the analysis compare to the dec 2020 event?
15:26:38 <sethsimmons> sech1: there is a report being prepared on it, not sure on details yet.
15:27:06 <Rucknium[m]> sech1:  We have produced overwhelming evidence that it is a single entity.
15:27:36 <Rucknium[m]> gingeropolous: No, not in this analysis.
15:27:37 <sethsimmons> Rucknium[m]: Can't wait to read it...
15:28:08 <carrington[m]> I though Dec 2020 was the naughty nodes causing issues rather than a flood attack
15:30:02 <gingeropolous> dunno that naughty nodes would cause tx spikes: https://bitinfocharts.com/comparison/monero-transactions.html#3y
15:30:43 <gingeropolous> but yeah thats a much different event than july 21
15:37:12 <sgp_[m]> <carrington[m]> "sgp_ @sgp_:monero.social  had..." <- https://onedrive.live.com/view.aspx?resid=473062B43FF0AD33!23780&ithint=file%2cxlsx&authkey=!AOpTq2h4tkFKeUU
15:38:31 <sgp_[m]> This flood attack probably is a good reason to do that hardfork quite soon
15:38:56 <gingeropolous> which hf?
15:39:00 <sgp_[m]> Get more padding with larger rings and bump the base fee
15:39:41 <carrington[m]> I'd assume that the dip in December 2020 was because many people couldn't transact on account of the FUK nodes
15:59:23 <atomfried[m]> what is the current status of BP+? could the hf include BP+ and a larger ring size?
16:28:17 <carrington[m]> <atomfried[m]> "what is the current status of BP..." <- Yes
16:29:27 <sethsimmons> That would be the plan for a HF, BP+ is ready to go AFAIK, and would offset some of the efficiency loss due to increasing ring size.
16:38:41 <gingeropolous> atomfried[m], the next dev meeting this sunday is about consensus changes for next hf
16:38:46 <gingeropolous> wait. not this sunday
16:38:52 <gingeropolous> whenever the next one is
20:32:19 <Reuben> Hey guys! Reuben from Firo here and noticed that there was some discussion on Lelantus Spark in here which I have been following on Discord but my messages weren't being piped through :( Also thanks for the shoutout sethsimmons!
20:34:50 <Reuben> I wanted to clarify some things about the relationship of Spark with Seraphis. Our Lelantus Spark construction was worked out independently without any knowledge of Seraphis/ZCT with our researcher Aram contributing the key ideas behind it. Spark was not designed as an instantiation of Seraphis which hadn't existed then (was still in an early stage and called ZCT).
20:37:35 <Reuben> In the process of making sure our Spark addresses were fine, Sarang had helpful discussions with UkoeHB in relation to payment proof construction, output construction and general feedback on addressing. This discussion benefited both Seraphis and Spark. 
20:38:50 <Inge> progress is good
20:42:48 <moneromooo> I don't think anyone accused you of anything really. Or at least I didn't see it. Maybe on reddit but that's a troll site.
20:42:54 <Reuben> As UkoeHB mentioned, rather than being a full protocol, Seraphis is a tx protocol 'abstraction' and is described in a more general sense with several ways to 'instantiate it', while Spark is a full protocol with all components worked out. Seraphis is described generally enough that Spark can probably fit into this framework but Spark was not designed as a Seraphis instantiation. 
20:42:54 <Reuben> Both constructions of course coming from similar ideas have a lot of similarities and I think it's a result of helpful discussions hence the credit to UKoeHB.
20:43:18 <moneromooo> (oh, and except geonic but that was way tinfoil)
20:43:55 <Reuben> As for the question of anonymity sets we are playing around with sets of 32k-65k and have some tricks to get batching working really efficiently so we'll wait until we have full optimized code implementation but we'll definitely be happy to collaborate on this as we believe the privacy space needs more solid privacy protocols.
20:44:58 <Reuben> thanks moneromoo
20:47:32 <Reuben> Right now we're working on diversified addressing support (sub-addresses) 
20:54:40 <geonic> yes my tinfoil was extra that day
21:08:38 <coinstudent2048[> <Reuben> "As UkoeHB mentioned, rather than..." <- This is the best description that relates between the two.
21:51:20 <Inge> Reuben: do you guys have any eyes on Halo 2 et.al.? 
22:09:47 <UkoeHB> Yes my purpose in calling Spark an instantiation of Seraphis is just so no one gets the idea the two protocols/papers are doing fundamentally different things.
22:10:27 <UkoeHB> Compared to the difference between eg cryptonote/ringct/triptych/etc
22:43:08 <UkoeHB> Also, if the papers overlap, then security proofs/models back each other up, which is why I increased the level of abstraction of Seraphis compared to early drafts. More generally, a higher level of abstraction makes it easier to update any given instantiation with new proof components, or design a new instantiation without necessarily needing to write a big paper.
22:49:01 <Rucknium[m]> UkoeHB: What does "instantiation" mean in this context? Feel free to point me to a definition online.
22:49:32 <moneromooo> I think it just means "particular case".
22:49:35 <UkoeHB> As a historical note, Aram and I, at around the same time, independently came up with the same idea for membership proofs to be purely based on commitments to zero to output content. The novel linking tag and address construction was the product of our discussion as we both tried to make the commitment-to-zero approach work (at one point I thought it was impossible to find a workable solution, but somehow we landed on 
22:49:35 <UkoeHB> the hidden timeline :p).
22:50:22 <UkoeHB> discussion along with Sarang of course ^
22:59:17 <UkoeHB> Rucknium[m]: An abstract tx protocol, in my view, lays out cryptographic structures and statements about them, and requires any instance of the protocol to prove those statements are valid with concrete proving systems. It can also describe core conventions for building transactions.
23:02:07 <UkoeHB> There is a layer of abstraction that encompasses all p2p tx protocols that use the output model. A second layer that encompasses all private tx protocols. The third layer is something like Seraphis that provides a framework for proving structures to fit inside. RingCT can be thought of as another protocol abstraction (or it could be formulated that way with some effort).
23:04:39 <UkoeHB> The fourth layer is a specification for an abstract protocol (defining proving structures and protocol rules), the fifth layer is an actual implementation, and the final layer is a specific cryptocurrency instantiation (eg blockchain) running the code of a protocol implementation.
23:04:43 <Rucknium[m]> UkoeHB: Thanks! DO you have any recommendations on an introduction to cryptography on a technical level? You can assume knowledge of multivariate calc, linear algebra, real analysis, and some topology.
23:05:55 <UkoeHB> Well there is ZtM2 lol, but it isn’t gentle.
23:06:21 <UkoeHB> I did not learn crypto formally or via a single resource.
23:06:34 <Rucknium[m]> Zero to Monero? It's on my reading list.
23:06:39 <UkoeHB> And what I just wrote, I can up with just now. :)
23:06:47 <UkoeHB> came*
23:08:17 <UkoeHB> Yes the second edition (or mechanics of mobilecoin, which is my fork of ZtM2 with various improvements to the early crypto chapters).
23:10:56 <UkoeHB> I think this resource is supposed to be good: https://crypto.stanford.edu/~dabo/cryptobook/