Logs

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

15 KiB Raw Blame History Unescape Escape

Logs

15 KiB

Raw Blame History