- Ledger(Blue/Nano S)上的程式碼已經成功的合併了
- 本周應該還有最後一次的PoW更新會上傳至Github
- 未來幾天將會公布確切的硬分叉區塊高度
- 已有共識決議將環狀簽名大小預設值調整為7
- 審查防彈協定的募資活動(於論壇資助系統上)將訂於三月五日(周一)開始。Sarang將會公布更多資訊。
- 若你對如何減輕因重複使用金鑰而造成的隱私疑慮的”技術性”討論有興趣，請點這裡
以上翻譯來自於紀錄原文: https://monerobase.com/wiki/DevMeeting_2018-03-04
完整會議紀錄：
12:01 PM rehrar> https://github.com/monero-project/meta/issues/188
12:01 PM rbrunner> Hoi zäme
12:01 PM sgp_> hello!
12:02 PM knifeofpi> hello!
12:02 PM rehrar> ArticMine luigi1111 luigi1111w smooth vtnerd endogenic anonimal pigeons
12:02 PM rehrar> gingeropolous ErCiccione medusa_ dsc_ MoroccanMalinois xmrscott[m]
12:03 PM rehrar> I know I’m missing people. Ping them? :)
12:03 PM ErCiccione> Hi!
12:03 PM knifeofpi> rbrunner
12:03 PM rehrar> dEBRUYNE iDunk
12:03 PM rehrar> all hands on deck people. binaryFate
12:03 PM rbrunner> Here :)
12:03 PM iDunk> Hi
12:03 PM dEBRUYNE> here
12:04 PM knifeofpi> suraeNoether sarang
12:04 PM → +monero (voiced) joined
12:04 PM +monero> [monero] fluffypony pushed 2 new commits to master: https://git.io/vAHR7
12:04 PM +monero> monero/master e745c1e cslashm: Code modifications to integrate Ledger HW device into monero-wallet-cli….
12:04 PM +monero> monero/master c7ace5f Riccardo Spagni: Merge pull request #3303…
12:04 PM mode: @binaryFate (opped) ↔ +monero (voiced) nipped out
12:04 PM +monero> [monero] fluffypony closed pull request #3303: Ledger Nano S (master…Ledger-NanoS) https://git.io/vAuCx
12:04 PM ← +monero left (monero@coreteam.getmonero.org)null@2607:5300:60:1c3f::)
12:04 PM @fluffypony> boom
12:04 PM sgp_> woo-hoo, Ledger Nano S code merged!
12:04 PM rehrar> So as was decided last week, meetings will become weekly until the March hardfork, just so devs can get everything necessary and needed together and touch base a bit more often
12:04 PM @ArticMine> hi
12:05 PM @fluffypony> +1
12:05 PM rehrar> Let’s jump right in. :)
12:05 PM rehrar> 2. Brief review of what’s been completed since the previous meeting
12:05 PM @fluffypony> ok so
12:05 PM @fluffypony> we had a bit of a slow down because of the Ledger PR
12:05 PM @fluffypony> it touched a LOT of the code, and they have limited resources
12:06 PM @fluffypony> so we held off on merging till they were done, to save them the hassle of dealing with rebases whilst still trying to get their PR done
12:06 PM +hyc> so, time for a new mergefest now that that’s out of the way?
12:07 PM @fluffypony> there are parts of the PR that moneromooo and vtnerd and stoffu would like to further improve, but as of a few hours ago it got to a point where it could be merged
12:07 PM @fluffypony> hyc yes indeed - I’m going to give it ~24 hours for dust to settle, and then merge tomorrow
12:08 PM @fluffypony> so please be on the lookout in 24 hour’s time for anything that may need rebasing, and anything that breaks
12:08 PM → BobBarker joined (
12:08 PM @fluffypony> we’re also going to start cutting back on merging things that can go in post-branch
12:09 PM @fluffypony> with a view to branching by, say, next weekend, if everyone thinks that is wise
12:09 PM @fluffypony> (not to go too far from agenda item 1)
12:10 PM rehrar> Well, it doesn’t sound like there’s much else done this past week because of holding off for Ledger, so it kind of moves nicely into the next item
12:10 PM rehrar> 3. March hardfork items + code freeze
12:10 PM rehrar> officially on-topic fluffypony
12:10 PM @fluffypony> ok
12:10 PM @fluffypony> what I was thinking for this
12:11 PM @fluffypony> is if anyone with open PRs that they think should form part of the imminent release, if you could please change the title to include a [RELEASE] prefix
12:11 PM @fluffypony> and think carefully about whether it is truly an important / urgent fix that must go in, or if it can hold off till the next release
12:11 PM @fluffypony> and/or a point release
12:12 PM rbrunner> How are the chances for a point release?
12:12 PM → psychocrypt joined (psychocry@p200300ED73F2670005FC1ADC94FB1D8B.dip0.t-ipconnect.de)Madilyn36@ns334669.ip-5-196-64.eu)
12:12 PM @fluffypony> alternatively if you don’t feel like editing titles just dump PR numbers in channel and flag me
12:12 PM → netrik182 and foobar000 joined ⇐ xnbya quit
12:12 PM @fluffypony> rbrunner: we almost always have a point release pretty soon after to catch any nagging issues / regressions
12:12 PM dEBRUYNE> rbrunner: I’d say quite likely, as there are always bugs that are only caught by general usage
12:13 PM rbrunner> Thanks, expected this
12:13 PM → Madilyn36Herzog joined (
12:15 PM @fluffypony> how does everyone feel about branching on the weekend, with an expectation that code freeze is soon thereafter ?
12:15 PM @fluffypony> (soon™)
12:16 PM → xnbya joined (quassel@ec2-54-72-128-94.eu-west-1.compute.amazonaws.com)Madilyn36@ns334669.ip-5-196-64.eu) Ping timeout: 248 seconds
12:16 PM knifeofpi> No objection
12:16 PM +hyc> sounds good
12:17 PM ErCiccione> ok
12:17 PM psychocrypt> does this also mean that the POW change get locked and that the POW is definitiv changed?
12:18 PM @fluffypony> psychocrypt: yes
12:18 PM knifeofpi> has the bias in the PoW change been fixed?
12:18 PM @fluffypony> moneromooo: ^^
12:18 PM sarang> Hullo
12:19 PM psychocrypt> I will only vote against the fast pow change. IMO the time to change the POW is not long enough to test everything well
12:19 PM rehrar> I am a bit inclined to agree with psychocrypt
12:19 PM +moneromooo> Yes.
12:20 PM rehrar> I appreciate what it’s trying to do, but it was a bit sudden
12:20 PM rehrar> and I’m not sure that it would be detrimental to think about pushing it to September to allow for testing and stuff
12:20 PM iDunk> That was the whole point :)
12:20 PM psychocrypt> I am absolutly fine with the change but the time for test is to short
12:20 PM knifeofpi> It’s already been announced. Reversing that would be considered by many to be a breach of trust
12:20 PM @ArticMine> … but likely necessary
12:20 PM @fluffypony> the point is to have a short time
12:20 PM gingeropolous> ^^
12:20 PM knifeofpi> fluffypony: exactly
12:20 PM @fluffypony> if we wait till September then new ASICs will be taped out
12:20 PM @fluffypony> the end
12:20 PM rehrar> shrug ok
12:21 PM knifeofpi> \o/
12:21 PM DaveJones> well he is right … you would have to develop some change in hidden… how do you want to test sth thats hidden and review it ?
12:21 PM psychocrypt> are there ASICs on the way?
12:21 PM +moneromooo> The fork is pushed back to end of march, due to the two weeks faffing around.
12:21 PM @fluffypony> psychocrypt: ASICs already exist
12:21 PM medusa_> well is there anything we dont know in that regard ?
12:21 PM medusa_> really ?
12:22 PM knifeofpi> fluffypony: what??
12:22 PM ⇐ foobar000 quit (b99f9d09@gateway/web/freenode/ip.185.159.157.9) Ping timeout: 260 seconds
12:22 PM knifeofpi> somebody made an FPGA
12:22 PM knifeofpi> but ASICs…?
12:22 PM @fluffypony> somebody taped out an ASIC
12:22 PM knifeofpi> when did this happen?
12:22 PM medusa_> the reddit post you mean ?
12:22 PM rehrar> link?
12:22 PM @fluffypony> sidechannelled to me, not public
12:22 PM @fluffypony> a handful of others have had similar confirmation via via
12:22 PM psychocrypt> @fluffypony: are this ASICS or FPGAs?
12:23 PM @fluffypony> were it just me I would find it suspicious
12:23 PM @fluffypony> psychocrypt: ASICs, not FPGAs
12:23 PM sgp_> Do you have estimated hashrate, estimated quantity of these, etc?
12:23 PM @fluffypony> sgp_: I’ve asked
12:23 PM knifeofpi> Cost? Efficiency?
12:24 PM psychocrypt> fluffypony: What is the planned date for the hard fork? My only information is end of this month
12:24 PM +hyc> “not enough time to test” I would consider this a valid argument if you propose an actual testing schedule that you will adhere to
12:24 PM rehrar> fair point hyc
12:24 PM @fluffypony> psychocrypt: we’ll set the exact fork height in the next few days
12:25 PM rbrunner> Aaaand … where will you set it, aproximately?
12:25 PM ⇐ Madilyn36Herzog quit (
12:25 PM @fluffypony> rbrunner: month end
12:25 PM knifeofpi> so, three weeks or so
12:25 PM rbrunner> Sounds good, 2 weeks + for testing
12:26 PM psychocrypt> hyc: currently the pull request is not up to date. Therefore we need not to think about a schedule
12:26 PM +moneromooo> Helpful.
12:26 PM +moneromooo> Did vtnerd not PR a patch for the latest variant code ?
12:27 PM +hyc> I thought he already did, yeah
12:27 PM psychocrypt> I correct myself: it is up to date since yesterday or the day before
12:28 PM rbrunner> Maybe also a question when Testnet will fork?
12:28 PM +moneromooo> Testnet has forked.
12:28 PM rbrunner> Oh … so I lost overview
12:28 PM +moneromooo> Though it will need to again…
12:28 PM +moneromooo> :)
12:28 PM @luigi1111> :)
12:29 PM iDunk> Maybe that was about stagingnet.
12:29 PM medusa_> i geuss thats what he means yes :)
12:29 PM +moneromooo> Whenever the PoW patch goes in. Then seed nodes update within… some time.
12:29 PM +moneromooo> Oh, that one I have no idea.
12:29 PM +moneromooo> I think it’s down to the people who asked for it to decide.
12:29 PM medusa_> riolling back testnet is always a little messy
12:29 PM — iDunk is not sure if he’s pushing through v7/8 again
12:29 PM +moneromooo> I was thinking they’d need some pre-rct txes in there, but I’m not sure.
12:30 PM gingeropolous> if ppl need to test the new PoW there’s a private testnet mining pool on killallasics.moneroworld.com
12:30 PM +hyc> gingeropolous: running latest PoW patch?
12:30 PM rbrunner> Cool name
12:30 PM ⇐ TheoStorm quit ([email protected]) Quit: Leaving
12:30 PM knifeofpi> best name
12:31 PM gingeropolous> hyc, yeah. right moneromooo ?
12:31 PM +moneromooo> Yes.
12:31 PM +hyc> great
12:34 PM ocinvfvsUIOIvdsb> testing pre ringct txs seems important
12:34 PM ocinvfvsUIOIvdsb> many still have old cold storage created during that time
12:34 PM +hyc> they already exist on current testnet. this seems to only be a question for the new stagenet
12:34 PM +moneromooo> Yes, I meant this for the new stagenet indeed.
12:35 PM rbrunner> Just to be sure: stagenet is that which is is kept on the same version as release?
12:35 PM +hyc> yes
12:35 PM +hyc> as mainnet
12:35 PM rbrunner> Ok :)
12:36 PM rbrunner> Puff, you don’t watch a few days, one more net :)
12:36 PM +moneromooo> I guess we’ll need to fork it a bit before mainnet… but mainly same.
12:36 PM @fluffypony> lol
12:36 PM knifeofpi> lol
12:36 PM @fluffypony> just wait for moonet
12:36 PM @fluffypony> and hycnet
12:36 PM knifeofpi> cnet?
12:37 PM +moneromooo> moonet is only if you can get on my inter-VM network ^^
12:37 PM psychocrypt> I have a big wish: Is it possible to announce the hard fork hight next time more than two month before the fork? This would also help the exchanges to schedule there updates and if we change the pow now each fork this will help us to schedule our work.
12:37 PM +moneromooo> Depends if you’re OK with it changing if necessary.
12:38 PM +moneromooo> Still, people could have aimed for mid march without knowing the exact height.
12:38 PM rbrunner> IT and release dates, a checkered history, right?
12:38 PM gingeropolous> psychocrypt, hard forks are ^^ yeah what mooo said
12:38 PM rehrar> I think it’s necessary to be flexible with time if it means better security.
12:39 PM scoobybejesus> i’ve been aiming for mid-march since october
12:40 PM +moneromooo> It may be that people in general don’t know about the periodic forks though, but that’s kinda different.
12:40 PM ocinvfvsUIOIvdsb> If ASICs exist already how do we know that they will not have 51% of network hash rate by hard fork time at end of March?
12:40 PM +moneromooo> I suppose having a warning a month or two before as a matter of course is noit a bad idea.
12:40 PM +moneromooo> They may well do, but we needed that extra two weeks for miner testing.
12:40 PM +hyc> don’t we already have that warning in monerod?
12:41 PM +moneromooo> We do. A bit late for such a purpose though maybe.
12:41 PM +moneromooo> It started moaning a couple weeks ago I think.
12:41 PM +hyc> we could just permanently add it to the startup banner - “next hardfork on XX” where XX is approx 6 months from current release date
12:41 PM +moneromooo> Could do. With “expected” wording.
12:41 PM +hyc> right
12:42 PM @fluffypony> yeah
12:42 PM @fluffypony> hyc: nobody reads startup banners I’m afraid
12:42 PM knifeofpi> some people do, lol
12:42 PM rbrunner> But it can’t hurt
12:42 PM +moneromooo> Though I guess many of the “heaviest” users may not start it often, and might be unattended.
12:42 PM rehrar> Make it like those annoying pop ups that want your email when you get into a website
12:42 PM rehrar> Need to check four separate checkboxes to close it
12:42 PM +hyc> ok, so we could do periodic warnings like we currently have, just start them sooner
12:43 PM +hyc> once/month, then once/week, then once/day, etc. as the date approaches
12:43 PM +moneromooo> Maybe best to add another state to the “do I think I need an update” a couple months before and moan less loudly then.
12:43 PM rehrar> I think that’s an overall smart idea though, and points to fp saying that it’s good to keep relative consistency in fork dates
12:43 PM +moneromooo> Yes, agreed.
12:43 PM +moneromooo> It’s on my list now.
12:45 PM rehrar> Anything else on hard fork/code freeze?
12:45 PM sgp> Just a reminder the code for the ringsize needs to be changed
12:45 PM +hyc> ?
12:45 PM ocinvfvsUIOIvdsb> 7
12:45 PM rehrar> aha, yes. There was loose consensus last meeting to change the minimum ringsize to 7.
12:45 PM dEBRUYNE> I am not sure if there was consensus on that
12:45 PM rehrar> Shall we open that up for a second discussion?
12:45 PM ocinvfvsUIOIvdsb> loose consensus from last meeting
12:46 PM dEBRUYNE> It seems like a too abrupt change
12:46 PM knifeofpi> dEBRUYNE: I disagree
12:46 PM rehrar> Let’s talk about it. ;)
12:46 PM knifeofpi> min 7 is absolutely necessary at this point, IMO.
12:46 PM @ArticMine> I am in favor on the increase in min ringsize to 7
12:46 PM Slack_4> nicolas.misiura> Will this release affect the wallet (api)?
12:46 PM ocinvfvsUIOIvdsb> agree with knife of pi
12:46 PM sgp_> Well, I don’t have any more data than last week. If anyone needs it again I can provide it
12:47 PM sarang> I’m in favor
12:47 PM ocinvfvsUIOIvdsb> + sarang
12:47 PM ocinvfvsUIOIvdsb> +1
12:47 PM DaveJones> +1
12:47 PM rbrunner> +1
12:47 PM knifeofpi> +1
12:47 PM rehrar> My opinion is that sgp did the work to show that it is helpful, unless someone will do the work to show it’s tradeoffs are worse than the benefits, I think sgp has shown enough to convince (me at least) that it’s worth it
12:47 PM knifeofpi> rehrar: agreed
12:47 PM @fluffypony> +1
12:48 PM ErCiccione> i’m in favor too
12:48 PM +hyc> yep. +1 rehrar
12:48 PM dEBRUYNE> rehrar: smooth posted some compelling retorts on github fwiw
12:48 PM @ArticMine> link
12:48 PM dEBRUYNE> Anyway, if it gets increased, please increase the consensus and not merely the wallet default
12:48 PM rbrunner> That was left hanging last time
12:48 PM @ArticMine> I am talking about consensus
12:48 PM ocinvfvsUIOIvdsb> I think everyone here read all of smooths posts in GitHub. I still vote for 7 based on SGP and other data
12:48 PM +moneromooo> The min ring size is necessarily consensus.
12:49 PM dEBRUYNE> ArticMine: https://github.com/monero-project/monero/issues/3035#issuecomment-368273632
12:49 PM rehrar> His retorts amounted to: the numbers for the model are chosen arbitrarily, so it’s not hard proof that the tradeoffs are worth it
12:49 PM rehrar> so in the absence of hard proof we should not be rushing into things
12:49 PM knifeofpi> tx size increase is fairly negligible though
12:50 PM knifeofpi> we need to assume a worst case scenario
12:50 PM rehrar> these are indeed arguments that I respect to a degree, because arbitrariness leads to things like how Sumo handles things
12:50 PM dEBRUYNE> 7-8% verification time increase is significant though
12:50 PM rehrar> but how does one ‘plan for an attack’ except by threat modeling to the best of their ability
12:50 PM knifeofpi> didn’t moneromooo have a 10% speedup for some kind of verification?
12:50 PM ocinvfvsUIOIvdsb> Well we have auditors lined up now. Post FFS quickly and we can move up bulletproofs to this summer if needed
12:51 PM rehrar> modeled I think to a reasonable adversarial model (50% compromised outputs).
12:51 PM +moneromooo> I do have that for borromean sig verification, but it was deemed not worth the code complexification at the time.
12:51 PM knifeofpi> understood
12:51 PM +moneromooo> It wasn’t very complex though, just straightforward avoidance of conversions.
12:51 PM rehrar> And even smooth’s alternative % of compromised outputs still had convincing numbers, at least for me
12:52 PM @ArticMine> The small increase in verification time has to be balanced against the privacy threat. So yes I understand smooth’s argument about a slippery slope but at this point in time it is simply prudent to increase to 7
12:52 PM rehrar> smooth: “For example, at 50% (in some sense perhaps the optimal share for making the argument for an increased ring size), going from ring size 5 to 10 reduces the compromise rate from 6.25% to 0.195%. But with an assumed compromise share of 20%, going from ring size 5 to 10 decreases from 0.16% to 0.000051% and with an assumed compromise share of 80%, from 40% to 13%.”
12:52 PM Slack_4> serhack> Hello everyone, I agreed with sgp.
12:52 PM rehrar> smooth: “I suppose there are probably different views on how to interpret these numbers, but it is clear to me that both the numbers and character of the improvements changes greatly depending on the assumed compromise share, with no real basis to choose one assumption over another afaik.”
12:52 PM rehrar> He’s right that different people will see those numbers differently
12:53 PM rehrar> I realize we’re discussing 7 not 10, however.
12:53 PM rbrunner> If XMV flies high we might have a second such fork on our hands even before the next hardfork …
12:53 PM dEBRUYNE> rehrar: I think smooth’s point is that the output varies wildly based on what (arbitrary) input is given
12:53 PM +hyc> sure, the basic point is these are minimal changes that won’t make a night-and-day difference
12:53 PM ocinvfvsUIOIvdsb> Just like last week, we seem to have loose (or arguably farily strong) consensus, sans smooth and a few others. Can we agree on 7 as default and min?
12:54 PM knifeofpi> ocinvfvsuioivdsb: concur
12:54 PM ocinvfvsUIOIvdsb> I dont think we have debated fixed ring size enough yet to move to that (although many support fixing it)
12:54 PM @ArticMine> Going from 5 to 7 is significant privacy wise
12:54 PM sgp_> Yeah, last meeting we agreed this isn’t the time for a single fixed ringsize
12:55 PM @ArticMine> A singe fixed ringsize at this point is very premature
12:55 PM +hyc> right, one step at a time.
12:55 PM rehrar> #fixedringsizeseptember
12:55 PM sgp_> I think most people agree that an increase from 5 to 7 provides measurable benefits under realistic scenarios at limited cost
12:56 PM rehrar> Alright, so it comes down to it.
12:56 PM rehrar> We doing 7 min or not?
12:56 PM @ArticMine> Yes
12:56 PM ocinvfvsUIOIvdsb> yes +1
12:56 PM scoobybejesus> Aye
12:56 PM knifeofpi> Yes
12:56 PM Slack_4> serhack> +1
12:57 PM knifeofpi> So consensus is min-7?
12:57 PM Slack_4> janowitz> yes
12:57 PM rehrar> yes
12:57 PM ocinvfvsUIOIvdsb> We still need a pull request for fluffypony to merge on ring size issue
12:57 PM +moneromooo> It’s on my list.
12:57 PM rbrunner> Make it with love :)
12:57 PM sgp_> ty moneromooo
12:57 PM @fluffypony> 3
12:57 PM ocinvfvsUIOIvdsb> ty
12:57 PM sarang> In the interest of time, is there anything relating to BPs or the audit that there are questions on?
12:58 PM sarang> (he said, butting in)
12:58 PM +moneromooo> Moar Pippenger!
12:58 PM sarang> lol yes
12:58 PM sarang> Consensus seems to be split between 2 or 3 auditors
12:58 PM rehrar> Can we have it moved to funding required on Monday?
12:58 PM sarang> yep
12:58 PM sarang> that’s the plan
12:59 PM sgp_> good
12:59 PM sarang> I’ll prioritize 3 of them, with checkpoints
12:59 PM sarang> If we hit 2, we fund 2
12:59 PM sarang> If we hit 3, we fund 3
12:59 PM sarang> plain and simple
12:59 PM rehrar> Can we target all four?
12:59 PM rehrar> And if we hit three we fund three?
12:59 PM ocinvfvsUIOIvdsb> + 1 rehrat
12:59 PM rehrar> and if we hit four, we can do all four?
12:59 PM sarang> I think 4 is severely diminishing returns
12:59 PM rehrar> rehrat is the best name
12:59 PM ocinvfvsUIOIvdsb> why not checkpoints for 4?
12:59 PM sarang> I’d be happy with 2, TBH
12:59 PM sarang> But I’m also happy with 3
12:59 PM rbrunner> Yes, we may need XMR later for other important things
12:59 PM dEBRUYNE> 3 would be optimal imo
1:00 PM sarang> ^
1:00 PM dEBRUYNE> Sarang, the total will be for 3 then?
1:00 PM rehrar> Alright, we can just do three then. :)
1:00 PM sarang> Yep
1:00 PM dEBRUYNE> And dependent on the percentage we hit we pick 2 or 3
1:00 PM @ArticMine> There is a point of diminishing return here 3 is optimal
1:00 PM xmrmatterbridge> pinkphloid> Hi all
1:00 PM sarang> That gives 1 audit of the maths directly, and up to 2 on the implementation
1:00 PM rbrunner> Which is the 2?
1:00 PM sarang> Bunz will be first on the list
1:00 PM +moneromooo> If you want more reviewing, how about getting the second review group to review, say, multisig instead ?
1:00 PM sarang> Then QuarksLab, then Dudelski
1:00 PM sarang> *Kudelski
1:01 PM sarang> moneromooo: we’d have to do a separate SoW requst
1:01 PM dEBRUYNE> I’d prefer Kudelski Quarkslab and Buenz
1:01 PM sarang> dEBRUYNE: in that order?
1:01 PM dEBRUYNE> No not necessarily
1:01 PM xmrmatterbridge> pinkphloid> I’m on a flight from Fra to dxb so will probably lose signal. How this this update affect the wallet api. My lead dev doc is on too.
1:01 PM knifeofpi> excellent!
1:01 PM dEBRUYNE> I am quite sure we’d be able to get funding for 3
1:01 PM dEBRUYNE> especially if the general dev fund kickstarts the proposal
1:01 PM @fluffypony> definitely
1:01 PM ocinvfvsUIOIvdsb> +1 moneromooo idea for multisig review (in addition to the 2-3 based on checkpoints for bulletproofs)
1:01 PM +moneromooo> The wallet API will change, but I expect it will be backward compatible AFAIK.
1:01 PM rehrar> Alright, it’s past time. Shall we end, or do we want code disucssion?
1:02 PM rehrar> Can we also get a RingCT vet?
1:02 PM sarang> OK, expect FFS posting tomorrow
1:02 PM Slack_4> serhack> How will Wallet Api change moneromooo?
1:02 PM sarang> I think it’ll open the door to additional excellent discussion on future audits, which I’d love to see a part of our dev process for big new changes
1:02 PM — sarang is done talking now
1:02 PM +moneromooo> Well, since many people are reading, I want to point out that it would be good to publicize the existence of the key reuse mitigtions (mainly the ring db).
1:02 PM iDunk> moneromooo will never be the same, serhack.
1:03 PM ocinvfvsUIOIvdsb> the more review we have the easier it is to defend against FUD like this: https://twitter.com/matthew_d_green/status/832971753186029570
1:03 PM +hyc> meh. trollnoise.
1:03 PM +moneromooo> Especially to those people who will be using a key reusing fork. Spending safely is not hard (unless it’s really a key stealing trojan).
1:03 PM sgp_> Yes, the mitigations are very useful tools
1:03 PM rbrunner> You never win such fights …
1:03 PM @fluffypony> heh
1:03 PM rehrar> Alright. 6. Confirm next meeting date/time (for those who need to leave, discussion can continue after of course)
1:04 PM @fluffypony> whatever happened to the “next few months” besides MoneroLink, which was a fail
1:04 PM rehrar> Next week?
1:04 PM @fluffypony> rehrar: same time, same place, same pony, same moo
1:04 PM rehrar> March 11, 17:00 UTC