Monero Dev Meeting Note Highlights – 2017-12-17
Logs
351 lines
fluffypony1. Greetings
fluffypony2. Brief review of what's been completed since the previous meeting
fluffypony3. March hardfork items + code freeze
fluffypony4. Code + ticket discussion / Q & A
fluffypony5. Any additional meeting items
fluffypony6. Confirm next meeting date/time
fluffyponyI think we've done 1. so we'll skip it
fluffypony2. Brief review of what's been completed since the previous meeting
fluffyponywell Bulletproofs went live on testnet
fluffyponyso there's that
fluffyponyand we merged some stuff
fluffyponymoneromooo: anything in particular you want to highlight?
moneromoooAh, whether to enable them for v7 or v8 on mainnet.
fluffyponythat's the next point
fluffyponyI meant anything in 2. you want to highlight :)
moneromoooNot in particular, no.
HUCK45Hey all, I just saw that awesome project recently and a question came to my mind- why there isn’t any option for GPU mining instead of CPU? Browsers these days allow that, by webgl for example (depending on the user settings, but on default it uses gpu)
fluffyponyHUCK45: we're in a meeting - feel free to take that to #monero
rehrarHUCK45 we're in a dev meeting right now. :) This'll have to wait.
suraeNoetheras far as MRL is concerned: the math on bulletproofs seems tight, but the best test for cryptography is time
fluffyponyok so I'll highlight a few PRs
fluffyponysuraeNoether: not there yet
suraeNoetheroh woops
fluffypony#2878 tightens up –offline mode by disabling DNS lookups
fluffypony#2877 refactors a bunch of p2p stuff
fluffyponyand then the obvious bug fixes and improvements
fluffyponyBulletproofs on testnet is in #2883
fluffyponywhich brings us to 3. March hardfork items + code freeze
fluffyponyso v7 already has sorted inputs
fluffyponymoneromooo: do you want to explain that?
moneromoooSorted inputs? Or bp ?
moneromoooI assume bp. They're just a smaller sized range proof system.
fluffyponysorted inputs
fluffyponyI assume everyone knows what BP is
moneromoooWell, just… sort inputs by their key image. Nothing more.
iDunkIs it like unsorted inputs, but sorted ?
fluffyponyiDunk: kinda
gingeropolousand why sort?
moneromoooKinda :)
fluffyponygingeropolous: that's the big question
iDunkCool :)
gingeropolous:)
fluffyponyit's to prevent metadata leaking
fluffyponyeg. the specific wallet used for a tx
moneromoooTo avoid broken implementations leak stuff. It'd be better for outputs (ie, always put change last, etc), but unfortunately it doesn't work for outputs as the keys depend on their index.
moneromoooIt has become hairy after subaddresses unfortunately, at least for the small benefit.
luigi1111wwhich?
moneromoooWhat is the question ?
luigi1111wwhat is "it"
fluffyponyordering outputs
moneromoooinputs.
luigi1111wsubaddress or multisig?
moneromoooI'll rephrase:
moneromoooThe input sorting code has become hairy after subaddresses unfortunately, at least for the small benefit.
luigi1111wyes that was clear, just not why
luigi1111wwell was clear after <moneromooo> inputs.
moneromoooBecause the sorting was internal to construct_tx before, now it's changed in the caller as well.
luigi1111wok
moneromoooSo that means you have to order selected_transfers too, and possible something else, can't recall exactly.
moneromoooAnyway, it's just minutiae particular to our wallet code.
luigi1111wbtw, change being last doesn't leak metadata
moneromoooIt doesn't leak that change is that ?
moneromoooIt doesn't leak that change is last ?
luigi1111wright
luigi1111wor what wallet was used
moneromoooOK, it leaks that change is more likely to be last than otherwise.
luigi1111wis it?
luigi1111wwhat if a popular wallet puts it first
moneromooox+epsilon > x, even if epsilon is very small.
moneromooo(assuming epsilon is positive)
fluffyponyluigi1111w: the onus is on wallets to follow the pattern
luigi1111wwhat pattern
luigi1111wwhy is there a pattern
moneromoooI'm lost here, I'll wait.
luigi1111wme too :)
moneromoooMaybe ask your question again, rephrased :)
pigeonsI guess if there is an intentional pattern, there won't be several accidental identifying ones
rbrunnerFingerprinting wallets?
luigi1111wmy point is chnage isn't a fingerprinting pattern for wallets
luigi1111wwell my new point, whatever
luigi1111wanyway it doesn't really matter as we're not doing it anyway
fluffyponyok let's talk about Bulletproofs then
fluffyponysuraeNoether: your turn :)
suraeNoetherwhelp, i pretty much had my piece in terms of bulletproofs: there isn't a research-oriented approach to answer if they are ready for implementation.
suraeNoetherthe best test for crypto is use and time.
suraeNoetherthe math has been reviewed, looks tight. it may feel like it's being put into production too soon, but…
suraeNoetherany time we implement something new, we take some risks in that regard
suraeNoetherit looks to me like a no-brainer drop-in replacement for our current range proofs, and to sarang it seems fine. the coding is done.
msvb-mobsuraeNoether: Is there a way to merge new features on testnet only?
msvb-mobMaybe a risk reduction strategy I mean?
suraeNoetherafaik BP is already on testnet as of … today?
moneromoooAs of a week back or so.
suraeNoetherah there you go
msvb-mobSo we have at least that granularity, okay.
luigi1111wI'm going through the code and have some questions
suraeNoetheryeah, i mean
suraeNoetherluigi1111w: sarang will be able to answer them tomorrow afaik.
rehrarIs the chance of finding meaningful vulnerabilities that much greater if we extend it out to September hard fork? Like, would the extra six months be an adequate amount of time if it was determined that the three months between now and March hardfork wasn't sufficient?
suraeNoether\^ this is actually sort of the tough spot we find ourselves in
suraeNoetherthing is, there isn't a real monetary incentive to attack something like BP while its on testnet
luigi1111wattacking it on mainnet is catastrophic, however
suraeNoetheryep
suraeNoetherits like designing a new parachute
rbrunnerWell, we could put bounties for Testnet attacks, no?
luigi1111wmeh
rehrarIt's simple. We make testnetcoin a 3B dollar project.
fluffyponysure, but then we shouldn't ever deploy anything
fluffypony:-P
fluffyponyLOL rehrar
suraeNoetherlol
suraeNoethereventually someone has to strap it onto their own backs and jump
suraeNoetheris what i mean
fluffyponyyes
fluffyponyso here's my thinking
luigi1111wthe people that could review and attack are pretty small in number
fluffyponywe code freeze via a 0.12 branch in the next 2-ish weeks
fluffyponywe include BP for the March HF
fluffyponywe release test bins in Jan
fluffyponywe re-measure our confidence towards the end of Jan / beginning of Feb
fluffyponyif we're not happy with it we change it to v8
fluffyponyor the opposite - put it in v8 and move it to v7 towards the end of Jan if we're confident
luigi1111wmuch more comfortable with the latter
luigi1111wthough there's plenty of support for delaying v7 as well
rehrarI think delaying v7 by a couple months would be well worth it?
rehrarand even if the next fork is still held to September, we will still have the multi-input BP to merge, which is exciting, no?
fluffyponyI don't think we should move fork dates
rehraror were both single and multi output BPs being discussed right now?
moneromoooSingle only.
fluffyponyit's becoming increasingly difficult, and sticking to the predictable fork schedule is advantageous for exchanges, merchants, and pools
fluffypony(emergency hard forks aside)
moneromoooI'm reasonably sure most don't know in advance when the fork is supposed to be anyway.
luigi1111w^^
rehrarother loser coins: "oh btw mister exchange, we're forking in like two weeks, please update software"
fluffyponymoneromooo: they're starting to know
dEBRUYNEAs long as they are notified well in advance I don't see a problem with pushing it back 1-2 months
dEBRUYNELike moneromooo says, most probably don't even know we have one scheduled for march
fluffyponypushing it back by 1-2 months isn't enough time
luigi1111wit might be
luigi1111walthough
fluffyponyimho we're either happy with March or we need 6 additional months of testing
moneromoooHow about 12 ?
rehrarIt may be that in the future FP you might be right, but I think we're still small enough that we can pull a stunt like this without too many consequences
fluffyponymoneromooo: we might need that, if our confidence level is low
moneromoooThe confidence will stay low until 3 months before the fork, when people will start looking.
moneromoooBefore 3 months, (almost) nobody will look.
suraeNoetherif we give ourselves 6 months of testing for BPs
suraeNoetheri'll tell you what'll happen
fluffyponylol
suraeNoether5 months an 2 weeks will go by
fluffyponyso then March it is?
moneromoooNow, if people did look for 6 months… then yes.
suraeNoetherand then testing will begin
dEBRUYNEPushing it back 6 months might perhaps result in it going down the priority list
moneromoooI'm ready to go for september if there is a good reason (ie, someone says they need the 6 months).
dEBRUYNEAnd then we just get the same # of months of review
fluffyponyI'm happy with March, but I'm also open to having my mind changed
fluffyponyI'm also reaching out to the paper authors to see if any of them are able to do an implementation review
moneromooosmooth thinks it's too early, for the record.
rbrunnerMain argument?
moneromoooAt 9 txes per block (monthly average now), I think BPs save ~ 2 GB per month.
dEBRUYNEI think you'll see more transactions once fees drop to an acceptable level though
dEBRUYNESo savings might be even more
VespcoMarch with aggressive promotion of testnet usage starting now. We can highlight the need on reddit and provide clear stack exchange instructions and .bins to attract more users
luigi1111wI don't think that helps
luigi1111wyou need math and code people
luigi1111wwe may have enough (not now, I mean within the next 3 months)
rehrarOk, just so the discussion doesn't go on forever, and to summarize for anyone reading logs afterwards, there's three main camps here: 1. Launch BPs in March HF, 2. Launch BP's in September HF, 3. Delay March HF to something like a May HF and launch BPs then.
rehrarOf those three, I'd say 3 is reasonable
luigi1111wthere are two other non-forking changes that people would like to see in a release too, subaddresses and multisig
luigi1111wformer is in already
dEBRUYNEAs the fork height isn't set yet, can't we reasses in 2 months?
luigi1111wlatter "should" be (IMO) in the next release
dEBRUYNEAnd see if there has been adequate review
fluffyponyluigi1111w: agreed
luigi1111wdEBRUYNE no we are trying to get releases out in reasonable time
luigi1111wie, not the week before
moneromoooMS is going in soon. Just after I fix the core tests after last rebase :)
dEBRUYNENo I meant whether BP go in or not
dEBRUYNE\^ luigi1111w
VespcoIs GUI ready for multisig and subaaddresses?
dEBRUYNEOr is two months to late for that to decide?
luigi1111wyes
dEBRUYNEtoo*
dEBRUYNEOk
fluffyponydEBRUYNE: basically-final bins need to be out by Feb
fluffyponybeginning-ish of Feb
luigi1111wby the time you decide and build the release you're at like one week
luigi1111wagree
dEBRUYNEBut also, if we push back the fork 1-2 months, we have more time to release basically-final bins
luigi1111wwell 2 months imo
luigi1111wso whenever in march
suraeNoetheri think MRL's opinion is 2 1 3, to vote for a september hard fork. because if we are wrong, the cost is large. if we are correct, we save 12 G
suraeNoethergrand scheme of things
luigi1111win grand scheme you don't really save anything
dEBRUYNEIf we don't include BP in March 2018, I suppose we can at least fix the fees :-P
luigi1111wsince we "might as well" prune that data
luigi1111wlater
suraeNoetherluigi1111w: yeah, on a long enough time horizon
vtnerdprune the range proofs?
luigi1111wyes
fluffyponyif we did 2, any opinions on reducing the base fee in the March HF? we can increase it again later if we need
vtnerdhow would some future user verify inflation?
luigi1111wvtnerd if you desire to do that for your trust model, of course you don't prune
dEBRUYNEfluffypony: we need to tweak the penalty
vtnerdoh so this is like the bitcoin prune old blocks option
luigi1111wwell you don't lose the hashability
suraeNoetherfluffypony: I think dEBRUYNE may have thought about fee structures more than anyone else
fluffyponyyes
luigi1111wJollyMort[m] :)
dEBRUYNE\^ would certainly beat me :P
suraeNoetherfair
endogenicis it worth writing a paper on fee structure modeling etc?
luigi1111wlonger term I think yes
luigi1111wbut we certainly don't have time for march
dEBRUYNEPerhaps we could change the penalty exponent to \^3 instead of \^2
fluffyponysuraeNoether: what would your comfort level change to if one or more of the paper's authors reviewed the implementation?
suraeNoetherfluffypony: no, the implementation isn't the concern at all, in my mind at least
suraeNoetherassuming it's passing unit tests
suraeNoether(which i think it is, iirc)
moneromoooIt is.
dEBRUYNEWhat if the paper itself is "broken"? Only time will tell that I guess
suraeNoetherthere ya go. the question is whether or not someone clever can divide by zero and cause a big monero bang with bullet proofs .
suraeNoetherdEBRUYNE: \^ exactly
suraeNoetherthe best test for crypto is time
rehrarwill an aggressive 'test bps on testnet' campaign do anything?
luigi1111wno
suraeNoetheri don't think so
suraeNoetherif someone found something
rehrarso then that's points for March HF isn't it?
suraeNoetherit would be worht more for them to wait until it was implemented than to report it
rbrunnerI think with no high-value target to attack nobody will aim at BP
luigi1111wI disagree with suraeNoether and would like the implementation reviewed
rehrarif we gain little value for waiting, then we shouldn't wait
suraeNoetherluigi1111w: I dind't say i dind't want the implementation reviewed. fluffypony asked me if such a review would make me more comfortable with a March HF
luigi1111wthen we still disagree
luigi1111wso it's fine :)
suraeNoetherheh, okay. well at least we can agree that we both want the implementation reviewed one way or another
moneromooo(thanks stoffu btw, who did review it well)
suraeNoetherstoffu is a silent hero
rehrarMeeting is coming to a close. Not necessarily to decide right now, but just to see where everyone is, can we have everyone that was in this conversation verbally state whether they prefer March or September for BPs?
fluffyponyin terms of someone finding an issue in the math itself, I don't think that 6 months is a macro-enough timescale for that
fluffyponymy preference would be March, pending peer review, or September + fee reduction failing that
rbrunnerMarch: Only with BP live on mainnet you would ever get bright and bad people interested to break something
suraeNoetheri have the reversed preference as fluffypony, plus i would like the authors to review the implementation in either case
suraeNoetheri think sarang has the same preference as fluffypony though
vtnerduh, so before meeting adjourns I'd like to prod https://github.com/monero-project/supercop/pull/1
moneromoooWhat we'd need is for people who may review it to tell is now when they would, and how much time they'd need… Not gonna happen most likely.
vtnerdunedited supercop code is all that is now
luigi1111wcool
pigeonspre-borromean ringct signature issue was found by 3rd party (and/after the monero team), so people do look at non-mainnet code. and also that incident shows how short timelines are scary
endogenic\^
fluffyponyalso msvb-mob wanted to say a couple of things about the HW wallet
suraeNoetherpigeons: that's an extremely good point
msvb-mobHardware team achieved a breakthrough today in manipulating the MCU factory bootloader without programming.
msvb-mobThat means that future firmware developers can flash boards using DFU over USB.
msvb-mobDFU == Device Firmware Upgrade
fluffyponypigeons: good point
fluffyponymsvb-mob: nice one!
msvb-mobIn the near future we will ask for in depth advice from core development and MRL to confirm our design is on track.
msvb-mobAny questions? You can ask about 34C3 assembly as well.
moneromoooThere is a factory bootloader ? As in, code you did not write ?
msvb-mobmoneromooo: Yes, most hardware manufacturers (Nordic, STM, Maxim, TI) supply a default bootloader you can't get rid of.
msvb-mobAnd when they're nice, it's full of USB and DFU.
luigi1111wpigeons thanks, and that memory pushes me towards the wait camp
moneromoooThat sounds like a great idea :/
msvb-mobNext topic.
luigi1111wmeeting is basically over afaik
rbrunnerPlease don't forget the GUI wallet Windows installer and put it into service sometime after busy Christmas. I have a PR waiting that gives the last polish to the installer script, and after that it's really, really ready
fluffyponyyep that's it
fluffyponyone last thing
fluffyponynext meeting would be Dec 31
fluffyponybut I don't think anyone wants that
fluffyponyso push out to Jan 14?
rehrarMonero New Year party?
msvb-mobIf we do one week later, we synced again with community meetings.
luigi1111wis that what we want?
luigi1111wok with both
rehraryou guys don't go anyways :P
luigi1111wand by ok I mean as not ok as normal
fluffyponymsvb-mob: I'd prefer us unsynced, otherwise it's just too much on a weekend
fluffyponywife will murder me :-P
moneromoooTechnically, that's still synced, but out of phase…
moneromooosteps back
msvb-mobNobody is protesting 14 Jan. I'm not opinionated, just wanted to mention the sync aspect.
fluffyponylol moneromooo
rehrarOk 14 Jan it is
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-12-17, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.