06:54:59 <Halver[m]> <nioc> "Monerujo is currently raising..." <- Very interesting feature imo
06:56:38 <mj-xmr[m]> <hyc> "btw, sech1, any other rpi users,..." <- I'll gladly check today. Thanks.
07:57:10 <m2049r[m]> <moneromooo> "That already exists (assuming..." <- What exactly?
08:59:56 <moneromooo> Output splitting.
09:48:03 <BigmenPixel[m]> Will this [issue](https://github.com/monero-project/monero-gui/issues/3478) not be resolved? The appstream file [already exists](https://github.com/flathub/org.getmonero.Monero/blob/master/org.getmonero.Monero.metainfo.xml).
14:55:17 <helloimpha[m]> hola
14:55:41 <helloimpha[m]> is there anyoone here who understand the zero knowledge cryptography that monero uses? someone who is intimately familiar with the code with concrete understanding, not just superficial high level understanding
14:56:50 <fluffypony> there are a number of people here who have written that code, so yes
14:57:18 <fluffypony> and there's #monero-research-lab if you're talking more about the theory than the code
14:57:28 <helloimpha[m]> ok so i have one simple question
14:57:29 <helloimpha[m]> btw, glad to see you're free online
14:57:59 <helloimpha[m]> well this is not theoretical
14:58:13 <helloimpha[m]> well part of the explaination is, but the question itself is about real world implications of design
14:58:19 <helloimpha[m]> so here is how i'll phrase it
14:59:23 <helloimpha[m]> suppose i am the greatest mathematician since antiquity and i could break discrete log based algorithms, RSA based algorithms, even lattice based algorithms, and i could also find collisions to SHA256 and any other one way algorithm that exists
14:59:48 <helloimpha[m]> would this affect the anonymity of past transactions? i don't care if it affects the integrity of the system
15:00:01 <helloimpha[m]> basically is this information theoretically secure anonymity or does it hinge on the cryptography
15:00:27 <helloimpha[m]> ?
15:01:29 <helloimpha[m]> as an example to this point: even if i can find collisions to SHA256, there is no way i could ever hope to find a particular collision (there are 2^128 different inputs for every output). hence, the anonymity factor of SHA256 remains secure, even if the integrity is not
15:03:01 <helloimpha[m]> by integrity, i mean the assumptions regarding security are broken
15:03:57 <helloimpha[m]> another way to think of it: does monero offer long term privacy or conditional privacy (depedent on cryptography)?
15:04:29 <helloimpha[m]> i think ZCash for example (hope I'm not recalling this incorrectly, because I'm not personally familiar with their code) offers long-term privacy. even if cryptography is broken, anonymity remains secure. it's just that the integrity of the system is broken
15:05:21 <fluffypony> I think if DL is broken then the world basically collapses
15:05:43 <helloimpha[m]> even the anonymity?
15:05:57 <helloimpha[m]> i get that monero becomes worthless, but does the privacy go away too?
15:06:01 <helloimpha[m]> will everyone be revealed?
15:07:11 <moneromooo> At least *some* of the possible breaks will break past privacy. Folk in #monero-research-lab will know more.
15:07:36 <helloimpha[m]> damn
15:07:40 <helloimpha[m]> not what i wanted to hear
15:08:19 <helloimpha[m]> it's possible to design so that past privacy is preserved, really important. 
15:08:35 <moneromooo> Well, some layers of privacy. Not sure which of ring sigs and/or one time addresses. Maybe each break only breaks one of them...
15:08:42 <helloimpha[m]> i don't want to see a situation where everyone who used monero gets screwed later
15:09:07 <moneromooo> I think isthmus has been looking at that before (in the context of QC).
15:09:08 <helloimpha[m]> it turns monero into a weapon basically
15:11:26 <coinstudent2048[> Hmm... how does ZCash offer long-term privacy? Assuming they'll deploy a variant of Halo, I think Halo/Halo 2 will get screwed also in that scenario.
15:11:31 <fluffypony> helloimpha[m]: you have to assume that ANY cryptography will be broken later, including ZCash
15:11:46 <fluffypony> it's the reason that certain TLAs are snorting up web traffic
15:11:57 <ComplyLast> <helloimpha[m]> i don't want to see a situation where everyone who used monero gets screwed later
15:12:03 <fluffypony> they can't break TLS right now, but they will later on
15:12:11 <ComplyLast> this will happen, same with Zcash, it's a matter of time.
15:12:38 <moneromooo> It's also why I constantly send out encrypted goatse pictures.
15:13:09 <ComplyLast> there's a cute american entity that's storing all the information they can't decrypt until there is a scientific breakthrough
15:13:28 <ComplyLast> Blockchains given their very nature make that job easier, if the breakthrough is achieved
15:15:06 <helloimpha[m]> i'm going to give you an example i'm familiar with and not talk about ZCash since i am not personally familiar with their code. some crypto systems that use ZKP do not "encrypt" any sensitive information into the proofs which are published in the open. so no "encrypted" data is ever put out there (which can be decrypted later, if crypto is broken). if you were to make a transaction with this type of system, and later all the crypto
15:15:06 <helloimpha[m]> is broken, no one can retroactively go back and decrypt anything of any value
15:15:29 <helloimpha[m]> other systems encrypt data. these ones have ciphertexts that can be opened later, after the transaction has been made
15:16:11 <fluffypony> right, so consider hashed passwords
15:16:18 <fluffypony> they're not plaintext that is encrypted, they're a one-way hash
15:16:30 <fluffypony> but nowadays we have rainbow tables and all sorts to attack leaked password hashes
15:17:01 <fluffypony> and in some future there will be a quantum computer or some other improvement that will allow for those hashes to be attacked orders of magnitude faster than now
15:17:33 <helloimpha[m]> so just to be clear on definitions
15:18:00 <fluffypony> Monero's strong privacy may not be "reversable" in some obvious way, and there are specific design choices that prevent that (eg. Pedersen commitments are computationally hiding, but perfectly binding), but there is no such thing as a perfect system
15:18:01 <helloimpha[m]> when we say one-way hash function, what we're implying is that there are many more inputs than there are outputs. IOW, there are a huge number of possible ways to achieve a particular image.
15:18:04 <fluffypony> information wants to be free.
15:19:13 <helloimpha[m]> therefore if you were to hash psuedo random data, even if the cryptography of the one-way function is broken later, there is no way someone is going to find the exact pre-image you made. they can produce the same image, but the way they produce that image will be with a different pre-image because the space of pre-images is so much greater than the space of images and it's too much to iterate through
15:19:31 <helloimpha[m]> that is a secure design for privacy. it means someone can't figure out what your password was (assuming it's sufficiently random) just by breaking the hash
15:19:41 <helloimpha[m]> they can only re-produce the hash, they can't figure out your exact password
15:19:49 <helloimpha[m]> that is secure if monero is based only on systems like that
15:19:59 <fluffypony> right, but even in that event you still have a limited data set - most passwords are <50 characters so you can disregard hash matches for larger data
15:20:14 <fluffypony> and you are likely to find only a single match in the <50 chars space
15:20:31 <helloimpha[m]> still 64^50 is a big number
15:20:33 <helloimpha[m]> so you'd have to itereate all of those
15:20:40 <helloimpha[m]> and even then how do you tell which one is the real one?
15:20:43 <helloimpha[m]> many will produce the same hash
15:21:08 <fluffypony> I don't think "many" will, not for a 256-bit hash
15:21:31 <fluffypony> and with something like passwords it doesn't matter
15:21:38 <fluffypony> you can login with the wrong password as long as it produces the right hash
15:21:59 <fluffypony> the point being: there are entire classes of attack that we can't imagine today
15:22:15 <fluffypony> so you can't prevent an attack that you can't even fathom
15:22:42 <fluffypony> Monero provides strong privacy today, using more than just a single tool (ring signatures + confidential transactions + dual-key stealth addresses)
15:22:53 <fluffypony> one or more of those tools may be broken tomorrow
15:22:57 <fluffypony> there is no way to know
15:23:18 <fluffypony> so you need to combine using a tool like Monero with good opsec, if maximal privacy is your aim
15:23:22 <helloimpha[m]> what i want to be sure of is.... suppose i send a transaction with monero and it's mixed with 1000 other addresses (not even sure exactly how you guys do this, merkle tree or something). if the crypto is broken later, i am sure that this will no longer work correctly. however, will it be possible to discover where my past transactions went?
15:24:13 <helloimpha[m]> and about SHA256 (if thats' what you're talking about). There are 2^128 possible inputs (really more, if you account for the merkle damgard construction they use internally) that produce each possible output
15:24:40 <isthmus> The ONLY way we can make public digital ledgers private is through cryptography. If the premise is “suppose I can crack all crypto” then no public ledger will offer protection
15:25:16 <isthmus> Not to be too reductionist, but that’s what it boils down to
15:25:17 <helloimpha[m]> so if you want to know someone's password, given only sha256, you need to iterate all possible inputs... with merkle damgard that's infinite
15:25:33 <isthmus> That’s not breaking crypto though
15:25:40 <isthmus> It’s designed that you would have to iterate
15:25:49 <helloimpha[m]> assuming the block size is restricted to the standard 512 bits, it's 2^128 possible 
15:25:56 <helloimpha[m]> that's not true
15:26:04 <helloimpha[m]> but privacy more important than the integrity of the system
15:26:10 <helloimpha[m]> doesn't matter so much if people lose money
15:26:10 <isthmus> If you have to resort to brute force then the crypto is working properly, no?
15:26:17 <helloimpha[m]> matters a lot if they can be persecuted later after the fact
15:26:37 <helloimpha[m]> if you can find two inputs that produce the same SHA256 hash, you have broken SHA256
15:26:46 <helloimpha[m]> i don't mean brute force
15:27:01 <helloimpha[m]> brute force would require 2^128 guesses to find a single collision. then you'd have to do that another 2^128 times
15:27:09 <helloimpha[m]> you're talking 2^256 iterations
15:27:21 <helloimpha[m]> if you break sha256, you can rapidly find a collision
15:27:27 <helloimpha[m]> but you can't find a particular collision
15:27:29 <helloimpha[m]> make sense?
15:29:06 <isthmus> Yeah but now we’re selectively defining the adversary’s capabilities with respect to preimage attack vs collision attack etc
15:29:47 <isthmus> Anyways TLDR if privacy crypto is broken then privacy is broken. Hard rule for all public ledgers
15:29:48 <helloimpha[m]> 100% chance DL will be broken
15:29:56 <helloimpha[m]> so these nuances matter a lot
15:30:55 <isthmus> I have to bounce to a meeting but you might enjoy this doc which has a lot of “what if X mechanism was broken” hypothetical analyses
15:30:58 <isthmus> https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/technical_note.pdf
15:33:20 <Rucknium[m]> helloimpha[m]: Why do you think this?
15:38:21 <helloimpha[m]> it's a really strong assumption. there is absolutely no proof it is secure (like all other assumptions), but we do know that quantum computers can break it (this is unlikely other assumptions). so either we get QC's and it's broken or we don't and it's likely broken.
15:38:41 <helloimpha[m]> that's as much as i can say on it
15:39:17 <helloimpha[m]> QC's can't even break small instances of NP-complete problems
15:39:21 <helloimpha[m]> but have no trouble with DL
15:39:32 <helloimpha[m]> gives you a sense of where it stands in the assumption hierarchy 
15:40:18 <hyc> it will take at least a decade for QCs of significant size to be built
15:40:20 <helloimpha[m]> from a mathematical perspective, it's  insane to think it's secure
15:40:36 <hyc> lol
15:40:51 <hyc> there's a good joke about a mathematician and an engineer...
15:41:11 <helloimpha[m]> yeah?
15:41:24 <hyc> they're presented with a challenge: they enter one end of a long hallway, there is a $1M prize at the other end of the hallway
15:41:49 <hyc> the rule is tevery time they take a step, their next step can only be half as long as the previous
15:42:18 <hyc> the mathematician looks at the hallway, and walks away, because he knows that at the limit, he will never reach the end
15:42:53 <hyc> the engineer walks down the hall and takes the prize. because he knows that theoretically it would take infinite steps, but for all practical purposes he can just get there.
15:43:46 <helloimpha[m]> haha
15:44:42 <hyc> s/just get there/get close enough/
15:47:20 <helloimpha[m]> well hey guys. thanks for trying to answer my question. i'm really impressed with the work monero is doing for privacy (which is essential for freedom). i really hope past transactions are secure long term, and if not, my advise is to work on fixing it asap
15:48:20 <hyc> cryptographic strength is a constantly moving target. it can't be "fixed".
15:49:07 <hyc> 20 years ago it was impossible to brute-force DES, now it's easy.
15:49:18 <hyc> the same dynamic will always exist.
16:03:10 <helloimpha[m]> i'm back
16:03:22 <helloimpha[m]> i just skimmed this paper: https://github.com/insight-decentralized-consensus-lab/post-quantum-monero/blob/master/writeups/technical_note.pdf
16:03:23 <helloimpha[m]> the one isthmus sent
16:03:23 <helloimpha[m]> Section 3.2 Violated Signer Ambiguity from On-Chain
16:03:39 <helloimpha[m]> From what I can infer from this section, monero is NOT long term privacy secure
16:04:03 <helloimpha[m]> My advise is to make this the top priority to fix
16:04:36 <helloimpha[m]> It seems to suggest if DL is broken, then monero becomes retroactively publicly traceable like Bitcoin transactions
16:05:52 <helloimpha[m]> This also means monero is weaponizable. If gov't can break DL, monero would be ideal choice to spy on people in secret
16:06:07 <UkoeHB> There are no priorities... people work on what they feel like. Are you volunteering to study this issue?
16:06:46 <hyc> if DL is broken, TLS is broken and pretty much everything else in crypto space
16:07:13 <moneromooo> I suggest you refrain from bullshit if you want to have a conversation here. Keep to tech. Weapon stuff will get you in ignore lists.
16:07:15 <kor678[m]> Hello everybody. Guys, why do you think that everyone except Monero will develop, their algorithms and encryption methods are also evolving
16:07:18 <helloimpha[m]> I already know solution. I am just warning you guys that huge number of your users may be subjected to retroactive persecution if this is not addressed. That will be huge disservice to your users, could result in lots of freedoms and lives lost
16:07:50 <hyc> you already know a solution? do tell ...
16:07:59 <helloimpha[m]> is it not true?
16:08:09 <helloimpha[m]> i'm stating facts, based on the research paper discoveries
16:09:37 <helloimpha[m]> use cryptography that does not make it possible to retroactively reveal information about transactions.
16:09:47 <fluffypony> there's no such thing
16:09:58 <helloimpha[m]> my advice also is to stop using DL but that's less important than privacy
16:10:11 <helloimpha[m]> no such thing?
16:10:20 <helloimpha[m]> yes there is
16:10:22 <fluffypony> "use cryptography that does not make it possible to retroactively reveal information about transactions." <- it doesn't exist
16:10:29 <helloimpha[m]> tell you what
16:10:30 <hyc> lol
16:10:48 <fluffypony> all that exists is a panacea that something is secure and safe, but merely we just haven't figured out a meaningful attack
16:10:48 <helloimpha[m]> yes it does
16:11:16 <helloimpha[m]> no
16:11:27 <helloimpha[m]> zero knowledge proofs use information theoretically secure math
16:11:35 <helloimpha[m]> for example
16:11:44 <helloimpha[m]> Stern's protocol
16:11:57 <UkoeHB> Can you write a paper on how to do this?
16:12:04 <helloimpha[m]> is secure with the only assumption being the commitment scheme used (which as I explained earlier is one-way, so this is OK to use, because there is no way to iterate all the possible inputs or distinguish which input was real)
16:12:11 <hyc> what's the size of a typical proof in your example systems
16:12:13 <helloimpha[m]> the rest of it is rock solid math, no assumption
16:12:52 <hyc> what's the computation time required to construct it
16:13:16 <helloimpha[m]> proof size depends on implementation, but very large would be what i'm familiar with.
16:13:25 <helloimpha[m]> however
16:13:43 <helloimpha[m]> i think zcash managed to achieve this same effect using different techniques. you can inquire with their team to find out. i would advise that.
16:13:52 <helloimpha[m]> but privacy too important
16:14:00 <hyc> once again, difference between theory and practice
16:14:13 <fluffypony> if you think ZCash is unbreakable then use ZCash and don't bother with Monero, problem solved
16:14:16 <helloimpha[m]> this is about people's lives
16:14:17 <helloimpha[m]> more important that it's private than fast
16:14:27 <fluffypony> otherwise it's really hard to read this as anything other than concern-trolling
16:14:47 <helloimpha[m]> i don't think zcash is great solution, but it's safer for privacy if they solved that problem
16:15:03 <hyc> go ahead and talk to them and find out then. educate yourself.
16:16:04 <hyc> theoretically perfect solutions that are impractical to implement and use are pointless.
16:16:26 <helloimpha[m]> not at all true
16:16:39 <hyc> go and educate yourself...
16:17:11 <hyc> just like the initial zcash protocol, that required 4+GB RAM and minutes to construct a proof - nobody can use that
16:17:37 <hyc> well, maybe you can use that if you're routinely working with a supercomputer, etc.
16:17:51 <hyc> but for average consumers, not happening.
16:18:50 <hyc> an impractical solution like that is worthless.
16:19:05 <helloimpha[m]> i'm all for speed. that's great. i'm just saying your website says "untraceable". and i came in here without any assumptions about that. i thought you achieved the same thing in terms of long term security (in which case, i think "untraceable" is perfectly valid description).
16:19:18 <helloimpha[m]> people use moner for privacy
16:19:34 <helloimpha[m]> not just speed
16:19:39 <fluffypony> one additional point before I check out of this convo: you're right that people's lives hang in the balance with privacy-enhancing systems, which is why we have to balance providing strong privacy with providing strong soundness around the economic system AND making it easy for people to use on low-power devices. There is NO value in building a theoretically perfect system where there is massive risk that everyone's life savings could be
16:19:39 <fluffypony>  worthless tomorrow, and where it's infeasible to use on 99% of devices.
16:19:41 <helloimpha[m]> people should know this
16:20:37 <helloimpha[m]> i think you guys should at least point this out on your website. if DL is broken, research suggests the privacy will be retroactively lost.
16:20:47 <helloimpha[m]> this way people can at least mix the coins traditionally and take additional steps before using
16:21:01 <hyc> nonsense. traditional mixing is BS.
16:21:22 <hyc> time to put this guy on /ignore\
16:25:48 <helloimpha[m]> it's not good, but if your entire transaction history is revealed later and you did no mixing, that's even worse. that's my point
16:25:56 <helloimpha[m]> i'm not being hostile with anyone here
17:18:03 <selsta> .merge+ 7972 7989 7975
17:18:03 <xmr-pr> Added
17:30:23 <mj-xmr[m]> hyc: All green on RPi4, Re: #8001
17:30:34 <selsta> good then we can include that in the release too
17:31:55 <mj-xmr[m]> Then let me run all the other tests as well.
17:32:05 <mj-xmr[m]> I think it will finish tomorrow morning.
17:34:00 <UkoeHB> moneromooo: are you planning to review #7877 (multisig pr)?
17:35:07 <moneromooo> No. I could look at the code itself but I could not review the crypto, which is where I expect any issues to be. Besides, I went to see a couple days ago and got scared off by the size...
17:35:41 <moneromooo> If think you a code-not-crypto review is still useful, I can do it though.
17:35:52 <selsta> is it better to merge BP+ first or the fee changes?
17:36:01 <selsta> BP+ is older
17:36:21 <moneromooo> BP+, since I'll remember fee changes better.
17:36:30 <moneromooo> (for conflict resolution)
17:36:33 <selsta> ok
17:42:38 <selsta> moneromooo: BP+ fails to compile with clang currently: https://github.com/monero-project/monero/pull/7170#issuecomment-940224775
17:43:34 <UkoeHB> Maybe if you could skim it for any stand-out issues, that could be useful.
17:43:44 <UkoeHB> At the very least, the tests all work lol.
17:44:19 <moneromooo> OK, I will. Just as long as everyone knows I can't find crypto bugs :)
17:45:16 <UkoeHB> Thanks :)
17:45:38 <UkoeHB> Anyone know if stoffu is around/available to review the PR? He reviewed the initial multisig PR.
17:46:32 <UkoeHB> Also, moneromooo, where did you get the original implementation from, if it wasn't from scratch?
17:47:22 <moneromooo> luigi1111.
17:52:57 <luigi1112> .merges
17:52:57 -xmr-pr- 7793 7873 7874 7912 7954 7958 7959 7960 7972 7975 7976 7978 7989
17:56:00 <moneromooo> selsta: should be fixed now
17:58:20 <selsta> moneromooo: did you see https://github.com/monero-project/monero/pull/7170#issuecomment-940225290 too?
17:58:28 <selsta> I think a function call has to be updated or so, did not look in detail
18:01:58 <moneromooo> I had not.
18:02:23 <moneromooo> Ah, it's the silly gui wallet layer again...
18:03:02 <moneromooo> Gimme like an hour
18:04:02 <selsta> moneromooo: you can use the `wallet_api` target to compile it
18:06:36 <midnightmage[m]> Hey Jberman I’m going to take a look at the rw blockchain lock, who should I contact regarding library choices going forward? Thanks
18:07:15 * mj-xmr[m] watches the evil he's made, by peeking at the often cache reuses in the GH Action list.
18:42:02 <moneromooo> selsta: done
18:42:49 <selsta> ty
18:45:21 <UkoeHB> luigi1112: can you review the multisig PR?
18:49:46 <hyc> mj-xmr[m], selsta ok I'll PR against release branch as well
18:52:55 <hyc> #8005
19:15:44 <luigi1111> UkoeHB: I'm not sure. stoffu would be better if we can locate and kidnap him 
20:17:01 <jberman[m]> midnightmage: I think general questions like that are good to ask in here. I believe this is a good starting point for that task (see how `m_blockchain_lock` is used elsewhere): https://github.com/monero-project/monero/blob/c458d5fe401f460c5eed2146f74d77e1f840a19c/src/cryptonote_core/blockchain.h#L1109
20:18:46 <jberman[m]> Also note there's an existing rw lock class and related functions that matches `epee::critical_section` here: https://github.com/monero-project/monero/blob/c458d5fe401f460c5eed2146f74d77e1f840a19c/contrib/epee/include/winobj.h#L95-L128
20:24:48 <selsta> there also was this PR: https://github.com/monero-project/monero/pull/6401
21:07:10 <midnightmage[m]> Ok cool, thanks guys, I’ll DM you tomorrow as it’s late here now and got to work in the morning.