開發者會議紀錄

開發者會議紀錄 DevMeeting 20180225

  • 支援ledger硬體錢包的程式碼距離可以被合併的進度又大幅的縮短了
    • 需要與ledger硬體錢包的團隊更進一步的討論才能收尾
  • 三月的硬分叉(協定的升級)
    • 正在等待vtnerd的PoW調整。CUDA跟CPU的部分已經上傳到Github了，而OpenCL還在測試中。
    • 在硬分叉前後一周的禮拜天都將舉行開發者會議，時間在17:00 UTC
  • 有關預設環狀簽數量的討論

以上翻譯來自於紀錄原文: https://monerobase.com/wiki/DevMeeting_2018-02-25

完整會議紀錄：
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@184.70.226.34) 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.46.125.250.55)
12:03 PM rehrar> that’s good to report
12:03 PM ⇐ WWW-XMRTalk-Org| quit (2e7dfa37@gateway/web/cgi-irc/kiwiirc.com/ip.46.125.250.55) 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 (monero@coreteam.getmonero.org)
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 (justi@50-202-180-242-static.hfc.comcastbusiness.net) 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 (citypw@183.6.142.122)
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 (justi@50-202-180-242-static.hfc.comcastbusiness.net)
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 (justi@50-202-180-242-static.hfc.comcastbusiness.net) 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 (justi@50-202-180-242-static.hfc.comcastbusiness.net)
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.79.154.147.141) 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.99.252.24.166)
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.79.154.147.141) 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 (dnaleor@host-im1adb.cbn1.zeelandnet.nl) 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.185.153.176.2) 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.185.153.176.2)
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@84.241.208.224)
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 ([email protected]) 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.99.252.24.166) 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.185.153.176.2) 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.