- 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 joinedCritical@173-12-204-46-Albuquerque.hfc.comcastbusiness.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 (
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 joinedDiffusive@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 (
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 joinedshillosop@unaffiliated/shillosopher) 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 (
fluffypony> if those can be PRd to the branch that would be great
hyc> willdo * monero (monero@192.30.252.40) has joinedmonero@192.30.252.40) has left
monero> [monero] hyc opened pull request #2318: Dbcleanup (release-v0.11.0.0…dbcleanup) https://git.io/v5fO3 * monero (
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 joinedmonero@192.30.252.34) has left
monero> [monero] hyc opened pull request #2319: Safesync (release-v0.11.0.0…safesync) https://git.io/v5fOC * monero (
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 joinedhribayz@krupka.kolej.mff.cuni.cz) 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 (
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 joinedredfish@163.172.173.182) 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 (
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 joinedmagic_cir@x590de3fd.dyn.telefonica.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 (
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 joinedbbhgf@c-98-237-104-21.hsd1.pa.comcast.net) 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 (
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