開發者會議紀錄 DevMeeting 20170820

  • RingCT 2.0團隊已與我們聯絡
    • 但目前這方案似乎不太可行,因RingCT2.0需要一個信任設置(trusted setup)的過程。
  • 在RingCT 2.0中,Tim Ruffing 提出了透過次級線性環狀簽名+CT的方案來改進 Monero
    • 這篇論文的作者為Time Ruffing、Sri Aravinda Krishnan Thyagarajan、Viktoria Ronge 跟 Dominique Schröder。
    • Knacc 將會把資訊統整後透過java來試著植入。
    • surae表示 RuffCT 極為有效的讓環狀簽名的容量大幅上升(100k以上)。 “有這個之後,幾乎每筆交易都可以輕鬆地直接跟半個區塊鍊的交易資訊環簽在一起”。
    • surae表示 “這感覺像是外星人突然降臨然後給我們比光速還快的移動能力”。
    • 後續在Reddit上Tim 解釋了100k以上的附註可能無法實行,但至少比現有的環簽容量提升許多。
    • 這方案有可能影響到MultiSig,因為現有的MultiSig程式碼都需要重寫,所以 MultiSig 應該會先用原樣發布,等到RuffCT上線後再重新植入。
  • 手機錢包的部分
    • “app store的帳號正在等待Apple要求的鄧白氏環球編碼(D-U-N-S)程序,已將文件掃描後寄到Google跟M$了”
  • 為了準備Monero即將到來的版本釋出跟分叉(還有其他東西),已在Github上開了新的分支。
  • 針對”專案要更頻繁釋出版本”的討論,這問題是會大幅增加開發者們的負擔,而且我們其實一年也已有數個版本在釋出了。
    • 上述提到的專案分支也許可以解決這個問題。

以上翻譯來自於紀錄原文: https://monerobase.com/wiki/DevMeeting_2017-08-20

完整會議紀錄:
fluffypony> 1. Greetings
fluffypony> 2. Brief review of what’s been completed since the previous meeting
fluffypony> 3. Code + ticket discussion / Q & A
fluffypony> 4. Any additional meeting items
fluffypony> 5. Confirm next meeting date/time
fluffypony> rehrar can do it next time :)
_Slack>
rehrar> I can, sorry for the confusion
fluffypony> 1. Greetings
fluffypony> can all the people who aren’t here just say nay
fluffypony> :-P
hyc> neigh
surae> we never get past this part : * athan (athan@c-24-8-115-79.hsd1.co.comcast.net) has joined
fluffypony> it’s a fun part
fluffypony> we can move on to 2
fluffypony> 2. Brief review of what’s been completed since the previous meeting
fluffypony> I guess the big thing is that we’ve branched * rehrar (
Critical@173-12-204-46-Albuquerque.hfc.comcastbusiness.net) has joined
surae> well
surae> from MRL
surae> we got contacted by RingCT2.0 people, and we got contacted by a rsearcher named Tim Ruffing, each of them presenting improved set-ups for our current implementations * Diffusive (Diffusive@200.8.144.192) has joined
surae> not sure if I should just jump in or what..
dEBRUYNE> Yeah go ahead
hyc> sure, go
surae> ok so * fzerosum has quit (Quit: Leaving)
surae> I have a .txt file describing the pseudocode of Ruffing’s sublinear ring sig + CT set-up
surae> knaccc has been going through it and implementing it in Java
surae> we have a surprising amount of it debugged
hyc> ^ note, we’re walking away from the RingCT2.0 stuff because it requires a trusted setup .
surae> Ah, I didn’t look into it because Ruffing’s doesn’t have a trusted set-up or any “new” crytpo. it just doubles all our key lengths
iDunk> surae: fpaste.org or pastebin.mozilla.org
sn0wmonster> has the meeting started?
endogenic> yes * atomicman has quit (Ping timeout: 248 seconds)
sn0wmonster> where does it say it started? jesus
surae> iDunk is 0bin not good enough? :P
iDunk> It requires java.
iDunk> js actually
moneromooo> I think it needs to be encrypted due to agreement with Tim Ruffing.
surae> oh i didn’t realize that
DaveyJones> surae … the mooo wants javaless paste
surae> moneromooo no, just habit
surae> ok one sec
moneromooo> Oh, ok. I’m dying to see it then :D
dEBRUYNE> You can put a password on fedoraproject, fwiw .
moneromooo> ty
surae> we are in the midst of debugging knaccc’s java code
dEBRUYNE> surae: Could you perhaps give an ELI5 (for anyone that reads the logs later) how RuffCT will improve our protocol?
surae> well, roughly, (ruffly)
knaccc> lol
surae> signature sizes are O(N) right now. So signature sizes take up “as much space” as the number of public keys implicated in the signature
surae> Ruffing’s set-up, for N=n^m, has signature sizes O(n*m). Verification and computation *it appears* to be on the same order. so, for example, to sign a ring signature with N=10^17 signers, which is freaking absurd, you would need “as much space” as 10*17 = 170 public keys
surae> there are constants and stuff, so it’s not exact, but at the very least, Ruffing’s set-up is looking at really absurdly large ring signatures
hyc> … without taking absurdly large amount of space
surae> with a set-up like this, there should be no good reason to not simply sign every transaction with the top half of the blockchain every time
surae> or taking absurdly large amounts of time to verify or compute
dEBRUYNE> So we can easily use ring size 100k for instance?
dEBRUYNE> Or even higher
hyc> even higher
fluffypony> EVEN HIGHER
surae> assuming his set-up actually works (the math seems tight) and assuming his security proofs hold up (I am going to try to make independent security proofs and then later compare them), and after six months to a year of testing, etc etc
surae> i mean
JollyMort[m]> UNLIMITED RINGSIZE
endogenic> fluffypony: what does the scouter say about monero’s ringsize level?
moneromooo> log(infinity) is infinity…
surae> in a certain sense, this is like an alien came down and gifted us faster than light travel. yeah, we can go out there and start traveling around, but we have to consider consequences for the timeline. :P haha
fluffypony> endogenic: I give up?
endogenic> it’s over 9000 * endogenic sees himself out
fluffypony> lol
DaveyJones> the puns are ruff today
fluffypony> also to add to what surae’s said
moneromooo> Would be need (pretty much) all pubkeys/commitments in RAM all the time, in order to verify such sigs ?
moneromooo> Or can some precomp be done ?
fluffypony> multisig isn’t baked in right now, it would need to be re-done from scratch
rehrar> the room fell silent
hyc> I’ll precompute it all for ya. trust me.
dEBRUYNE> fluffypony: Are we certain it has to be re-done from scratch or would it possible to just tweak the current implementation?
surae> moneromooo the signature itself only uses the commitments from the column of the signer
fluffypony> dEBRUYNE: we’re certain * dnaleor has quit (Quit: Leaving)
dEBRUYNE> k
DaveyJones> fluffypony - can it be dual run like pre-ct and ring-ct till the fork?
dEBRUYNE> I think we shouldn’t forego the current implementation, because we’re already quite far in
surae> debruyne the shen-luigi multisig set-up which is a version of the schnorr multisig, might lead us to a similar set-up for RuffCT, but it’s not a simple gluing like one would hope
dEBRUYNE> In addition, it may take a year before RuffCT is actually implemented
DaveyJones> so that we could keep luigi ms till ruff ms is done ?
dEBRUYNE> And even longer before we have a multisig that is compatible with ruffct
JollyMort[m]> you can always convert later
fluffypony> DaveyJones: I don’t think so, at least not trivially
JollyMort[m]> i mean if we have to do RCT->RuffCT
surae> dEBRUYNE I’m actually with you on that. chances are good RuffCT is about 1 year out from being live, and I wouldn’t be *shocked* if we could make a threshold scheme out of it before that year is up
JollyMort[m]> same can be done for wallets
JollyMort[m]> RCT multisig -> RuffCT multisig
fluffypony> well, basically this isn’t going in to a hardfork until we have multisig
msvb-lab> JollyMort[m]: hardware or software wallets? * Diffusive has quit (Remote host closed the connection)
tyrionmcmmaster> i agree with the majority, that multisig pre-ruffct should be implemented for the time being
JollyMort[m]> and shen/luigi multisig can work regardless of consensus rules
dEBRUYNE>
msvb-lab> JollyMort[m]: hardware or software wallets?
= Doesn’t matter
JollyMort[m]> by means of one-time multisig wallets
surae> so i’m happy finsihing up the shen-luigi multisig scheme, letting wallets use it until RuffCT goes live, they’ll still be able to use it for whatever RCT outputs are still floating around if they like… and maybe users may miss out on threshold signatures for one hardfork, but probably not two. * Diffusive (
Diffusive@200.8.144.192) has joined
hyc> that sounds decent
fluffypony> ok
DaveyJones> ^+1
fluffypony> guys let’s move on
surae> excellente
fluffypony> 3. Code + ticket discussion / Q & A
DaveyJones> can i chime in for the AFK devs?
fluffypony> before we discuss any specific PRs / issues
fluffypony> I wanted to get a feel as to how we should handle the branch wrt PRs
fluffypony> ie. do we want people to push PRs to both branches where relevant
fluffypony> or must I just cherry-pick commits?
moneromooo> Push to both, or the GPG signature drops. * Diffusive has quit (Client Quit)
fluffypony> moneromooo: I meant cherry-pick to my fork and then PR it
hyc> ok. but tat this pre-release time, how are we deciding which PRs are eligible for the release branch?
moneromooo> fluffypony: I don’t understand that.
moneromooo> If someone wants a patch to the release branch, they PR it to that branch too.
vtnerd> bug fixes should automatically be considered … everything else is subjective
fluffypony> vtnerd: it’s bug fixes only * tyrionmcmmaster has quit (Quit: Page closed)
moneromooo> I guess you can cherry-pick if the commit isn’t signed in the first place.
fluffypony> nothing else goes in, we’re in code freeze on the branch
fluffypony> moneromooo: if I cherry-pick and I sign it then it’s still signed?
vtnerd> ok good, at least we are in agreement on that
moneromooo> Well, it’s signed by you, yes…
moneromooo> But you’re kinda not the author ? :)
fluffypony> moneromooo: with cherry-pick it lists both myself and the aithor iirc
fluffypony> *author
moneromooo> I guess nobody really cares anyway.
moneromooo> Yes, but the author’s signature drops AFAIK.
moneromooo> So you could modify a large patch, sign it, and nobody would notice.
iDunk> I agree with moneromooo, that’s not the way to do it.
hyc> ok, so PR directly to release branch
fluffypony> moneromooo: https://i.imgur.com/PG0YmsF.png

  • like that
    hyc> there’s 22 open PRs at the moment. only a few seem to be current bugfixes
    moneromooo> Most people will just PR to master anyway, so not much trouble.
    moneromooo> I’m not sure I get the point.
    fluffypony> ok this is more about the fallback if the contributor doesn’t PR to the branch in a timeous fashion
    moneromooo> In that case, if it’s really needed for the branch, cherry-pick is OK I suppose. * atomicman (bbhgf@endeavour.whatbox.ca) has joined
    fluffypony> ok cool
    hyc> but re: the branch, I’d like #2313 and #2314 to go into the release. should help further reduce chance of corruption on powerfail.
    moneromooo> Agreed.
    moneromooo> I’ll just fixup the target thing too.
    hyc> cool
    moneromooo> I think just removing the state check will be fine.
    fluffypony> yes * shillosopher has quit (Quit: shillosopher) * shillosopher (
    shillosop@unaffiliated/shillosopher) has joined
    fluffypony> if those can be PRd to the branch that would be great
    hyc> willdo * monero (monero@192.30.252.40) has joined
    monero> [monero] hyc opened pull request #2318: Dbcleanup (release-v0.11.0.0…dbcleanup) https://git.io/v5fO3 * monero (
    monero@192.30.252.40) has left
    fluffypony> ok - anything else?
    JollyMort[m]> about GUI cold signing
    JollyMort[m]> any plans to add import/export outputs&keyimage stuffs
    msvb-lab> fluffypony: Not sure when it’s appropriate to ask for consensus on (yes) increase efforts towards a hardware wallet or (no) maintain status quo.
    fluffypony> what’s everyone’s feelings on merging 0MQ into master? * monero (monero@192.30.252.34) has joined
    monero> [monero] hyc opened pull request #2319: Safesync (release-v0.11.0.0…safesync) https://git.io/v5fOC * monero (
    monero@192.30.252.34) has left
    DaveyJones> so tewinget only said that he just wants further feedback
    dEBRUYNE> JollyMort[m]: Jaquee isn’t here afaik
    DaveyJones> and jaquee asked this
    Jaquee> i’m here now
    hyc> I thought merging 0MQ is slated for after the release
    DaveyJones>
    Jaquee> not sure if i can make it to the meeting. have two questions. 1. updates on disk space on build machines (when can we have an android apk available for download?) 2. updates on app store and transifex accounts?
    Jaquee> reading backlog
    moneromooo> After the release is done, yes.
    DaveyJones> oh your here :D
    fluffypony> we’ve already branched, tho, so surely we can merge to master?
    moneromooo> his here.
    fluffypony> msvb-lab: the dev working group don’t really control external manufacturers
    dEBRUYNE> fluffypony: moneromooo wants to put in an additional review afaik
    moneromooo> I’ve not looked at the latest changes yet.
    dEBRUYNE> And tewinget is waiting for further feedback
    fluffypony> ok
    Jaquee> but maybe lightwallets PR can be merged? (in masteR)
    pigeons1[m]> Jaquee we got the build machine so early this week on the android jobs
    rehrar> regarding the transifex account, I’ve found an open-source, self-hosted alternative in weblate.org
    medusa_> i dont think the fact if we branched mathers too much regradiing 0mq
    Jaquee> pigeons1[m]: Great!
    rehrar> just waiting on the new server infrastructure :)
    medusa_> we should play it safe
    moneromooo> If the lightwallet stuff is the same I reviewed already, it was OK to merge IIRC.
    Jaquee> it’s the same
    fluffypony> kk .
    dEBRUYNE> ^ Not sure we should put that up on SE already
    sn0wmonster> i have a suggestion for future meetings, let me know when i can make it.
    JollyMort[m]> yeah i thought that too dEBRUYNE
    JollyMort[m]> surae what do you think?
    fluffypony> yeah I think some of this is confidential-ish
    hyc> are we still on ticket discussion?
    DaveyJones> aye
    JollyMort[m]> i mean, putting it in the meeting logs also makes it public
    JollyMort[m]> the genie is out of the bottle
    dEBRUYNE> I can just remove it from the logs
    fluffypony> hyc: about to move on, but you can still bring stuff up
    hyc> no that’s fine
    dEBRUYNE> JollyMort[m] ^
    hyc> let’s move on
    dEBRUYNE> fluffypony: Jaquee wanted to know about the appstore accounts btw
    fluffypony> surae should weigh in on that
    dEBRUYNE> If you have any update on that
    Jaquee> ^^
    fluffypony> app store accounts are waiting on the D-U-N-S number to be sent to Apple, I’ve sent scans of docs to Google and M$
    fluffypony> so Two Weeks™ ?
    fluffypony> 4. Any additional meeting items
  • moving on to that
    fluffypony> since it’s part of it anyway
    sn0wmonster> is this where i can make a suggestion?
    fluffypony> sn0wmonster wanted to make a suggestion
    sn0wmonster> yay
    sn0wmonster> so, i noticed the meeting started only after it was obvious it was a meeting
    sn0wmonster> i don’t see a Meetbot (which apparently is a package in Debian),
    sn0wmonster> so if you must do it this way, i was wondering if you wouldn’t make it painfully obvious to everyone with a header of some kind, like this: * archLinuxUser (archlinux@unaffiliated/archlinuxuser) has joined
    othe> msvb-lab asked a question but got overrun, i am willing to help sponsor his hw wallet stufdlf
    othe> Stuff
    sn0wmonster> +——————————————————————————-+
    sn0wmonster> | –+ossssso+– |
    sn0wmonster> | .-ossssssssssssso+- Monero Developers Meeting, #monero-dev |
    sn0wmonster> | -sosssssssssssssssos+. August 20th, 2017 17:00 UTC |
    msvb-lab> Both FFS proposals relating to hardware wallets are on the forum now.
    sn0wmonster> | oss::osssssssssso+::ss+. |
    sn0wmonster> | +sss: :+ossssso+: :sss+ Agenda: Greetings, Brief review of what’s been |
    sn0wmonster> | ssss: -+sss+-`` :ssss completed since the previous meeting, Code + | sn0wmonster> | ssss: :.``-+-``.: :ssss ticket discussion / Q & A, Any additional |
    sn0wmonster> | +ooo- :::. .::: -ooo+ meeting items, Confirm next meeting date/time | moneromooo> No span please :/ sn0wmonster> | ````` :::::-::::: ````` |
    moneromooo> spam even ffs
    sn0wmonster> | -:::::::::::::::::::- | endogenic> lol JollyMort\[m\]> my eyes! JollyMort\[m\]> sn0wmonster: there WAS a intro sn0wmonster> pff, if you consider that spam, then there goes my suggestion ;) fluffypony> also the time is set two weeks in advance sn0wmonster> /flushq pigeons1\[m\]> Sn0wmonster makes a great meeting bot hyc> it's also announced on reddit and github sn0wmonster> beep bop boop othe> Ffs sake, there are 2 hw wallet proposals. Feedback appreciated. msvb-lab> othe: If anyone has advice on what to change in those FFS, the URLs are: msvb-lab> https://forum.getmonero.org/7/open-tasks/88149/dedicated-monero-hardware-wallet/ hyc> and was announced here a few hours earlier msvb-lab> https://forum.getmonero.org/7/open-tasks/88160/monero-firmware-for-ledger-wallet/ endogenic> sn0wmonster: https://github.com/monero-project/meta/issues fluffypony> sn0wmonster: https://www.reddit.com/r/Monero/comments/6uvu94/dev\_kovri\_meetings\_later\_today\_1700\_1800\_utc/ DaveyJones> shhh listen to othe and msvb-lab sn0wmonster> i didn't say it wasn't known, i said the \*chatlog\* had no introduction that the meeting had started really endogenic> sn0wmonster: it did though ? JollyMort\[m\]> i'm saying it had :) first post by fluffypony with the agenda 0. .. 1. .. 2.. ... JollyMort\[m\]> maybe you missed it msvb-lab> DaveyJones: Rather than listen, please speak whoever is interested in hardware crypto and border searches. rehrar> but it didn't have the Monero symbol endogenic> msvb-lab: doesn't quite seem like a dev item tho hyc> yeah, I think we can put that meeting announcement topic to rest. DaveyJones> msvb-lab they cannot speak if they dont listen :D
    moneromooo> In other code news: I’m still debugging sync niggles with iDunk’s help (who’s been doing a LOT of testing, so many thanks). It’ll be ready soon (both branch and master).
    rehrar> msvb-lab: we can talk about it in Community meeting next week?
    msvb-lab> endogenic: Okay, let’s postpone. Good idea rehrar.
    JollyMort[m]> about the gui cold signing
    iDunk> Yw :)
    JollyMort[m]> it’s still missing features
    moneromooo> If someone feels like syncing, please try the sync-standby3 branch :)
    endogenic> msvb-lab: no need to post-pone. maybe bring it up in #Monero ?
    dEBRUYNE> rehrar, endogenic: If there’s room left, why not give msvb-lab the floor for a few minutes? * hribayz (
    hribayz@krupka.kolej.mff.cuni.cz) has joined
    moneromooo> It may not be code per se, but it’s tech. I think it’s fine here. Still 10 minutes.
    othe> I’ll just sponsor it, its hilarious that there’s no secure way to store xmr.
    endogenic> kk
    fluffypony> msvb-lab: a dedicated wallet would be cool
    rehrar> well that’s decided then isn’t it?
    msvb-lab> So the question is if we can achieve consensus on how to lower risk of another year with no wallet.
    hyc> there are two proposals tho, do we have to pick one, or do both?
    msvb-lab> hw wallet, i mean.
    fluffypony> Ledger are already working on it, not sure if we need to double up efforts there
    dEBRUYNE> Perhaps it’d be more beneficial if we have some general firmware that hw wallets could implement
    surae> gosh, sorry, i got distracted. no, please don’t put up a stackexchange yet. a few weeks, no problem, but right now we should maybe keep it a little quieter~
    surae> if possible
    surae> cat’s out of the bag, but i mean
    msvb-lab> hyc: One deals with dedicated hardware design, the other with porting to existing hardware.
    fluffypony> msvb-lab: https://www.reddit.com/r/Monero/comments/6thv8j/ledger\_hardware\_wallet\_monero\_integration/
  • this is from 6 days ago
    endogenic> 2quick4u fyi
    msvb-lab> fluffypony: That’s probably Cedric’s document Blue-something, quite good.
    dEBRUYNE>
    msvb-lab> hyc: One deals with dedicated hardware design, the other with porting to existing hardware.
    = Even though the former would be pretty cool, the latter is probably more beneficial
    JollyMort[m]> and debruyne **** out the link then; i feel like simply removing stuff from the logs goes against some principle on transparency
    hyc> looks to me like Ledger has done the hard part of figuring out the division of labor between hw wallet and Monero libraries
    Jaquee> ledger said alpha around end of september iirc.
    fluffypony> I don’t think there’s value in doubling up on the Ledger effort
    hyc> ^^ agreed
    dEBRUYNE> What about porting to Trezor and Keepkey though?
    Jaquee> +1
    msvb-lab> There have been firmware ports (to Trezor) before that have not met Monero’s feature set (RingCT) or unmaintained.
    dEBRUYNE> Perhaps msvb-lab is interested in finishing noodle’s code?
    fluffypony> msvb-lab: Trezor was more complicated than that
    msvb-lab> I just hope if Cedric completes the port, that there is maintenance after that.
    fluffypony> NoodleDoodle did the Trezor firmware
    JollyMort[m]> Cedric is the Ledger crypto-guy
    ferretinjapan> fluffypony, choice is always a good thing WRT HWE wallets, otherwise we may get centralisation of support/development/monopoly of service, etc.
    hyc> I’d say we pick up whatever changes ledger comes up with and use that as a basis for other hw projects
    fluffypony> then there was a bit of a disagreement between Trezor and us
    JollyMort[m]> afaik
    fwrttrukjwtrijdh> sorry, noticed objections above to SE questions. Will delete for now. Does same objection apply to both Ruffling and RingCT2.0 paper?
    fluffypony> and then I met up with them 33c3, and they said that it’s not worth us moving forward on it till Trezor 2.0
    hyc> if all the wallets use the same handshakes that saves everyone effort
    fluffypony> which was Coming Soon™
    moneromooo> Tim Ruffing requested keeping is internal as a courtesy. I don’t think anhything like that applies to Ringct 2.0. * Foobar__ (d5e108da@gateway/web/freenode/ip.213.225.8.218) has joined
    dEBRUYNE> The 2.0 paper was posted on reddit too :P
    hyc> that’s as close as we’ll get to a “common firmware” - other hw wallets will be based on different chips anyway
    msvb-lab> Not sure how stable (management or technically) Trezor is, hoping Cedric follows through on the Ledger work is a possibility. We then do little or nothing and wait for results.
    fluffypony> msvb-lab: I’d support effort on a dedicated HW wallet
    JollyMort[m]> chip design etc? that sounds good
    JollyMort[m]> especially if all the schematics are published
    msvb-lab> Something that interests me is adding Monero specific features to a dedicated wallet, and make it as border search proof as possible (not supported by Ledger.) * herch has quit (Ping timeout: 260 seconds)
    JollyMort[m]> so anyone can buy the parts and build it
    hyc> lol. I’m not soldering surface-mount chips by myself.
    msvb-lab> JollyMort[m]: Everything would be designed with KiCad and published in a github or similar.
    sn0wmonster> what is not border-proof about ledger?
    msvb-lab> hyc: I have a SMD lab, reflow and all.
    ferretinjapan> hyc, what’s the problem? All you do is put it in the oven ;)
    msvb-lab> sn0wmonster: No ability to destroy the private key without battery. * dnaleor (dnaleor@78-23-74-78.access.telenet.be) has joined
    fluffypony> avoiding the glitching attacks just demonstrated against Trezor will be fun
    hyc> let’s just say I’ve overcooked a few microcontrollers in my day…
    endogenic> hyc: you need an intern or two
    JollyMort[m]> hyc baking bad :)
    msvb-lab> fluffypony: Yes, glitch defense is part of the design. I’m not sure it’s possible at all, but there will be research.
    fluffypony> cool beans
    dEBRUYNE> fluffypony: Do we still have time, I wanted to suggest something more generally?
    msvb-lab> fluffypony: Randomness probably plays an important role, so we have chips like ATSHA240A.
    DaveyJones> so dedicated hw of the two it will be ? so we can come to a conclusion before the end of meeting
    JollyMort[m]> Jaquee: would it be too much effort to add the import/export stuffs into gui
    msvb-lab> dEBRUYNE: Let’s close off hw wallets now, but everyone please add a post to the FFS if you have a strong opinion.
    msvb-lab> Thanks for the floor folks!
    JollyMort[m]> would be nice to avoid depending on the CLI to fix cold signing glitches
    dEBRUYNE> All right, I’ll leave a comment later msvb-lab :)
    JollyMort[m]> and some use cases require import/export stuffs
    dEBRUYNE> I personally wanted to raise the idea to release more often (e.g. a new release every quarter) to (i) tighten and improve the feedback loop and (ii) decrease time spend on helping out people that incur issues that are already long fixed in master
    Jaquee> JollyMort[m]: not that much effort. problem is that code is frozen in monero. so wont make into this coming release
    dEBRUYNE> I spoke with fluffypony about this in private and he was concerned it would put too much pressure on contributors
    JollyMort[m]> :(
    dEBRUYNE> So I’d like to hear their opinion about it
    Jaquee> i added some improvements yesterday
    dEBRUYNE> I guess I should mainly page Jaquee, moneromooo, hyc, iDunk
    JollyMort[m]> i saw, haven’t tested it yet
    dEBRUYNE> ^ apologies if I forgot someone :P * redfish has quit (Remote host closed the connection)
    hyc> “release early, release often”
    JollyMort[m]> i’ll check it out
    moneromooo> I think it’d put too much pressure on the pony.
    dEBRUYNE> hyc: Right, that was kind of my basis for the idea
    Jaquee> i’d love to release more often * redfish (
    redfish@163.172.173.182) has joined
    hyc> I think having another interim release would be nice
    moneromooo> He barely has the time to do anything AIUI.
    dEBRUYNE> moneromooo: Could this be mitigated if we had an additional maintainer?
    endogenic> i think it’s funny when people say “fail fast”
    fluffypony> we need to bear in mind that this is security software
    dEBRUYNE> I think luigi wanted to do an FFS soon for it
    moneromooo> Who would you trust which can do it ?
    moneromooo> hyc! * moneromooo flees
    hyc> :P * Robotrock (robert.fr@p5DF4A5E9.dip0.t-ipconnect.de) has joined
    dEBRUYNE> Well luigi could merge stuff and FP release?
    fluffypony> I don’t think we should be pushing to release unstable software :-P
    DaveyJones> hyc or the luigi1115
    fluffypony> an additional maintainer won’t make software magically stable :-P
    hyc> true
    dEBRUYNE> fluffypony: No, but it would take time away that you have to spend on merging and reviewing stuff
    ferretinjapan> I’d just like to say that a backup maintainer should be seriously considered, even if the release schedule stays the same, there’s nothing like redundancy…
    fluffypony> we need way more eyes on PRs than that
    fluffypony> ferretinjapan: we already have backups
    dEBRUYNE> Also, those large merging waves inhibit the momentum of the project imo
    ferretinjapan> ah, goodo
    medusa_> the lack of follow up bugfix releases causes huuge amunt of support work
    fluffypony> the Core Team have access, and luigi1115 is my direct backup
    fluffypony> medusa_: we’ve already solved that
    medusa_> how?
    rehrar> What if one release added content, and the intermin is just bug fixes?
    fluffypony> with the branch
    dEBRUYNE>
    fluffypony> I don’t think we should be pushing to release unstable software :-P
    = Not saying we should, but if master is deemed stable we could put out a release with a few new features right?
    medusa_> so this time we going to have a follow up release 100% ?
    medusa_> like 2 weeks later
    fluffypony> medusa_: it depends on if there are bug fixes
    dEBRUYNE> There are always bug fixes
    dEBRUYNE> :P
    medusa_> well depends on severity i agree
    medusa_> of the bug
    ferretinjapan> dEBRUYNE, what about early beta releases? Say just before the freeze?
    JollyMort[m]> for one thing, i would love to see cold signing stuffs added asap; feel like it’s an important feature to those who don’t want to use CLI for the same thing
    JollyMort[m]> and be able to resolve any problem people may have by using GUI functions
    ferretinjapan> or an “experimental” release?
    hyc> can we just get people to use a nightly build, for bugfix verification?
    dEBRUYNE> ferretinjapan: That seems suboptimal, as there would be new binaries a few weeks later
    _Slack>
    bigreddmachine> Isn’t that what the nightly builds are?
    hyc> and then at some point we can decide if we have something stable enough for another release
    medusa_> if we potentially want to keep the branch that long, we should also slow down with merging stuff in trunk (especially 0mg)
    medusa_> until we can estimate the quality of the branch somehow
    fluffypony> just looking at the recent releases, I don’t think there have been a lack of them
    fluffypony> Sep 19, 2016: 0.10.0
    fluffypony> Dec 13, 2016: 0.10.1
    fluffypony> Feb 23, 2017: 0.10.2
    fluffypony> Feb 24, 2017: 0.10.2.1
    fluffypony> Mar 26, 2017: 0.10.3
    fluffypony> Mar 26, 2017: 0.10.3.1
    medusa_> otherwise we risk, dpeending on buigs we have after release, to end up in a hairy position
    hyc> so it sounds like release-as-needed is working
    fluffypony> yeah, I’m not really seeing a lack of releases there * magic_circle (
    magic_cir@x590de3fd.dyn.telefonica.de) has joined
    moneromooo> especially on march the 26th.
    hyc> heh
    JollyMort[m]> release density == nan
    ferretinjapan> The last 5 months have been rather quiet, but I don’t think it’s all bad.
    medusa_> those 1d releases dont yount
    medusa_> they fix emergency stuff
    ferretinjapan> You guys were busy with making sure ringct was solid after all…
    medusa_> we talk about follow up releases, with 2 weeks in between
    medusa_> we enever do that
    ferretinjapan> and then there was that bug…
    hyc> 2 weeks seems too soon for a scheduled followup
    _Slack>
    bigreddmachine> Q before meeting is over. What kinds of things need to be studied on the PoW change proposal? I’m happy to dig into that but would like some direction if possible.
    hyc> and 5 months since the last release seems too long
    endogenic> bidreddmachine: what problem necessitates that?
    dEBRUYNE> hyc: If the release merely intends to fix bugs of the latest release, is two weeks too soon?
    endogenic> the PoW change * onefox (onefox@p579012D6.dip0.t-ipconnect.de) has joined
    hyc> dEBRUYNE: I presume bug fix releases go out as soon as available
    dEBRUYNE> But we haven’t done that in the past
    hyc> e.g., for emergency fixes
    dEBRUYNE> That’s the issue medusa_ is raising
    hyc> otherwise, if it’s not urgent, 2 weeks seems short.
    msvb-lab> has the meeting officially ended, one hour right? * gethh has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
    fluffypony> well in the past 5 months we haven’t really been able to release stable + bug fixes
    DaveyJones> afaik the GUI had/has a bug that freeze’s the wallet on some system thats already fixed but never got released … thats what your talking about medusa_ ?
    _Slack>
    bigreddmachine> endogenic: some things were raised in the thread on GitHub. I wouldn’t be going into it saying “this needs to happen” but rather trying to dissect the potential issues and see if there is anything to be gained.
    fluffypony> because we didn’t branch
    fluffypony> now we branch * redfish has quit (Remote host closed the connection)
    fluffypony> so it seems like we’re discussing something we’ve already fixed…?
    dEBRUYNE> DaveyJones: Yes, which causes a lot of support issues
    medusa_> well we expect you to be around and build a bin
    medusa_> if thats all fine that its all good
    hyc> yeah sounds like it’s fixed already
    dEBRUYNE> fluffypony: For the GUI, for example, we’re still helping people that incur bugs from GUI beta 2
    dEBRUYNE> That were fixed a week after the release
    hyc> 3 months from now we can raise the question of an interim release if there haven’t already been a slew of releases * atomicman has quit (Ping timeout: 240 seconds)
    fluffypony> dEBRUYNE: I know what the issue was, hence the branching thing
    medusa_> its also a time and tacting thing
    medusa_> if we plan to let the branch live that long you will need to thread the trunk differently
    dEBRUYNE> fluffypony: So if I understand the branching correctly, we’ll release from the branch and if too much annoying bugs are found in the release version, we’ll do a follow up point release to include fixes?
    medusa_> it has a lof of effects
    msvb-lab> netsplit for me i guess…
    _Slack>
    bigreddmachine> With branching now, couldn’t we just have monthly release candidates or something?
    fluffypony> dEBRUYNE: yes - follow-up releases are based off the branch
    rehrar> I know we’re already over, but can we get a brief update regarding Sarang’s FFS?
    moneromooo> How about we don’t spam the pony yet ? Let’s wait, and maybe do a release from the branch if there are bugs we want fixed.
    fluffypony> @bigreddmachine no need to timeframe it, we’ll release when there are bug fixes part of the branch that make it worth releasing
    fluffypony> ie. major bug fixes
    hyc> agreed
    _Slack>
    bigreddmachine> Fluffy, I just meant a pseudostable branch that’s a bit more tested than the nightlies.
    dEBRUYNE>
    fluffypony> dEBRUYNE: yes - follow-up releases are based off the branch
    = All right, well, let’s see how that will go then
    fluffypony> not spelling errors or whatevs
    _Slack>
    bigreddmachine> But not an actual release.
    _Slack>
    bigreddmachine> Maybe that’s a “2 years down the road” thing
    fluffypony> @bigreddmachine you mean off the main branch or the release branch?
    moneromooo> We tried that before, it was a massive pita.
    hyc> can the build system do nightlies of the release branch too?
    fluffypony> hyc: pretty sure, yeah
    _Slack>
    bigreddmachine> I meant as its own branch… Commits get tested, when somewhat sure moved to release candidates, which is still unstable, and then when that’s tested moves to the actual release. Probably a pita like mooo said * fwrttrukjwtrijdh has quit (Quit: Page closed)
    fluffypony> pigeons1[m]: ^^
    fluffypony> yeah complete PITA
    _Slack>
    bigreddmachine> Okay just brainstorming
    pigeons> yes, i’ll setup jobs for the release branch * pizzasushibeer (adefe661@gateway/web/freenode/ip.173.239.230.97) has joined
    hyc> that ought to be good enough then as far as release candidates go * Foobar__ has quit (Ping timeout: 260 seconds)
    fluffypony> re: sarang, pero were your questions satisfied?
    pizzasushibeer> As a supporter of Ledger see nothing wrong with the community funding a 2nd hw wallet initiative. More options are beneficial and im sure many of us already own multiple Bitcoin hw wallet types for a variety of reasons
    DaveyJones> pero is rarely available this week @ fluffypony
    dEBRUYNE> fluffypony: I think sarang was rewriting the proposal, but I am not sure if he has finished yet
    fluffypony> ok * john_alan has quit (Quit: Connection closed for inactivity)
    pizzasushibeer> If the community is willing to fund, it I see nothing wrong with moving proposal to funding required (after any more required clarifications are made)
    sn0wmonster> i think i’m gonna bother these guys to make a patch for their box for Monero http://bitseed.org/ * rehrar has quit (Ping timeout: 240 seconds)
    sn0wmonster> wrong channel
    pizzasushibeer> I would help contribute to the hardware wallet proposal. Im sure others agree
    pigeons> if pero’s questions aren’t answered maybe post a forum reply reminding him that so sarang can see clearly its outstanding still
    hyc> yeah I recall pero was going to be unavailable for the next week or two
    ferretinjapan> pizzasushibeer, I’m another person and I agree. * msvb-lab has quit (Read error: Connection timed out)
    _Slack>
    scoobybejesus> sarang was about to post clarifications to his ffs a couple times recently. it’s been mentioned more than once on #mrl * pizzasushibeer has quit (Quit: Page closed)
    hyc> ok, we’re 25minutes over. any more stuff?
    dEBRUYNE> Guess not :-P * atomicman (
    bbhgf@c-98-237-104-21.hsd1.pa.comcast.net) has joined
    DaveyJones> would it be possible that -site maybe gets an additional maintainer ?
    DaveyJones> afaik it less to no coding stuff and maybe people like dEBRUYNE or rehrar would be able to maintain it… so no need to bother you fluffypony ^ ^
    fluffypony> DaveyJones: we’re working on alternatives, probably doing something based off issue helper
    DaveyJones> fine :)
    JollyMort[m]> binaries and .raw downloads are high-sec
    fluffypony> ^^
    _Slack>
    rehrar> Ye. Responsibility is scary.
    fluffypony> so issue helper could be used to trigger merges where it doesn’t touch sensitive parts of the site
    _Slack>
    rehrar> Dude, that’s awesome.
    _Slack>
    rehrar> For all those little merchant merges
    DaveyJones> yeah i had things like merchants in mind
    dEBRUYNE> And then we could give the issue helper trusted community members access to the issue helper right?
    dEBRUYNE> ^ fluffypony
    _Slack>
    rehrar> We eventually should drop support for Merchants on the site tbh imo
    fluffypony> dEBRUYNE: yes
    fluffypony> rehrar: why?
    moneromooo> It’s a good, if small, incentive for people to support monero.
    moneromooo> And for connecting monero spenders with monero earners.
    _Slack>
    rehrar> As Monero grows it will become gigantic eventually, but maybe that’s not a huge issue.
    _Slack>
    rehrar> Just my thoughts.
    hyc> success problems are nice to have. we’re not there yet
    moneromooo> Oh, sure. Once Monero’s world reserve currency, it can go :)
    DaveyJones> ^ but only then
    dEBRUYNE> fluffypony: All right, seems cool. That’d also relieve you from some “low hanging fruit” work
    dEBRUYNE> Which still can be quite time consuming
    fluffypony> yup
    DaveyJones> but maybe we should put up some kind of Disclaimer
    DaveyJones> in case some service goes rogue
    sn0wmonster> which judging by bitcoin’s history, is not a matter of if, but when
    DaveyJones> “this is just a list of merchants, and no appraisement by the core team”
    _Slack>
    rehrar> I’m actually going to be going g through all the Merchants this week to find the dead websites.
    moneromooo> Warning: the monero team does not control Amazon, odd as it might seem to you.
    pigeons> cryptokingdoms
    pigeons> for example
    moneromooo> CK’s kinda back from the moribund actually.
    pigeons> ok
    _Slack>
    rehrar> Meeting = end?
    DaveyJones> sure