Monero Dev Meeting Note Highlights – 2017-12-03
Logs
351 lines
fluffypony1. Greetings
fluffypony2. Brief review of what's been completed since the previous meeting
fluffypony3. Code + ticket discussion / Q & A
fluffypony4. Any additional meeting items
fluffypony5. Confirm next meeting date/time
fluffyponyso 1. Greetings
fluffyponyhi
ArticMineHi
fluffyponyluigi1111 (if you're back) / smooth / hyc / moneromooo etc.
moneromooohere
gingeropolousetc here
fluffypony2. Brief review of what's been completed since the previous meeting
fluffyponylots of stuff
sarangMRL has working Java test code for complete multi-output bulletproofs
sarangIt's being ported over to C++
moneromooo(not the multi output one)
sarangThe Java part is complete
moneromoooSorry, I meant just about the port ^_^
sarangDiscussions are ongoing about if/how the fee structure would be modified to prevent large-output txn DoS
fluffyponywhat's wrong with per-byte fees?
sarangYou can load a txn with tons of outputs
sarangbut verification is linear in the # of outputs
dEBRUYNEfluffypony: verification is linear, whilst size is log
dEBRUYNEbasically
sarangSo for low fees you can force the network to verify
fluffyponyah ok, makes sense
sarangSo we need to incentivize the use of aggregate BPs while basically scaling the fee to the number of outputs etc.
sarangBut things are looking good
sarangVerification is still quite efficient
sarangand with the multi-output setup, space savings are unreal
moneromoooIn fact, the per byte fee needs to be done first, as per kB is way too coarse for this.
sarangYeah a single output BP is about 704 bytes, while a 2-output BP is something like 768 bytes
sarang(including commitments)
sarangit's just too damn good
fluffyponynice
dEBRUYNEFor clarification, a single output is currently ~ 6 kB, whereas a 2-output is ~ 12 kB <* hotoatmeal was about to ask
sarangSo we'll continue moving forward with porting and testing
manifestserhack here?
dEBRUYNEA typical Monero transaction has 2 ins + 2 outs
serhackyep manifest
manifesti was wondering who was the m8 that was gonna work on the go-library since i started on it myself a little bit swell
fluffyponydEBRUYNE: this would also be a major cost-saving for pool payments
fluffyponymanifest: we're in a meeting
sarangFor reference, the size of an M-output BP is 32*(2*log(64*M)+9) bytes (this doesn't count the amount commitments)
sarangadd 32 bytes for each of the M amount commitments if you want to include them
sarang(log is base 2)
rehrarmanifest you can hop on mattermost.getmonero.org. Serhack is also there and you guys can PM and chat so as not to disrupt the meeting. Thanks. :)
ArticMineI have to give some thought to the fees to deal with the verification issue
fluffyponyok so beyond BP is there anything else worth noting?
sarangWe do require a power of 2 in the # of outputs
pigeonsSo sometimes you just create an additional change output, or how do you cause always a power of 2?
sarangWe'll need to either pad with dummy outputs or split into power-of-2 proofs
ArticMineSplit the change into two tx
pigeonsOK
sarangThe dummy output doesn't need to actually represent anything
sarangIt just needs to be there for the proof
sarangIt can be amount 0
ArticMinethat will work also
sarangAnyway, that's my 3 cents
luigi1111Better to split
luigi1111Space is cheap gp
luigi1111Cpu is expensive*
ArticMineWe will have to price cpu
moneromoooThere's a possible optimization for "filler" outs AIUI.
luigi1111Probably not as good as not using them :)
sarangThere aren't any security proofs for a non-power-of-2 proof
moneromoooI was led to think it was not inherent in the scheme, though ?
sarangIt is
moneromoooaw…
sarangAt least for right now
sarangThere's a recursive step that split arrays in half
ArticMineThe issue I see is that the penalty only prices space
sarangThe authors of the paper are looking into a generalization, but it doesn't exist yet
luigi1111That's interesting
fluffyponyok so
fluffyponyanything else from the last two weeks worth noting?
sarangsuraeNoether is completing review for multisig
sarangHe is unable to be here today
Gdhhyfjjs467Has a code freeze date for the next for been set yet?
fluffyponyGdhhyfjjs467: yeah we'll be branching towards the end of the month
fluffyponyassuming our comfort levels are ok
rehrarThis was discussed briefly in MRL channel with the idea that if BPs are not too far off, would it be worth delaying the next hard fork by a couple months so it can be in?
dEBRUYNEThe plan is to include multisig right?
dEBRUYNE\^ fluffypony
luigi1111Yes
fluffyponyno need to delay the hard fork
luigi1111I don't think the upcoming fork does anything useful though
luigi1111So there's that
fluffyponyif BP is ready it'll go into the Sept fork
dEBRUYNEShould we fork if there's nothing to fork for?
luigi1111Who knows ^_^
fluffyponyluigi1111: consistency, then
fluffyponywell, that's what we committed to with the fork schedule
fluffypony"even if it's just bumping the block version number"
dEBRUYNESure, but didn't we also discuss slowing things down once the ecosystem got bigger?
moneromoooWe did not commit to an exact fork schedule.
luigi1111And who is this we :)
moneromoooI, at least, did not :P
hotoatmealdoes the wallet release schedule track the protocol fork schedule exactly?
hotoatmealor do they have different cadences
moneromoooThe wallet needs to update for a fairly large subset of consensus changes.
pigeonsthe wallet-cli and wallet-rpc are included with the daemon release that supports the fork
moneromoooSo it's convenient to release at the same time.
fluffyponydEBRUYNE: I don't think we're at a point where we can go to annual
moneromoooBesides, the wallet and daemon rely on the same libs.
rehrarIsn't ZMQ also in the new release? Or has that been there for a while now?
fluffyponyyes ZMQ is in the new release
moneromoooThere's some of it in, but some of it's still missing.
pigeonsthere is some support for zmq over rpc, and more is comming, like tx/block notify and some changes to the existing zmq rpc
pigeons*rpc over zmq
hotoatmealmoneromooo: yeah, mainly thinking about when I need to spend time to get those two memwipe patches (and the third I haven't written yet) reviewed/merged
pigeonsthe notify is what the people i hear from are waiting for, and tewinget told me a few weeks ago he's got the basics worked out
rehrarAre we still waiting on him for stuff?
moneromoooThere's a patch waiting on changes IIRC.
moneromooo(for 0mq)
rehrarsigh tewinget, can you please get this stuff done? Seriously.
moneromoooEspecially as I think some of the large pool speedups were lost.
moneromooo(not 100% sure)
hotoatmealis there a way to detect that the network has forked, and your client hasn't gone with it?
moneromoooKinda.
hotoatmealmy local daemon got left behind on the last one, because I forgot to update
fluffyponyyou can make an educated guess
hotoatmealcue colorful headscratching
moneromoooCurrent daemon should moan if it sees blocks with a higher version than what it knows about.
fluffyponyand there's auto-update records that notify
moneromoooThe block verison thing is a bit vulnerable to someone mining a bad block on purpose to make you think there's been a fork though.
fluffyponyyeah
moneromoooLosing 10 monero in the process or whatever it is :)
fluffyponyok let's move it along, then
fluffypony3. Code + ticket discussion / Q & A
fluffyponyare there any issues that could do with some input / resolution?
moneromoooThe handful of oldest ones.
moneromoooThe PRNG one.
moneromoooones.
moneromoooFor multisig, I think it's pretty much ready to go in, stoffu's done a lot of careful reviewing.
fluffyponyok - what's the blocker on switching to the Bitcoin one?
hotoatmealmoneromooo: what still needs doing / deciding on your part of the memwipe ones, and how can I help there?
moneromoooMainly deciding whether we want to, or not.
moneromoooAnd bitcoin has two RNGs, the one I ported, and one that's closer to what we have. so there's the possibility of entropy attrition using only the "good" one.
moneromooohotoatmeal: the only thing left IIRC was switching from std::vector<char> to std::unique_ptr<char[]> and I feel more confident getting it right with vector.
moneromoooOther than that, nothing I think.
fluffyponymoneromooo: by "good" one you mean the ported one?
moneromoooThat can be done later by someoine who's familiar with how the refcounting works with operators though.
moneromoooYes. The one that uses getrandom, etc.
fluffyponyok so I think if they haven't hit entropy attrition problems over the past few years it's unlikely we will - thoughts?
moneromoooLet me rephrase:
moneromoooBitcoin has two RNGs: a good one using HW, and a… hmmm, less good ? one similar to our keccak based one
moneromoooUsing the keccak based one does not deplete entropy nearly as fast as using the good one. Monero can use a lot of entropy (eg, range proofs).
moneromoooTherefore, I'm wondering whether using the good one all the time is worse than not.
hotoatmealmoneromooo: ok, I'll pick up the vector vs unique_ptr part of that later this month
moneromoooThanks
fluffyponyok so what if we used the good one for critical stuff like privkey generation
fluffyponyand output selection
hotoatmealand if you give me some pointers, can look at whatever that refcounted operators thing is in Jan
fluffyponyand the stream one for range proofs
moneromoooWell, if I knew that, I'd know the answer to my question, since they're opposites.
moneromoooAnyway, to go back to multisig, I tihnk it's good to go now. If you haven't yet reviewed it, and want to do so, do so now.
hotoatmealdrops out
fluffyponyok
fluffypony4. Any additional meeting items
moneromoooWhen do we want bulletproofs on testnet ?
dEBRUYNETomorrow!
fluffyponyhah hah
moneromoooA day may be a bit short to get people to update in time.
fluffyponyare we going to wait for the multi output stuff?
sarangI think we should
moneromoooNot sure. This is not quite finished (multiple of 2 requirement), and has a non trivial impact on fees.
sarangHrmm true, the fee thing
sarang:/
moneromoooAnd I'd really, really like to get smaller txes double plus quick.
fluffyponyok so how would this work
ArticMineA lot of people do
sarangIn case it's relevant, every single-output proof is still a valid multiproof
moneromoooThat's nice.
sarang(provided we define the Gi and Hi in the same order)
sarang(not sure if my extended code addressed that, will check)
moneromoooSo, no clear votes for or against. Except me ^_^ so that's 100% of expressed votes :P
sarangchecks the math on that
fluffyponymoneromooo: I asked how it would work
moneromoooThe fork ? I imagine similar to rct. Allow bulletproofs at fork f, optionally disallow borromean at f+1.
moneromooo(the code currently does not do that second part)
moneromoooThat might become a bit more complicated if we start allowing aggregated proofs at f+1.
moneromoooBut not very much.
dEBRUYNEso moneromooo, you'd like to start with single output right? And then eventually switch to multioutput
moneromoooYes.
rehrarSorry if this was answered, but is there an ETA on multioutput port from Java?
moneromoooNo. It doesn't appear to be a lot of work though.
fluffyponyso then txs with more than 1 output would use borromean?
moneromoooNo. They'd use two bulletproofs.
sarangyup
rehrarWhich is still a savings.
sarangStill great space savings
sarangAnd no DoS issues
dEBRUYNE2 bulletproofs is 1.3 kb give or take right?
fluffyponyok
dEBRUYNEAnd we can keep our current fee structure
sarangdEBRUYNE: yes
moneromoooMost of it, in fact. Txes are ~2.2 kB.
rehrarI think that's worth it. And then it can be enhanced even further with multioutput later. But the immediate savings would be appreciated.
rehrarAnd gives time for the fee dislogue
fluffyponyand what's our confidence level like in this? like is it March-fork-worthy?
rehrarDialogue*
moneromoooWell, we can know better if we fork in a couple days on testnet :)
ArticMineI have an idea on the fee issue
rehrarIt can be deployed to testnet asap no.
rehrar?
moneromoooThat's what I'm asking about, yes.
fluffyponycould we fork testnet this coming weekend?
moneromoooWorks for me. Gives time for review.
rehrarExciting!
sarangYes and the code should definitely be reviewed by others
endogenicwho?
endogenicif you had your pick
JollyMort[m]could someone do me a favor and send me the log of this channel from 2017-04-18?
sarangIdeally andytoshi since he's a paper author
moneromoooIf I had my pick…
sarangsuraeNoether
fluffyponySatoshi
endogenicfluffypony: on it
sarangSomeone who digs the maths
Gdhhyfjjs467So Evan duffield?
dEBRUYNEluigi1111 I guess
endogenicvtnerd hyc fyi
moneromoooOh yeah, luigi1111 is a good one.
rehrarLet's just get all hands on deck for this?
endogenicok that means you too rehrar
Gdhhyfjjs467Lol jk. I like andytoshi idea
sarangI'm sure we'll find additional optimizations… I know for a fact my implementation of scalar operations into vectors could be refactored
rehrarI will understand none of it, but I'll look at it and either nod approvingly or cringe based on a coin toss.
sarangbut I didn't in Java in order to keep it clean and understandable
endogenici move to instate rehrar as new RNG
moneromoooThe slice op ? Yes, but I don't think it takes much time compared to the muls.
sarangRandom Nod Generator?
sarangWell and operations involving many vector ops could run a single loop per element, instead of per operation
sarangbut they're generally fast and it makes things clean
sarangI'm not a huge fan of sacrificing clarity for a tiny speedup
sarangI'd like to chat with moneromooo post-meeting about our basepoint selection, to ease the transition into multiproofs later
sarangFor those who want to compare code to paper, this is the paper: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf
moneromoooI pushed the patch as 2883 if people want to start reviewing ^_^
rehrarCan I make a Reddit post calling devs to review it?
moneromoooReddit.. devs ?
dEBRUYNE\^ that lol
rehrar:P nvm then
dEBRUYNEThe people able to review it will be watching Github
endogenicrehrar: answer is in the question :P
fluffyponyoh
fluffyponyI guess meeting ~done
fluffypony5. Confirm next meeting date/time
fluffyponySunday the 17th
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2017-12-03, 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.