10:11:52 https://github.com/monero-project/monero/pull/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. ..." 10:15:03 merge of multisig cryptography without security analysis - no question to the monero community 10:15:23 * merge of multisig cryptography without security analysis - no need to ask the monero community 10:17:43 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 10:19:17 ooo123ooo1234567: So... do what? Asking ooo 10:19:39 What to do*? 10:20:50 is it ok to not fix privacy issue with subaddresses (https://github.com/monero-project/research-lab/issues/62) in this hardfork ? - no need to ask the monero community 10:24:13 "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 10:24:36 Losing trezor would be a major detriment however, potentially bricking important workflows 10:25:53 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. 10:33:45 "Considering the standing code is..." <- https://github.com/monero-project/monero/pull/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)" 10:33:47 see ? 10:33:57 this step wasn't done at that time and you all are skipping it now too 10:34:20 call at least 1 user who would agree to rely on cryptocurrency that is avoiding proper verification of used cryptography ? 10:35:26 "Considering the standing code is..." <- https://github.com/monero-project/research-lab/issues/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 10:37:52 "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 ? 10:40:13 "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 10:48:56 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 11:04:02 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 11:17:17 "The aim was to make sure that..." <- or wasn't achieved, who is responsible for this conclusion ? 11:41:28 "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. 11:58:10 it's interesting who is going to take responsibility for merge of that code 11:59:11 In general, you can push arbitrary code into repo, but someone should be responsible for failure, otherwise it's a system without feedback loop 12:17:29 "selsta, https://termbin.com/g2b8..." <- request for competent developers: how to fix this deadlock ? 12:40:11 Compile with thread sanitizer and run: "TSAN_OPTIONS=second_deadlock_stack=1 ./monerod ..." 12:40:23 then search for "Writer::initializeLogger" in tsan reports 12:41:08 or search for "LogDispatcher::dispatch" 12:41:28 is it applicable to static stack trace ? 12:44:34 what do you mean 12:44:59 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 12:45:25 those stack traces only hint at some circular lock dependency in logger or in how Monero uses the logger 12:46:48 running it with tsan will quickly find this dependency even without reproducing 12:50:42 "those stack traces only hint..." <- ~4 hours 12:51:08 Trezor firmware will be out July 20th now, in time for the delayed HF: https://github.com/monero-project/monero/pull/8299#issuecomment-1171167355 12:51:16 Thanks for all of the work on that communication, selsta! 12:55:45 Seth For Privacy: thanks for pushing hardfork date forward without having actual code 13:01:01 "running it with tsan will..." <- yes, but proper code fix would require code knowledge anyway 13:01:19 s/code// 13:04:27 "Seth For Privacy: thanks for..." <- Man you're a fun guy to be around, aren't you? 13:07:31 I'm just hiding deep hate with this jokes 13:07:43 That's obvious, not hidden at all. 13:08:00 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. 13:08:05 * I'm just hiding deep anger about whole situation with these jokes 13:08:27 and waiting for the decision of others 13:08:33 it looks like they don't want to change anything 13:08:44 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. 13:08:57 but don't want to admit it and trying to be somewhere between 13:09:03 Attacking literally everyone who is not you is quite the approach if you actually care about Monero. 13:09:48 Hey, 2 months ago they were ignoring that scammer and still didn't publish any conclusion about that situation 13:09:55 now they are dodging problems with multisig cryptography 13:10:11 Do you know any way to communicate with such people ? 13:10:17 ooo123ooo1234567: I do 13:10:29 Yeah, lay out a rational and reasonable argument with facts and a useful tone and voila, you're much more effective! 13:10:43 Being a massive asshole to everyone just makes your useful arguments and points get lost in the assholery. 13:11:04 sethforprivacy: Hey, risking with money due to incompetent developers 13:11:46 ooo123ooo1234567: Giving away money to incompetent developers. 13:11:46 Ooo, we all see it! You cant change anything by being angry 13:11:59 Please be trolled somewhere that's not -dev. 13:12:14 sethforprivacy: asshole ? I'm pointing problems in development process and they don't change anything 13:12:17 Is it being asshole ? 13:12:19 moneromooo: -dev is where he's harrassing everyone but good point. 13:12:21 I didn't even use swear language in pblic 13:12:23 s/pblic/public/ 13:12:24 see ? 13:12:37 Yes, but I don't see it, so that doesn't annoy me :D 13:12:46 Take it to -community if you want to continue the convo ooo123ooo1234567 13:12:56 ooo123ooo1234567: Ooo, come over to community 13:12:57 moneromooo: Glad to hear that 🙂 13:13:27 moneromooo: I can discuss purely technical problems 13:14:04 moneromooo: https://termbin.com/g2b8, request for competent developers: how to fix this deadlock ? 13:14:54 but you already fixed it, submit a patch and let's move on 13:15:01 This split of whole environment into community and dev allows to do ping-pong 13:16:41 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 ? 13:16:49 ping-pong 13:17:56 sech1: ^ 13:18:09 stop using two accounts ooo123ooo1234567 ofrnxmr[m] 13:18:21 Sech.. im not ooo 13:18:52 hahahahaha 13:19:24 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. 13:19:59 It's ok to use already solved task for educational process 13:20:11 are you a self-proclaimed teacher? 13:20:15 it isn't waste of time 13:22:59 Monero devs are not your interns. Submit a patch with description of the issue or stop mentoring everyone here 13:23:20 "It's straight up malicious practice of stalling the development." asking someone else to try to solve some real problem is stalling the development ? 13:23:40 What's about incompetent developer introducing another incorrect patch that was merged and it's a consequence of it ? 13:29:09 "but you already fixed it, submit..." <- I've submitted 3 patches and all of them are not merged 13:31:23 "Yeah, lay out a rational and..." <- There are examples when others are stubborn even in front of reasonable arguments with facts 13:34:43 "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 ? 13:35:18 "I know you've done some things..." <- updating cryptography without doing security analysis is way to introduce another vulnerability; the same deep problem 13:51:45 funny how you all are ignoring problems in monero repo, but attacking me personally; at the same time no one was attacking that scammer; 13:53:53 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 13:54:25 first the wallet syncs for a while, then it pauses and logs show that error. confirmed using v0.17.3.2 gui. any ideas? 13:55:17 testnet forked already 13:55:28 you need wallet compiled from master branch 14:03:10 will the next release be based on master instead of the current release branches? 14:03:31 testnet is based on release branch 14:03:41 s/release/master/ 14:03:50 ah ok 14:03:55 the next release is undefined currently 14:43:15 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." 14:43:33 * July 20." - matejcik 14:50:41 * hyc considers adding tor and i2pd to our build process, since people are talking about attacking unencrypted p2p links 14:52:35 what kind of attacks do you mean ? 14:53:11 and why these attacks aren't working with p2p over tor/i2p ? 14:57:24 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? 14:57:24 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?" 15:06:19 the attacks start by identifying the unencrypted traffic. if using tor/i2p then the nature of the traffic is hidden. 15:06:46 just using TLS for encryption alone isn't enough, since IP addr:port would still be visible 15:07:27 unless we stop using default port numbers... 15:09:57 @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 15:12:13 it seems pretty obvious that we should not continue using clearnet for p2p 15:13:13 and also that just using TLS for p2p isn't sufficient, since our port numbers will still be visible 15:13:57 if (tcp_packet.startswith(BENDERS_NIGHTMARE) { drop(tcp_packet); add_to_no_fly_list(tcp_packet.sender); } 15:14:30 hyc, it would be much more effective to block few major mining pools instead of filtering p2p packets 15:14:41 you're focusing on minor problem 15:14:54 ooo123ooo1234567: "Or if they started blocking the traffic from the largest mining pool nodes to reduce the hashrate so they could 51% attack." 15:14:58 Sorry... I left that part out 15:15:20 blocking mining pools would work for a short while. then the remaining miners would adopt p2pool 15:15:47 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 15:16:14 an attack on the big mining pools would be a good thing for us, if it forces miners onto p2pool 15:16:23 Tor p2p is kinda garbage still, unfortunately 15:16:27 As much as I hate to say it 15:16:32 hahahahaha, you're talking about p2p behind anonymization network to someone did research for the best way to do it 15:16:47 while you all were busy with p2pool 15:17:24 what are you talking about? 15:17:28 ooo123ooo1234567: Share? 15:17:55 "you all were busy with p2pool" - pretty sure that was 99% sech1, with a little help from me 15:20:06 so busy 15:22:00 @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 15:22:36 We could do this and overhaul connection code along the way since we need to do it anyways (7760 comes to mind) 15:23:15 I don't see how you can effectively hide the port info since you must advertise it in peer lists 15:23:40 you need an anonymizing network, not just E2E encryption 15:24:29 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 15:25:01 would also interfere with running thos other common services 15:25:08 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 15:25:18 unless of course, you multiplex it 15:25:54 so we would need to write an apache or nginx module to forward the traffic we want into monerod 15:26:03 hyc: how about NYM? 15:26:08 jeffro256[m]: you're following path of least resistance, while ideal solution is to have p2p over anonymization network; 15:26:33 hyc: you're inventing another pluggable transport for tor, why ? 15:27:05 does tor already mimic an https server? I didn't know. 15:28:14 Full anonymity networks are expensive computationally and in network time. There can be middle ground between complete clearnet and Tor 15:29:15 yeah, if we can hide in existing https traffic I think that'd be sufficient 15:29:21 Also Tor network has its own fingerprint 15:30:10 dev meeting in 1.5h 15:30:52 it doesn't matter what anonymization network will be used, choose the one with the best latency/privacy/bandwidth properties 15:32:09 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 15:33:01 just a lot of average folk running their own websites at home 15:33:14 As long as it quacks like an HTTPS server from an observer standpoint, that would be loads better than current situation 15:33:42 Like @hyc said 15:34:00 jeffro256[m]: HTTPS server isn't the best pluggable transport for tor 15:34:31 funny that no one reviewed patch for p2p connection, but everyone wants to add E2E encryption for p2p 15:34:31 could maybe include a random homepage generator so it actually serves up a webpage 15:34:34 I’m talking Tor besides 15:34:40 are you sure that you're starting from the right end ? 15:35:26 gingeropolous: Yeah give it the default Apache index.html would be funny 15:36:19 hyc: it's either full anonymity or cleanet, nothing in between since list of p2p peers is easily obtainable 15:36:34 hm, good point 15:36:58 but current p2p protocol isn't working even on clearnet 15:37:08 too early to move behind anonymization network 15:37:27 well. if we're using 443, then can legitimately protest an ISP block 15:37:34 you will just heat easy DDoS via sybil nodes and end of the game 15:37:35 s/heat/hit/ 15:38:19 ooo123ooo1234567: gl with sync and flag `--hide-my-port` on tor 15:38:42 close to nothing coming through 15:38:57 s/tor/exit relays/ 15:39:25 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 15:40:03 I'm not interested in short-term heuristics which require regular manual support 15:40:08 Having some sort of p2p identity / integrity would make a more robust network 15:40:08 100% your solution is crackable 15:40:15 can you explain in detail ? 15:40:23 Define “crackable” 15:40:43 describe what how and for what you're going to use tLS 15:40:47 s/tLS/TLS/ 15:40:53 s/what//, s/tLS/TLS/ 15:41:17 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 15:41:52 DSP may block plain/SSL ports, useless 15:42:20 in clearnet encryption of p2p is useless, in tor there is already built-in e2e encryption bounded to hostname 15:42:30 conclusion: don't waste time on TLS for p2p 15:42:56 ooo123ooo1234567: How about i2p? 15:43:14 Tor can be blocked too, no? 15:43:17 i2p/tor both has e2e for hidden services 15:43:24 * has e2e encryption for hidden 15:43:58 how to bypass block of anonymization network is a separate problem (pluggable transports / gateways / ...) 15:44:09 but once you're behind it you have e2e encryption 15:44:34 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 15:44:39 jeffro256[m]: i recc to use a dns solution: https://hnsnetwork.com/names/getmonero 15:44:40 you can set an identity and lease out subdomains; this can be auto done; 15:44:40 what monerod needs is hsd spv node; efficent in C: https://github.com/handshake-org/hnsd 15:45:12 problem is hns censorship, which might not happen if adopted 15:45:17 jeffro256[m]: not anything, otherwise it's physical link disconnect 15:45:44 "describe what how and for what..." <- TLS ensures your connection is not tampered with by a middleman 15:46:10 jeffro256[m]: all p2p peers are not trusted by default 15:46:37 * by default, everything must be verified 15:46:44 so TLS is useless 15:47:18 only centralized list of nodes benefit from TLS, but it isn't a proper solution for decentralized project 15:47:27 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 15:48:01 jeffro256[m]: No, there are tor bridges that help to bypass censorship 15:48:25 certainly not as easily 15:48:54 ooo123ooo1234567: Is I2p more robust against censorship compared to tor? 15:49:28 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 15:50:11 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 15:52:14 client <-pluggable transport -> bridge <-> tor network 15:53:08 jeffro256: "it's either full anonymity or cleanet, nothing in between since list of p2p peers is easily obtainable" 15:53:33 tor bridges aren't public, otherwise any DPI will block them easily 15:53:58 monero nodes are public 15:54:34 unbelievable waste of time 16:02:45 Is 7760 review close to being finished? Any blockers? ooo123ooo1234567: jberman: 16:05:46 Will approve once merge conflicts are resolved, I approved 7759 16:07:41 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 16:08:37 it's interesting what else more important was blocking progress in the meantime 16:08:53 Why not just resolve the merge conflict ? We can verify after the fact if anything on substance has changed 16:10:44 jeffro256: because I'm 100% sure that merge of placebo PRs instead of focusing on important things was a mistake 16:10:59 and the same happening right now with multisig / seraphis / mining centralization problem 16:11:25 So lets fixxxxx it. Jberman approves, lets get it done. 16:11:44 Cant change the past 16:11:58 disconnect CCS from development or change it firstly 16:12:44 then changes for review process 16:12:51 then explicit focus on important topics 16:13:02 and finally development may continue in the right direction 16:13:28 That has nothing to do with “git rebase -i master” 16:15:43 2, show us how you would do it (who does the reviews? Core? Contributors? You?) 16:15:43 3, of course 16:15:43 4, would hope so 16:17:16 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" 16:17:40 Yeah, and enough about tjat 16:17:45 You said focus on important work 16:18:27 we can discuss CCS anytime, but you keep complaining about merge limbo but won’t fix merge conflicts 16:18:55 it's interconnected problem, to avoid any potential ping-pong I don't do further actions 16:19:20 Jberman approves.... where you have the pingpong ball. 16:20:03 I have no control over jberman, the next time it will not work 16:20:11 It took a too long to be prioritized ? Yes. But were here now and youre the blocker? That doesnt add up 16:20:25 I'm not a blocker, currently the most important thing is multisig, not p2p 16:20:42 How about both? 16:20:54 firstly multisig, order is important 16:21:14 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 16:21:14 Ok, so what to do? 16:21:31 jeffro256[m]: there are many things that you don't see, but they exist 16:22:21 Merge? Reaudit? 16:22:21 What is the correct path 16:22:27 multisig is going to be discussed in the dev meeting today 16:22:43 in an open source project, prioritization is a nice-to-have. you can't dictate where volunteers will spend their time 16:23:05 ofrnxmr[m]: waiting for meeting to discuss something 16:23:06 in 40 minutes 16:23:41 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" 16:24:27 I've said already that most of the noise is coming from CCS 16:24:54 disconnect it (to /dev/null or whatever is suitable for luigi) or change it firstly 16:25:06 Before meeting starts, just to poll, what does everyone think top 3 priorities should be at this very moment ? 16:25:29 afaik multisig is the #1 blocker for new release 16:26:13 Multisig merge blockers 16:26:13 Hard fork date 16:26:13 .... 16:26:13 is ooo going to fix merge conflicts on 7760 so we can move onto 7999 16:26:15 For me 1. Multisig 2. p2p in general 3. Seraphis 16:26:19 hyc: prioritization / focus is important for a project to be competitive 16:27:03 sure. but this isn't a company, you can't expect to enforce it. 16:27:15 nice-to-have. that's all. 16:28:00 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 16:28:25 I'm ok to force whatever others think is important currently, but I'm not ok when others changing topic without focusing on anything 16:28:52 what's important currently is getting the new release out 16:29:00 since the hardfork is a little over 2 weeks away now 16:29:51 I mentioned p2p encryption as a matter of curiosity, not as an urgent priority 16:30:41 > I mentioned p2p encryption as a matter of curiosity, not as an urgent priority 16:30:41 Right, getting HF is highest priority, not implying it was an urgent matter 16:31:31 there are a lot of people here, we can have a bunch of side discussions ongoing without detracting from the urgent stuff. 16:37:51 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 16:38:03 and there are some problems 16:59:28 I may or may not be available, despite being here now 16:59:39 Friendly reminder 8149 is incomplete without the burning bug fix 17:00:28 meeting time now 17:00:32 yep, hi 17:00:36 Was the burning bug mentioned in the audit report or did it slip past them? 17:00:47 hello 17:00:48 hey 17:00:49 jeffro256[m]: (read audit report) 17:00:56 hello 17:00:58 howdy 17:01:15 hi 17:01:40 i don't really have a meeting template, should we start with multisig? 17:01:54 heyo 17:01:56 Hi 17:02:00 Hello 17:02:06 Hi 17:02:09 Hello 17:02:16 seems reasonable to start with multisig :) 17:02:36 selsta: before starting, can you recap the items we should cover? Besides multisig 17:02:56 multisig, and we should set a final fork date, as 2 weeks from now is too early 17:03:13 we now have a definite date from trezor so that should be possible 17:04:15 let's start with multisig, what would your recommendation be UkoeHB? 17:04:26 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). 17:04:41 selsta: It was 17:05:09 *sorry, meant to reply to the question about the burning bug 17:05:13 as soon as 8149 is merged I want to expedite this branch (the 'burning bug'): https://github.com/UkoeHB/monero/tree/multisig_signfixes_deterministic_secrets 17:05:25 it's a 150 diff commit on top of 8149 17:06:39 last update from vtnerd__ 3 weeks ago* 17:06:58 Hi 17:07:32 hey there 17:07:34 UkoeHB: what would "expedite" entail? What level of review is needed? It's "just" code and doesn't touch crypto right? 17:08:02 "code doesn't touch crypto" interesting statement 17:08:07 binaryFate: it changes how tx private keys are computed, so there is some crypto involved 17:08:28 expedite as in, let's not take 6 months to merge it... 17:09:00 seems fine 17:09:06 > binaryFate: it changes how tx private keys are computed, so there is some crypto involved 17:09:06 Does it utilize something similar to "guaranteed addresses" like kayabaNerve proposed? 17:09:53 yes, you generate the keys from a hash chain starting with entropy provided by the tx initiator + the input key images 17:10:54 the burning bug PR used to be part of 8149, and is pretty self-contained 17:10:54 it's essentially this commit: https://github.com/UkoeHB/monero/commit/ee28a2207f9b6929b270d2741354b3ad6e695f4c 17:11:10 for miner txs, it would just be the previous block hash right? (or whatever block hash) 17:11:11 Kayaba spoke about it in his talk at Monerokon 17:11:32 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) 17:11:43 "multisig: I am fine with..." <- not fine with 8149, not fine with multisig_signfixes_deterministic_secrets 17:11:52 jeffro256[m]: multisig does not make coinbase txs 17:13:05 kayabanerve[m]:'s proposal requires a change to view scanning, this just changes the tx author's ephemeral key 17:13:36 ooo123ooo1234567: can you cleanly elaborate what it is about both you are not fine with 17:13:53 what's the final goal regarding multisig features ? 17:14:09 unsafe implementation with experimental flag ? 17:14:25 if yes, then it doesn't matter whether 8149 will be merged or not 17:14:35 if the goal is to have working multisig then there is a need for additional changes 17:16:12 can you give an example of what you thought was incorrect in the audit? 17:16:59 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? 17:17:06 why does it matter if it doesn't cover multisig completely ? 17:17:13 It's the same uniqueness principle, yet it moves generated from the shared secret to r specifically 17:17:39 8149 has been thoroughly reviewed, audited, and Koe already implemented everyone's remarks 17:17:40 Sorry, few minutes behind 17:18:30 once 8149 is merged, we can use this as a new basis of discussion for further improvments 17:18:41 arnuschky: thorough review of C++ isn't for cryptography, audit is poor, minor remars are not important 17:18:48 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. 17:19:07 Regardless, yes, obviously, it would be a major issue if this was also broken. 17:19:25 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 17:19:32 That's why we've gotten it reviewed by multiple people who contribute regarding cryptography, and multiple people regarding C++ 17:20:05 May I recommend instead of shutting down progress, forcing people to use known insecure code, you instead work to be the progress you want? 17:20:26 ooo123ooo1234567 Are you saying that the scope of the audit should have been expanded? 17:20:50 I believe they want formal security proofs comparable to bulletproofs/clsags 17:21:01 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 17:21:20 It's a formal theoretical spec and tens of pages of documentation, combined with more months of review 17:21:21 Even if repeated, that's a strange opinion to have IMHO 17:21:44 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 17:21:46 "bad or worse does not matter, if nothing perfect is available". Really 17:21:55 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. 17:22:02 kayabanerve[m]: it's needed to catch all details in one place 17:22:27 I won't completely disagree, yet I will disagree it's required 17:22:27 kayabanerve[m]: it's a necessity whether it's moths or not 17:22:32 UkoeHB: ACK 17:22:32 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"? 17:22:34 s/moths/months/ 17:23:08 I'd close my "unsafe" PR in that case, giving precedence to the experimental one 17:23:11 > 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. 17:23:11 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 17:23:24 Assuming the burning bug addition is successfully merged 17:23:45 UkoeHB: in this meeting nobody cares about cryptography security analysis, so technical defeat ? 17:24:11 Who or what is defeated? 17:24:32 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 17:24:34 I think merging iterative improvements to software doesn't conflict with analysis of the system as a whole 17:24:49 sorry wrong window 17:25:05 Still true? 17:25:09 jberman[m]: yes, but it was already said 17:25:18 > <@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. 17:25:19 > 17:25:19 > 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 17:25:19 While leaving the community in a known critically vulnerable state in the meantime 17:25:44 Friendly reminder they submitted their own PR, which they've yelled wasn't merged, without these specs 17:25:57 binaryFate: collective responsibility means no one will be responsible 17:26:12 I truly believe they're just a pissed off obstructionist, not that I believe there's anyone else left to convince 17:26:37 kayabanerve[m]: not leaving, I was busy with security proof since it's the most important port 17:26:38 s/port/part/ 17:27:01 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 17:27:19 And while formal spec would certainly help... It doesn't guarantee 17:27:55 can someone explicitly say what is supposed to be placed into hardfork release ? unsafe multisig + experimental / safe multisig without experimental ? 17:27:57 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 17:28:23 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. 17:28:42 merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag 17:28:56 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. 17:29:05 > merge 8149 -> merge burning bug -> keep experimental -> try to get more formal security proofs before removing experimental flag 17:29:06 +1 17:29:11 selsta: ok, I want add additional changes to my own PRs -> merge it -> remove experimental 17:29:21 ooo is then invited to propose a new PR on top of it if he wants to prove that there's more to fix 17:29:36 arnuschky: why on top ? 17:29:40 ooo123ooo1234567: so no formal security proof then? 17:29:51 If ooo actually wants security, and actually knows of issues, they're welcome to contribute them 17:30:09 ooo123ooo1234567: Code style/myriad of other edits towards form and function? 17:30:17 tobtoht[m]: including security proof 17:30:40 And about the time frame, in a first rough estimate? 17:30:49 kayabanerve[m]: there are controversial style/myriad changes, not important 17:30:50 8149 can be rebased on top my prs with all that style changes 17:30:54