diff --git a/_posts/2016-03-05-overview-and-logs-for-the-dev-meeting-held-on-2016-03-05.md b/_posts/2016-03-05-overview-and-logs-for-the-dev-meeting-held-on-2016-03-05.md index 3ea17ffc..9bdf3591 100644 --- a/_posts/2016-03-05-overview-and-logs-for-the-dev-meeting-held-on-2016-03-05.md +++ b/_posts/2016-03-05-overview-and-logs-for-the-dev-meeting-held-on-2016-03-05.md @@ -10,223 +10,222 @@ author: gingeropolous # 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 +**\** 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