開發者會議紀錄 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 ([email protected]) 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 ([email protected]/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 ([email protected]/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 ([email protected])
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 ([email protected]) 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 protected])
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 ([email protected])
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 ([email protected]/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 😛
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 protected]) 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 ([email protected])
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. 😀
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> 😀
12:20 PM <unknownids> u fast
12:20 PM <iDunk> Define normal time.
12:20 PM → rasengan joined ([email protected]/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 ([email protected]/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 ([email protected]/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 ([email protected]: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 ([email protected]: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 😛 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 ([email protected]/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> 😛
12:36 PM <@luigi1111> Ok with 7 as wallet default, not as consensus for this fork
12:36 PM ⇐ raas quit ([email protected]/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 😀
12:39 PM ⇐ dnaleor quit ([email protected]) 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 ([email protected]/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 ([email protected]/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 ([email protected])
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 ([email protected]/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 ([email protected]/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.

發表迴響