12:00 PM <rehrar> Alrighty 17:00 UTC. Meeting time. :) 12:00 PM <rehrar> Here's the agenda: https://github.com/monero-project/meta/issues/175 12:00 PM <+moneromooo> I have an easy 10% speedup in Borromean range proof verification if needed. That's a lot of the time spent verifying. 12:00 PM <knifeofpi> good job! 12:01 PM <+moneromooo> It was kinda thought not worth the more complex code so I didn't push it. 12:01 PM <suraeNoether> moneromooo: well that puts the nail in the coffin for RTRS ring signatures. 12:01 PM <rehrar> Had a bit of a hiccup with starting time, but we'll be fine. Let's start with 1. Greetings as always. Who all is here? 12:01 PM <sgp_> Here again :) 12:01 PM <knifeofpi> I’m not here 12:01 PM <rbrunner> Me, me, me! 12:01 PM <suraeNoether> Howdy~ 12:01 PM <msvb-mob> Hello. 12:02 PM <erciccione_[m]> hi, i could crash anyime, sorry 12:02 PM <rehrar> Even those casual observers watching with interest, feel free to squeak 12:02 PM <DaveyJones_> wow nice mooo 12:02 PM <rehrar> 2. Brief review of what's been completed since the previous meeting 12:02 PM ⇐ @ArticMine quit (~ArticMine@22.214.171.124) Quit: Leaving 12:02 PM <rehrar> Anyone have anything good to report? 12:03 PM <@fluffypony> I am here 12:03 PM → WWW-XMRTalk-Org| joined (2e7dfa37@gateway/web/cgi-irc/kiwiirc.com/ip.126.96.36.199) 12:03 PM <rehrar> that's good to report 12:03 PM ⇐ WWW-XMRTalk-Org| quit (2e7dfa37@gateway/web/cgi-irc/kiwiirc.com/ip.188.8.131.52) Client Quit 12:03 PM <@fluffypony> lol 12:03 PM <knifeofpi> lol 12:03 PM <@fluffypony> was meant for 1 12:03 PM <@fluffypony> looks like Ledger is close to their PR being done and merged 12:03 PM <iDunk> We may finally have a dev meeting then 12:03 PM <@fluffypony> we'll have to talk to them to find out what their risk profile is like 12:04 PM → monero joined (~email@example.com) 12:04 PM <monero> [monero] leonklingele opened pull request #3315: wallet2: No longer create '.address.txt' files for non-testnet wallets (master...nuke-address-file) https://git.io/vArT7 12:04 PM ← +monero (voiced) left 12:04 PM <@fluffypony> and if they want to leave it disabled for now 12:04 PM <@fluffypony> obviously if it's enabled then, as moneromooo pointed out, everyone will rush to use something that is largely untested 12:04 PM <+moneromooo> What does put the nail in the coffin ? 12:04 PM <@fluffypony> I *suspect* that the risk is largely their on-device code 12:05 PM <@fluffypony> in which case maybe they have some way of only enabling it to users that opt-in to beta firmware or something 12:05 PM ⇐ sgp_ quit (~firstname.lastname@example.org) Read error: Connection reset by peer 12:05 PM <@fluffypony> moneromooo: in a good or a bad sense? 12:05 PM <dEBRUYNE> cslashm said they wanted it extensively tested first after it was merged 12:05 PM <dEBRUYNE> and there will be some kind of beta 12:05 PM <dEBRUYNE> ^ fluffypony 12:06 PM <+moneromooo> fluffypony: what are you refering to ? 12:06 PM <@fluffypony> dEBRUYNE: yes but does that mean we disable it in the code, or leave it enabled, and what is the impact on us? 12:06 PM <@fluffypony> moneromooo: "nail in the coffin" 12:06 PM → citypw joined (~email@example.com) 12:06 PM <+moneromooo> Ah, I was replying to suraeNoether. Sorry, I was reading backlog and replying late. 12:06 PM <@fluffypony> ah ok 12:06 PM <dEBRUYNE> fluffypony: What's the harm of enabling it? 12:07 PM <@fluffypony> dEBRUYNE: that's what we need to ascertain 12:07 PM <dEBRUYNE> I *think* normal users can only use the code if they include it in a some kind of firmware upgrade 12:07 PM → sgp_ joined (~firstname.lastname@example.org) 12:08 PM <rehrar> anything else on 2? :) 12:09 PM <rehrar> Alright, let's move on to 3. It's something that we can really dig into now with fp present 12:09 PM <rehrar> 3. March hardfork items + code freeze 12:09 PM <dEBRUYNE> fluffypony: perhaps a good idea to discuss with Ledger (e.g. btchip) what their full plan is after the PR is merged 12:09 PM <@fluffypony> dEBRUYNE: will do 12:09 PM <dEBRUYNE> ty 12:09 PM <rehrar> code freeze when? hard fork when? 12:09 PM <@fluffypony> so, as we all know, for various reasons this stuff has had to be pushed down to the wire 12:09 PM <@fluffypony> but now we're at the wire 12:10 PM <msvb-mob> @fluffypony: If possible, inform me or #monero-hardware if you learn new things. 12:11 PM <+moneromooo> Even an old pony can learn new things ? 12:12 PM <+moneromooo> Someone asked above about spent/unspent outs: 26.5e6 outs, 22.7 of them spent. 12:12 PM <+moneromooo> 22.7e6. 12:12 PM <suraeNoether> is this using a first-order approach at estimating spent outputs? 12:12 PM <+moneromooo> It's using a mdb_stat approach. 12:13 PM <iDunk> :) 12:13 PM <@fluffypony> suraeNoether: can you guys move this to -research-lab until after the meeting? 12:13 PM → BoldErea joined (~BoldErea@unaffiliated/bolderea) 12:14 PM <rehrar> Has the Core Team or their delegate that handles releases talked about dates for code freeze and hard fork? 12:15 PM <+moneromooo> Not yet, but (1) we usually fork on the 15th, and (2) we need a few important things first (such as vtnerd's extra PoW changes). 12:15 PM <suraeNoether> yeah, sorry 12:15 PM <@fluffypony> rehrar: the community decides, not us 12:15 PM <@fluffypony> we're already getting fork warnings, but we can address those with a sticky on the sub-reddit or whatever 12:16 PM <knifeofpi> I think the best date to fork would be a day before the scam-coin forks monero 12:16 PM <rehrar> do we know how long vtnerd needs? February only has 28 days after all :P 12:16 PM <@fluffypony> rehrar: when's that? 12:16 PM <@fluffypony> sorry I meant knifeofpi 12:16 PM <@fluffypony> not rehrar 12:16 PM <knifeofpi> 17 days from 12:16 PM <knifeofpi> now 12:16 PM <unknownids> lol 12:16 PM <knifeofpi> according to monerov.org 12:16 PM <@fluffypony> lol 12:16 PM <rbrunner> knifeofpi: Seriously? This has advantages? 12:17 PM <rehrar> countdown here: https://monerov.org/ 12:17 PM <+moneromooo> Do they have any source ? I looked and found nothing. 12:17 PM <rehrar> careful, website probably gives malware 12:17 PM <knifeofpi> no source moneromooo 12:17 PM <@fluffypony> we could just match their fork height for fun 12:17 PM <knifeofpi> if we do it before theirs, it’ll make it a bit more difficult for them 12:17 PM <@fluffypony> someone was bragging on Reddit that they "already have a block explorer up" 12:17 PM <rehrar> As funny as it'd be, I think that would cause mass confusion 12:17 PM <knifeofpi> rehrar: agreed 12:18 PM <@fluffypony> so maybe there is source somewhere 12:18 PM <@fluffypony> but we digress 12:18 PM <@fluffypony> so how about we do this 12:18 PM ⇐ sgp_ quit (~email@example.com) Read error: Connection reset by peer 12:18 PM <@fluffypony> - wait for the important stuff like the final work on the PoW change 12:19 PM <unknownids> would you be surprised to learn its a copy of xmrchain https://monerovexplorer.com/ 12:19 PM <@fluffypony> - based on when that's done we decide whether to move the fork date out by a week or two 12:19 PM <knifeofpi> unknownids: no 12:19 PM <@fluffypony> how does everyone feel about having weekly meetings till the fork, given the urgency? 12:19 PM <knifeofpi> fluffypony: concur 12:19 PM → sgp_ joined (~firstname.lastname@example.org) 12:19 PM <suraeNoether> fine with it 12:20 PM <@fluffypony> ok so every Sunday, normal time, till the Sunday after the fork date 12:20 PM <erciccione_[m]> fluffypony: i agree 12:20 PM <rehrar> I mean, meetings can happen, sure. But we need people to show up. :D 12:20 PM <@fluffypony> where we can do a post-mortem and figure out how to avoid this occurring again in future 12:20 PM <@fluffypony> rehrar: yeah people shouldn't be like that fluffypony guy who misses 3 meetings in a row, he's the wurst 12:20 PM <rehrar> bratwurst 12:20 PM <knifeofpi> :D 12:20 PM <unknownids> u fast 12:20 PM <iDunk> Define normal time. 12:20 PM → rasengan joined (~rasengan@pdpc/corporate-sponsor/privateinternetaccess.com/rasengan) 12:20 PM <iDunk> 16:00 of 17:00 UTC? 12:21 PM <rehrar> iDunk, I think for simplicity sake, we should just go back to 17 UTC 12:21 PM <@fluffypony> iDunk: 17:00 UTC 12:21 PM <msvb-mob> We should get it straight what the best meeting time is while considering a frequency acceleration, but that's the last agenda item I think. 12:21 PM <@fluffypony> 7pm Pony Standard Time 12:21 PM <rehrar> the fact that what happened this week happened shows that the experiment didn't go well 12:21 PM <iDunk> OK, that clears taht up then. 12:21 PM <rehrar> yep, sorry for the confusion 12:21 PM <knifeofpi> we are officially off-topic 12:21 PM <vtnerd> did you mean how long I need for the PoW alterations I was making? 12:21 PM <rehrar> yes vtnerd 12:21 PM <vtnerd> rehar ^ 12:22 PM → al-maisan joined (~al-maisan@opentransactions/monetas/al-maisan) 12:22 PM <rehrar> *waits with bated breath for response* 12:22 PM <vtnerd> I have the cuda changes pushed out, and the cpu changes 12:22 PM <vtnerd> the remaining is opencl 12:22 PM <vtnerd> the remaining miners are variations of those sources afaik 12:23 PM <rbrunner> Including bots :) 12:23 PM ⇐ raas quit (4f9a938d@gateway/web/freenode/ip.184.108.40.206) Quit: Page closed 12:23 PM <vtnerd> the opencl version I have coded, but am trying to figure out how test - Ive been insisting on getting reference hashes back out 12:23 PM <vtnerd> the GPU miners arent really written to do that sort of thing, so its somewhat of a pain. if the miners have a better way to test accuracy of hashes contact me 12:23 PM → raas and rex_4539 joined 12:24 PM <vtnerd> randomly trying one that has some difficulty then comparing against cpu is sort of crap, because it never verifies the computed hash on the device 12:24 PM <vtnerd> so it can have a subtle bug without actual verification 12:25 PM <+hyc> hm? if you set a low difficulty you can check each candidate hash against the CPU version 12:25 PM <vtnerd> the opencl (wolf) implementation is a little more straighforward than the cuda implementation 12:25 PM <vtnerd> so there is that at least 12:26 PM <vtnerd> the cuda version never copied the hash back out, only a flag to indicate to check 12:26 PM <vtnerd> so I suppose the odds that the cpu kept getting some difficulty are low, but its still a weird way to test IMO 12:27 PM <+moneromooo> vtnerd: you could push 32 bytes extra as the input, bodge the hasher to hash 32 bytes less. Then compare with the last 32 bytes of te input. 12:27 PM <vtnerd> Im probably going to have to do some variation of the technique you described for the opencl version :/ 12:27 PM <vtnerd> for the cuda version I made temp changes to copy memory around to verify hashes 12:27 PM <+moneromooo> (and the CPU hasher places its own hash as the last 32 bytes before sending to the GPU). 12:28 PM <vtnerd> you mean copy the results to the input? yeah thats what I ended up doing for cuda - I just copied over the keccak state to get it back out for testing 12:28 PM <+moneromooo> But really, I'm afraid that's going to take even more time again :/ 12:28 PM <@fluffypony> yeah 12:29 PM <knifeofpi> and we’re very low on time. 12:30 PM ⇐ knifeofpi quit (~Mutter@2601:84:8701:6508:8529:fdce:a27d:3ef5) Quit: Mutter: www.mutterirc.com 12:30 PM <rehrar> And will there be adequate testing time? Should we consider moving back the fork a bit? 12:31 PM → knifeofpi joined (~Mutter@2601:84:8701:6508:8529:fdce:a27d:3ef5) 12:32 PM <+moneromooo> <@fluffypony> - based on when that's done we decide whether to move the fork date out by a week or two 12:32 PM <rehrar> oh yeah, that was literally just said :P sorry, I'm an idiot 12:33 PM <rehrar> So the other thing to discuss for the fork then is something we've been discussing in the pre-meeting about upping the ringsize 12:33 PM <knifeofpi> i think the default ring size can be reasonably upped to 7, and keep minimum at 5 12:34 PM <rehrar> https://github.com/monero-project/meta/issues/175#issuecomment-366760767 12:34 PM <rehrar> also: https://github.com/monero-project/monero/issues/3035 for those who want to keep track of the full conversation 12:34 PM → qwebirc74821 joined (63fc18a6@gateway/web/freenode/ip.220.127.116.11) 12:34 PM <rehrar> what would that look like to up the default ringsize to 7, but not enforce it as the minimum? 12:35 PM <sgp_> Yes. The reasoning was discussed pretty extensively earlier, but I recommend a minimum ringsize of 7. It provides the minimum level of protection against chain splits that I feel comfortable with while containing veriifcation time and size to modest increases 12:35 PM <@fluffypony> I don't have a problem with 7 - any thoughts, smooth / luigi1111 ? 12:35 PM <knifeofpi> rehrar: it’d be a bit like March-Sep of last year, where we had min RS 3 and default RS 5 12:35 PM <sgp_> smooth voiced some concerns on GitHub that that 50% compromised "weighted outputs" model we selected was arbitrary 12:36 PM <@fluffypony> sgp_ has done a lot of thinking on this so I'll defer to him on this 12:36 PM <@fluffypony> all of the magic numbers we pick are arbitrary 12:36 PM <@fluffypony> :-P 12:36 PM <@luigi1111> Ok with 7 as wallet default, not as consensus for this fork 12:36 PM ⇐ raas quit (4f9a938d@gateway/web/freenode/ip.18.104.22.168) Quit: Page closed 12:36 PM <rehrar> smooth had some good arguments against however 12:36 PM <rehrar> but perhaps if this is not enforced strictly, then that could help somewhat 12:37 PM <rbrunner> If not "consensus" minimum would stay at 3? 12:37 PM <sgp_> rbrunner it is currently 5 12:37 PM <gingeropolous> i think doing the wallet different than consensus just stamps transaction as "from exchange" vs "from wallet" 12:37 PM <rbrunner> Ah, ok 12:38 PM <knifeofpi> that’s true gingeropolous 12:38 PM <knifeofpi> maybe a minimum of 7 is warranted 12:38 PM <gingeropolous> cause services aren't going to increase the cost of tx willingly 12:38 PM <sgp_> I think there is exensive documentation in other discussions saying that we should move towards a single ringsize, not further away from it 12:38 PM <knifeofpi> right 12:38 PM <rehrar> agreed, but we're in a weird adolescence period between bullet proofs 12:39 PM <rehrar> so current decisions will be radically changed in less than six months 12:39 PM <knifeofpi> we might need a stopgap fee algorithm adjustment to compensate 12:39 PM <rehrar> we are in the tricky position of finding a 'good' setup for six months to tide us over in the face of potential threat, while also waiting for great technology that will make us a big boy 12:39 PM <sgp_> Luckily changing the ringsize takes little effort. This isn't a single vs multi-output bulletproof situation 12:39 PM <+moneromooo> I'm not changing fee algorithm now :D 12:39 PM ⇐ dnaleor quit (~email@example.com) Quit: Leaving 12:39 PM <knifeofpi> moneromooo: why? 12:40 PM <+moneromooo> Because I want monero to work after the fork. 12:40 PM <@fluffypony> knifeofpi: we can just set the default multiplier down 12:40 PM <@fluffypony> no need to change the fee algo 12:40 PM <knifeofpi> yeah that’s what I mean 12:40 PM <suraeNoether> oh hi sorry, ring size: yes, i vote fixed ring size of 7, or, failing that, a min ring size 7, or, failing that, a default ring size 7 with our fixed ring size 5. tha'ts my order of preference. 12:40 PM <knifeofpi> wait, no 12:40 PM <rehrar> sarang, do you agree with suraeNoether? 12:41 PM <rehrar> having both MRL stamps on this would be beneficial for discussion 12:41 PM <gingeropolous> and 2 more ringmembers isn't crazy heavy. id say network min 7, then we try and figure out the more difficult problem of fixed ringsize. 12:41 PM <rehrar> a fixed ringsize of 7 seems really heavy of a change to shoehorn on the final hour though 12:42 PM <rehrar> so I think I would go for suraeNoether's second option for the time being 12:42 PM <suraeNoether> i'm not sure if sarang is around right now 12:42 PM <gingeropolous> yeah, second option 12:42 PM <sgp_> If you haven't played with the data yet, you can mess with this Google Sheet. Check out the summary page, and make sure to use Incognito/InPrivate mode to protect privacy: https://docs.google.com/spreadsheets/d/1iLa_yklutjHqn_DrOlO_eTb00l4YDAezijX2J5r6P14/edit?usp=sharing 12:42 PM <scoobybejesus> People who want ring size effectively higher can churn 12:42 PM <sgp_> I have the same exact recommendation as surae :) 12:42 PM <WWW-XMRTalk-Org|> Fixed is best to avoid exchange tx stamping. Voting for fixed at 7 12:42 PM <chachasmooth> sgp_ lol how does incognito protect your privacy 12:43 PM <suraeNoether> ring size 5->7 means a 40% increase in verification time and blockchain space. but we are shaving essentially all of our range proofs 12:43 PM <sgp_> Just logs you out of Google 12:43 PM <knifeofpi> I concur with surae 12:43 PM <sgp_> surae I don't think that 40% is correct 12:43 PM <suraeNoether> linear in verification time and space 12:43 PM <rbrunner> 40% strictly only for the ring sig part, right? 12:43 PM <suraeNoether> rbrunner: yes 12:44 PM <suraeNoether> 7/5 = 1.4 12:44 PM <sgp_> Ah ok, agree with you now. Just the ring sig part 12:44 PM <suraeNoether> yeah 12:44 PM <suraeNoether> moneromooo also said he had a 10% boost in verification time for mlsag 12:44 PM <rbrunner> Overall it seems to be surprisingly small 12:44 PM <sgp_> All together, for a 2 in/2out, it will increase verification time by 7.2% and size/fees by 2% 12:44 PM <rehrar> ok, so it seems a loose consensus to up a consensus minimum to 7? 12:44 PM <sgp_> For the entire transaction, not just the ring sig part 12:44 PM <+moneromooo> No, I said I had a 10% speedup for range proofs. 12:44 PM <knifeofpi> rehrar: concur 12:45 PM meeh_ → mikalv 12:45 PM <rehrar> luigi1111: you didn't like the idea of this consensus change, care to give a brief chime? 12:45 PM <sgp_> moneromooo if you have a 10% improvement, then that's great! I still think this should be pursued regardless 12:45 PM <dEBRUYNE> If you use 7 as the wallet default and 5 as consensus default there's going to be discrepancy between ring sizes, which might be detrimental to privacy 12:45 PM <dEBRUYNE> wrt to ring sizes it's probably best to be as uniform as possible 12:46 PM <rbrunner> Yes, that's why minimum goes to 7, right? 12:46 PM <rehrar> dEBRUYNE: then your thoughts on upping the consensus minimum to 7? 12:46 PM <chachasmooth> sgp_ first sheet looks broken to me https://i.imgur.com/mZuWK5o.png 12:46 PM <suraeNoether> moneromooo: ooooh 12:46 PM <dEBRUYNE> rehrar: Kind of ambivalent currently 12:46 PM <dEBRUYNE> I feel like agreeing with smooth's comment on Github 12:47 PM <sgp_> chachasmooth the numbers are just really small since the ringsize is set to 70. Change the number in the grey box :) 12:47 PM <suraeNoether> on another note: we can make our MLSAGs a bit faster with the multiexp operations that we've used in bulletproofs 12:47 PM <knifeofpi> if we’re going to increase the consensus ring size, we have to schedule our HF before the scam HD 12:47 PM <knifeofpi> *HF 12:47 PM <chachasmooth> sgp_ oh, it's interactive? oops 12:47 PM <rehrar> youch, that'd be a crunch 12:47 PM <knifeofpi> the influx of users claiming forked coins will be much more harmful than anything after the fork date 12:48 PM <rehrar> is that possible given our current constraints? 12:49 PM <scoobybejesus> We'd need testing binaries asap 12:49 PM <rehrar> we still need vtnerd's stuff too 12:49 PM <rehrar> not to be a spoil sport, but if we can't work this in before the MoneroV fork date, is it still worth doing? 12:49 PM <rehrar> Given that BPs will be coming not far from now 12:50 PM <sgp_> I argue yes 12:50 PM <knifeofpi> IMO it’s extremely urgent 12:50 PM <+hyc> 6 months is kind of a long time 12:50 PM <rbrunner> Don't like it if that MoneroV nonsense suddenly gets so much weight for our own actions .. running around like rabbits, in a way 12:50 PM <gingeropolous> ^^ 12:50 PM <vtnerd> / 12:50 PM <scoobybejesus> If we fork before exchanges pick up monerov, probably worth it 12:50 PM <pigeons> yeah i think most people know about them from monero users who are concerned about it 12:50 PM <knifeofpi> true 12:50 PM <WWW-XMRTalk-Org|> Yes, because there may be monerov copycats. Moving ringsize min and default to 7 still helpful 12:50 PM <sgp_> Can still protect against situations where people chaim MoneroV en masse, including additions to exchanges, etc. Also protects against other possible forks 12:51 PM <rehrar> rbrunner: it's not just MoneroV. This is a weakness in our current setup period that can be taken advantage of by anyone 12:51 PM <knifeofpi> WWW-XMRTalk-Org|: the more copycats there are, the less effective they are 12:51 PM <rbrunner> Setup period? 12:51 PM <rehrar> setup, period. 12:51 PM <knifeofpi> rbrunner: as in setup, period 12:52 PM <rehrar> the potential threat of deanonymizing outputs is real, so in that sense, it shouldn't matter who is doing the 'attack' and whether it's malicious or not 12:52 PM <rbrunner> Yeah but I think the sky is not falling, really no need for risky stunts and hurry an unfishined update out the door ... 12:52 PM <rehrar> the core is, it's possible in a real, non-theoretical scenario, so it should be addressed 12:52 PM <gingeropolous> and right now, the best defense is increased ringmembers? 12:53 PM <rehrar> I agree with you there rbrunner. I think we should not rush to get this release out, even if that means not before MoneroV 12:53 PM <rehrar> it may not help us a super amount with the MoneroV thing, but it will slightly help after, and will definitely help for any copycats after 12:53 PM <knifeofpi> rehrar: “before XMV gets on exchanges” may be the more relevant time point 12:53 PM <rbrunner> Agreed about exchanges 12:54 PM <knifeofpi> If we get an exchange listing date, we fork before that date 12:54 PM ⇐ WWW-XMRTalk-Org| quit (b999b002@gateway/web/cgi-irc/kiwiirc.com/ip.22.214.171.124) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client 12:54 PM <sarang> Bad cell service. I agree with increase of ring size 12:54 PM <sarang> Consensus preferred, wallet default otherwise 12:54 PM <+moneromooo> What does forking before/after give us ? I don't get the advantage. 12:55 PM <+moneromooo> (except if we bump ring size) 12:55 PM <sgp_> That's the only impact moneromooo 12:55 PM <knifeofpi> If we fork before, it makes things more difficult for them + improves privacy before the influx of scam coin claims 12:55 PM <knifeofpi> assuming RS increase 12:55 PM <rehrar> I'm inclined to agree with MRL here, along with sgp's research 12:55 PM <knifeofpi> As am I 12:56 PM <rehrar> I didn't necessarily agree with smooth's comment: We already shifted upward from the clearly-research-suported 3 (due to potentially-catastrophic chain reaction effects) to 5 purely for "It seems better and the cost isn't that high" reasons. 12:56 PM → WWW-XMRTalk-Org| joined (b999b002@gateway/web/cgi-irc/kiwiirc.com/ip.126.96.36.199) 12:56 PM <rehrar> We're not doing it for no reason, SGP has actually given some decent data to ponder about this. 12:56 PM <rehrar> comment here: https://github.com/monero-project/monero/issues/3035#issuecomment-368273632 12:56 PM <rehrar> but anyways, we're running really short on time New messages since you tabbed out 12:57 PM <WWW-XMRTalk-Org|> Since most of us seem to agree on 7 can we discuss fixed vs min vs default? I voted fixed 12:57 PM <rbrunner> My vote: Only default 12:57 PM <rehrar> to summarize, fork date or code freeze date can't be set yet because we're waiting on important stuff, and there is loose consensus about an increase in consensus minimum ringsize to 7 12:57 PM <scoobybejesus> I sympathize with smooth that the increase in verification time is a bitter pill. Despite that, I also support consensus RS of 7 12:57 PM <knifeofpi> I vote either fixed or min. 12:58 PM <rbrunner> Maybe if we prod Moneromooo a little he draws some optimazitions out of some hat :) 12:58 PM <rehrar> I would personally like a little bit more formal research done into fixed ringsizes (even though it's fairly obvious on the surface it does nothing but help) 12:58 PM → defterade__ joined (~AndChat54@188.8.131.52) 12:58 PM <knifeofpi> rehrar: concur 12:58 PM <rehrar> moving from 5 to 7 so late already is a big enough change I think 12:58 PM <rbrunner> Exactly my thinking 12:59 PM <rehrar> throwing something else in there for funsies would honestly be very uncomfortable 12:59 PM <knifeofpi> but if we allow both 5 and 7, that basically marks tx as “from exchange” vs “from wallet” 12:59 PM <rehrar> alright, so because we're meeting next week, we don't have to rush to get through everything on the agenda this week 12:59 PM <@fluffypony> I don't think we have enough time to move to fixed 12:59 PM <@fluffypony> for this fork 12:59 PM <@fluffypony> but we can motivate for it for Sept 12:59 PM <gingeropolous> ^^ 12:59 PM <knifeofpi> fluffypony: what do you say to a min ring size of 7, but not fixed? 12:59 PM <scoobybejesus> ^^ 1:00 PM <+hyc> min 5, default 7. 1:00 PM <@fluffypony> I prefer min 5, def 7 1:00 PM <suraeNoether> btw, it's worth pointing out 1:00 PM <+moneromooo> If we move to default 7, I'd rather min 7, for the reason gingeropolous gave. 1:00 PM ⇐ defterade_ quit (~AndChat54@ip5451444e.direct-adsl.nl) Ping timeout: 256 seconds 1:00 PM <suraeNoether> each time we make a decision to do ringsize += 2 1:00 PM <suraeNoether> the % harm it does is lower than the previous time we made the decision, in terms of cost 1:01 PM <rbrunner> Clever argument :) 1:01 PM <+hyc> lol. 1:01 PM <knifeofpi> lol 1:01 PM <gingeropolous> its possible transactions are already stamped as service vs. user though, primarily due to the number of outputs 1:01 PM <rehrar> Alright, it's past time. Shall we decide next meeting, or we want to keep discussing a bit? 1:01 PM <suraeNoether> but the improvement to security are unknown, so while it seems clever, it's a good way to induct our ways into blockchain hell 1:01 PM <knifeofpi> rehrar: i’m open to continuing this meeting a bit 1:02 PM <sgp_> surae good point. We can "formally" say here that the reason for the increase is to better protect against 50% threat models. We can tie performance to that benchmark unless some fork exceeds this threshold 1:02 PM <sgp_> something along those lines 1:03 PM <rbrunner> Well, it seems people are exhausted 1:03 PM <sgp_> This was an unusual case since no one had thought about a large-scale key image reuse attack before 1:04 PM ⇐ qwebirc74821 quit (63fc18a6@gateway/web/freenode/ip.184.108.40.206) Ping timeout: 260 seconds 1:04 PM <rbrunner> In itself somewhat surprising, no? 1:04 PM <rbrunner> Given all the forking that happens around us 1:04 PM → @ArticMine (opped) joined 1:05 PM <sgp_> fluffypony hyc luigi1111 are you ok with minimum 7? I think most people think this is better than default 7 1:05 PM <Slack_3> <rehrar> Ok, we can officially end for those who have to go, but as always discussion can continue 1:06 PM <rbrunner> See you next week then 1:06 PM <knifeofpi> Same time, same channel. 1:06 PM <Slack_3> <rehrar> March 4th, 17 UTC 1:06 PM <gingeropolous> well is there gonna be a post meeting now for those that got the time mixed up in the other direction? :) 1:06 PM ⇐ WWW-XMRTalk-Org| quit (b999b002@gateway/web/cgi-irc/kiwiirc.com/ip.220.127.116.11) Quit: http://www.kiwiirc.com/ - A hand crafted IRC client 1:06 PM <Slack_3> <rehrar> Let's do it. 1:07 PM <sgp_> lol gingeropolous 1:07 PM <gingeropolous> 3 hour dev meetings! Because the more meetings you have, the more productive you are 1:07 PM <Slack_3> <rehrar> Post meeting agenda: 1. Gingeropolous interpretive dance 1:07 PM <gingeropolous> said every project manager everywhere 1:07 PM <knifeofpi> what one programmer can do in one month, two programmers can do in two months 1:08 PM <@fluffypony> lol 1:08 PM <gingeropolous> |/-\|/-\__== 1:09 PM <gingeropolous> thats it. thats my interpretive dance. it means "kill all asics" 1:09 PM <knifeofpi> lol 1:09 PM <+hyc> yeah I'm fine with min 7 1:10 PM <scoobybejesus> Default RS 7 w/ min RS 5 would mean the network would forgo lots of passive obfuscation, whether or not many-out txns are exchange-stamped 1:10 PM <Slack_3> <rehrar> Thanks everyone. Though sometimes the nitty gritty can be tedious and have tension, it helps to keep some perspective. We're trying to change the world here. More often than not a thankless task.