-
selsta
core team has access to the backups
-
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?
-
selsta
BigmenPixel[m]: what do you want to do exactly?
-
selsta
as long as it compiles with protobuf enabled it should be fine
-
BigmenPixel[m]
<selsta> "BigmenPixel: what do you want to..." <- Choosing what is best to use for flatpak build
-
BigmenPixel[m]
It seems to be compiled with protobuf cpp, but I can't check it, because there is no hardware wallet
-
selsta
-
selsta
so should be fine
-
BigmenPixel[m]
selsta: thanks
-
selsta
are you building GUI or CLI?
-
BigmenPixel[m]
selsta: GUI
-
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
-
selsta
then try to create a wallet, it will error out
-
selsta
confirm if your flatpak app shows fhe exact same error
-
BigmenPixel[m]
selsta: Ok, I'm going to try now
-
BigmenPixel[m]
it looks like it works
-
BigmenPixel[m]
* it works in a flatpak environment
-
BigmenPixel[m]
in the sense that an error is shown that there is no device
-
selsta
ok, if it's the same error then it should be good
-
mj-xmr[m]
.merges
-
xmr-pr
7798 7799 7804 7808 7859 7861 7867 7868 7869 7870 7876 7971 7993 7994
-
selsta
merges would be nice
-
fluffypony
xmrscott[m]: I don't believe so - not a bad idea to have additional backups
-
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.
-
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.
-
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.
-
chaser[m]
what do you think?
-
chaser[m]
I'd really like to see such a short-term change because the sooner the loss of privacy decreases, the better.
-
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.
-
moneromooo
It's a neverending work to improve, with a never reachable asymptote.
-
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.
-
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.
-
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
-
moneromooo
If you have a short term change that makes it better, do it.
-
chaser[m]
no, I don't think at all that it's a binary good/bad.
-
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.
-
moneromooo
You may not, but this kind of thinking encourages people to.
-
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.
-
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.
-
luigi1111
a little of both
-
luigi1111
ot maybe more than a little
-
luigi1111
selsta: coming soon to a repo near you
-
Rucknium[m]
Unless I am mistaken, a dev meeting is supposed to start now:
-
Rucknium[m]
-
rbrunner
Yes, 17:00 UTC
-
rbrunner
Just the two of us? Hard to believe :)
-
sech1
I'm here and watching :)
-
rbrunner
Zcash is much better than Monero!!! (That will get them out of hiding)
-
UkoeHB
hi
-
vtnerd_
Hi
-
jberman[m]
hello :)
-
UkoeHB
um since no one else bothers to do this, I guess I can jump in as chairman...?
-
rbrunner
Splendid!
-
UkoeHB
2. Updates: any devs want to let us know what they are developing?
-
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...
-
jberman[m]
Wrote a PoC for a wallet-side binning algorithm here:
monero-project/research-lab #88
-
UkoeHB
Thanks, I still haven't looked at this yet
-
UkoeHB
Maybe no other dev work is being done? Do we even need a meeting? lol
-
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)
-
UkoeHB
Cool thanks vtnerd_
-
UkoeHB
Is that for p2p encryption between nodes, client to node?
-
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.
-
Rucknium[m]
There is also a defined agenda on the GitHub issue for the meeting.
-
vtnerd_
yes, its to protect the p2p traffic (as opposed to the rpc traffic which is encrypted)
-
fluffypony
vtnerd_: is the encryption opportunistic?
-
vtnerd_
the p2p is tricky because authentication isn't realistic, and some community members asked about the Noise protocol (instead of TLS)
-
vtnerd_
yes
-
vtnerd_
there'll be options to specify authenticatio though
-
fluffypony
ok cool
-
fluffypony
maybe in a few years we can make it mandatory
-
vtnerd_
so node operators can specifcy a priority node, with auth
-
fluffypony
maybe a simple auth could just be specifying a pubkey for that node
-
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)
-
vtnerd_
yup
-
fluffypony
sorta like .ssh/known_hosts
-
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
-
vtnerd_
and I think there'll be some encouragement to get the bootstrap nodes authed
-
UkoeHB
Is selsta around to give us an update/overview of the dev cycle for next hardfork? Or anyone else who knows about it?
-
UkoeHB
There are several pieces (in the agenda) waiting on review: fee PR, multisig PR
-
UkoeHB
Ringsize increase
-
vtnerd_
yeah, I need to the fee PR review, as promised
-
vtnerd_
I should likely look at the multisig one too
-
UkoeHB
I think h4sh3d mentioned he would look at multisig as well (maybe kayabaNerve too?)
-
UkoeHB
We can try to reach a 'decision' about the ring size at next MRL meeting. Maybe a poll... lmao
-
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.
-
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.
-
h4sh3d
I mentioned that I’ll do a review, but also mentioned that I don’t what it to stop others to do it…
-
kayabaNerve
While I may at some point want to be the cryptographer, I don't believe I have the skills.
-
UkoeHB
Yeah I just meant from the review pov
-
h4sh3d
*want it to stop others
-
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
-
UkoeHB
The more eyes, the better :). This is the first big piece of code with any real-world significance I have ever written.
-
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?
-
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.
-
UkoeHB
Anyone have anything else to say? Otherwise we can call it quits. Attendance seems lacking...
-
sech1
"9. Setting date for network upgrade." are we going to discuss this?
-
sech1
or at least the next point release date?
-
Rucknium[m]
Are we closer to the hardfork than we were two weeks ago? It seems yes, incrementally.
-
UkoeHB
sech1: is there anyone involved in release planning actually here?
-
rbrunner
I think that's pretty much selsta's show ...
-
rbrunner
At least they are the one keeping the overview :)
-
rbrunner
I also wonder whether we will get a new release branch, off master
-
sech1
that's the necessary first step before hardfork :)
-
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?
-
rbrunner
-
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.
-
dEBRUYNE
rbrunner: The author is still regularly submitting patches to the Monero Github
-
dEBRUYNE
-
rbrunner
Ah, ok, so many small ones, not a big bang?
-
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 ?
-
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 😭.
-
kayabaNerve
I actually don't know what the multisig discussion is about :p
-
wfaressuissia
"
monero-project/research-lab #67" considering that is was mentioned long time ago
-
kayabaNerve
It's why I said so much when I was summoned
-
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.
-
kayabaNerve
I figured it was about the Triptych work and immediately wanted to distance myself from any expectations
-
kayabaNerve
UkoeHB makes it sound like a C++ Monero PR
-
UkoeHB
kayabaNerve: it is unrelated to Triptych
-
kayabaNerve
I would love more info :)
-
wfaressuissia
" I think you need a multisig tx with >=9 in ..." then 16 should be reduced without fix for Wagner's attack
-
UkoeHB
it is 16 output limit, infinite inputs
-
kayabaNerve
Oh
-
wfaressuissia
`constexpr std::uint32_t MULTISIG_MAX_SIGNERS{16};` I'm about this limit
-
UkoeHB
the number of signers is unrelated (mostly)
-
rbrunner
Yes, that's the number of outputs. You can easily construct 100-input txs
-
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
-
kayabaNerve
I'm also surprised to hear it has that limit which seems arbitrary (I do recognize it's 2^4)
-
rbrunner
Well, 2/3 is very much in use
-
dEBRUYNE
kayabaNerve: It's this PR ->
monero-project/monero #7877
-
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.
-
wfaressuissia
"the number of signers is unrelated (mostly)" number of participants in multisig is unrelated ?
-
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
-
UkoeHB
unrelated to Wagner attack
-
wfaressuissia
* max number ...
-
kayabaNerve
And what's the Wagner attack?
-
kayabaNerve
I'm very late to this party yet would love to learn more
-
kayabaNerve
I do know of FROST though
-
UkoeHB
-
rbrunner
Ah, now I see, MULTISIG_MAX_SIGNERS. Of course.
-
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.
-
coinstudent2048[
UkoeHB: So we stick with commit-and-reveal?
-
UkoeHB
coinstudent2048[: what do you mean? we don't have commit-and-reveal now
-
UkoeHB
binonce signing is much easier to implement to mitigate Drijvers
-
coinstudent2048[
sorry, that's address gen. never mind
-
coinstudent2048[
UkoeHB: I never saw "address generation" so I thought you'll not implement FROST. sorry
-
kayabaNerve
How does Drijvers attack work given it seems to rely on generating the same scalar for two different hashed values?
-
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:
github.com/UkoeHB/monero/blob/serap…k_tx/seraphis_composition_proof.cpp.
-
UkoeHB
kayabaNerve: I wrote that tech note to explain my understanding.
-
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.
-
rbrunner
Because only a hardfork forces update
-
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
-
rbrunner
Ok, yes. But might to lead to bad UX, right?
-
UkoeHB
yep
-
wfaressuissia
It's expected that parties in multisig can force each other to update client
-
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.
-
rbrunner
Thus maybe not put too much into it now, IMHO.
-
UkoeHB
one engineering aspect is the need to clear cached partial-tx stuff when updating
-
UkoeHB
rbrunner: do you mean delay the Drijvers solution until after hardfork?
-
rbrunner
Yes. Or maybe even delay until Seraphis, who knows. Depends how things develop.
-
rbrunner
But I can't judge severity, I have to confess.
-
rbrunner
Just thinking about the release schedule, and how to hardfork relatively early, to get bigger rings.
-
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.
-
vtnerd_
UkoeHB - the last link you posted doesn't work
-
UkoeHB
-
UkoeHB
period at end?
-
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?
-
vtnerd_
ah yeah obvious
-
UkoeHB
`unit_tests/seraphis` has a demo of multisig signing
-
UkoeHB
in that branch
-
UkoeHB
wfaressuissia: these guys say 9:
eprint.iacr.org/2020/945 (that's why I said 'I think')
-
rbrunner
Not sure I understand: Stay under 9 inputs, problem solved?
-
UkoeHB
The Drijvers attack requires concurrent signing attempts. The easiest way to get concurrent is multiple inputs (multiple parallel tx more rare/difficult).
-
UkoeHB
Supposedly you need at least 9 concurrent attempts for the attack to be efficient.
-
rbrunner
Sounds weird :)
-
wfaressuissia
lambda = upper(log(256, 2)) == 8 ?
-
wfaressuissia
why 9 ?
-
UkoeHB
don't ask me lol
-
UkoeHB
It's in their conclusion
-
wfaressuissia
polynomial for l > lambda, ok
-
UkoeHB
Btw there is a bounty on the Drijvers attack (
haveno-dex/haveno #103), maybe that can motivate someone :)
-
UkoeHB
Anyway, I think we can end the meeting here. Thanks for attending everyone
-
luigi1111
thanks for running koe
-
hyc
+