02:02:33 <selsta> core team has access to the backups
04:19:26 <BigmenPixel[m]> Hello! Can I use protobuf-cpp-3.18.1.tar.gz instead of protobuf-all-3.18.1.tar.gz for build monero with hardware wallet support?
05:58:04 <selsta> BigmenPixel[m]: what do you want to do exactly?
05:58:23 <selsta> as long as it compiles with protobuf enabled it should be fine
06:09:33 <BigmenPixel[m]> <selsta> "BigmenPixel: what do you want to..." <- Choosing what is best to use for flatpak build
06:10:16 <BigmenPixel[m]> It seems to be compiled with protobuf cpp, but I can't check it, because there is no hardware wallet
06:11:07 <selsta> fwiw https://github.com/monero-project/monero/blob/master/contrib/depends/packages/native_protobuf.mk also uses protobuf-cpp
06:11:12 <selsta> so should be fine
06:12:25 <BigmenPixel[m]> selsta: thanks
06:13:35 <selsta> are you building GUI or CLI?
06:13:43 <BigmenPixel[m]> selsta: GUI
06:14:20 <selsta> a good way to confirm if hw wallet support is enabled is to download the GUI from getmonero.org, click "Create new wallet from hardware" and then select Trezor
06:14:30 <selsta> then try to create a wallet, it will error out
06:14:47 <selsta> confirm if your flatpak app shows fhe exact same error
06:15:03 <BigmenPixel[m]> selsta: Ok, I'm going to try now
06:16:05 <BigmenPixel[m]> it looks like it works
06:18:15 <BigmenPixel[m]> * it works in a flatpak environment
06:21:30 <BigmenPixel[m]> in the sense that an error is shown that there is no device
06:24:34 <selsta> ok, if it's the same error then it should be good
06:34:33 <mj-xmr[m]> .merges
06:34:33 -xmr-pr- 7798 7799 7804 7808 7859 7861 7867 7868 7869 7870 7876 7971 7993 7994
06:45:24 <selsta> merges would be nice
14:03:13 <fluffypony> xmrscott[m]: I don't believe so - not a bad idea to have additional backups
15:01:01 <chaser[m]> something I've been thinking about: even if Rucknium's OSPEAD would be funded today, it's still at best 4 months from making it into wallets. that's a lot of time.
15:01:20 <chaser[m]> in the meantime, lots of people continue to use Monero without knowing that the decoy selection algo has a known weakness. people who trust Monero with their safety and their lives.
15:01:58 <chaser[m]> Rucknium told me that with a month of concentrated effort they can devise a short-term fix that would improve decoy selection a lot before OSPEAD is completed.
15:02:35 <chaser[m]> what do you think?
15:02:59 <chaser[m]> I'd really like to see such a short-term change because the sooner the loss of privacy decreases, the better.
15:04:19 <moneromooo> With this kind of argument, you'd never do anything. Do you think Rucknium[m]'s change will make it so it's 100% good ? Of course not. Did anyone beore think it was 100% good ? Of course not.
15:04:44 <moneromooo> It's a neverending work to improve, with a never reachable asymptote.
15:05:26 <moneromooo> Actually, "[d]id anyone be[f]ore think it was 100% good" is not "no". Some did. But some will also think so after any change.
15:06:59 <moneromooo> This is the problem. This stupid reduction to a two state "it's perfect" and "it's broken", encouraged by the hype/noise bullshit.
15:09:17 <chaser[m]> you imply that the goodness of the algo is subjective. I agree the improvement is asymptotic, but as far as I understand, each discovered weakness can be objectively ascertained and give a reason for improving the algorithm
15:09:22 <moneromooo> If you have a short term change that makes it better, do it.
15:09:36 <chaser[m]> no, I don't think at all that it's a binary good/bad.
15:09:47 <moneromooo> If you have a short term change that's just "do something because it's something and hype/noise says we have to do something", screw this.
15:10:18 <moneromooo> You may not, but this kind of thinking encourages people to.
15:14:01 <chaser[m]> "do something because it's something and hype/noise" -- I can't know for sure because I haven't seen the internal report Rucknium wrote. but based on the CCS proposal and the citations in it, it seems to me to be more than just hype/noise.
15:14:50 <chaser[m]> "If you have a short term change that makes it better, do it." well, I don't have, but they said they do.
15:47:54 <luigi1111> a little of both
15:48:02 <luigi1111> ot maybe more than a little
15:48:16 <luigi1111> selsta: coming soon to a repo near you
17:02:04 <Rucknium[m]> Unless I am mistaken, a dev meeting is supposed to start now:
17:02:04 <Rucknium[m]> https://github.com/monero-project/meta/issues/617
17:03:45 <rbrunner> Yes, 17:00 UTC
17:04:59 <rbrunner> Just the two of us? Hard to believe :)
17:05:51 <sech1> I'm here and watching :)
17:06:15 <rbrunner> Zcash is much better than Monero!!! (That will get them out of hiding)
17:06:46 <UkoeHB> hi
17:07:01 <vtnerd_> Hi
17:07:41 <jberman[m]> hello :)
17:07:42 <UkoeHB> um since no one else bothers to do this, I guess I can jump in as chairman...?
17:08:04 <rbrunner> Splendid!
17:09:25 <UkoeHB> 2. Updates: any devs want to let us know what they are developing?
17:10:06 <UkoeHB> I continue to work on Seraphis PoC on my end. I am in the boring part where I code all the things I already figured out...
17:11:58 <jberman[m]> Wrote a PoC for a wallet-side binning algorithm here: https://github.com/monero-project/research-lab/issues/88
17:12:36 <UkoeHB> Thanks, I still haven't looked at this yet
17:13:37 <UkoeHB> Maybe no other dev work is being done? Do we even need a meeting? lol
17:13:57 <vtnerd_> I am going to push out my proposal for p2p encryption, and I am nearing completion on integrating the monero-lws serialization scheme into epee (as per selsta suggestion)
17:14:45 <UkoeHB> Cool thanks vtnerd_ 
17:15:07 <UkoeHB> Is that for p2p encryption between nodes, client to node?
17:15:14 <Rucknium[m]> I continue to work on OSPEAD. I wrote out a fairly precise mathematical description of a key part of it recently. I'm not sure that it quite qualifies as "dev" work, however, so I'm not sure whether it should be mentioned here.
17:15:33 <Rucknium[m]> There is also a defined agenda on the GitHub issue for the meeting.
17:15:41 <vtnerd_> yes, its to protect the p2p traffic (as opposed to the rpc traffic which is encrypted)
17:16:05 <fluffypony> vtnerd_: is the encryption opportunistic?
17:16:07 <vtnerd_> the p2p is tricky because authentication isn't realistic, and some community members asked about the Noise protocol (instead of TLS)
17:16:13 <vtnerd_> yes
17:16:22 <vtnerd_> there'll be options to specify authenticatio though
17:16:29 <fluffypony> ok cool 
17:16:35 <fluffypony> maybe in a few years we can make it mandatory
17:16:47 <vtnerd_> so node operators can specifcy a priority node, with auth
17:17:27 <fluffypony> maybe a simple auth could just be specifying a pubkey for that node
17:17:34 <vtnerd_> part of the spec was on making sure that it was "hidden" from the perspective of the ISP (even though the ISP could probably guess due to frequency of traffic)
17:17:38 <vtnerd_> yup
17:17:45 <fluffypony> sorta like .ssh/known_hosts
17:19:04 <vtnerd_> yeah close, but after some thought its mainly goign to be opportunistic because of the dynamic IP issue - auth is just tough in this p2p environment
17:19:26 <vtnerd_> and I think there'll be some encouragement to get the bootstrap nodes authed
17:20:31 <UkoeHB> Is selsta around to give us an update/overview of the dev cycle for next hardfork? Or anyone else who knows about it?
17:21:06 <UkoeHB> There are several pieces (in the agenda) waiting on review: fee PR, multisig PR
17:21:22 <UkoeHB> Ringsize increase
17:21:33 <vtnerd_> yeah, I need to the fee PR review, as promised
17:21:46 <vtnerd_> I should likely look at the multisig one too
17:22:30 <UkoeHB> I think h4sh3d mentioned he would look at multisig as well (maybe kayabaNerve too?)
17:23:49 <UkoeHB> We can try to reach a 'decision' about the ring size at next MRL meeting. Maybe a poll... lmao
17:23:51 <kayabaNerve> UkoeHB: Thanks for the info. I debated saying this back then, yet I was already a few hours past and didn't want to bother chat.
17:24:36 <kayabaNerve> I was solely interested in m-of-n multisigs and have an interest in ensuring they're preserved into the new protocol. I am absolutely not looking into developing them under the new system nor verifying the accuracy of the described potential system beyond pass/fail.
17:24:47 <h4sh3d> I mentioned that I’ll do a review, but also mentioned that I don’t what it to stop others to do it…
17:24:59 <kayabaNerve> While I may at some point want to be the cryptographer, I don't believe I have the skills.
17:25:06 <UkoeHB> Yeah I just meant from the review pov
17:25:48 <h4sh3d> *want it to stop others
17:26:03 <kayabaNerve> Got it. I solely want to verify inclusion m-of-n, and then I may write up a PoC depending on complexity. I'd love to do more, yet I'm no where near required cryptographic knowledge :p Just wanted to be absolutely clear
17:26:17 <UkoeHB> The more eyes, the better :). This is the first big piece of code with any real-world significance I have ever written.
17:28:13 <UkoeHB> Otherwise, it seems BP+ is ready to go for hardfork. The agenda mentions BP+ storage - has there been any interest in merging that feature?
17:29:35 <UkoeHB> Maybe can evaluate a potential PR once BP+ is merged. I am slightly concerned it would entail a large amount of code for fairly small gain. Not a huge concern.
17:32:08 <UkoeHB> Anyone have anything else to say? Otherwise we can call it quits. Attendance seems lacking...
17:33:26 <sech1> "9. Setting date for network upgrade." are we going to discuss this?
17:33:35 <sech1> or at least the next point release date?
17:33:39 <Rucknium[m]> Are we closer to the hardfork than we were two weeks ago? It seems yes, incrementally.
17:34:05 <UkoeHB> sech1: is there anyone involved in release planning actually here?
17:34:27 <rbrunner> I think that's pretty much selsta's show ...
17:34:52 <rbrunner> At least they are the one keeping the overview :)
17:36:12 <rbrunner> I also wonder whether we will get a new release branch, off master
17:36:46 <sech1> that's the necessary first step before hardfork :)
17:38:27 <rbrunner> If nothing else, I have a little varia, but maybe nobody here now knows that: What happened to this? Did is sizzle out, so to say?
17:38:28 <rbrunner> https://ccs.getmonero.org/proposals/anon-perfect-peer-to-peer-protocol.html
17:38:39 <UkoeHB> I wonder if I should try to make another multiisig PR to fix the Wagner attack with the FROST technique, before release. It was easy to fix in my seraphis multisig implementation (<200 lines?). But, there is more delay to review and so on.
17:39:20 <dEBRUYNE> rbrunner: The author is still regularly submitting patches to the Monero Github
17:39:39 <dEBRUYNE> e.g. -> https://github.com/monero-project/monero/pull/7999
17:39:41 <rbrunner> Ah, ok, so many small ones, not a big bang?
17:41:10 <wfaressuissia> "I wonder if I should try to make another multiisig PR to fix ..." do it too, otherwise what's the point of partialy fixed multisig ?
17:41:11 <coinstudent2048[> kayabaNerve: I can guide a bit for the math of multisig as described in ZtM2, but I do not know C++ and the structure of Monero code. I cannot build right now because my laptop is dead and I am currently using someone else's 😭.
17:41:34 <kayabaNerve> I actually don't know what the multisig discussion is about :p
17:41:39 <wfaressuissia> "https://github.com/monero-project/research-lab/issues/67" considering that is was mentioned long time ago
17:41:41 <kayabaNerve> It's why I said so much when I was summoned
17:41:45 <UkoeHB> wfaressuissia: well the address attacks are a lot easier to exploit. I think you need a multisig tx with >=9 inputs to exploit wagner.
17:41:58 <kayabaNerve> I figured it was about the Triptych work and immediately wanted to distance myself from any expectations
17:42:08 <kayabaNerve> UkoeHB makes it sound like a C++ Monero PR
17:42:26 <UkoeHB> kayabaNerve: it is unrelated to Triptych
17:42:34 <kayabaNerve> I would love more info :)
17:42:40 <wfaressuissia> " I think you need a multisig tx with >=9 in ..." then 16 should be reduced without fix for Wagner's attack
17:42:54 <UkoeHB> it is 16 output limit, infinite inputs
17:43:32 <kayabaNerve> Oh
17:43:38 <wfaressuissia> `constexpr std::uint32_t MULTISIG_MAX_SIGNERS{16};` I'm about this limit
17:43:53 <UkoeHB> the number of signers is unrelated (mostly)
17:44:07 <rbrunner> Yes, that's the number of outputs. You can easily construct 100-input txs
17:44:20 <kayabaNerve> Considering no one currently uses m-of-n, though I do personally insist it's preserved as I know how it can be used, I'm surprised to hear this got attention
17:44:38 <kayabaNerve> I'm also surprised to hear it has that limit which seems arbitrary (I do recognize it's 2^4)
17:45:08 <rbrunner> Well, 2/3 is very much in use
17:45:09 <dEBRUYNE> kayabaNerve: It's this PR -> https://github.com/monero-project/monero/pull/7877
17:45:20 <UkoeHB> I introduced the limit of 16 in my multisig PR because of combinatorial explosion during address generation with the MRL-0009 address gen approach.
17:45:32 <wfaressuissia> "the number of signers is unrelated (mostly)" number of participants in multisig is unrelated ?
17:45:38 <kayabaNerve> rbrunner: Good to know. I saw a Reddit post about a year ago where no one chimed in. I would've guessed the CCS used it though
17:45:40 <UkoeHB> unrelated to Wagner attack
17:45:41 <wfaressuissia> * max number ...
17:45:53 <kayabaNerve> And what's the Wagner attack?
17:46:07 <kayabaNerve> I'm very late to this party yet would love to learn more
17:46:13 <kayabaNerve> I do know of FROST though
17:46:17 <UkoeHB> It's actually Drijvers attack: https://github.com/UkoeHB/drijvers-multisig-tech-note
17:47:24 <rbrunner> Ah, now I see, MULTISIG_MAX_SIGNERS. Of course.
17:47:33 <UkoeHB> FROST address generation is more efficient if you have `N - M > 1`, so it could allow unlimited signers. But, I am not going to implement it.
17:48:15 <coinstudent2048[> UkoeHB: So we stick with commit-and-reveal?
17:48:34 <UkoeHB> coinstudent2048[: what do you mean? we don't have commit-and-reveal now
17:48:52 <UkoeHB> binonce signing is much easier to implement to mitigate Drijvers
17:48:52 <coinstudent2048[> sorry, that's address gen. never mind
17:50:23 <coinstudent2048[> UkoeHB: I never saw "address generation" so I thought you'll not implement FROST. sorry
17:50:25 <kayabaNerve> How does Drijvers attack work given it seems to rely on generating the same scalar for two different hashed values?
17:50:33 <UkoeHB> It would be helpful to me if someone else could implement the Drijvers fix for current Monero multisig. Can look at my demo here: https://github.com/UkoeHB/monero/blob/seraphis_perf/src/mock_tx/seraphis_composition_proof.cpp.
17:50:58 <UkoeHB> kayabaNerve: I wrote that tech note to explain my understanding.
17:52:16 <rbrunner> Is any of this stuff that only works if all signers are on the same release level? If yes, a hardfork would be a really good time to introduce it.
17:52:34 <rbrunner> Because only a hardfork forces update
17:53:23 <UkoeHB> rbrunner: you can also just change message serialization, so if two versions try to interact they will error out - forcing lower version to update
17:53:59 <rbrunner> Ok, yes. But might to lead to bad UX, right?
17:54:12 <UkoeHB> yep
17:55:04 <wfaressuissia> It's expected that parties in multisig can force each other to update client
17:56:17 <rbrunner> Still, a hardfork and after that a clean slate release-wise would be very nice for multisig. It's complicated enough as it is.
17:56:38 <rbrunner> Thus maybe not put too much into it now, IMHO.
17:56:52 <UkoeHB> one engineering aspect is the need to clear cached partial-tx stuff when updating
17:58:18 <UkoeHB> rbrunner: do you mean delay the Drijvers solution until after hardfork?
17:58:45 <rbrunner> Yes. Or maybe even delay until Seraphis, who knows. Depends how things develop.
17:59:34 <rbrunner> But I can't judge severity, I have to confess.
18:00:03 <rbrunner> Just thinking about the release schedule, and how to hardfork relatively early, to get bigger rings.
18:00:21 <UkoeHB> I will have more time to write a PR after Seraphis PoC is settled and paper is done. Maybe we can target the release after hardfork, unless someone wants to step up to the plate.
18:02:47 <vtnerd_> UkoeHB - the last link you posted doesn't work
18:03:18 <UkoeHB> https://github.com/UkoeHB/monero/blob/seraphis_perf/src/mock_tx/seraphis_composition_proof.cpp
18:03:20 <UkoeHB> period at end?
18:04:23 <wfaressuissia> "... I think you need a multisig tx with >=9 inputs to exploit wagner." is it your own hypothesis or it's proved somewhere already?
18:04:36 <vtnerd_> ah yeah obvious
18:04:36 <UkoeHB> `unit_tests/seraphis` has a demo of multisig signing
18:04:49 <UkoeHB> in that branch
18:05:35 <UkoeHB> wfaressuissia: these guys say 9: https://eprint.iacr.org/2020/945 (that's why I said 'I think')
18:07:21 <rbrunner> Not sure I understand: Stay under 9 inputs, problem solved?
18:09:31 <UkoeHB> The Drijvers attack requires concurrent signing attempts. The easiest way to get concurrent is multiple inputs (multiple parallel tx more rare/difficult).
18:09:57 <UkoeHB> Supposedly you need at least 9 concurrent attempts for the attack to be efficient.
18:10:58 <rbrunner> Sounds weird :)
18:12:26 <wfaressuissia> lambda = upper(log(256, 2))  == 8 ?
18:12:27 <wfaressuissia> why 9 ?
18:12:36 <UkoeHB> don't ask me lol
18:13:16 <UkoeHB> It's in their conclusion
18:13:47 <wfaressuissia> polynomial for l > lambda, ok
18:17:44 <UkoeHB> Btw there is a bounty on the Drijvers attack (https://github.com/haveno-dex/haveno/issues/103), maybe that can motivate someone :)
18:18:11 <UkoeHB> Anyway, I think we can end the meeting here. Thanks for attending everyone
18:27:45 <luigi1111> thanks for running koe
18:34:09 <hyc> +