-
selsta
anyone want to do some basic testing with release-v0.17 branch? otherwise we will tag tomorrow
-
hyc
.merges
-
xmr-pr
7910 7977
-
hyc
still waiting for those two to go in. then everyone can test the branch easily
-
hyc
everyone, anyone, whatever
-
dEBRUYNE
tevador: Thanks for clarifying
-
woodser[m]
hi Ian Niculescu :)
-
ErCiccione
Found a bug when sending a transfer from a multisignature wallet:
monero-project/monero #8091
-
monerobull[m]
-
monerobull[m]
There will be a meeting in this chat in about 2 hours.
-
hyc
~12 minutes to meeting now?
-
Rucknium[m]
Yes
-
disclosure-bot[m
Greetings. If any meeting participants have a potential conflict of interest, please disclose it now.
-
monerobull[m]
A what
-
selsta
hi
-
hyc
hey
-
Halver[m]
hi
-
dont_thread_on_m
o7
-
tevador
o/
-
Rucknium[m]
Present
-
monerobull[m]
Hello, the meeting starts now. Main goal for today is deciding on a fork-date for .18 :)
-
selsta
I think there is a discussion about it on Github, right?
-
selsta
-
monerobull[m]
Yes, everything should be linked here
monero-project/meta #633
-
tevador
15th March 2022
-
selsta
So basically we want to release 1 month before, so 15 Feb 2022
-
selsta
Code wise everything should be ready in January
-
selsta
so that we have 1 month for last minute bugs that pop up
-
selsta
that worked quite well for the last hardforks
-
monerobull[m]
that seems reasonable for the features that currently are on the list for .18, does anyone have any objections?
-
hyc
sounds good
-
monerobull[m]
We will come back to this point later in case someone joins the discussion late
-
monerobull[m]
Alright, 2. Fee changes, is there discussing to do on this topic?
-
selsta
not from my side but maybe others have something to add
-
monerobull[m]
ok, moving on, Decoy selection algorithm changes
-
selsta
Rucknium[m] ^
-
monerobull[m]
jberman: anything on this topic?
-
Rucknium[m]
I clarified here that decoy selection doesn't need to go into a hard fork. OSPEAD will in fact leverage the discontinuity created by the 11 --> 16 ring size for statistical purposes:
-
Rucknium[m]
-
jberman[m]
Binning is next up to work on on my end. Planning to spend more time fleshing out parameter selection (e.g. how many blocks per bin). Would be nice to get feedback on the general approach laid out in this issue:
monero-project/research-lab #88
-
Rucknium[m]
I think binning should be vetted by a statisticians before it's implemented in production code. We audit our cryptography. Our statistics should be similarly audited.
-
jberman[m]
We had discussed in the past targeting to release binning in the hard fork, to maximize chances everyone uses the same algo
-
monerobull[m]
on the topic of binning, deprecation of timelocks has officially been decided on, correct?
-
jberman[m]
seems it's fair to say there is a rough consensus to deprecate imo. It's not a strict requirement that it is deprecated for the binning algo proposed though
-
Rucknium[m]
Another issue is that isthmus found that tens of thousands of rings have an effective ring size of one due to the fact that services or wallets used "cached" outputs as decoys. In fact the current estimate is that 250,000 rings do this.
-
Rucknium[m]
I discuss the issue here, along with a rough proposed solution:
-
Rucknium[m]
-
hyc
they used the same set of outputs for multiple txns?
-
jberman[m]
I recall looking at the tx and seeing many rings using the same subset of outputs, but not the same rings entirely (which isn't possible to do for 250,000 rings)
-
Rucknium[m]
hyc: hyc: Yes. So M-1 outputs were all the same. Just the M'th was different, which is clearly the real spend.
-
Rucknium[m]
In effect, it's a loophole for the consensus rule of having exactly M ring members.
-
hyc
ugh
-
Halver[m]
hyc: quote isthmus : 65k ring sigs with effective ring size = 1.
-
jberman[m]
hash-based collisions wouldn't work as was being discussed earlier, this would be overly burdensome to check for I think
-
tevador
Yes, this detection of duplicates would be quite difficult to implement.
-
Rucknium[m]
Halver: isthmus has given me a back-of-the-envelope estimate that the true number may be about 250k, not 65k.
-
jberman[m]
hash-based collisions wouldn't work because they're not identical rings (bc of the real outputs)
-
hyc
right so what's the proposed solution? keeping a map of the last N rings?
-
Rucknium[m]
This was just revealed a few days ago. I'm not sure about how large the computational burdens for any solution may be. This is a delivery of the problem from MRL to -dev. You're welcome :(
-
hyc
outputs are referenced by an integer index, not their hash
-
hyc
so the first thing that comes to mind is turning a ring into a bitmap
-
tevador
It would need a huge hashtable and each new output would add N items into the hashtable where N is the ring size (all possible real spends).
-
UkoeHB
This can be more-or-less solved with deterministic rings.
-
tevador
^this is a better solution
-
Rucknium[m]
What do you mean by deterministic rings?
-
UkoeHB
using a public seed to generate rings, instead of inserting private entropy to an rng
-
hyc
i don't understand how that works to keep the real output hidden
-
Rucknium[m]
Interesting. And the real spend would be hidden by some sort of hash function that combines the real spend and the public seed, and spits out the set of all ring members?
-
tevador
the sender of the TX would be able to fix only a single output location (the real spend), the rest woule be random
-
UkoeHB
You get e.g. 11 pseudo-random numbers from the public seed, randomly select one of them, take the delta between that random selectee and your real output, then rotate all the generated numbers by that offset.
-
hyc
then you're assuming the internal state of the RNG can't be reversed
-
tevador
it works even if the RNG can be reversed, see for example:
github.com/tevador/igamma
-
Rucknium[m]
UkoeHB: I don't yet understand the words you are using. I will try to understand how this process cannot be reversed.
-
UkoeHB
It has already been discussed here:
monero-project/research-lab #84
-
UkoeHB
The point is it solves ring-reuse because if you tie the input seed to tx data, including key images, then seeds are always unique.
-
UkoeHB
In any case, what's the next agenda item?
-
monerobull[m]
Ringsize increase, i assume consensus has been reachend
-
tevador
16?
-
monerobull[m]
yes
-
Rucknium[m]
I see. I will read into it. Deterministic decoy selection is probably too novel to include in this hard fork.
-
UkoeHB
I think the concerns raised about verification cost increases haven't really been addressed:
monero-project/research-lab #79
-
monerobull[m]
ill remove ringsize increase as an item for the next meeting then
-
monerobull[m]
UkoeHB: or maybe i wont just yet
-
tevador
what is the verification time and tx size cost of ringsize=16?
-
UkoeHB
Has anyone made any effort to examine the upper bounds of tx throughput of the network?
-
UkoeHB
This topic was brought up a couple months ago and people said 'wow cool idea', but has anything been done?
-
Rucknium[m]
Ring size was discussed in -dev. -dev push it to MRL. MRL said, 16, basically. We can re-open the issue for discussion, I guess.
-
Rucknium[m]
What do you mean by "upper bounds of tx throughput of the network"?
-
UkoeHB
I mean that literally ?
-
UkoeHB
How much tx throughput can nodes handle?
-
Rucknium[m]
mj-xmr with others is working on generating stats about tx characteristics like input and output numbers to map onto UkoeHB 's work on the Seraphis performance tests.
-
selsta
I assume it will depend on node specs and network speed
-
UkoeHB
Rucknium[m]: I see, yes that might be the right direction.
-
rbrunner
Well, can we do anything at all about larger verification costs of ringsize 16? Seems to me we have to just "eat" somewhat longer syncs for enhanced privacy
-
hyc
should prob benchmark on "typical" PC of 2020 vintage or so. assuming 3-5yr lifetime of most PCs
-
monerobull[m]
l i7 2600k quad core roughly 400 TPS per core.
-
monerobull[m]
limiting factor would be bandwidth
-
UkoeHB
> Seems to me we have to just "eat" somewhat longer syncs for enhanced privacy
-
UkoeHB
Yes, but it would be useful to know exactly when nodes have to shut down.
-
Rucknium[m]
rbrunner: I think if we can eat the cost, we should do so. Privacy threats are increasing every day. I don't think I need to enumerate them here.
-
rbrunner
Agreed, that why I was wondering what concerns we could probably address, as UkoeHB asked
-
selsta
We have to live with increased verification anyway once we move to Seraphis
-
UkoeHB
Sure, but the same problem would arise for Seraphis: what ring size is acceptable, that won't kill the network?
-
tevador
Also worth noting that CPU speed increases faster than network bandwidth, so verification time is a somewhat smaller problem than tx size.
-
monerobull[m]
anything to add to this topic?
-
UkoeHB
I think verification time can also be a problem if synching from scratch. If synching a new copy takes e.g. 1 month, that is a bit concerning.
-
rbrunner
But we should be very, very far from that, right?
-
UkoeHB
Revalidating from scratch without checkpoints*
-
UkoeHB
Ok, but when does that happen? When does that happen after increasing ring size? We are discussing what things look like, without any light.
-
tevador
I think the initial sync is more I/O bound than CPU bound at the moment
-
rbrunner
Agreed, it would be nice to hold hard numbers
-
Rucknium[m]
Who is going to take this on? There's got to be some people in the broader Monero community who love running benchmarks.
-
ErCiccione
Maybe better postpone the decision for when there will be more concrete numbers? This is something that must not be rushed. Even worth delaying the hard fork if there are doubts IMO
-
hyc
... sorry to go offtopic - my gitian build of release-v0.17 failed on Mac, looks like it's missing -std=c++11 build flag
-
selsta
hyc: will check
-
selsta
we use c++14 so don't think adding -std=c++11 is correct
-
hyc
ok, can look into this more after meeting
-
selsta
also we set the c++ version with cmake so it shouldn't be necessary to set manually
-
selsta
re verification: the question is, is the slight ring size bump worth the increased verification time without seraphis
-
monerobull[m]
@idk are you here?
-
monerobull[m]
selsta: the ring size bump was short-term to be compatible with binning, no?
-
crypto_grampy[m]
Would be fun to have a sort of xmrig style benchmarking for monerod that anyone can run/submit processor benchmarks. Not sure what all the metrics would be
-
UkoeHB
the sentiment was more like 'seems like a good idea to increase ring size periodically'
-
jberman[m]
compatibility with binning was 1 reason for going with an even 16, not necessarily for increasing by the exact amount proposed
-
ErCiccione
FWIW i'm for being more conservative when it comes to ring size increases. We should also keep in mind that Monero's UX is far from great and increasing verification times and size should be considered very carefully
-
tevador
another option is to increase to 12, which should also support binning
-
Rucknium[m]
crypto_grampy: That's a great idea. Get the community involved in dev planning decisions by providing data in a decentralized way.
-
jberman[m]
I think I can take on this research to arrive at throughput limits targeting a specific machine pre-hard fork. I'm kinda putting lots on my plate, and would cede it to someone else who comes along who wants to take it. But if no one else comes along, I'll do it
-
hyc
if there's no significant improvement in resistance to flooding attacks there's no point
-
UkoeHB
jberman[m]: I think you should focus on your current stuff. Someone else should take this.
-
ErCiccione
^ exactly. If it's a significant improvement, let's see some data. Otherwise a smaller increase (if an increase is necessary at all) would be better IMO
-
ErCiccione
In any case appears to me that we need more data before being able to take an informed decision (unless i'm missing something)
-
hyc
definitely, anyone can run benchmarks, no programming skills required. someone else in the community should step up for that
-
Rucknium[m]
Isn't 11 --> 16 a significant increase to resistance to flooding attacks? It would pretty much kill them, probably?
-
rbrunner
Hmm, this GitHub issue seems to have lots and lots of number already, no?
monero-project/research-lab #79
-
rbrunner
I think 16 is markedly better
-
hyc
agreed
-
hyc
but 11 -> 12 seems quite arbitrary
-
rbrunner
Otherwise you would think the proposal would be dead for a long time already ...
-
hyc
and "seems like a good idea to increase ringsize periodically" is just baseless
-
ErCiccione
not a big fan of the idea as well
-
monerobull[m]
we already have a decent amount of data suggesting 16 is the most reasonable number
-
Rucknium[m]
Very back-of-the-envelope: if you want to control 50% of outputs in a one-month period, say, then with the current size of 11 you need to increase tx volume by 5 times, or 500%. With 16 it would be increasing volume by 8 times, or 800%.
-
ErCiccione
> Ring size 15/16/17 will mean verification time increases of 36%/45%/55%.
-
crypto_grampy[m]
Maybe sgp_ @sgp_:matrix.org can speak to it
-
monerobull[m]
verification only effects initial node setup, right?
-
ErCiccione
45% is quite a lot
-
rbrunner
The cost of doing business in a hostile world?
-
monerobull[m]
ErCiccione: not if its bottlenecked by download speed 5/95
-
hyc
right, there's a good possibility most users won't see it because it's hidden by I/O bottlenecks
-
sgp_
Frankly an increase is necessary for the minimum privacy guarantees. This has been discussed like 1000 times now in MRL, what's up with this discussion now
-
UkoeHB
It seems knaccc and sgp_ were looking at improving churn effectiveness with larger rings (in MRL issue 79).
-
sgp_
Churn is only one minor reason, it's not the main reason for me
-
sgp_
I wouldn't say 11 is "unsafe", but it makes my VERY uneasy
-
ErCiccione
sgp_: Discussion is always good if doubts arise and the doubt right now it's not much about ring increase or not, but more of how much
-
sgp_
s/my/me/
-
monerobull[m]
might suck for raspberry nodes but you shouldnt do that anyways based on the lack of aes
-
ErCiccione
Also, as you said the increase to 16 would be the largest in Monero's history. Don't think it's crazy to weight the option carefully
-
hyc
we're past the hour mark, should we move on?
-
hyc
sounds like we already have relevant data to answer this question
-
sgp_
It has been weighted carefully over almost a year of discussion
-
sgp_
ArticMine wanted ~25
-
monerobull[m]
we will skip the i2p agenda point for now since idk isnt here
-
Rucknium[m]
sgp_: Same here. I speak also as someone who has been closely examining the statistical attack surface of Monero's privacy model.
-
monerobull[m]
encode restore height as 26th word will be skipped since it will most likely wait till seraphis
-
monerobull[m]
so we have a lot of time for that
-
ErCiccione
If 16 is considered a good comproise between security and UX i'm ok with it. I just want to stress the importance of good user experience.
-
monerobull[m]
lets quickly come back to hardfork date: 15.th March 2022, any objections?
-
tevador
It doesn't need to wait for Seraphis, but it doesn't need a hardfork, so it can be discussed another time.
-
sgp_
monerobull[m]: Seems late to me but it is what it is I guess
-
UkoeHB
My objection is there are still open PRs with insufficient reviews, that have been open for over a month. Setting dates implies they will get reviews... is that really the case?
-
ErCiccione
setting dates could help pushing people to review.
-
hyc
is gingeropolous still here? talking about hackathon events to close tickets
-
ErCiccione
hyc: this is something i've been proposing many times in past before hard fork. Would be a cool idea if somebody could organize something
-
monerobull[m]
PRs for this fork shouldnt be all that complex, right?
-
UkoeHB
There is fee PR and multisig PR in limbo.
-
UkoeHB
BP+ PR, I'm not sure - close?
-
monerobull[m]
UkoeHB: didnt you just find some bug with multisig?
-
UkoeHB
Yes there are more issues after this PR.
-
ErCiccione
multisig doesn't require hard fork rght? In any case we (haveno) need it in soon
-
ErCiccione
UkoeHB: something new beside what we already discussed?
-
UkoeHB
I don't remember what we discussed. I believe core is planning to make an announcement to clarify the situation.
-
ErCiccione
-
ErCiccione
ah ok it's something new then
-
monerobull[m]
lets quickly close this:
monero-project/meta #623
-
monerobull[m]
Fluorine Fermi was the condorcet winner.
-
UkoeHB
sgtm
-
monerobull[m]
?
-
UkoeHB
sounds good to me
-
monerobull[m]
oh ok
-
monerobull[m]
we need at least somewhat of a consensus, please reply ,:)
-
hyc
meh. should've required name begin with fl---. imo.
-
monerobull[m]
oxygen orion doesnt either ;)
-
hyc
not a lot of choices there. I seem to recall suggesting oxygen ocelot a the closest I could find
-
Rucknium[m]
Fermi is fine. Flamingo would have been glorious and very meme-able, however.
-
monerobull[m]
Next one will most likely be Neon Nebula so that will be cool
-
monerobull[m]
and after that salty sombrero/spider, lots of memeable stuff for the future
-
monerobull[m]
so we have 1 sgtm, 1 fine and one meh?
-
hyc
officially meh, yes. ;)
-
ErCiccione
+1 meh
-
monerobull[m]
does this count as consensus or whats the plan now?
-
hyc
prob need a few more people to speak up
-
jberman[m]
~ I respect the vote ~
-
monerobull[m]
ill need to get going soon, i porpose next meeting next week so we can get 2 in before christmas/holidays
-
hyc
then it sounds like consensus to me
-
hyc
next meeting should prob be focused on v0.17.3
-
hyc
presumably we're tagging it in the next day or so
-
hyc
assuming no other last minute issues
-
monerobull[m]
monerobull[m]: 5.12, 19.12, 9.01.22
-
moneromooo
To increase volume 5 times, you increase by 400%. Yes, I am a bloody pedant.
-
Rucknium[m]
moneromooo: Yes, true. Thanks for the precision.
-
monerobull[m]
alright, ill have to leave now, i think we discussed all the pressing issues. Thanks for participating, feel free to keep discussing though.
-
UkoeHB
thanks monerobull[m]
-
hyc
yes thanks for moderating
-
moneromooo
Thanks monerobull[m]
-
monerobull[m]
Can someone post the logs / explain to me how to do it 😅
-
UkoeHB
I got it
-
UkoeHB
monerobull[m]: got to mrl channel, open monerologs linked in the channel info, do 'raw' view, copy paste
-
monerobull[m]
Thanks, will add it
-
dEBRUYNE
<Rucknium[m]> Fermi is fine. Flamingo would have been glorious and very meme-able, however. <= Shouldn't underestimate the power of memes to bring awareness to a coin
-
dEBRUYNE
Personally like Flamingo more, sounds more fluent
-
dEBRUYNE
<UkoeHB> the sentiment was more like 'seems like a good idea to increase ring size periodically' <= I don't think this is a good idea to be honest, such a decision needs to be made quite carefully
-
dEBRUYNE
I think an increase in the upcoming scheduled network is warranted
-
dEBRUYNE
Plus an increase when a next-gen protocol goes live (e.g. Seraphis)
-
gingeropolous
ok, so the idea for the "hackathon" to close old things, as hyc mentioned, was to get the final word on old PRs
-
gingeropolous
not too difficult to find the list, just goto github and goto PRs and goto the last page and work backward
-
gingeropolous
-
gingeropolous
like 4159, 5370, ... PRs from 2019
-
gingeropolous
anyway, the idea was to pick a date and time for a particular PR, and the champions of the PR can attend and make their case and perhaps make a live review of the code happen
-
gingeropolous
and at the end of the hour, it can be decided to delete, merge, or punt
-
gingeropolous
or a set of them can be chosen for a given meeting perhaps