monero-project/monero #8299#issuecomment-1169235856, "If not we will have to ask the monero community if they prefer to delay the hardfork or if they are okay with leaving Trezor users unable to transact for about 2 weeks. ..."

merge of multisig cryptography without security analysis - no question to the monero community

* merge of multisig cryptography without security analysis - no need to ask the monero community

is it enough to rely on audit by those who failed to notice trivial problems in implementation and removed their names in 2nd audit ? - no need to ask the monero community

ooo123ooo1234567: So... do what? Asking ooo

What to do*?

is it ok to not fix privacy issue with subaddresses (monero-project/research-lab #62) in this hardfork ? - no need to ask the monero community

<ooo123ooo1234567> "merge of multisig cryptography..." <- Considering the standing code is fundamentally broken in multiple ways, and both your PR and 8149 would be explicit improvements, no, it doesn't require asking everyone for their personal opinions on the matter since it will solely benefit them

Losing trezor would be a major detriment however, potentially bricking important workflows

This shouldn't even be a question if you weren't just constantly obnoxious about things you feel personally enraged about despite frequently not helping to actually resolve your perceived issues.

<kayabanerve[m]> "Considering the standing code is..." <- monero-project/monero #2134#issuecomment-312050442, "This needs review from a qualified cryptographer and/or the cryptography community (i.e. the latter by writing it up in a paper and seeking review) before being deployed live but enabling it for testnet would be fine. (Comment on cryptography not code)"

see ?

this step wasn't done at that time and you all are skipping it now too

call at least 1 user who would agree to rely on cryptocurrency that is avoiding proper verification of used cryptography ?

<kayabanerve[m]> "Considering the standing code is..." <- monero-project/research-lab #100, you were supposed to push this task but decided to work on your serai dex, do it, but don't teach what to do it monero and how

<kayabanerve[m]> "Considering the standing code is..." <- I've spent time on deep verification of important parts in cryptography, UkoeHB resubmitted my patch in order to add unimportant changes (all of them aren't related to security); see difference ?

<kayabanerve[m]> "This shouldn't even be a..." <- merge of resubmitted patch with shitty audit without cryptography security analysis, it's already more than enough to hate everyone involved into it

whether to do retrospective analysis for discovered deep issues in order to identify their source and prevent similar issues in future ? - no need to ask the monero community

is it ok to write implementation for seraphis without cryptography security analysis (which will be even more complex than multisig one) - no need to ask the monero community

<arnuschky> "The aim was to make sure that..." <- or wasn't achieved, who is responsible for this conclusion ?

<arnuschky> "The aim was to make sure that..." <- Judging by incorrect details in audit report it looks like auditors have no idea what they were doing.

it's interesting who is going to take responsibility for merge of that code

In general, you can push arbitrary code into repo, but someone should be responsible for failure, otherwise it's a system without feedback loop

<gingeropolous> "selsta, termbin.com/g2b8..." <- request for competent developers: how to fix this deadlock ?

Compile with thread sanitizer and run: "TSAN_OPTIONS=second_deadlock_stack=1 ./monerod ..."

then search for "Writer::initializeLogger" in tsan reports

or search for "LogDispatcher::dispatch"

is it applicable to static stack trace ?

what do you mean

I mean I've solved that deadlock already via stack trace + code reading -> reproduce it locally -> write patch to fix it; asking others to do the same

those stack traces only hint at some circular lock dependency in logger or in how Monero uses the logger

running it with tsan will quickly find this dependency even without reproducing

<sech1> "those stack traces only hint..." <- ~4 hours

Trezor firmware will be out July 20th now, in time for the delayed HF: monero-project/monero #8299#issuecomment-1171167355

Thanks for all of the work on that communication, selsta!

Seth For Privacy: thanks for pushing hardfork date forward without having actual code

<sech1> "running it with tsan will..." <- yes, but proper code fix would require code knowledge anyway

s/code//

<ooo123ooo1234567> "Seth For Privacy: thanks for..." <- Man you're a fun guy to be around, aren't you?

I'm just hiding deep hate with this jokes

That's obvious, not hidden at all.

I know you've done some things for Monero in the past but your approach is absolutely idiotic if you actually care about improving Monero as a whole.

* I'm just hiding deep anger about whole situation with these jokes

and waiting for the decision of others

it looks like they don't want to change anything

Nothing in your approach is helpful or useful, even if technical contributions and knowledge are solid. Learn a useful way to actually communicate with other people and you'd accomplish 10000% more.

but don't want to admit it and trying to be somewhere between

Attacking literally everyone who is not you is quite the approach if you actually care about Monero.

Hey, 2 months ago they were ignoring that scammer and still didn't publish any conclusion about that situation

now they are dodging problems with multisig cryptography

Do you know any way to communicate with such people ?

ooo123ooo1234567: I do

Yeah, lay out a rational and reasonable argument with facts and a useful tone and voila, you're much more effective!

Being a massive asshole to everyone just makes your useful arguments and points get lost in the assholery.

sethforprivacy: Hey, risking with money due to incompetent developers

ooo123ooo1234567: Giving away money to incompetent developers.

Ooo, we all see it! You cant change anything by being angry

Please be trolled somewhere that's not -dev.

sethforprivacy: asshole ? I'm pointing problems in development process and they don't change anything

Is it being asshole ?

moneromooo: -dev is where he's harrassing everyone but good point.

I didn't even use swear language in pblic

s/pblic/public/

see ?

Yes, but I don't see it, so that doesn't annoy me :D

Take it to -community if you want to continue the convo ooo123ooo1234567

ooo123ooo1234567: Ooo, come over to community

moneromooo: Glad to hear that 🙂

moneromooo: I can discuss purely technical problems

moneromooo: termbin.com/g2b8, request for competent developers: how to fix this deadlock ?

but you already fixed it, submit a patch and let's move on

This split of whole environment into community and dev allows to do ping-pong

How to discuss incorrect patch that was written by another incompetent developer and merged without proper review: any questions about development process in -dev - offtopic, any technical questions to that person in -community - offtopic; see ?

ping-pong

sech1: ^

stop using two accounts ooo123ooo1234567 ofrnxmr[m]

Sech.. im not ooo

hahahahaha

now ooo asks all developers to waste time on some deadlock debugging which he already fixed. It's straight up malicious practice of stalling the development. Devs have other stuff to do right now.

It's ok to use already solved task for educational process

are you a self-proclaimed teacher?

it isn't waste of time

Monero devs are not your interns. Submit a patch with description of the issue or stop mentoring everyone here

"It's straight up malicious practice of stalling the development." asking someone else to try to solve some real problem is stalling the development ?

What's about incompetent developer introducing another incorrect patch that was merged and it's a consequence of it ?

<sech1> "but you already fixed it, submit..." <- I've submitted 3 patches and all of them are not merged

<sethforprivacy> "Yeah, lay out a rational and..." <- There are examples when others are stubborn even in front of reasonable arguments with facts

<sethforprivacy> "I know you've done some things..." <- p2pool - dead end of development; do you know how much time I will waste debating with you all about it ?

<sethforprivacy> "I know you've done some things..." <- updating cryptography without doing security analysis is way to introduce another vulnerability; the same deep problem

funny how you all are ignoring problems in monero repo, but attacking me personally; at the same time no one was attacking that scammer;

I'm getting errors syncing wallets with the latest testnet blocks (using public nodes from rino and sethforprivacy): 2022-06-30 13:47:55.709 0x70000afa7000 ERROR cn src/cryptonote_basic/cryptonote_format_utils.cpp:215 Failed to parse transaction from blob

first the wallet syncs for a while, then it pauses and logs show that error. confirmed using v0.17.3.2 gui. any ideas?

testnet forked already

you need wallet compiled from master branch

will the next release be based on master instead of the current release branches?

testnet is based on release branch

s/release/master/

ah ok

the next release is undefined currently

selsta: "...but good news is, we considered this and decided to go ahead with July release. So the new firmware should be out by July 20."

* July 20." - matejcik

what kind of attacks do you mean ?

and why these attacks aren't working with p2p over tor/i2p ?

ooo123ooo1234567: "Did anyone read the DARPA paper recently about how government actors could disrupt Bitcoin/Eth by blocking unencrypted transaction data between nodes via ISPs blocking/filtering traffic?

How susceptible is Monero to such an attack? If the US wanted to nuke Monero from orbit by ordering ISPs to block any packet that looked like a Monero block, would they be able to disrupt the network?"

the attacks start by identifying the unencrypted traffic. if using tor/i2p then the nature of the traffic is hidden.

just using TLS for encryption alone isn't enough, since IP addr:port would still be visible

unless we stop using default port numbers...

@w : The levin protocol has a very unique fingerprint, as well as happening over basically one port b/c convention. Any amateur could write a trivial packet filter to block 99% of clear net Monero node traffic

it seems pretty obvious that we should not continue using clearnet for p2p

and also that just using TLS for p2p isn't sufficient, since our port numbers will still be visible

if (tcp_packet.startswith(BENDERS_NIGHTMARE) { drop(tcp_packet); add_to_no_fly_list(tcp_packet.sender); }

hyc, it would be much more effective to block few major mining pools instead of filtering p2p packets

you're focusing on minor problem

ooo123ooo1234567: "Or if they started blocking the traffic from the largest mining pool nodes to reduce the hashrate so they could 51% attack."

Sorry... I left that part out

blocking mining pools would work for a short while. then the remaining miners would adopt p2pool

ooo123ooo123[m]: I disagree, miners have economic incentive to stay up and can easily pass block thru anonymity network. Clear net p2p as it stands is trivial to completely block all together. That would truely cripple Monero

an attack on the big mining pools would be a good thing for us, if it forces miners onto p2pool

Tor p2p is kinda garbage still, unfortunately

As much as I hate to say it

hahahahaha, you're talking about p2p behind anonymization network to someone did research for the best way to do it

while you all were busy with p2pool

what are you talking about?

ooo123ooo1234567: Share?

"you all were busy with p2pool" - pretty sure that was 99% sech1, with a little help from me

so busy

@hyc I think recently (last 1.5 years) BTC went thru the grueling process of rewriting the p2p code to have E2E encryption and hiding port info etc

We could do this and overhaul connection code along the way since we need to do it anyways (7760 comes to mind)

I don't see how you can effectively hide the port info since you must advertise it in peer lists

you need an anonymizing network, not just E2E encryption

Yes of course, but if the port was a commonly used port like 443 then it would start to be hard to write trivial packet filters

would also interfere with running thos other common services

I think the idea was that you just use a port everyone else uses / switch it between multiple to make it look like normal web traffic

unless of course, you multiplex it

so we would need to write an apache or nginx module to forward the traffic we want into monerod

hyc: how about NYM?

jeffro256[m]: you're following path of least resistance, while ideal solution is to have p2p over anonymization network;

hyc: you're inventing another pluggable transport for tor, why ?

does tor already mimic an https server? I didn't know.

Full anonymity networks are expensive computationally and in network time. There can be middle ground between complete clearnet and Tor

yeah, if we can hide in existing https traffic I think that'd be sufficient

Also Tor network has its own fingerprint

dev meeting in 1.5h

it doesn't matter what anonymization network will be used, choose the one with the best latency/privacy/bandwidth properties

the point is whether we need full anonymity for node addresses. in most cases I think not. so, no need for all the overhead of multilayer routing

just a lot of average folk running their own websites at home

As long as it quacks like an HTTPS server from an observer standpoint, that would be loads better than current situation

Like @hyc said

jeffro256[m]: HTTPS server isn't the best pluggable transport for tor

funny that no one reviewed patch for p2p connection, but everyone wants to add E2E encryption for p2p

could maybe include a random homepage generator so it actually serves up a webpage

I’m talking Tor besides

are you sure that you're starting from the right end ?

gingeropolous: Yeah give it the default Apache index.html would be funny

hyc: it's either full anonymity or cleanet, nothing in between since list of p2p peers is easily obtainable

hm, good point

but current p2p protocol isn't working even on clearnet

too early to move behind anonymization network

well. if we're using 443, then can legitimately protest an ISP block

you will just heat easy DDoS via sybil nodes and end of the game

s/heat/hit/

ooo123ooo1234567: gl with sync and flag `--hide-my-port` on tor

close to nothing coming through

s/tor/exit relays/

ooo123ooo123[m]: there can be middle ground. Connection integrity is a big part of protocols like TLS. These malicious ISPs/routers can mangle our clearnet packets at a whim

I'm not interested in short-term heuristics which require regular manual support

Having some sort of p2p identity / integrity would make a more robust network

100% your solution is crackable

can you explain in detail ?

Define “crackable”

describe what how and for what you're going to use tLS

s/tLS/TLS/

s/what//, s/tLS/TLS/

Well p2p can include not just address but pubkeys, will Peers can verify they are talkIng on secure channels to a large portion of the network of their choosing

DSP may block plain/SSL ports, useless

in clearnet encryption of p2p is useless, in tor there is already built-in e2e encryption bounded to hostname

conclusion: don't waste time on TLS for p2p

ooo123ooo1234567: How about i2p?

Tor can be blocked too, no?

i2p/tor both has e2e for hidden services

* has e2e encryption for hidden

how to bypass block of anonymization network is a separate problem (pluggable transports / gateways / ...)

but once you're behind it you have e2e encryption

ISP can block anything they want because they are out overlords. Is a question of how much collateral the block creates b/c they have an incentive to keep “normal” protocols like HTTPS intact for their customers

jeffro256[m]: i recc to use a dns solution: hnsnetwork.com/names/getmonero

you can set an identity and lease out subdomains; this can be auto done;

what monerod needs is hsd spv node; efficent in C: github.com/handshake-org/hnsd

problem is hns censorship, which might not happen if adopted

jeffro256[m]: not anything, otherwise it's physical link disconnect

<ooo123ooo1234567> "describe what how and for what..." <- TLS ensures your connection is not tampered with by a middleman

jeffro256[m]: all p2p peers are not trusted by default

* by default, everything must be verified

so TLS is useless

only centralized list of nodes benefit from TLS, but it isn't a proper solution for decentralized project

ooo123ooo1234567: Yeah, but they can just as easily block all Tor connections as they can clearnet Monero connections because they both are identifyably part of a certain network. If you mix Monero protocol in with a “normal” network like HTTPS, then trying to block Monero all of the sudden becomes much more painful and noticeable

jeffro256[m]: No, there are tor bridges that help to bypass censorship

certainly not as easily

ooo123ooo1234567: Is I2p more robust against censorship compared to tor?

I've read i2p design and it's quite shitty, there are a lot of heuristics to prevent sybil and all of them are crackable

ooo123ooo1234567: And how do those bridges work? They add a layer which makes it look like “normal” traffic, which is what adding TLS to Monero p2p would do

client <-pluggable transport -> bridge <-> tor network

jeffro256: "it's either full anonymity or cleanet, nothing in between since list of p2p peers is easily obtainable"

tor bridges aren't public, otherwise any DPI will block them easily

monero nodes are public

unbelievable waste of time

Is 7760 review close to being finished? Any blockers? ooo123ooo1234567: jberman:

Will approve once merge conflicts are resolved, I approved 7759

w[m]: 1 year delay, few months of discussion, merge conflict due to placebo PR, finally 1 particle in this universe may be moved from 0 to 1, very efficient

it's interesting what else more important was blocking progress in the meantime

Why not just resolve the merge conflict ? We can verify after the fact if anything on substance has changed

jeffro256: because I'm 100% sure that merge of placebo PRs instead of focusing on important things was a mistake

and the same happening right now with multisig / seraphis / mining centralization problem

So lets fixxxxx it. Jberman approves, lets get it done.

Cant change the past

disconnect CCS from development or change it firstly

then changes for review process

then explicit focus on important topics

and finally development may continue in the right direction

That has nothing to do with “git rebase -i master”

2, show us how you would do it (who does the reviews? Core? Contributors? You?)

3, of course

4, would hope so

most of the noise currently is generated by participants of CCS that use argument like "since we are doing paid work, our arbitrary patches must be merged"

Yeah, and enough about tjat

You said focus on important work

we can discuss CCS anytime, but you keep complaining about merge limbo but won’t fix merge conflicts

it's interconnected problem, to avoid any potential ping-pong I don't do further actions

Jberman approves.... where you have the pingpong ball.

I have no control over jberman, the next time it will not work

It took a too long to be prioritized ? Yes. But were here now and youre the blocker? That doesnt add up

I'm not a blocker, currently the most important thing is multisig, not p2p

How about both?

firstly multisig, order is important

ooo123ooo1234567: I don’t see the “ping-pong” here. Your PR is pretty old, and thus has merge conflicts. You need to fix merge conflicts before we can move forward

Ok, so what to do?

jeffro256[m]: there are many things that you don't see, but they exist

Merge? Reaudit?

What is the correct path

multisig is going to be discussed in the dev meeting today

in an open source project, prioritization is a nice-to-have. you can't dictate where volunteers will spend their time

ofrnxmr[m]: waiting for meeting to discuss something

in 40 minutes

if you want to make progress, you accept and merge what you can when you can. you don't sit back and say "these are not being done with the right priority"

I've said already that most of the noise is coming from CCS

disconnect it (to /dev/null or whatever is suitable for luigi) or change it firstly

Before meeting starts, just to poll, what does everyone think top 3 priorities should be at this very moment ?

afaik multisig is the #1 blocker for new release

Multisig merge blockers

Hard fork date

....

is ooo going to fix merge conflicts on 7760 so we can move onto 7999

For me 1. Multisig 2. p2p in general 3. Seraphis

hyc: prioritization / focus is important for a project to be competitive

sure. but this isn't a company, you can't expect to enforce it.

nice-to-have. that's all.

There are very strong arguments in favour and as i said current lack of focus is mostly due to broken CCS which adds a lot of noise

I'm ok to force whatever others think is important currently, but I'm not ok when others changing topic without focusing on anything

what's important currently is getting the new release out

since the hardfork is a little over 2 weeks away now

I mentioned p2p encryption as a matter of curiosity, not as an urgent priority

> I mentioned p2p encryption as a matter of curiosity, not as an urgent priority

Right, getting HF is highest priority, not implying it was an urgent matter

there are a lot of people here, we can have a bunch of side discussions ongoing without detracting from the urgent stuff.

hardfork in isolation isn't a priority, upgrade to bulletproofs+ / tx fee changes / view tag / multisig / increased ring size may be a priority, but incorrect code isn't acceptable

and there are some problems

I may or may not be available, despite being here now

Friendly reminder 8149 is incomplete without the burning bug fix

meeting time now

yep, hi

Was the burning bug mentioned in the audit report or did it slip past them?

hello

hey

jeffro256[m]: (read audit report)

hello

howdy

hi

i don't really have a meeting template, should we start with multisig?

heyo

Hi

Hello

Hi

Hello

seems reasonable to start with multisig :)

selsta: before starting, can you recap the items we should cover? Besides multisig

multisig, and we should set a final fork date, as 2 weeks from now is too early

we now have a definite date from trezor so that should be possible

let's start with multisig, what would your recommendation be UkoeHB?

multisig: I am fine with squashing 8149 whenever. vtnerd__ said he is working on a follow-up review, but his last message was a couple weeks ago so idk what to think about that (in the past he has always followed through despite sparse irc activity).

selsta: It was

*sorry, meant to reply to the question about the burning bug

as soon as 8149 is merged I want to expedite this branch (the 'burning bug'): github.com/UkoeHB/monero/tree/multi…sig_signfixes_deterministic_secrets

it's a 150 diff commit on top of 8149

last update from vtnerd__ 3 weeks ago*

Hi

hey there

UkoeHB: what would "expedite" entail? What level of review is needed? It's "just" code and doesn't touch crypto right?

"code doesn't touch crypto" interesting statement

binaryFate: it changes how tx private keys are computed, so there is some crypto involved

expedite as in, let's not take 6 months to merge it...

seems fine

> binaryFate: it changes how tx private keys are computed, so there is some crypto involved

Does it utilize something similar to "guaranteed addresses" like kayabaNerve proposed?

yes, you generate the keys from a hash chain starting with entropy provided by the tx initiator + the input key images

the burning bug PR used to be part of 8149, and is pretty self-contained

it's essentially this commit: UkoeHB/monero ee28a22

for miner txs, it would just be the previous block hash right? (or whatever block hash)

Kayaba spoke about it in his talk at Monerokon

it changes the serialization of the pending_tx struct or whatever it's called, so it's a breaking change (but could be released in a post-fork update if necessary I suppose)

<UkoeHB> "multisig: I am fine with..." <- not fine with 8149, not fine with multisig_signfixes_deterministic_secrets

jeffro256[m]: multisig does not make coinbase txs

kayabanerve[m]:'s proposal requires a change to view scanning, this just changes the tx author's ephemeral key

ooo123ooo1234567: can you cleanly elaborate what it is about both you are not fine with

what's the final goal regarding multisig features ?

unsafe implementation with experimental flag ?

if yes, then it doesn't matter whether 8149 will be merged or not

if the goal is to have working multisig then there is a need for additional changes

can you give an example of what you thought was incorrect in the audit?

I feel we'd be more productive by taking this one at a time. So before moving onto the burning bug discussion or other discussions, can we agree that 8149 is ready to be merged?

why does it matter if it doesn't cover multisig completely ?

It's the same uniqueness principle, yet it moves generated from the shared secret to r specifically

8149 has been thoroughly reviewed, audited, and Koe already implemented everyone's remarks

Sorry, few minutes behind

once 8149 is merged, we can use this as a new basis of discussion for further improvments

arnuschky: thorough review of C++ isn't for cryptography, audit is poor, minor remars are not important

ooo123ooo1234567: No one is saying we don't want formal review. We're saying the existing is definitively broken, and no one has come forth saying this is broken. Therefore, regarding the code alone, it's a definitive benefit.

Regardless, yes, obviously, it would be a major issue if this was also broken.

arnuschky: no, it isn't a basis; cryptography shouldn't be implemented with partial changes without having overall design; it's a way to add more vulnerabilities

That's why we've gotten it reviewed by multiple people who contribute regarding cryptography, and multiple people regarding C++

May I recommend instead of shutting down progress, forcing people to use known insecure code, you instead work to be the progress you want?

ooo123ooo1234567 Are you saying that the scope of the audit should have been expanded?

I believe they want formal security proofs comparable to bulletproofs/clsags

kayabanerve[m]: I'm saying that 8149 isn't enough for safe multisig; if the goal is to have unsafe + experimental then it doesn't matter whether 8149 is merged or not

It's a formal theoretical spec and tens of pages of documentation, combined with more months of review

Even if repeated, that's a strange opinion to have IMHO

You're welcome to that opinion. We can keep the experimental label accordingly, to make it clear this isn't safe. But it DOES matter if it's merged

"bad or worse does not matter, if nothing perfect is available". Really

If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week.

kayabanerve[m]: it's needed to catch all details in one place

I won't completely disagree, yet I will disagree it's required

kayabanerve[m]: it's a necessity whether it's moths or not

UkoeHB: ACK

ooo123ooo1234567: are you aware of additional vulnerabilities in multisig that require more code changes to patch? Or is your position that it isn't "enough" to reach the bar of "safe"?

s/moths/months/

I'd close my "unsafe" PR in that case, giving precedence to the experimental one

> If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week.

It would be a different matter if ooo123ooo1234567 had a specific gripe, but it seems that ooo123ooo1234567 wants 8149 to be the be all, end all PR for multisig and *only* then merge it

Assuming the burning bug addition is successfully merged

UkoeHB: in this meeting nobody cares about cryptography security analysis, so technical defeat ?

Who or what is defeated?

I think if things are agreed as they are in that meeting, and as it generally goes with community decision, we'll all take collective responsibility for the good and the bad

I think merging iterative improvements to software doesn't conflict with analysis of the system as a whole

sorry wrong window

Still true?

jberman[m]: yes, but it was already said

> <@jeffro256:monero.social> > If ooo123ooo1234567 can't convince anyone that 8149 should be stalled further by the end of the meeting, I would like to squash and merge 8149 this week.

>

> It would be a different matter if ooo123ooo1234567 had a specific gripe, but it seems that ooo123ooo1234567 wants 8149 to be the be all, end all PR for multisig and *only* then merge it

While leaving the community in a known critically vulnerable state in the meantime

Friendly reminder they submitted their own PR, which they've yelled wasn't merged, without these specs

binaryFate: collective responsibility means no one will be responsible

I truly believe they're just a pissed off obstructionist, not that I believe there's anyone else left to convince

kayabanerve[m]: not leaving, I was busy with security proof since it's the most important port

s/port/part/

ooo123ooo1234567: So they've claimed this, there's been no evidence, no one else has found them, and it's obvious they don't actually want to help. I won't say there isn't. I will say we can't trust them

And while formal spec would certainly help... It doesn't guarantee

can someone explicitly say what is supposed to be placed into hardfork release ? unsafe multisig + experimental / safe multisig without experimental ?

ooo123ooo1234567: Great. I don't believe you've ever shared that that's why you ghosted the PR. Would you like to contribute now? We'd appreciate it

I think the only way forward is to do this how any collective open software project is driven forward. Agree on set of changes, merge them, invite people to suggest further improvements.

merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag

So I think we got all reviews and changes we gonna get for 8149. Let's merge it, as monero will be in a better state afterwards.

> merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag

+1

selsta: ok, I want add additional changes to my own PRs -> merge it -> remove experimental

ooo is then invited to propose a new PR on top of it if he wants to prove that there's more to fix

arnuschky: why on top ?

ooo123ooo1234567: so no formal security proof then?

If ooo actually wants security, and actually knows of issues, they're welcome to contribute them

ooo123ooo1234567: Code style/myriad of other edits towards form and function?

tobtoht[m]: including security proof

And about the time frame, in a first rough estimate?

kayabanerve[m]: there are controversial style/myriad changes, not important

8149 can be rebased on top my prs with all that style changes

Controversial to you. Not to the project

@ooo123ooo1234567: because that's how you develop incrementally using git, in a group of people

kayabanerve[m]: No, controversial objectively, do you want to discuss ?

arnuschky: yes, that's why 8149 can be rebased on top my PR one more time and submit all miner changes

s/miner/minor/

I think we have community consensus 8149 is the proper PR for the fundamental set of changes both PRs contain. Therefore, it's the one not controversial to the community. If yours was fine, it would've been merged without requested edits

And how is this better than merging, and then continue to develop from that point onward?

ooo123ooo1234567: wouldn't it be faster to explain publicly what the remaining issues to be fixed are, in plain english?

kayabanerve[m]: community consensus ?

Fuck it. If it gets ooo to shut up, if they want to edit their PR to have the same HEAD as 8149, fine. Let's merge theirs

Then you can either do it on your own or get help

ooo123ooo1234567: I would argue for keeping 8149 unmerged, we proceed with multisig disabled until we reach the bar of safe, if you prove you're aware of additional vulnerabilities

But no one will step up to maintain your PR.

binaryFate: it's vulnerabilities, can't publicly

Lol

you can always talk to me or hacker one team privately

if it's your worry

vulnerabilities in unmerged code

binaryFate: no, there are no competent people behind hackerone, not ok

whoever you would give your updated PR to review, then why not tell these people now what the issues are?

It seems it's always only black and white ...

let's move onto discussing how to move forward with a release. I see two open PRs for multisig:

- 8149 (consensus to be merged)

- burning bug (small PR, but needs review)

what else should go into that release?

Are we doing to have a closed source ooo monero daemon?

Like that seems to be the only path they'll accept at this point

kayabanerve[m]: PRs are public, why closed source ?

Once the new release is out, ooo (or anyone else) is invited to report vulnerabilities using the usual channels.

I don't find it productive to turn in circles on hypotheticals.

Because that'd disclose the vulnerabilities because we're all incompetent and can't be trusted, apparently

ooo123ooo1234567: why not DM vulns to koe?

arnuschky[m]: Exactly

arnuschky[m]: no circles yet

jberman[m]: sure, he'll need a new account though

The ironic thing is responding to that would be yet another iteration of the circle

😏

:)

8149. Burning bug. "Experimental". It seems like everyone except ooo agrees on that.

yes

mark it as experimental

From maintainers, to the acknowledged cryptographer of the project, to people who are willing to bet their business on multisig

Does anyone else have objections ?

I don't see it being super actionable to not merge something because it's experimental and could have flaws, without person who says it's flawed being able to articulate them

Not to mention that everything always can have more flaws

by all means be cautious, but I think in this case the community's caution is just being taken advantage of to stall. or at least that's the side effect

word

<kayabanerve[m]> "Fuck it. If it gets ooo to..." <- it isn't just edit, there are important changes

jeffro256[m]: no one understands what is it about, not clear what's the purpose of such voting

if the current code has reviews from competent people and we don't know of any vulnerabilities, then ok to merge as experimental. my 2c

sgp_: agree

Purpose of voting? Reaching a decision, maybe

sgp_: those competent people removed their names and failed 1st time

it's like strong sign that we don't want to participate in it from side of auditors

If ooo123ooo1234567 discloses a single vuln to koe that was previously unknown, I would argue for keeping multisig disabled and we give them time to continue work on their patch

can't we just put out as experimental and commission audits as necessary later? I don't see what's the big deal

ooo123ooo1234567: I believe the competency referred to koe and others, not just the auditors who are grey

sgp_: we would ideally need formal security proof, not audit

okay, so just say formal security proof doesn't exist then

Keyword is probably "ideally"

work on this can continue outside of the hardfork and release

UkoeHB: what was your opinion on how in depth the audit was compared to your knowledge?

jberman[m]: If it lead to any loss of funds/denial of service of fund access that isn't just the rpc routes being manual, sure

playing devil's advocate but where do we draw the line between "experimental" or not? There is surely more to Monero crypto and code that isn't as security proved as ooo123ooo1234567 would wish for to deserve being non-experimental

do the multisig changes in question even require a hard fork?

r4v3r23: no

rbrunner: Fuck it, I'll add a 10 XMR bounty on 8149. If any loss of funds are submitted, outside of the rpc routes being manual, and UkoeHB: confirms... Stands until the hf

binaryFate: MuSig2 paper - not experimental, no paper - experimental

Sorry, did not mean to reply to rbrunner. My client is acting up

jeffro256[m]: then why is a feature that can be hased out later holding up an entire network upgrade?

r4v3r23[m]: it's not holding up the network upgrade

ooo123ooo1234567: Tell koe one new loss of keys/funds. Prove you're superior and help monero. I'll pay you 10 xmr

binaryFate: previous researchers were writing security proofs since it's necessary in cryptography and done everywhere

Or yes, we go back to ignoring you

selsta: I'd say it wasn't as thorough as my own review, but at the same time the auditor(s) brought a different set of expertise/experience to the table, which always improves the venn-diagram of concept coverage (e.g. hightlighting the bias issue in hash_to_scalar(), which prompted me to update my seraphis lib).

kayabanerve[m]: 1000xmr ?

hey that's enough of this please

meh. mercenaries have no place here.

help improve things or go away.\

people need these upgrades for better wallets and privacy. move past this discussion or else monero won't ever improve

ooo123ooo1234567: are you going to disclose a vuln or not?

selsta: some people here are under the impression that it is

hyc: Based. I just want to iterate I don't believe they have anything

We're going in circles again. Let's take it one at a time. Merge 8149, merge the burning bug fix, reevaluate

if not, giving some clarity to the community on the path forward to this network upgrade would be great

ok, let's do like I said before

19:28 <+selsta> merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag

48 minutes into the meeting and nothing has been decided yet. What's the date of v15 network upgrade?

jberman[m]: yes I can

I'll happily badger ooo to prove to us that he indeed knows of more vulnerabilities

selsta: seems perfect

ooo123ooo1234567: if you want to change that you have to disclose your patch or your vulnerabilities to _someone_

otherwise we don't get anywhere

indeed.

selsta: besides ooo, does anyone else oppose this

sech1: apparently we're now actually blocked waiting for trezor?

yes, the only thing worse than hearsay is 'Isay'

Trezor said they'd be ready on the 20

I agree with selsta's plan for 8149

I +1 selsta plan

+1

+1

+1

+1

+1

Can we just be done with disussing 8149 now (in this meeting)?

if everyone agreees

yes, so fork date next

so how about July 23, 1 week delay

+1 for selsta

sgp_: In this meeting only UkoeHB has some knowledge, not sure what's the purpose to ask others

+1, as obvious

hyc: Bit tight to trezor release but I'm not against it

I'd like to delay the hardfork 2 weeks, so that we hardfork around August 1st

Should be longer

+1

ok

so that we gave people at least 1 month to update

Oh longer than one week

give*

yes, +1 on July 30th release

+1 give at least 1 month to update

1month to update for august first means release tomorrow?

luigi1111: what would you suggest?

there's no release branch yet

August 7th?

which PRs need to be merged before release?

when tag?

first thing to consider before fork date

1month after tag is my preference

.merges

Tag being moving target so just best guess

we need a new fork height first before tag

if it's 2 weeks delay, just add 10000 blocks

We also need the Ledger code in the repo

jberman[m]: we gave ledger everything

height 2678888?

i will update them on the new fork height, if they aren't ready until then it's not our fault

last hardfork they also were 1 week late

sounds fine then

ok, makes sense

So we are proposing merging this stuff today and branching like tomorrow?

sech1: can you do August 3rd or so? we need a couple days to merge and tag

and releasde

So the final date for HF?

Tag after 8149, Ms burning bug, and I have a PR I'd insist is critical :p

*and then other people's submissions, ofc

That's just my list

August 3rd is 4 more days, so 2681720

what else needs to go into this release? Is all the rest ready?

arnuschky[m]: there are a couple unreviewed patches

but we will have a second release before the hardfork anyway

to include hardware wallet support

I have a PR unmerged yet reviewed by moneromoooo: and I think selsta: :/

I badly want the DNS leak fix in (8408)

kayabanerve[m]: wow, crowd based voting on whether to merge cryptography changes or not

july 16 was a Saturday, push 4 weeks would be August 13.

Selsta, Jberman is ok w 7760.. can we rebase and merge without ooo? Or 😅

4 weeks would basically be adding 20k blocks, also an option I suppose

Would put the fork date around the 13th of August

sounds good

I'll add reviews to those 2 kayabanerve and tobtoht today

tobtoht[m]: I didn't add things to the merge queue yet, 8408 will be included

ok, great

In case of having a date in the middle of August, we should release binaries in 1-2 weeks

ofrnxmr[m]: not sure if a rebase is even needed, no actual merge conflicts have to be solved

it's just git being confused, you have to tell it to take the patch side, have to look up the exact command

"we should release binaries in 1-2 weeks" sounds realistic, no?

should i leave now or wait for release ?

@selsta that won’t work because some macros included in 7760 were removed in one of my PRs

Do i get it right that you will release 8149 + experimental flag in hardfork ?

and this decision can't be changed

correct ?

ooo123ooo1234567: it can be changed if you point out any remaining issues

ooo123ooo1234567: Wrong

ooo123ooo1234567: Not unless we're provided with a literal reason why not

so this meeting has run over an hour now. congrats ooo on successfully DOSing development

^

there is unresolved conflict with UkoeHB (maybe will resolve later via pm) but he is the most competent in current meeting, how to solve this issue ?

hyc: meething is for discussion, not development

s/meething/meeting/

work is done silenly when someone is thinking and reading/writing code

s/silenly/silently/

ooo123ooo1234567: pm him with new account if you want to resolve things with him

hyc: excuse me, but merge of incorrect code is a regress, not progress

It's not incorrect, just not perfect

if it's exploitable then it's incorrect

Show

anyway let's not waste even more time please

is there anything else

no, we will add 20k blocks to the fork height

great

for the blog post announcing the delay, 1) who will write it, and 2) what is the stated reason for the delay

delay for trezor

sgp_: monero-project/monero #8299#issuecomment-1171167355

lol perfect

If we are moving on to less pertinent issues, has anyone looked at monero-project/monero #8385?

It just gives better control over whether persistent SSL keys are used

jeffro256[m]: we need 7760 first

sgp_ why do you think a blog post is necessary? We didn't have one to announce temptative date

ideally

Ideally , yes but 7760 is unrelated to the SSL files

binaryFate: we announced here: getmonero.org/2022/04/20/network-upgrade-july-2022.html

selstaso tag+release in next few days?

<kayabanerve[m]> "Not unless we're provided with a..." <- I don't like that crowd of incompetent people say me what to do

sgp_: I'd say the delay is caused by having to wait for the Trezor firmware update + mulsitig audit results

binaryFate I'm not sure where and how it was announced, but many picked up: nicehash.com/countdown/xmr-forking-2022-07-16-12-00

sgp_ ah right, forgot about that. We should add adendum to this post then (regardless of new post or not), in case people just land on it via direct link

sgp_: We announced it via a post

And on Twitter

And on Reddit

I will edit the post, what's the new height?

<kayabanerve[m]> "Not unless we're provided with a..." <- and expected scenario is the following: I point out issues, you all are grabing them and merging instantly skipping long discussion and kick me after, correct ?

I can get a PR submitted in a few minutes

ooo123ooo1234567: Kick you????? What?

ooo123ooo1234567: please leave this alone, your comments are entirely unproductive

sethforprivacy " we will add 20k blocks to the fork height"

sech1: Thanks, sorry, missed most of the meeting due to work

20k blocks is approx. 4 weeks

* kick me out after, correct

any other topics?

looks like we're done

sgp_: Wallet2 dns issue?

Are we prioritizing this? The PR is done

jeffro256[m]: hahahah, you're suggesting to remove something from PR; facepalm

doh... I'm done, gotta go. ttyl

> <@ofrnxmr:monero.social> Wallet2 dns issue?

> Are we prioritizing this? The PR is done

I’m all for removing that DNS code, good find tobtoht

<selsta> "tobtoht: I didn't add things..." <- this is the DNS leak, will be included

ooo123ooo1234567: No I’m not

I only wanted to discuss multisig and fork date

* DNS leak, patch will be

jeffro256[m]: what's the value in stupid parroting of already said statements ? facepalm

ooo123ooo1234567: I asked. Missed it earlier.

Ooo, chill.

seems like there's nothing else

New tag date?

selsta and SGP, thanks for hosting

Fork is approx August 13th

tag/binary release/etc.

I encourage a certain someone to wise up and learn to have a productive conversation with a group, and encourage everyone else to be more aggressive at changing discussions to get back on topic when someone is clearly trying to derail. Thank you.

sethforprivacy: release 1 month before, so tag before that

Would like an estimate date for the blog post but can leave it out if we don't want to commit to one

selsta: thanks for the meeting. I will squash 8149 in 2hr unless I get a solid pm justifying more delays.

Err, nvm, can just roll with release date estimate of July 13th

we also have to delay the stagenet fork date

thanks selsta and everyone for the meeting

PR for blog post update: monero-project/monero-site #1992

luigi1111 ErCiccione ^

Tag next week, hopefully

luigi1111: are you available again?

<sgp_> "please leave this alone, your..." <- incorrect code is unproductive too, but who cares

<UkoeHB> "selsta: thanks for the meeting..." <- merge now

no need to wait

good bye

selsta: yes

<sethforprivacy> "PR for blog post update: https:..." <- luigi1111 ErCiccione if both of you can please review this and then merge/publish, would be great to be able to use this to get the word out about the shifted timetable ASAP. Very simple update to the blog post.

Ok

Or even just luigi1111, sgp_ has already reviewed/approved.

done

Thanks!

luigi1112: can you remove "firmware" from hardware wallet delays?

we kinda delayed it for both ledger and trezor and firmware is only trezor relevant

just hardware wallet delays?

yes, or hardware wallet related delays

Sure

Well its merged now -- want a new PR?

oops, just realized that comment was for luigi -- let me know if I can help with anything.

selsta: I squashed 8149

thanks

quick comment/question on getmonero.org/resources/developer-g…aemon-rpc.html#send_raw_transaction

we weren't able to get it to work with the example, but we were able to get it to work with

'{"params": {"tx_as_hex": "<hex>", "do_not_relay": "true"}}'

difference is we needed to include `params`. Can someone else reproduce?

"do_not_relay": "true" <- should be true, not a string. Not sure if it matters.

The curl example in the docs works for me.

okay, thanks for checking. I'll check on the string