<ooo123ooo1234567> "checkpoint is a compromise..." <- This

openssl/openssl #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

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

it must crash with two duplicate OPENSSL_cleanup calls to

selsta, can you test ?

s/OPENSSL_cleanup/OPENSSL\_cleanup/, s/to/too/

yes

`Reviewed-by: Paul Dale <pauli⊙oo>` hmm, they are supposed to know their code better than others

<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.

it does not crash with just OPENSSL_cleanup twice

and init first

can you run once again with gdb and print stack trace ?

nvm, not needed

selsta, got a stall on your branch that im usin

<selsta> "it does not crash with just..." <- 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`

gingeropolous: is it still open?

yeah i just got a thread apply all logfile dump

tryin to think where to... ah yeah the termbin thing there we go

selsta, termbin.com/g2b8 ... lemme know what else might be good. ima dig through the actual log see if anything

ooo123ooo1234567: does ^ seem related to your connection / p2p patch?

nothing interesting in logs

can i restart the daemon? or is there any thread diving needed

or whatever its called

thread pulling

not so fast

but im missin all those sweet blocks

is it debug or release build ?

oh prolly release

yeah, release.

press continue for few seconds, then interrupt it and paste another stack trace

it's interesting whether it's completely stuck in all threads or not

well, the current state is that the daemon is no longer spitting out any logs

and I can't get a response from the status command

you have to enter: continue

then wait a couple seconds

ctrl+c

and then again thread apply all bt

doesn't matter if it appears stuck or not

looks like a deadlock within logger

that includes the first dump as well

gingeropolous: which log level are you running these days?

the monerod.conf says its log level 1

its me, u know, it could be something stupid like file descriptors or whatever

though i thought i already tweaked this box and ive got that mdbstat running every 2 mins

wait, don't just drop that gdb session so early

yeah ima fire up a second node. i'll keep this dead one up

the same stack trace, so completely stuck

so....

I'm reading code and that stack trace currently, searching for an explanation

roight roight roight

sonofabitch. my new node got stuck on Height: 2653718

the same way ?

naw, it thought it was syncd. rpc responded

false negative ?

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

oh there it goes

also on the new node im just running master, not selsta's branch

if master will stuck too then it's unrelated to patches on top of it

gingeropolous: did it deadlock, or was it just on the wrong height for a bit? and does it work now?

just wrong height. its working now.

<selsta> "ooo123ooo1234567: does ^ seem..." <- indeed, obvious relation: deadlock -> deadlock with pthread mutex -> connection / p2p patch

s/deadlock/some/, s/with//

* indeed, according to the following deduction chain: deadlock -> some pthread mutex -> connection / p2p patch

gingeropolous: did you run this branch github.com/selsta/monero/blob/master-beta without any modifications ?

ooo123ooo1234567, correct

when did you compile?

looks like i made the selsta_monero folder on may 11

yeah, bin was made then as well

on the new box im getting 30+ connections from single IPs

what would be the next action if this problem is reproducible with maste rtoo ?

s/maste/master/, s/rtoo/too/

i gotta sleep. the dead one is still in gdb. the new one is being stupid

who will fix broken code ?

i dunno. i just break stuff

list of recently broken things ? 1. deadlock in monerod, 2. ... ?

openssl/openssl #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

their review process is an example when even labels / github bots / dedicated maintainer / etc together can't help

<selsta> "when did you compile?" <- it doesn't matter

<gingeropolous> "can i restart the daemon? or..." <- as you wish

<selsta> "ooo123ooo1234567: does ^ seem..." <- it's reproducible without patches on top of master

why do we sometimes supply an additional public_spend_key to check_tx_proof? github.com/monero-project/monero/bl…253a5/src/wallet/wallet2.cpp#L11817

I also saw that the proof is different for subaddresses and the legacy standard addresses: monero-project/monero #2487 but that is unrelated, correct?

Outputs to subadresses are made with those keys, rather than the "main" tx key.

Or rather, with the corresponding secret key.

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) :

crypto::check_tx_proof(prefix_hash, address.m_view_public_key, tx_pub_key, boost::none, shared_secret[0], sig[0], version); ```

what I also dont understand: what is this: get_additional_tx_pub_keys_from_extra function? github.com/monero-project/monero/bl…253a5/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?

They are always in extra.

Public keys are sometimes known as R in shorthand. At least prior to subaddresses, not sure if the convention changed for those.

moneromooo: how do they relate to public view keys and public spend keys and stealth addresses?

Zero to monero should have that.

<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?

can you read C++ ?

openssl/openssl #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

openssl/openssl #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

spirobel: tx_pub_keys are the shared secret for that tx.

Technically aren't since they're public.

They're used to derive the shared secret though.

<wernervasquez[m]> "spirobel: tx_pub_keys are the..." <- are shared secrets and encrypted payment_ids the same?

spirobel: Not at all.

moneromooo: Yes. I misspoke. The tx pub keys are used to derive the shared secret.

spirobel: see cryptobook.nakov.com/asymmetric-key-ciphers/ecdh-key-exchange for a textbook example of what a shared secret is

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.

That is a sliiiiight simplification since xmr has both view keys and spenk keys and subaddresses, but that is the gist of it

are payment_ids verified when doing check_tx_proof on a transaction that was sent to an integrated address?

<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?

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

So, the "additional" pubkeys are just to support subaddresses since they each need their own pubkey (rK instead of rG in ZTM2)....

wernervasquez[m]: in case the transaction has multiple destination addresses?

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.

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?

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?

I apologize that I do not

Have time to answer this now.

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.

See page 38 and page 40. Step 3 on both pages

thanks! I appreciate it! 🙂👍️

spirobel[m]: page 40 footnote 16

<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.

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?

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.

but if I have the payment_id, can I recreate the encrypted_payment_id and compare the outputs? is github.com/monero-project/monero/bl…/src/device/device_default.cpp#L352 deterministic ?

It appears to be deterministic at first glance.

spirobel[m]: it should be possible by adapting the InProof or OutProof

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?

does lmdb include a pid or finger print?

s/pid/identifier/

spirobel[m]: why not always call both? then you don't have to worry about the different scenarios

stretch1: rephrase

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.

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.

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).

You'd have to check the source to see whether they're cleared. I'm guesing not, for performance.

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.

If you meant something else, explain what.

thank you

i ask explicit: no

implicit: yes (due unique chain of ops)

<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. 🙂

please handle SIGINT when cli in locked state

rlly kill -9 ...

So, what does the `--no-dns` flag do for the wallet, and why are there DNS requests necessary at all for spending?

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.

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".

I forget the specifics, but the fake out selection would weigh differently pre/post fork height.

I'm not sure it even works anymore. It was iffy.

I don't *think* anything else uses DNS in the wallet.

Also hitting these DNS servers: github.com/monero-project/monero/bl…70/src/common/dns_utils.cpp#L46-L53

In general, it could be any other centralized dns record. Is it obvious now why dns was so slow ?

OpenAlias resolve uses DNS. (And I believe there is some (unused?) stuff in checkpoints.cpp that that can load checkpoints from DNS.)

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.

Oh yes, I'd forgot openalias, thanks.

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?

it's default of wallet2

None of these DNS servers or domains should be called if you're not actually sending to an OpenAlias address.

The only default DNS usage should be resolving domain name of a given remote node or resolving an OpenAlias (if actually used)

* remote node (if DNS is used for the node address) or resolving

Calling all of these servers and moneropulse.* domains each transaction generation is... very, very bad.

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.

Thats why only some people (like myself) have noticed the UX issues.

Well, change it ?

I don't know C++ sadly

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.

Ah, then file a bug.

tobtoht[m]: A manual flag for those who want it for some reason is fine, but default behavior these days doesn't make sense.

Yeah I wanted to confirm my suspicion before I did

I'll raise an issue now.

Working on a PR.

Threw it together but it's a starting point

tobtoht[m]: Thanks!

Honestly I'm much more worried about the network privacy implications of this than my pesky UX issues anymore

I had no idea this was default behavior...

I also had no idea the same servers were pinged before sending a transaction

<sethforprivacy> "github.com/monero-..." <- monero-project/monero #8408

Thanks, tobtoht!

No problem :)

hit new circuit

Hello everyone, the audit of PR 8149 is finally here: community.rino.io/rino-multisig-pr8194-audit-20220627.pdf

\o/

thanks 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.

(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)

A big thank you to everyone that helped, first and foremost to Koe who explained and commented throughout the whole process.

<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 ?

I guess to bring them to the attention of the community, ideally following the responsible disclosure process or HackerOne

I am not the most qualified to say. However the route you have taken last time seems sensible.

If the issues are minor and don't need to be disclosed privately, maybe the simplest solution is to discuss them here

How would you describe the aim for that audit ? Was it achieved ?

The aim was to make sure that the three reported issues were indeed fixed. This was achieved.

(as described in the Scope section of the report)

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.

@ooo123ooo1234567 you've said in the past that you have done that, so it doesn't surprise me that you have found further issues.

<ooo123ooo1234567> "if you all stopped pretending..." <- this

<arnuschky> "I guess to bring them to the..." <- nitter.42l.fr/kayabaNerve/status/1539991529795866627#m, indeed, a good way

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.

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.

And I do mean 8149 + minor fixes, which will require new review, + the burning bug fix.

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 :)