--- layout: post title: Overview and Logs for the Dev Meeting Held on 2016-03-05 summary: Clarification on ringCT next steps, Trezor integration status, net_skeleton replacement tags: [dev diaries, core, crypto] author: gingeropolous --- *March 5th, 2016* # Logs **\** dev meeeeeeeting **\** role call **\** ping **\** no problem :) **\** hyc / moneromooo / warptangent / luigi1112 / smooth **\** smooth, luigi1112, othe, NoodleDoodle, ArticMine, warptangent, moneromooo, hyc **\** pingping **\** or any other luigi's **\** present **\** my body is here too **\** present **\** lol **\** othe: but your mind is... ? **\** ok let's start **\** i dont know where it is fluffypony **\** er, hi ? **\** open pull requests: mostly just DB stuff by warptangent and hyc **\** will be merged within the next couple of hours **\** ok **\** how are you guys? **\** glad for the weekend **\** merged pull requests in the last couple of weeks: unit test fixes, threading fixes, lots of little things **\** I suppose the big stuff is hyc's readtxn changes **\** is the exp/performance stuff from warptangent also to be merged in? **\** warptangent / moneromooo: do one of you want to give us an overview of readtxn? **\** not soon **\** and should we add the trezor support from NoodleDoodle ? **\** othe: we're doing PR review first **\** the txn cursors enable lmdb to read and write more efficiently **\** hyc added write cursors and then read cursors to cover just about all the DB operations **\** cool **\** re: warptangent's performance changes **\** we have to implement some sort of migration system **\** we can't expect people in production to keep dropping and re-syncing **\** so that would stall it being merged **\** hi, sorry I'm late. our experience with blockchain_import indicates migration will be slow **\** also, migration won't take place until after things settle with the db changes and testing. **\** development is ongoing here https://github.com/warptangent/bitmonero/branches in the exp/performance branch **\** hyc: well at the very least we need to detect that the current DB isn't what we expect, and that it must be converted or redownloaded **\** *resynced **\** right. well fortunately the DBs have version stamps so that's straightforward **\** yeah **\** ok let's move on to trezor **\** NoodleDoodle: are your changes stable enough to PR? **fluffypony** plays elevator hold music **\** ok whilst we wait for that **\** there's been some discussion about fees with the price rise **\** any thoughts on the fee thing? **\** i think they are still fine **\** My thought is that fees will ultimately have to be tied to the blocksize **\** what will be the price point when they change? **\** at the moment it's like $0.012 per kb I think **\** Ideally we would wait for it to settle down a bit **\** the price **\** yeah **\** Too soon for adjustments imo **\** true **\** gingeropolous: dropping fees is a hard fork, so ideally we want to bundle it into the October fork or whatever **\** 1 cent is nothing **\** You mean fees are in the consensus code **\** ArticMine: yes - we don't allow 0 fee transactions **\** We could just calculate the average over the last 6 months **\** I think ArticMine's point about fees being tied to block size is interesting, as block size goes up, fee per kb declines, linearly I guess **\** BitcoinErrorLog has been talking about "magic number automation", he might have some thoughts on it too **\** he's offline atm **\** jwinterm: yes **\** fee tied to blocksize - but you can't predict the blocksize when you create a txn to someone **\** hyc: we can use the median **\** the tx size **\** It is because fess are tied to the emission and blocksize via the bock penalty **\** right, unpenalized max block size **\** So we could actually use a formula based on emission and block size **\** So that the min fee corresponds to a low position in the penalty **\** say around 5% **\** present! **\** is anyone aware of another coin using a similar scheme with also using the block size? seems worth looking into. **\** not that I know of **\** This only applies to cryptonote **\** i think it'd be awesome to find a way to do it automatically, as opposed to hardforks **\** but likely Monero would be first **\** it sounds good. especially since emission and blocksize are already automatic **\** ok let's sketch that out and see what we come up with **\** in the meantime, we need to push 0.9.2 out **\** I can put something together **\** I was holding off on it until the meeting **\** on fees **\** I'm still hitting SIGBUS on ARMv7 but go ahead with current PRs and don't wait for anything more from me **\** ok **\** moneromooo: how are you feeling on an upstream merge to dev? **\** I don't see my test resolving this soon **\** the current RPC interface is starting to become a problem for multiple concurrent wallet sessions **\** I'm waiting for 0.9.2 to be tagged first so that no new patches go there. **\** ok **\** (or few anyway) **\** Why is it a problem ? **\** The new one seems to be made to be non thread safe fwiw. **\** moneromooo: Peter Todd and I have hit the issue with scanning a new wallet when other wallets are open **\** and I don't think we should necessarily waste time trying to optimise an interface that's going away **\** Oh what does this break ? **\** it makes it slooooow **\** Ah, fair enough. Did you try with the 0mq one ? **\** no - was in the air (literally) :-P **fluffypony** ponders **\** oh yes **\** I would prefer new wallets don't auto-refresh, but I understand why it was added **\** net_skeleton become Fossa which became Mongoose **\** which needs to become gone ? **\** yes **\** the only licenses they have available are GPL and a commercial license **\** which doesn't play well with ours **\** We would have to go GPL **\** basically we just need a library that plays well with HTTPS, and supports authentication **\** and is compatible with our license **\** something to keep eyes out for **\** next up: ringCT **\** warptangent: you were chatting to Shen - what's the latest on that? **\** i've begun to familiarize myself with what will need to be done, and development on that will go on top of the newer database branch **\** we'll be opening Github issues or Forum threads, either or, for the specific decisions we have to make around things like ring size **\** a forum thread would work well for the first issue re: floating point or fixed **\** luigi1114: you had some thoughts on that, iirc? **\** I do **\** I feel like I've missed a lot of stuff, somehow. **\** im still getting woops something went wrong when click on the bell on the forum... not that I need to do much for these topics, but just throwin it out there. **\** gingeropolous: thanks, will take a look at the error log **\** What's this about floating point ? **\** I think a forum or other untimed format would be easier though **\** it's a decision to be made about the confidential transactions scheme **\** Alright. First I've heard of it. **\** it's how many amounts can be represented **\** size tradeoffs basically **\** So since I've not seen that conversation nor arguments, I'll just say "floating point is only fine if you really know what you're doing". **\** it's more a design decision **\** moneromooo: first you've heard of RingCT, or of the floating point / fixed issue? **\** fp/fp **\** the conversation needs to take place in the forum and with Shen's input. moneromooo i only recently learned of it myself. **\** It has significant economic implications **\** we're not going to get very far here I agree warptangent **\** ok - let's create a thread **\** does anyone want to run with that? **\** *silence* **\** lol **\** crickets **\** i can **\** thanks warptangent **\** i'll let NobleSir know when it's up too **\** Can I make a general remark? **\** dEBRUYNE: of course **\** We should change mixin to ring size or another sufficient alternative **\** mixin sounds active **\** which isn´t the case **\** we were just talking about ringsize just now, in context of RingCT **\** I know - terminology and binary name changes are going to happen for 1.0 **\** sounds like ring size already has a meaning that we shouldn't confuse **\** and making sure flags are all uniform etc. **\** hyc: Yeah I saw that, I just wanted some confirmation that we are going to change that **\** certainly with a lot of newcomers coming in it might be confusing **\** \ and making sure flags are all uniform etc. <= Great **\** definitely **\** hyc: I believe they are the same (function at least) **\** ok, then that's straightforward **\** ring size is the community agreed replacement for (mixin+1) **\** well number of bytes in a ringct is different than what's currently mixin count **\** i think that's hyc's concern **\** Then we should name them similiar **\** shouldn´t **\** * **\** yes. I didn't follow ringct closely, but the fact that floating point is even an option means the two are quite different **\** it's likely the latter is the one most users will even be aware of. **\** but it's something to consider. **\** warptangent: Agree, perhaps we could ask NobleSir if he has a sufficient synonym **\** \ well number of bytes in a ringct is different than what's currently mixin count <= this doesn't parse for me **\** afaik users don't choose anything with ringCT, though **\** floating point/exponents/bitsize has nothing to do with ring size and won't be named similarly **\** luigi1112: just the storage size for a ringct, if referred to as "ring size" could be confusing for those using "ring size" to refer to mixin count **\** ok **\** yes the former will/should not be named that way **\** signature size or something **\** yeah, i was not aware ring size already was used for something **\** maybe this isn't the place for the discussion but I would have preferred something other than "ring size" for mixin count. masking factor, blinding factor. **\** something that actually conveys the purpose. **\** as hyc mentioned, decoys is actually a good name / descriptor **\** Agree there. **\** but it sounds too subterfugey **\** yell on the reddit thead :) **\** the thread it still open **\** lol **\** anyway not a good place here **\** ok **\** or time **\** hyc: Ring size was just brought up earlier, it was more about the idea of changing it **\** Just arrived, what the subject? **\** Another term is fine by me as well **\** i do like ring size fwiw. **\** malmenonphome: Changing the term mixin to something else **\** this is basically a community thing, not a dev thing **\** @fluffypony not yet, I'll work on osx/linux this weekend and see from there. As for the firmware, I'll request a pull upstream once I've added it to github. They are interested in merging it upstream. **\** (beyond making sure the name makes sense) **\** luigi1114: Let´s continue to the next subject then :) **\** Ah, ok, I agree with ring size as well, but we should think in other languages how it sounds too **\** masking/blinding factor or decoy is more descriptive, but ring size could be a happy medium between that and not making every user have to feel like a rebel. **\** ring size is ok for me, if it doesn't convey meaning people will learn and that's a good thing **\** In Portuguese... Tamanho de anel **\** right the problem with mixin is that people think it's a typo for the other word **\** yeah **\** ok - that's a discussion to have on the reddit thread or wherever **\** mixin definitely gives the idea, as we've seen, that it requires other active senders **\** we're not in a position to make a decision on it in this meeting **\** I agree **\** any word on the dev branch? as one who has been summarizing these meetings, the can has been kicked twice now. **\** we can can kick better than bitcoin huh **\** it was discussed above? **\** gingeropolous: did you miss part of the meeting? **\** perhaps. sorry. /me hides **\** is ok **\** in the summary you can just be like "the official troll-appointed dev was late" **\** :-P **warptangent** wonders who the first dev-appointed troll will be. **\** hah hah **\** ok I think that brings the meeting to a close