00:19:25 <ofrnxmr[m]1> <ooo123ooo1234567> "checkpoint is a compromise..." <- This
01:25:08 <ooo123ooo1234567> https://github.com/openssl/openssl/issues/18659, "I don't think operations after the cleanup are intended to continue working." indeed, why not to just stop using openssl and switch to something else
01:27:36 <ooo123ooo1234567> too simple reproduction - don't call it in that order / certainly not our fault, too complex reproduction - it must be problem in pthread / boost / monero; facepalm
01:34:24 <ooo123ooo1234567> it must crash with two duplicate OPENSSL_cleanup calls to
01:34:26 <ooo123ooo1234567> selsta, can you test ?
01:35:38 <ooo123ooo1234567> s/OPENSSL_cleanup/OPENSSL\_cleanup/, s/to/too/
01:35:59 <selsta> yes
01:37:23 <ooo123ooo1234567> `Reviewed-by: Paul Dale <pauli⊙oo>` hmm, they are supposed to know their code better than others
01:38:25 <kayabanerve[m]> <jeffro256[m]> "Can you expand on what the..." <- > is the sorted set of unique factors present in each input. For miner transactions, this would be the height, in its VarInt encoding. For non-miner transactions, this would be their key images.
01:38:37 <selsta> it does not crash with just OPENSSL_cleanup twice
01:38:47 <selsta> and init first
02:13:02 <ooo123ooo1234567> can you run once again with gdb and print stack trace ?
02:13:35 <ooo123ooo1234567> nvm, not needed
02:30:52 <gingeropolous> selsta, got a stall on your branch that im usin
02:31:38 <ooo123ooo1234567> <selsta> "it does not crash with just..." <- https://github.com/openssl/openssl/blob/openssl-3.0/crypto/init.c#L360, in theory, it should crash with concurrent execution of OPENSSL_cleanup due to usage of `static int stopped = 0`
02:32:58 <selsta> gingeropolous: is it still open?
02:33:07 <gingeropolous> yeah i just got a thread apply all logfile dump
02:33:16 <gingeropolous> tryin to think where to... ah yeah the termbin thing there we go
02:35:09 <gingeropolous> selsta, https://termbin.com/g2b8 ... lemme know what else might be good. ima dig through the actual log see if anything
02:40:52 <selsta> ooo123ooo1234567: does ^ seem related to your connection / p2p patch?
02:41:12 <gingeropolous> nothing interesting in logs
02:41:40 <gingeropolous> can i restart the daemon? or is there any thread diving needed
02:41:46 <gingeropolous> or whatever its called
02:41:53 <gingeropolous> thread pulling
02:42:38 <ooo123ooo1234567> not so fast
02:43:28 <gingeropolous> but im missin all those sweet blocks
02:45:44 <ooo123ooo1234567> is it debug or release build ?
02:46:05 <gingeropolous> oh prolly release
02:46:22 <gingeropolous> yeah, release. 
02:47:05 <ooo123ooo1234567> press continue for few seconds, then interrupt it and paste another stack trace
02:47:23 <ooo123ooo1234567> it's interesting whether it's completely stuck in all threads or not
02:47:42 <gingeropolous> well, the current state is that the daemon is no longer spitting out any logs
02:47:52 <gingeropolous> and I can't get a response from the status command
02:48:01 <selsta> you have to enter: continue
02:48:11 <selsta> then wait a couple seconds
02:48:13 <selsta> ctrl+c
02:48:24 <selsta> and then again thread apply all bt
02:48:41 <selsta> doesn't matter if it appears stuck or not
02:50:53 <ooo123ooo1234567> looks like a deadlock within logger
02:51:07 <gingeropolous> https://termbin.com/dh2q
02:51:15 <gingeropolous> that includes the first dump as well
02:51:26 <selsta> gingeropolous: which log level are you running these days?
02:51:52 <gingeropolous> the monerod.conf says its log level 1
02:52:51 <gingeropolous> its me, u know, it could be something stupid like file descriptors or whatever
02:53:15 <gingeropolous> though i thought i already tweaked this box and ive got that mdbstat running every 2 mins
02:54:43 <ooo123ooo1234567> wait, don't just drop that gdb session so early
02:55:22 <gingeropolous> yeah ima fire up a second node. i'll keep this dead one up
02:58:35 <ooo123ooo1234567> the same stack trace, so completely stuck
03:18:26 <gingeropolous> so....
03:19:08 <ooo123ooo1234567> I'm reading code and that stack trace currently, searching for an explanation
03:19:22 <gingeropolous> roight roight roight
03:57:23 <gingeropolous> sonofabitch. my new node got stuck on Height: 2653718
03:58:06 <ooo123ooo1234567> the same way ?
03:59:22 <gingeropolous> naw, it thought it was syncd. rpc responded
04:00:02 <ooo123ooo1234567> false negative ?
04:03:42 <gingeropolous> dunno what u mean. i tried copying over the data.mdb to the new node, that could be mucking it up. dunno what the head of the chain looked like. can't get blockchain import to pop blocks
04:04:14 <gingeropolous> oh there it goes
04:05:31 <gingeropolous> also on the new node im just running master, not selsta's branch
04:07:03 <ooo123ooo1234567> if master will stuck too then it's unrelated to patches on top of it
04:11:12 <selsta> gingeropolous: did it deadlock, or was it just on the wrong height for a bit? and does it work now?
04:12:49 <gingeropolous> just wrong height. its working now.
04:16:43 <ooo123ooo1234567> <selsta> "ooo123ooo1234567: does ^ seem..." <- indeed, obvious relation: deadlock -> deadlock with pthread mutex -> connection / p2p patch
04:16:54 <ooo123ooo1234567> s/deadlock/some/, s/with//
04:17:29 <ooo123ooo1234567>  * indeed, according to the following deduction chain: deadlock -> some pthread mutex -> connection / p2p patch
04:35:20 <ooo123ooo1234567> gingeropolous: did you run this branch https://github.com/selsta/monero/blob/master-beta without any modifications ?
04:37:50 <gingeropolous> ooo123ooo1234567, correct
04:37:55 <selsta> when did you compile?
04:40:15 <gingeropolous> looks like i made the selsta_monero folder on may 11
04:40:31 <gingeropolous> yeah, bin was made then as well
04:48:17 <gingeropolous> on the new box im getting 30+ connections from single IPs
04:56:50 <ooo123ooo1234567> what would be the next action if this problem is reproducible with maste rtoo ?
04:56:53 <ooo123ooo1234567> s/maste/master/, s/rtoo/too/
04:59:09 <gingeropolous> i gotta sleep. the dead one is still in gdb. the new one is being stupid 
05:02:08 <ooo123ooo1234567> who will fix broken code ?
05:04:18 <gingeropolous> i dunno. i just break stuff
05:05:05 <ooo123ooo1234567> list of recently broken things ? 1. deadlock in monerod, 2. ... ?
05:14:29 <ooo123ooo1234567> https://github.com/openssl/openssl/issues/18659, "I don't think operations after the cleanup are intended to continue working." it's interesting whether it's a form of laziness or intentional dodging of problems in openssl
05:17:37 <ooo123ooo1234567> their review process is an example when even labels / github bots / dedicated maintainer / etc together can't help
05:22:56 <ooo123ooo1234567> <selsta> "when did you compile?" <- it doesn't matter
06:39:13 <ooo123ooo1234567> <gingeropolous> "can i restart the daemon? or..." <- as you wish
06:41:14 <ooo123ooo1234567> <selsta> "ooo123ooo1234567: does ^ seem..." <- it's reproducible without patches on top of master
06:52:59 <spirobel[m]> why do we sometimes supply an additional public_spend_key to check_tx_proof? https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11817
07:05:27 <spirobel[m]> I also saw that the proof is different for subaddresses and the legacy standard addresses: https://github.com/monero-project/monero/pull/2487 but that is unrelated, correct?
07:06:40 <moneromooo> Outputs to subadresses are made with those keys, rather than the "main" tx key.
07:07:03 <moneromooo> Or rather, with the corresponding secret key.
07:10:05 <spirobel[m]> okay why do we need the public spend key in addition to the public view key to verify the proof? why sometimes the public view key is sufficient and the public spend key is not needed? ```       crypto::check_tx_proof(prefix_hash, address.m_view_public_key, tx_pub_key, address.m_spend_public_key, shared_secret[0], sig[0], version) :
07:10:05 <spirobel[m]>       crypto::check_tx_proof(prefix_hash, address.m_view_public_key, tx_pub_key, boost::none, shared_secret[0], sig[0], version); ```
07:10:20 <spirobel[m]> https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11817
07:18:45 <spirobel[m]> what I also dont understand: what is this: get_additional_tx_pub_keys_from_extra function? https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11790  does it mean somtimes public keys (what is meant by public keys in this context?) are being put in tx_extra? I assume this is some kind of legacy thing, true?
07:30:11 <moneromooo> They are always in extra.
07:31:28 <moneromooo> Public keys are sometimes known as R in shorthand. At least prior to subaddresses, not sure if the convention changed for those.
07:35:08 <spirobel[m]> moneromooo: how do they relate to public view keys and public spend keys and stealth addresses?
07:40:08 <moneromooo> Zero to monero should have that.
07:50:56 <spirobel[m]> <moneromooo> "Zero to monero should have that." <- I read chapter 8.1.3 ... it does not say anything about view and spend keys ... Is there another chapter that I could take a look at?
07:56:30 <ooo123ooo1234567> can you read C++ ?
08:02:31 <ooo123ooo1234567> https://github.com/openssl/openssl/issues/17995#issuecomment-1125862196, "the bottom line is that the cleanup flow is broken in OpenSSL 3.0. This would impact multiple users. Shouldn’t there be an urgency to fix this issue ?" hahahahaha
08:03:46 <ooo123ooo1234567> https://github.com/openssl/openssl/pull/18024#issuecomment-1106034011, "This issue is critical for our release. can you please help to provide an update?" it looks like they don't know how implement cleanup of resources properly
09:36:16 <wernervasquez[m]> spirobel: tx_pub_keys are the shared secret for that tx. 
09:40:07 <moneromooo> Technically aren't since they're public.
09:40:22 <moneromooo> They're used to derive the shared secret though.
09:52:38 <spirobel[m]> <wernervasquez[m]> "spirobel: tx_pub_keys are the..." <- are shared secrets and encrypted payment_ids the same?
10:17:33 <kayabanerve[m]> spirobel: Not at all.
10:42:02 <wernervasquez[m]> moneromooo: Yes. I misspoke. The tx pub keys are used to derive the shared secret. 
10:43:40 <wernervasquez[m]> spirobel: see https://cryptobook.nakov.com/asymmetric-key-ciphers/ecdh-key-exchange for a textbook example of what a shared secret is 
10:47:48 <wernervasquez[m]> With regards to a monero transaction, "Alice" would be the person recieving funds and her pubkey is the xmr address and her private key is tge private key for her xmr address. "Bob" is the sender and his pubkey is the tx pubkey and his private key (should be) randomly generated for that transaction.
10:48:29 <wernervasquez[m]> That is a sliiiiight simplification since xmr has both view keys and spenk keys and subaddresses, but that is the gist of it
11:09:48 <spirobel[m]> are payment_ids verified when doing check_tx_proof on a transaction that was sent to an integrated address?
11:11:24 <spirobel[m]> <wernervasquez[m]> "With regards to a monero..." <- so tx_public keys are the public part of the TX_KEY that we use to generate the proof for the transaction? but what are additional public_keys? the name sounds like they are something extraordinary ... does every transaction have those?
11:19:51 <wernervasquez[m]> spirobel: I believe that is from page 40 of ZTM2. With subaddresses, the tx pubkey is specific to the reciever instead of being able to be reused across all recievers in the tx
11:21:19 <wernervasquez[m]> So, the "additional" pubkeys are just to support subaddresses since they each need their own pubkey (rK instead of rG in ZTM2)....
11:22:02 <spirobel[m]> wernervasquez[m]: in case the transaction has multiple destination addresses?
11:23:16 <wernervasquez[m]> As far as I understand. But please dont take this as gospel and please double check this. I do not have the focus right now to be thorough.
11:23:54 <spirobel[m]> wernervasquez[m]: so that is why we need the public spend key to check a transaction that was made to a subaddress, correct? that was the question i started out with ... why do we need the public spend key to prove these kind of transactions where the destination is a subaddress, but in the case of a legacy standard address it is unneeded? 
11:25:55 <spirobel[m]> so transactions with a legacy standard address as the destination are non uniform from transactions made to subaddresses? or are these differences only visible to sender and receiver? 
11:26:33 <wernervasquez[m]> I apologize that I do not
11:26:52 <wernervasquez[m]> Have time to answer this now. 
11:28:05 <wernervasquez[m]> However, I will leave on this note. For both standard and subaddresses, in order to recognize an output as yours, you need the public spend key.
11:28:29 <wernervasquez[m]> See page 38 and page 40. Step 3 on both pages
11:29:02 <spirobel[m]> thanks! I appreciate it! 🙂👍️
12:13:24 <UkoeHB> spirobel[m]: page 40 footnote 16
12:40:00 <spirobel[m]> <UkoeHB> "spirobel: page 40 footnote 16" <- okay I have to dig into this further, but just judging from this footnote, transactions to subaddresses seem to be non uniform with transactions to the legacy standard addresses. Maybe we should address this problem by changing the wallet UX: no primary addresses should be displayed anymore, only subadddresses. this way we could increase transaction uniformity and decrease confusion. 
12:49:10 <spirobel[m]> another question is this: How do I verify that a transaction was made with a certain payment_id without the receiver view_key, just from the tx_proof? First of all: is the assumption correct, that check_tx_proof does not already make sure the payment_id  is right if we feed it an integrated address? 
12:55:23 <moneromooo> If you did not keep the payment id when you sent the tx, you cannot re-derive it from the tx. Only the recipient can.
12:57:35 <spirobel[m]> but if I have the payment_id, can I recreate the encrypted_payment_id and compare the outputs? is https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/device/device_default.cpp#L352 deterministic ?
13:00:23 <moneromooo> It appears to be deterministic at first glance.
13:00:47 <UkoeHB> spirobel[m]: it should be possible by adapting the InProof or OutProof
13:19:06 <spirobel[m]> okay so it seems i really need to understand this code in detail. When I have a normal transaction with just one subaddress as the destination address, is it enought to call get_tx_pub_key_from_extra or will there be additional keys and I need to call get_additional_tx_pub_keys_from_extra?
13:31:41 <stretch1> does lmdb include a pid or finger print?
13:32:00 <stretch1> s/pid/identifier/
13:34:01 <UkoeHB> spirobel[m]: why not always call both? then you don't have to worry about the different scenarios
13:48:42 <moneromooo> stretch1: rephrase
13:49:08 <moneromooo> If you mean "does the blockchain db used in monero have a unique string that identifies it from all other monero blockchain dbs", then no.
13:49:46 <moneromooo> However, its internal structure might be unique, ie the exact set of ops that were done on it might have left free pages in a particular order.
13:50:30 <moneromooo> Free pages might or might not be cleared, so that would also give you extra fingerprintability if so (ie, what data was there before it got freed).
13:50:49 <moneromooo> You'd have to check the source to see whether they're cleared. I'm guesing not, for performance.
13:51:42 <moneromooo> Then again, the only thing you can get from that is "are those two files from the same person", and possibly was this no involved in a recent reorg, maybe. 
13:52:02 <moneromooo> If you meant something else, explain what.
14:06:43 <stretch1> thank you
14:06:43 <stretch1> i ask explicit: no
14:06:43 <stretch1> implicit: yes (due unique chain of ops)
14:54:31 <spirobel[m]> <UkoeHB> "spirobel: why not always call..." <- that makes sense. I just want to make sure I understand this completely, because it affects transaction uniformity and that is an important topic that I should know in detail. 🙂 
15:54:49 <stretch1> please handle SIGINT when cli in locked state
15:55:09 <stretch1> rlly kill -9 ...
16:51:44 <sethforprivacy> So, what does the `--no-dns` flag do for the wallet, and why are there DNS requests necessary at all for spending?
16:52:29 <sethforprivacy> DoH/VPN DNS seems to be at the root of spending UX issues I and others are facing (not output distribution caching, though that could help as well), but I don't really understand why DNS queries are necessary at all when spending Monero.
16:56:40 <moneromooo> IIRC, obsolete check for "was there an asshole reusing the chain for fork, which would cause people to spend the same output twice with different rings".
16:57:10 <moneromooo> I forget the specifics, but the fake out selection would weigh differently pre/post fork height.
16:57:27 <moneromooo> I'm not sure it even works anymore. It was iffy.
16:57:47 <moneromooo> I don't *think* anything else uses DNS in the wallet.
17:01:38 <sethforprivacy> Also hitting these DNS servers: https://github.com/monero-project/monero/blob/9a124f681119855949f6406ecd69c2ad91da9770/src/common/dns_utils.cpp#L46-L53
17:01:40 <ooo123ooo1234567> In general, it could be any other centralized dns record. Is it obvious now why dns was so slow ?
17:01:43 <tobtoht[m]> OpenAlias resolve uses DNS. (And I believe there is some (unused?) stuff in checkpoints.cpp that that can load checkpoints from DNS.)
17:02:14 <sethforprivacy> ALl of this happens at transaction generation, which means you're absolutely fucked if your DNS server cares about Monero -- these are 100% attributable to Monero usage and contacting these domains with every send is a dead giveaway and simple source of timing analysis.
17:02:36 <moneromooo> Oh yes, I'd forgot openalias, thanks.
17:02:48 <sethforprivacy> The biggest thing to know is -- is this a default behavior of wallet2 etc. (and thus a core function of most wallets) or is this limited to select wallets?
17:03:06 <ooo123ooo1234567> it's default of wallet2
17:03:23 <sethforprivacy> None of these DNS servers or domains should be called if you're not actually sending to an OpenAlias address.
17:03:45 <sethforprivacy> The only default DNS usage should be resolving domain name of a given remote node or resolving an OpenAlias (if actually used)
17:04:06 <sethforprivacy> * remote node (if DNS is used for the node address) or resolving
17:04:23 <sethforprivacy> Calling all of these servers and moneropulse.* domains each transaction generation is... very, very bad.
17:05:07 <sethforprivacy> And it's the source of UX pain for users who have strict DNS handling, use DoH, or use some sort of DNS catch/redirect/block for privacy/security reasons.
17:05:19 <sethforprivacy> Thats why only some people (like myself) have noticed the UX issues.
17:05:19 <moneromooo> Well, change it ?
17:05:34 <sethforprivacy> I don't know C++ sadly
17:05:35 <tobtoht[m]> I agree with Seth here. Do we need to keep the segregation height over DNS stuff around? There is code in place to allow it to be configured manually for those that want to.
17:05:51 <moneromooo> Ah, then file a bug. 
17:05:56 <sethforprivacy> tobtoht[m]: A manual flag for those who want it for some reason is fine, but default behavior these days doesn't make sense.
17:06:06 <sethforprivacy> Yeah I wanted to confirm my suspicion before I did
17:06:11 <sethforprivacy> I'll raise an issue now.
17:12:35 <tobtoht[m]> Working on a PR.
17:14:52 <sethforprivacy> https://github.com/monero-project/monero/issues/8407
17:14:54 <sethforprivacy> Threw it together but it's a starting point
17:16:58 <sethforprivacy> tobtoht[m]: Thanks!
17:17:11 <sethforprivacy> Honestly I'm much more worried about the network privacy implications of this than my pesky UX issues anymore
17:17:19 <sethforprivacy> I had no idea this was default behavior...
17:17:45 <sgp_[m]> I also had no idea the same servers were pinged before sending a transaction
18:11:59 <sethforprivacy> <sethforprivacy> "https://github.com/monero-..." <- https://github.com/monero-project/monero/pull/8408
18:12:04 <sethforprivacy> Thanks, tobtoht!
18:12:40 <tobtoht[m]> No problem :)
18:18:11 <MajesticBank> hit new circuit
21:05:54 <arnuschky[m]> Hello everyone, the audit of PR 8149 is finally here: https://community.rino.io/rino-multisig-pr8194-audit-20220627.pdf
21:06:25 <dukenukem> \o/
21:06:55 <UkoeHB> thanks arnuschky[m] 
21:07:04 <arnuschky[m]> The report went through a few rounds of review and clarifications; as well as a review of the devs before publication. Hence the delay.
21:08:24 <arnuschky[m]> (I figured it's best to run this report by the devs first to make sure there's nothing critical in there, as I wasn't comfortable to make that call myself)
21:10:14 <arnuschky[m]> A big thank you to everyone that helped, first and foremost to Koe who explained and commented throughout the whole process.
21:37:49 <ooo123ooo1234567> <arnuschky[m]> "Hello everyone, the audit of PR..." <- What would be the next action in case if there are issues not mentioned in this report ?
21:40:21 <arnuschky> I guess to bring them to the attention of the community, ideally following the responsible disclosure process or HackerOne
21:40:48 <arnuschky> I am not the most qualified to say. However the route you have taken last time seems sensible.
21:41:29 <arnuschky> If the issues are minor and don't need to be disclosed privately, maybe the simplest solution is to discuss them here
21:41:35 <ooo123ooo1234567> How would you describe the aim for that audit ? Was it achieved ?
21:42:31 <arnuschky> The aim was to make sure that the three reported issues were indeed fixed. This was achieved.
21:42:44 <arnuschky> (as described in the Scope section of the report)
21:44:06 <arnuschky> It's pretty hard to set a target scope for such a limited audit. The best option would probably be to audit/analyse the whole multisig system, as previously discussed.
21:44:37 <arnuschky> @ooo123ooo1234567 you've said in the past that you have done that, so it doesn't surprise me that you have found further issues.
21:47:31 <ooo123ooo1234567> <ooo123ooo1234567> "if you all stopped pretending..." <- this
21:59:15 <ooo123ooo1234567> <arnuschky> "I guess to bring them to the..." <- https://nitter.42l.fr/kayabaNerve/status/1539991529795866627#m, indeed, a good way
22:59:49 <kayabanerve[m]> While I had a few comments, it seemed competent overall. While I don't mean without a few fixes merged, I would like to see 8149 merged using the experimental label.
23:01:50 <kayabanerve[m]> The discussion against isn't about issues with 8149. It's issues with the review process. While I'm not against such issues, I believe there's a lack of explicit steps to continue the review process posited for sufficiency, which makes us unavailable to actually continue with anything if we fall under that line of thinking.
23:02:16 <kayabanerve[m]> And I do mean 8149 + minor fixes, which will require new review, + the burning bug fix. 
23:03:36 <kayabanerve[m]> If ooo123ooo1234567: has either specific issues with the audit OR has explicit steps they'd like to see before it's merged, I'd appreciate their input though :)