Skip to content
Snippets Groups Projects
Unverified Commit 5dd20c12 authored by dEBRUYNE-1's avatar dEBRUYNE-1
Browse files

Logs for the Kovri and Dev meetings held on 2017-02-05 & 2017-02-19

parent 6e4fea1b
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
_posts/2017-02-05-logs-for-the-Kovri-dev-meeting-held-on-2017-02-05.md 0 → 100644
+ 246
− 0
View file @ 5dd20c12
---
layout: post
title: Logs for the Kovri Dev Meeting Held on 2017-02-05
summary: Brief review of what has been completed since last meeting, Salti, and code & open tickets discussion
tags: [dev diaries, i2p, crypto]
author: dEBRUYNE / fluffypony
---
*February 5th, 2017*
# Logs
**\<anonimal>** 1. Greetings
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** 3. Code + ticket discussion / Q & A
**\<anonimal>** 4. Any additional meeting items
**\<anonimal>** 5. Confirm next meeting date/time
**\<anonimal>** 1.
**\<anonimal>** Hello
**\<i2p-relay> {-olark}** greetings
**\<anonimal>** 'Hola' as hyc would say right now
**\<Slack> [endogenic]** Hi!
**\<i2p-relay> {-guzzi}** hi
**\<meeting-bot> [i2p-relay] {-ArticMine}** Hi
**\<anonimal>** 2. Brief review of what's been completed since the previous meeting
**\<anonimal>** Our last meeting was on November 27th, 2016 so, nothing can be "brief" about a review.
**\<anonimal>** There were holidays, etc, so there was a leave of absence but development is going strong.
**\<anonimal>** All I can say is if anyone is really interested, we have git-log and github (kovri + meta), my fork, and https://forum.getmonero.org/9/work-in-progress/86967/anonimal-s-kovri-full-time-development-funding-thread for any TL;DR
**\<anonimal>** I'm also have uncommitted work, finishing up the crypto impl refactor + testing for this new exception dispatcher.
**\<anonimal>** JFTR: of the thousands of lines of code that we forked from, almost none of it handled exceptions. All this spaghetti code, and that guy did not even have a basic grasp of design with exception handling in mind. Literally, much of the core code is still stringed together with the hope that it won't fail. I hate it. It's always been like walking on glass, but a real fix will take time. So, I've started in
**\<anonimal>** that direction at least in terms of getting exceptions handled or handled better.
**\<anonimal>** We have two new contributors: MoroccanMalinois and Chris Barry (lazygravy), and EinMbyte and olark have returned.
**\<anonimal>** At this point I think a Q&A for "brief review" would be best.
**\<hyc>** that summary is pretty scary
**\<anonimal>** lol
**\<anonimal>** Good scary, I hope?
**\<hyc>** ;)
**\<anonimal>** :)
**\<hyc>** it points in a good direction
**\<anonimal>** Good, I hope so!
**\<DaveyJones>** sounds like bytecoin code :D
**\<i2p-relay> {-olark}** The i2pd situation was interesting to say the least :p
**\<anonimal>** Or more aptly titled: "why2pd".
**\<Slack> [endogenic]** Total kovri noob here. Not looked at the code yet. Is there any significant future use case for kovri libraries? Is it worth doing upfront? *sits back down*
**\<anonimal>** Monero. That's the biggest future use-case so far.
**\<i2p-relay> {-olark}** I would like to see a future where kovri would be the go to i2p router for implementing into applications
**\<i2p-relay> {-olark}** Instead of tor
**\<i2p-relay> {-olark}** blegh
**\<i2p-relay> {-olark}** Monero obviously first though ;)
**\<hyc>** makes sense. tor was created for the gov't after all
**\<i2p-relay> {-olark}** Yep
**\<DaveyJones>** if it will do good for cash/monero i guess those use cases will follow by time
**\<anonimal>** Everyone seems to be ecstatic about libkovri but I must stress that this is a sensitive network so, the lib should be used with that in mind.
**\<anonimal>** Tor doesn't have this issue. All that work is upon the relays.
**\<i2p-relay> {-olark}** True
**\<anonimal>** Simply shutting down the router when it's most convenient has a negative impact on the network and anonymity. The API needs to take this into consideration as will any applications.
**\<anonimal>** I can get into details, not meeting worthy. endogenic I don't think I answered your question well enough, I hope I can do better after the meeting.
**\<anonimal>** Any questions about "brief review"?
**\<i2p-relay> {-olark}** Hang around in #kovri endogenic
**\<i2p-relay> {-olark}** Basically we are close to nightlies right?
**\<anonimal>** ^ #kovri-dev is more informative
**\<meeting-bot> [i2p-relay] {Slack} [endogenic]** i’m here
**\<i2p-relay> {-olark}** :)
**\<anonimal>** Yes, nightlies are technically available https://build.getmonero.org/waterfall
**\<anonimal>** *but*
**\<anonimal>** pigeons and I are working out packaging details.
**\<i2p-relay> {-olark}** ok
**\<anonimal>** Right now they *all* run a hacked makeself installer. So, download -> chmod +x -> run the installer.
**\<anonimal>** Windows requires msys2, this is silly so I think we can do a windows installer method (I posted details in the meta repo)
**\<i2p-relay> {-olark}** nice
**\<meeting-bot> [EinMByte]** Hi, sorry for being late
**\<Slack> [needmultisig90]** oh its being relayed
**\<Slack> [needmultisig90]** neat
**\<anonimal>** needmultisig90 wants to head up the packaging front. needmultisig90: if you aren't watching the meta repo, I highly recommend that.
**\<Slack> [needmultisig90]** link pls
**\<anonimal>** https://github.com/monero-project/meta
**\<anonimal>** If you review the issues, you'll see where are on packaging.
**\<anonimal>** where we are
**\<Slack> [needmultisig90]** Added, will do
**\<anonimal>** I don't want to shortchange the work that's been done since the last meeting, any more Q&A before moving onto the next point?
**\* anonimal** thinks too
**\<anonimal>** Oh, yes, another new contributor alvinjoelsantos (I don't know if he's around)
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** ajs is cool
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** @ajs
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** he appears to be online
**\<anonimal>** Oh, *that's* ajs, excellent.
**\<i2p-relay> {-olark}** Good to have new blood :)
**\<anonimal>** ajs wanted to work on the website too, IIRC?
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** he's working with me on /r/moneromarket
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** I believe so
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** he has a background in law
**\<anonimal>** "I am the law!"
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** and was working with OpenBazaar on drafting up arbitration agreements IIRC
**\<Slack> [jollymort]** also on the monero stealth addresses script : )
**\<meeting-bot> [i2p-relay] {Slack} [needmultisig90]** he can correct me
**\<anonimal>** Have him take a look at /r/Kovri
**\<bigreddmachine>** does the website exist? i'm happy to help add content and such
**\<anonimal>** bigreddmachine: we all need to tackle fluffypony because he's been coveting the website idea since we started
**\<anonimal>** "MY PRECIOUS!"
**\<meeting-bot> [fluffypony]** bigreddmachine: yes
**\<meeting-bot> [fluffypony]** I moved laptops and so now half my stuff lives on my old one
**\<meeting-bot> [fluffypony]** I'll try consolidate and push it up this week
**\<bigreddmachine>** okay, just wanted to make sure i hadn't missed something. i'll watch the repo - going under getmonero.org or as a separate repo/site?
**\<anonimal>** Last call for point 2. "brief review"
**\<anonimal>** bigreddmachine: while you're here, we did make some progress on Salti. Any news from upstream on their API?
**\<meeting-bot> [fluffypony]** bigreddmachine: same design, new content, linked from the getmonero menu bar
**\<meeting-bot> [EinMByte]** Progress on salti?
**\<anonimal>** EinMByte: yes, have you read some of the conversation in the open salti issue?
**\<bigreddmachine>** anonimal: i've been tracking the open tickets but everything got held during holidays. nothing there yet, but i might make a proof of concept for chromium if there'd be interest
**\<meeting-bot> [EinMByte]** "some of" yes, that sounds about right
**\<anonimal>** bigreddmachine: sounds great
**\<anonimal>** EinMByte: most of the collaboration was in IRC, not in issue.
**\<bigreddmachine>** it would be easy enough to port to firefox + tbb once they finish webrequests.proxy
**\<anonimal>** bigreddmachine: will you open FFS for this? I think it's worth it.
**\<bigreddmachine>** for the chromium part? or ff/tbb?
**\* anonimal** shrugs
**\<bigreddmachine>** i don't feel comfortable proposing something that at the moment isn't possible and relies on mozilla dev community before it can get started...
**\<anonimal>** Ok
**\<anonimal>** Chromium PoC sounds good none-the-less.
**\<bigreddmachine>** but i will FFS it once i think it's doable
**\<meeting-bot> [i2p-relay] {-ArticMine}** I would be careful with Chrome / Chromium since unlike Firefox there is no no option to disable DRM
**\<meeting-bot> [i2p-relay] {-ArticMine}** The DRM could be an attack vector
**\<meeting-bot> [EinMByte]** Anything that relies on mozilla sounds bad to me
**\<meeting-bot> [i2p-relay] {-ArticMine}** Firefox and clones are fine
**\<bigreddmachine>** ArticMine - DRM isn't included in chromium afaik. chromium is only open source code.
**\<bigreddmachine>** ... at least that's always been my understanding.
**\<meeting-bot> [EinMByte]** Firefox is fine, of course, and preferably we should use Firefox (or at least that was the initial idea)
**\<bigreddmachine>** anyway, we can discuss details after the meeting if there's interest. don't want to hold up anonimal
**\<meeting-bot> [EinMByte]** but relying on mozilla to move... probably not going to happen
**\<meeting-bot> [i2p-relay] {-ArticMine}** https://bugs.chromium.org/p/chromium/issues/detail?id=686430
**\<pigeons>** no chromium is even binary blobs download at compiletime
**\<meeting-bot> [i2p-relay] {-ArticMine}** The DRM in Chrome is currently an issue in Chromium
**\<anonimal>** bigreddmachine: this is technically "3. Code + ticket discussion / Q & A" so we can chrome-it-up if needed.
**\<anonimal>** Any other comments on Salti?
**\<bigreddmachine>** okay - maybe a chromium POC would need to stay just that, a POC, and never production.
**\<anonimal>** Something to play with at least, I'm up for that.
**\<bigreddmachine>** "Any other comments on Salti?" --> just that i'll keep trying webRequests.proxy
**\<anonimal>** Ok, thank you. That sounds ideal AFAICT.
**\<anonimal>** Onto other code + ticket discussion:
**\<anonimal>** Since I have no questions for myself, any Q&A?
**\<anonimal>** Open PR from guzzi, ETA for completion?
**\<Slack> [moroccanmalinois]** hi guys, guzzi are you interested in #399 ? i may give it a shot if you are not
**\<anonimal>** Oooo #399, my favourite.
**\<i2p-relay> {-guzzi}** \* anonimal, this week on PR
**\<i2p-relay> {-guzzi}** \* checks 399
**\<anonimal>** moroccanmalinois: ironically, I highly encouraged guzzi to get started on that after we merged his PR.
**\<meeting-bot> [olark]** I'll leave what I have to say for after.
**\<meeting-bot> [olark]** Unless there are no questions people have about kovri
**\<anonimal>** moroccanmalinois: but now that he will be funded, I would ask him to contribute partly to that and help me with many other areas instead
**\<Slack> [moroccanmalinois]** @anonimal "easiest" one i find
**\<i2p-relay> {-guzzi}** sounds like a plan.
**\<anonimal>** I mean, I can't speak for either of you; please do it!
**\<anonimal>** Ok, so moroccanmalinois is on #399 now?
**\<Slack> [moroccanmalinois]** my pleasure if guzzi is fine with it
**\<meeting-bot> [EinMByte]** Do we still have important SSU issues open?
**\<meeting-bot> [EinMByte]** Might take a look in the next week
**\<i2p-relay> {-guzzi}** but converting .jar to c is a great way to learn
**\<i2p-relay> {-guzzi}** we an decide away from the meeting.
**\<anonimal>** #399 is actually great for various reasons, one of which would introduce a new dev to the purpose of libkovri-client and libkovri-core
**\<Slack> [moroccanmalinois]** cool
**\<anonimal>** EinMByte: yes, the same ones I believe since you left though I may have resolved one or two but not closed (I don't know)
**\<anonimal>** guzzi: we wouldn't be converting .jar to c
**\<anonimal>** I'll give details after the meeting
**\<anonimal>** olark did you mean monero question for after the meeting or kovri question?
**\<meeting-bot> [EinMByte]** Alright. Might do some additional refactoring, since I never completely finished that
**\<i2p-relay> {-guzzi}** oh i see just skimmed
**\<i2p-relay> {-olark}** Not so much a question but a new development that pertains to both kovri and monero :)
**\<i2p-relay> {-olark}** Something I have been thinking about while I was looking at Monero's ring signatures.
**\<anonimal>** EinMByte: that sounds great
**\* anonimal** will look at issue tracker after meeting
**\<anonimal>** Ok, anymore on 3. Code + ticket discussion / Q & A ?
**\<anonimal>** Lots of TODO's. I'm adding them like spice to bland soup.
**\<i2p-relay> {-olark}** I'll mention it in 4.
**\<anonimal>** Once I get these two branches merged, maybe someone can pick some of them up. We'll see.
**\<meeting-bot> [i2p-relay] {-ArticMine}** I will bring up an item in 4
**\<anonimal>** 30 seconds until 4.
**\<i2p-relay> {-guzzi}** i like todos
**\<anonimal>** 4. Any additional meeting items
**\<anonimal>** Floodgates opened!
**\<anonimal>** Fashion, food, travel: anything goes!
**\<meeting-bot> [i2p-relay] {-ArticMine}** Yes https://www.myhackerhouse.com/windows_drm_vs_torbrowser/
**\<meeting-bot> [i2p-relay] {-ArticMine}** DRM used to attack tor in Windows
**\<anonimal>** lol
**\<meeting-bot> [i2p-relay] {-ArticMine}** Cost to get Windows to trust this attack 10,000 USD
**\<anonimal>** Thanks ArticMine, looks like a great read.
**\<anonimal>** bigreddmachine: ^
**\<meeting-bot> [i2p-relay] {-ArticMine}** Should also work against i2p
**\* anonimal** will read more after meeting
**\<anonimal>** fluffypony: are you gpg verifying the kovri subscription that's hosted on github?
**\<bigreddmachine>** okay, so i'll go ahead and say that i won't officially ever support a chrome version of Salti then.
**\<i2p-relay> {-olark}** I'll let ArticMine go first
**\* anonimal** wanted to ask that in monero's meeting on the topic of github security
**\<moneromooo>** "subscription" ?
**\<meeting-bot> [EinMByte]** By the way, if anyone needs access to the salti repo, please tell me
**\<anonimal>** moneromooo: https://github.com/monero-project/kovri/blob/master/pkg/client/address_book/hosts.txt
**\<meeting-bot> [i2p-relay] {-ArticMine}** My take is that any browser / OS that supports DRM is vulnerable to an attack against anonymity / IP obfuscation
**\<meeting-bot> [EinMByte]** As with many features like DRM, it's best that they're just enabled
**\<moneromooo>** Thanks.
**\<meeting-bot> [EinMByte]** \*disabled LOL
**\<anonimal>** lol EinMByte
**\<anonimal>** moneromooo: the only reason I'm signing it is because fp is pulling directly from github
**\<meeting-bot> [i2p-relay] {-ArticMine}** So i2p on such a platform may create a very dangerous sense of false security
**\<anonimal>** ArticMine: much like anything Windows
**\* anonimal** now windows fan
**\<anonimal>** \*not
**\<meeting-bot> [i2p-relay] {-ArticMine}** Yes
**\<anonimal>** olark: 10 minutes left
**\<anonimal>** Tick tock tick tock!
**\<anonimal>** fluffypony: in addition to my ping above, is there any kovri-related news related to your conference circuit?
**\<i2p-relay> {-olark}** Salti is a good solution for now
**\<i2p-relay> {-olark}** In the future we could have our own dedicated browser
**\<i2p-relay> {-olark}** Not sure when that is viable though
**\<i2p-relay> {-olark}** ok
**\<i2p-relay> {-olark}** sorry got really bad tunnel lag
**\<i2p-relay> {-olark}** I have been thinking about how LN or something similar would work with monero
**\<meeting-bot> [fluffypony]** anonimal: just generally good chats
**\<meeting-bot> [fluffypony]** Nothing mind blowing
**\<i2p-relay> {-olark}** Once kovri gets implemented into nodes and wallets this opens the doors to some really great developments
**\<meeting-bot> [fluffypony]** Some good talk on Tor failure modes
**\<i2p-relay> {-olark}** Since we would have access to i2p for routing
**\<meeting-bot> [fluffypony]** A few people at 33c3 said that i2p was a prescient choice
**\<pero>** kovri - the prescient choice for online anonymity
**\<i2p-relay> {-olark}** It would need to be a plugin for kovri
**\* anonimal** wants Kovri's I3P technology. Trademarked, stamped, hah!
**\<meeting-bot> [fluffypony]** Hah
**\<anonimal>** I3P, your cover of choice.
**\<i2p-relay> {-olark}** Could have a client tunnel for LN functionality in wallets
**\<i2p-relay> {-olark}** Use kademlia DHT so the other "lightning" nodes know of each other
**\<i2p-relay> {-olark}** Would be able to route around centralized troublesome nodes
**\<meeting-bot> [fluffypony]** Can I shut meeting-bot down, anonimal
**\<i2p-relay> {-olark}** Fixes a lot of problems the current LN development is trying to fix
**\<anonimal>** fluffypony: 3 minutes left?
**\<meeting-bot> [fluffypony]** Kk
**\<i2p-relay> {-olark}** Don't need to build routing from scratch
**\<i2p-relay> {-olark}** Anyway it is still way to early to really till this could be possible
**\<anonimal>** olark: sounds interesting. I'd need more info to have a comment.
**\<Snipa>** moneromooo - I'll work on the isolated testnet in a bit. I apparently need to rebuild all of my monerod's w/o libunwind, or it crashes trying to init a new blockchain. So I'll have it tested a bit later today.
**\<i2p-relay> {-olark}** But there is good potential
**\* anonimal** swats Snipa
**\<moneromooo>** Cool, thanks Snipa
**\<anonimal>** Ok, one minute left. 5. Confirm next meeting date/time
**\<anonimal>** Same time, two weeks from now?
**\<bigreddmachine>** february 19? i can do that
**\<i2p-relay> {-olark}** Sounds good
**\<anonimal>** Ok, I'll post on meta repo.
**\<anonimal>** Thanks everyone!
\ No newline at end of file
_posts/2017-02-05-overview-and-logs-for-the-dev-meeting-held-on-2017-02-05.md 0 → 100644
+ 340
− 0
View file @ 5dd20c12
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-02-05
summary: Sync improvements for HDD, GUI 2nd Beta, fluffy blocks, and dynamic fee discussion
tags: [dev diaries, core, crypto,]
author: dEBRUYNE / fluffypony
---
*February 5th, 2017*
# Overview
An overview [can be found on Hello Monero](https://hellomonero.com/article/monero-dev-meeting-note-highlights-and-transcript-2017-02-05).
# Logs
**\<fluffypony>** ok
**\<fluffypony>** welcome to the 77th annual hunger games
**\<hyc>** oof
**\<fluffypony>** 1. greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. Any additional meeting items
**\<fluffypony>** 5. Confirm next meeting date/time
**\<fluffypony>** so let's start with 1
**\<fluffypony>** hi
**\<pero>** HOLA
**\<hyc>** hi. I'm hyc, and I'm a monerophile
**\<Snipa>** Morning.
**\<DaveyJones>** ArcticMine, luigi1111, luigi1114, luigi1112, othe, hyc, smooth, jaquee, m5M400, medusa, tewinget, zone117x, dEBRUYNE, moneromooo
**\<i2p-relay> {-olark}** greetings
**\<Slack> [xmr-eric]** hullo
**\<Jaquee>** hey
**\<DaveyJones>** one question... is there free margeritas?
**\<anonimal>** Present in Q state.
**\<Slack> [endogenic]** \* hands DaveyJones a margarita
**\<fluffypony>** DaveyJones: of course, dev meetings are 100% serious business and you need margaritas for that
**\<ArticMine>** greetings
**\<fluffypony>** ok let's move on to 2
**\<hyc>** when was the last meeting?
**\<DaveyJones>** 2 weeks before christmas?
**\<fluffypony>** it's been nearly 2 months since the last dev meeting because of end-of-year and me travelling etc.
**\<fluffypony>** does anyone want to mention stuff that's been done
**\<meeting-bot> [EinMByte]** Hi
**\<fluffypony>** (brb hopping out of taxi)
**\<meeting-bot> [i2p-relay] {-anonimal}** ^ FYI, monero meeting, kovri in 55 minutes.
**\<hyc>** many many commits have been merged
**\<dEBRUYNE>** I am here
**\<hyc>** I will mention my own, using batched txns for node syncing, to reduce I/O demand
**\<meeting-bot> [EinMByte]** anonimal: Oh right, should be keeping an eye on the meta repository too
**\<hyc>** this seems to speed up syncing on HDD by 2-3x while improving stability
**\<Jaquee>** great stuff hyc!
**\<anonimal>** hyc: sounds tasty
**\<hyc>** (the actual goal was to eliminate the few corruptions we've see non Windows)
**\<hyc>** seen on
**\<anonimal>** So the corruptions were fixed too?
**\<hyc>** so far it appears so.
**\<hyc>** I examined 3 corrupted Windows data.mdb files. they all had zero pages at the tail of the file
**\<hyc>** due to not being sync'd before OS crashed
**\<hyc>** the new code syncs more frequently, but in a background thread
**\<hyc>** so throughput is still high because foreground doesn't have to wait for it
**\<hyc>** but syncs are more often, to reduce the chance of unsync'd pages during a crash
**\<hyc>** but there's no 100% guarantee there.
**\<anonimal>** IIRC, this fix/addition was after latest point release? Was point release before or after the previous meeting?
**\<hyc>** this is for the default "fast" mode. you can still use "safe" mode for 100% guarantee, but super-slow.
**\<hyc>** and this is recent, merge was only a week or so ago
**\<anonimal>** ok
**\<fluffypony>** ok back, just got to sXpher's house
**\<hyc>** cool. I think that's it for me.
**\<fluffypony>** hyc: tons of commits
**\<hyc>** yeah
**\<fluffypony>** was fluffy blocks already merged in by the last meeting?
**\<anonimal>** I think so?... That was before point release right?
**\<hyc>** I thought fluffyblocks was in 0.10.1
**\<Jaquee>** yes, pretty sure it was
**\<iDunk>** It was
**\<moneromooo>** I think it could be enabled on mainnet now, since testnet's not shown anything wrong with it.
**\<fluffypony>** anonimal: I can't remember
**\<fluffypony>** moneromooo: agreed
**\<Jaquee>** +1
**\<anonimal>** moneromooo's new logging implementation, this is new.
**\<moneromooo>** Snipa: you did test it with a private testnet with only such nodes, right ?
**\<gingeropolous>** the crazy reorgs on testnet are due to old nodes on testnet?
**\<fluffypony>** yeah the new logging colours threw me for a loop :-P
**\<medusa>** yes logging is new, GUi scope for next release is like this:
**\<medusa>** extended x64 x86 linux support / cold signing / view only wallets / restore from private keys / integrated mining / better logging / daemon status button /
**\<medusa>** +display unlock time and confirmation
**\<Snipa>** moneromooo - No, I didn't test on a private testnet, but my personal nodes all have patches enabling it on mainnet between them, and I'm not seeing any issues with it yet.
**\<Snipa>** All of my testnet nodes of course, have been running it as well without issues.
**\<moneromooo>** OK, I guess my point was lost. I don't have the disk space for many blockchains to test though...
**\<Snipa>** If I need to go setup another one, I've got enough disk space to do so. IIRC we thought it wasn't needed because all of the active testnet nodes were using it.
**\<fluffypony>** medusa: ok great
**\<fluffypony>** I think for future we should have a separate line item for GUI stuff
**\<moneromooo>** My point was that I wanted to see if it worked on a network with ONLY fluffy blocks being sent.
**\<fluffypony>** (if there is GUI stuff I mean)
**\<moneromooo>** But it seems everyone just mentally removes the "only" word :D
**\<Snipa>** Ah, sorry, I must of missed that. I can set that up still if it's wanted. I've got more than enough nodes to do so.
**\<moneromooo>** That'd be great, yes.
**\<moneromooo>** I thought you'd already done that actually.
**\<moneromooo>** What I want to know is whether there is a failure mode when a node can't sync from a fluffy block, but gets the block anyway from another peer.
**\<fluffypony>** can't we just make testnet fluffy blocks only?
**\<fluffypony>** and then we test it there
**\<Snipa>** kk, I'll go figure out how to isolate a bunch of nodes this afternoon, and setup a small network to mine on.
**\<moneromooo>** We could.
**\<fluffypony>** testnet seems pretty robust given the amount of stuff we've done on it
**\<fluffypony>** lol
**\<medusa>** Snipa: https://github.com/moneroexamples/private-testnet
**\<Snipa>** I mean, I leave a couple hundred h/s there on my test pool. And have ~10-ish nodes up on it.
**\<Snipa>** Oh, so I can add multiple exclusive nodes? I think that was one of the questionmarks I was running into.
**\<fluffypony>** okyes
**\<fluffypony>** yes
**\<Snipa>** Good stuff, I'll go fight with that here in a bit.
**\<fluffypony>** ok
**\<fluffypony>** let's move on
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** issues on Github are starting to pile up, and I think we should get on top of that
**\<fluffypony>** as discussed before, the lack of granularity in Github's permissions is a bit of an irritation
**\<fluffypony>** we've discussed having a second repo with more collaborators, but I think that's going to create more confusion than anything else
**\<fluffypony>** so my suggestion would be that we set up an issue closing bot that has collab status
**\<fluffypony>** and then that has a list of people that can ping it to close issues
**\<hyc>** that sounds cool
**\<fluffypony>** I haven't had a chance to see if such a thing exists, but if not it isn't hard to write
**\<pero>** https://github.com/foosel/GitIssueBot
**\<medusa>** that sounds great
**\<fluffypony>** and if we set it up to do re-labelling too
**\<i2p-relay> {-anonimal}** How to protect from troll abuse?
**\<Jaquee>** cool. could it handle labeling too?
**\<pero>** cant close yet but perhaps can be extended
**\<moneromooo>** by "list of people"
**\<fluffypony>** anonimal: only specific people can ping it
**\<i2p-relay> {-anonimal}** k
**\<medusa>** a good start would be if everyone also takes care of their own issues in the meantime ( i know me included)
**\<fluffypony>** medusa: agreed
**\<fluffypony>** ok any Q&A items?
**\<moneromooo>** About what ? Anything ?
**\<fluffypony>** moneromooo: yes
**\<fluffypony>** hi, I'm fluffypony, AMA
**\<pero>** i'm actually curious about the status of paybee
**\<pero>** ;p
**\<moneromooo>** Then I'm annoyed at the merge commits, which can embed some arbitrary amount of dross, making things easy for an external attacker with access to github to slip pwnage.
**\<moneromooo>** Does anyone know a good way to prevent those (with manual exceptions since tewinget already said he wouldn't rebase the massive 0MQ branch) ?
**\<fluffypony>** pero: we can talk about it later
**\<DaveyJones>** any word from tewinget? did not read a thing from him recently, regarding 0mq
**\<moneromooo>** A git hook looks like the obvious option, though it's still vulnerable to github.
**\<pero>** i asked him last night - sec
**\<fluffypony>** moneromooo: you mean to merge without the merge commit?
**\<Jaquee>** that would require a rebase by the merger?
**\<pero>** \<tewinget> \<pero> very little movement on that front - the pr hasnt been touched in 2 months \<--- I haven't commented on it in as much time, but I've worked on it. Not as much as I could/should have, of course, but...
**\<moneromooo>** I'm not sure about that. AIUI, it's needed for the signatures. I'm not super knowledgeable about what that entails wrt amount of dross.
**\<i2p-relay> {-anonimal}** fluffypony: you very recently finished your extended 1 month+ tour, can you fill us in with details of any notable experiences?
**\<fluffypony>** moneromooo: it *is* needed for the signature, not everyone is signing their commits
**\<moneromooo>** Yes, rebase would fix, but that'd need a LOT of rebases, so isn't practical.
**\<hyc>** and cherry-picking would lose signature?
**\<moneromooo>** cherry-pick -S resigns.
**\<fluffypony>** it re-signs
**\<fluffypony>** and we want to maintain author sigs where they exist
**\<hyc>** but with picker's key, not original key?
**\* anonimal** believes so
**\<moneromooo>** Yes, if someone else cherry-picks, then you can't preserve sig.
**\<moneromooo>** This massive hole just annoys me, but I'm not sure how to fix it.
**\<fluffypony>** moneromooo: me neither
**\<luigi1112>** are you talking about the merge commits into master or like merging instead of rebasing
**\<fluffypony>** I don't think it's a solvable problem
**\<moneromooo>** My automated sig checking on make thing is also vulnerable to that, since it trusts anyuthing the pony signs.
**\<fluffypony>** luigi1112: merge commits into master
**\<moneromooo>** Well, we can ask him to rebase, that's not hard.
**\<moneromooo>** It is for tewinget due to the amount of stuff, but that's a special case.
**\<fluffypony>** moneromooo: rebasing will also make it hard to use Github to track PRs, surely?
**\<fluffypony>** rebase-only I mean
**\<luigi1112>** so you want the maintainers merge commits to go away?
**\<moneromooo>** I meant rebasing before PR. The merger would still do a merge commit, unfortunately.
**\<moneromooo>** No, just yours, if you PR any. I understood fluffypony's line to mean this, maybe I misunderdtood.
**\<hyc>** well,we can solve this but the procedure gets more awkward:
**\<hyc>** PR author rebases before merge
**\<hyc>** which mean merger has to contact PR author immediately before each merge
**\<moneromooo>** Oh, I hadn't seem luigi1112's first line. Ignore my last 2 then.
**\<moneromooo>** Yes, that's what I ment by not practical :/
**\<fluffypony>** yeah that won't work
**\<fluffypony>** :(
**\<anonimal>** Question:
**\<fluffypony>** anonimal: answer
**\<fluffypony>** :-P
**\<moneromooo>** I guess the best we can do it some kind of subjective "rebased not too long ago so any extra dross diff is small enough".
**\<DaveyJones>** i know ... i know ... 42
**\<anonimal>** Ok, two questions: is PR author out of the picture? Poof/gone?
**\<moneromooo>** But it requires the merge to check it.
**\<moneromooo>** anonimal: usually not, but maybe a couple days' latency. Which means the merger has all the latencies in series.
**\* anonimal** not 100% following the problem
**\<anonimal>** Oh, ok.
**\<i2p-relay> {-olark}** What about hosting code on something that is under our control and not github? This would involve not using github though.
**\<fluffypony>** moneromooo: but this is all in an effort to make sure that maintainers can't introduce extra bits in, right?
**\<moneromooo>** I guess most of the problem is fixed by refusing any patch with irrelevant crap, with merge commits, and when they also cause more than trivial diffs in the final merge commit.
**\<fluffypony>** olark: that's not the problem, my merge commits are GPG signed, so *I'm* the failure mode, not Github
**\<i2p-relay> {-olark}** right
**\<anonimal>** So, why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?
**\<moneromooo>** Well, maintainers and anyone who could fool the maintainer into signing a large merge.
**\<anonimal>** If they can't keep up, then do the work for them?
**\<moneromooo>** anonimal: I do not understand "why not close their PR and reopen a new one with their branch merged (not rebased) to maintain original sigs?"
**\<hyc>** neither do I
**\<hyc>** sounds to me like it would create exactly the problem we're trying to address
**\<hyc>** PRs with irrelevant changes sliding in
**\<anonimal>** I think I don't understand the problem, so my question doesn't make sense.
**\* anonimal** is 25% here, preparing for kovri meeting
**\<fluffypony>** moneromooo: otoh it's not like we have so many eyes on PRs that nothing at all could be snuck past us, so maybe we're trying to solve a problem that is ultimately a non-issue
**\<hyc>** I think we should continue this after the meeting, probably won't solve it here.
**\<moneromooo>** So... we're screwed alrady, might as well not care ?
**\<luigi1112>** :-)
**\<fluffypony>** moneromooo: yes :-P
**\<moneromooo>** I guess it is a practical solution for now.
**\<moneromooo>** Though, an easy win is to automatically reject any PR with a merge commit in it.
**\<i2p-relay> {-olark}** hmm
**\<moneromooo>** If github could be set up to reject those, that'd remove a good chunk of dross already.
**\<fluffypony>** moneromooo: I'm happy with that - could the requester fix it by rebase + force-push ?
**\<moneromooo>** (though still vulberable to github itself, but we said we don't care for now)
**\<hyc>** do you have a recent example of a problematic PR?
**\<moneromooo>** Yes. That's what I do when I fix a trivial thing in a PR of mine.
**\<Slack> [nanoakron]** That’s what I do with mine
**\<hyc>** and yes, I usually rebase my PRs on latest master
**\<fluffypony>** on the topic of Github, pigeons has a Gitlab mirror running on our (Monero's) hardware, so we're reasonably resilient to weirdness
**\<moneromooo>** Not a recent one. I found one, but it's a very odd behavior on a single VM.
**\<moneromooo>** A mirror isn't really a good protection against this I think.
**\<fluffypony>** ok so new rule is that people submitting PRs should be asked to rebase + force-push if a merge commit exists in their PR
**\<moneromooo>** Yes, please. I do when I see them, but I often look just at the diffs and forget commits.
**\<hyc>** yeah that sounds reasonable
**\<Jaquee>** yep
**\<moneromooo>** But it could be automated I think.
**\<fluffypony>** I'll look to see if there's a hook
**\<fluffypony>** would be nice to automate things like notices on buildbot failures
**\<moneromooo>** I just saw a java jar one. Which seemed... meh.
**\<fluffypony>** or on first-buildbot-failure
**\<Slack> [jollymort]** i have one q: what if the price explodes again and does 10x - what to do with fees? make F0 in the dynamic fee calc 10x smaller? somehow i feel it would call for a one time 10x blocksize bump as well to keep the proportions same, otherwise we'd need huge multipliers to get to the point where increasing fee gives incentive to bump the blocks
**\<fluffypony>** ArticMine: ^^
**\<ArticMine>** A price increase without a corresponding increase in blocksize?
**\<Slack> [jollymort]** yeah
**\<pigeons>** the ircbot for buildbot can notify when a job goes success->fail
**\<Slack> [nanoakron]** @jollymort it’s not really reasonable to ask the blockchain to care about the fiat price because that requires gameable oracles
**\<fluffypony>** pigeons: can it notify on the PR tho?
**\<pigeons>** yes
**\<fluffypony>** pigeons: ok cool - let's chat about it later / tomorrow and figure out which platforms we want to target with that
**\<Slack> [jollymort]** nanoakron i get it, but with the current set-up we decided on an arbitrary starting point
**\<Slack> [nanoakron]** You mean 60k blocks?
**\<DaveyJones>** also jollymort ... what is a reasonable time-frame to call sth a higher price to even justify changing F0 ?
**\<moneromooo>** fwiw, there's so much constant failures that I ignore the buildot pings now (sorry)
**\<ArticMine>** Over time the assumption is that price follows transaction demand. Over the short term ther may well be a delay.
**\<Slack> [jollymort]** good point Davey... but i can imagine a scenario where we have 3$ fees for some period
**\<Slack> [nanoakron]** @jollymort What is a $3 fee? How does the system determine that in a zero-trust manner?
**\<Slack> [jollymort]** it doesn't
**\<Slack> [jollymort]** maybe difficulty is a loose peg
**\<Slack> [nanoakron]** Fees are an economic negotiation between miners and users
**\<ArticMine>** If the price rises very fast it could happen. There is another complication factor here namely one time changes in transaction size
**\<Slack> [jollymort]** yeah, was RCT size bump considered?
**\<DaveyJones>** maybe if sth like the average tx over a given time period sink TOO low some kind of mechanism would detect such a behaviour and see it as too expensive TX
**\<ArticMine>** Ultimately fees are set by the blocksize penalty / demand / base reward
**\<Slack> [jollymort]** nanoakron i know that, but the minimum fee could become problematic in case of price bump
**\<Slack> [nanoakron]** The sudden increase to RCT sizes should have perhaps been considered in advance. The problem is people who panicked and refused to use RCT Tx, thereby keeping an odd mix of large and small Tx in each block, preventing proper upwards adjustment in size and downwards adjustment in fee
**\<DaveyJones>** buth my math is way to bad to give a better example :D
**\<Slack> [jollymort]** so just changing F0 would probably be ok
**\<ArticMine>** Yes the minimuim fee could need to be adjusted
**\<Slack> [nanoakron]** @jollymort can you please model what you want to happen first and submit it as a post or code somewhere so it can be considered formally? A bit of academic rigour would be nice here
**\<ArticMine>** We just had an effective increase in TX size ~10x +
**\<DaveyJones>** without changing F0
**\<ArticMine>** F0 was changed just before in anticipation
**\<DaveyJones>** ah okay
**\<Slack> [jollymort]** cool
**\<Slack> [jollymort]** anyway, i'll do some study
**\<Slack> [jollymort]** but just wanted to see your thoughts
**\<ArticMine>** The relevant question is the change in RingCT Tx size and further optimizations
**\<Slack> [nanoakron]** I’m not averse to the idea, so long as it can be justified with a nice model of the expected behaviour and consideration of the potential attack surface
**\<Slack> [xmr-eric]** I have a question. When should the GUI come out of beta status? Because things are feeling pretty stable and the featureset seems complete to me.
**\<ArticMine>** Since this influences blocksize and consequently fee paid
**\<hyc>** It should be perpetually beta. It gets lonely around here without the reassuring lull of "where's the GUI" in the background
**\<Slack> [jollymort]** i was thinking of: increase baseline block size x5 and reduce F0 with x0.2
**\<Slack> [jollymort]** but block size is consensus so..
**\<moneromooo>** Where's the LMDB wallet file ?
**\<Slack> [jollymort]** needs some justifications
**\<DaveyJones>** nanoakron like i said... maybe sth like the average tx numbers decrease drastically for a given time frame could be a trust-less way too do it... but i have no clue how to get a decent formula
**\<Slack> [nanoakron]** Hrm...
**\<DaveyJones>** as actual example... the price pumps and suddenly it is WAY to expensive to do any tx for the people
**\<Slack> [jollymort]** tx numbers can be gamed
**\<ArticMine>** jollymort there is merit to this
**\<Slack> [nanoakron]** @hyc is it possible to auto-scan the database file if the system wants to crash? e.g. “Database corrupt after block 120842…rewinding…"
**\<Slack> [jollymort]** x5 due to RCT size increase
**\<Slack> [jollymort]** when the original 60kb was set, probably RCT was not in the works
**\<Slack> [jollymort]** so it was based on TXes of 1kb
**\<luigi1112>** yes
**\<ArticMine>** the issue is the relative size of the tx to minim blocksize
**\<Slack> [jollymort]** or whatever was the pre-RCT size
**\<luigi1112>** is dev meeting over
**\<hyc>** nanoakron: not in general. since we only keep 2 persistent versions of the DB.
**\<Slack> [jollymort]** ArcticMine yes, that's how i see it
**\<hyc>** nanoakron: if the OS failed to sync the previous two txns, then the corruption is uncrecoverable.
**\<Slack> [nanoakron]** @hyc :( How about these pages of zeroes - if that’s a consistent failure mode can they be unwound?
**\<Slack> [nanoakron]** Oh
**\<fluffypony>** ok guys
**\<Slack> [jollymort]** anyways, just wanted to know if anyone else thought about this; won't take any more of your time
**\<fluffypony>** let's wrap it up
**\<Slack> [nanoakron]** That’s all it takes?
**\<Slack> [nanoakron]** 2 Tx
**\<fluffypony>** Kovri meeting starting in 5 minutes
**\<hyc>** nanoakron: yes. we could change this.
**\<DaveyJones>** fluffypony ... AMA after the kovri meeting? :D about your journey and paybee?
**\<hyc>** nanoakron: use a longer delay before reusing old pages.
**\<DaveyJones>** if you got something to tell ^^
**\<Slack> [nanoakron]** @hyc Ok. At least there’s a potential way through it.
**\<i2p-relay> {-olark}** I opened an issue to start discussing alternatives to the ringsize increase in September 2017 that negates a lot of possible attack vectors on ring signatures and still ensure a 'true' strength of ringsize 4 at minimum for all transactions. It is here https://github.com/monero-project/monero/issues/1673 I think it requires serious consideration moving forward. I won't go too much into it and
**\<i2p-relay> {-olark}** just let everyone read the writeup :p
**\<Slack> [nanoakron]** @olark I’d like knaccc to contribute too with his modelling of churn
**\<Slack> [xmr-eric]** I like the idea of a static ringsize
**\<Slack> [jollymort]** i like the "static" proposal
**\<Slack> [xmr-eric]** ^^
**\<Slack> [jollymort]** and yes, also churn
**\<fluffypony>** DaveyJones: sounds good - I've got to step out for a little bit
**\<Slack> [xmr-eric]** No thoughts on getting GUI out of beta status, everybody
**\<i2p-relay> {-olark}** because the current situation is... undesirable to say the least
**\<moneromooo>** What is beta status ?
**\<hyc>** xmr-eric: sounds like not yet.
**\<Jaquee>** xmr-eric: i think we need one more beta release at least.
**\<knaccc>** nanoakron kenshi84 blew some big holes in my churn suggestion btw, so my model isn't good yet.
**\<Slack> [nanoakron]** @knaccc Ah…well, all discussion is good
**\<Slack> [xmr-eric]** Cool
**\<hyc>** knaccc: cool, is that written anywhere?
**\<Slack> [nanoakron]** @xmr-eric and if you see bugs, please bring them up on github
**\<fluffypony>** ok anonimal the floor is yours
**\<Slack> [jollymort]** also, opened discussion on multiple PID / TX : ) https://github.com/monero-project/monero/issues/1659
**\<knaccc>** hyc only in my IRC logs. Summary is that the churn only works if you're churning with pure ringct trees, doesn't work if there are non-ringCT transactions mixed in
**\<hyc>** thx
**\<meeting-bot> [i2p-relay] {-anonimal}** I have 2 minutes to prepare
**\<Slack> [jollymort]** i thought you can't mix rct+non-rct outputs anyway
**\<meeting-bot> [i2p-relay] {-anonimal}** 17:59 1 minute!
**\<Jaquee>** +1 lmdb wallet
**\<Slack> [nanoakron]** waits with bated breath
**\* moneromooo** congratulates nanoakron for correct spelling.
**\<Slack> [nanoakron]** :grimacing:
**\<anonimal>** Any objections to me typing in #monero-dev?
**\<knaccc>** jollymort it's when you mix with an output that is a ringct output but whose inputs are non ring-ct. that breaks churn
**\<meeting-bot> [fluffypony]** none from fluffy-on-this-side either
**\<fluffypony>** none
**\<hyc>** no objection
**\<moneromooo>** That wasn't sarcasm actually :D
**\<meeting-bot> [i2p-relay] {-ArticMine}** Fine with me
\ No newline at end of file
_posts/2017-02-19-overview-and-logs-for-the-dev-meeting-held-on-2017-02-19.md 0 → 100644
+ 204
− 0
View file @ 5dd20c12
---
layout: post
title: Overview and Logs for the Dev Meeting Held on 2017-02-19
summary: 0MQ, 10.2 release, and background mining
tags: [dev diaries, core, crypto, 0mq]
author: dEBRUYNE / fluffypony
---
*February 19th, 2017*
# Logs
**\<fluffypony>** 1. Greetings
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<fluffypony>** 4. Any additional meeting items
**\<fluffypony>** 5. Confirm next meeting date/time
**\<hyc>** hola
**\<fluffypony>** so greetings
**\<fluffypony>** hi!
**\<ArticMine>** hi
**\<tewinget>** (here)
**\<vtnerd>** also present
**\<moneromooo>** hi
**\<tewinget>** I'll be sorta afk for the next 5ish minutes, but I'm around.
**\<fluffypony>** ok
**\<fluffypony>** 2. Brief review of what's been completed since the previous meeting
**\<fluffypony>** so
**\<fluffypony>** second meeting of the year
**\<fluffypony>** and we've been pushing ahead solidly
**\<fluffypony>** we've had a bunch of PRs by newcomers
**\<jollymort>** once you go solid state you never go back
**\<fluffypony>** including tpltnt, and IPGlider has also pushed a few PRs
**\<fluffypony>** we switched to EasyLogging++, which is a pretty big change
**\<fluffypony>** and MoroccanMalinois made Android builds happen
**\<fluffypony>** tdprime also pushed their first PR
**\<fluffypony>** and then the usual rash of PRs from moneromooo, vtnerd, hyc, NanoAkron, and Jaquee
**\<fluffypony>** (I've probably missed someone)
**\<pigeons>** reveler with the background mining
**\<hyc>** revler
**\<fluffypony>** yes thanks pigeons
**\<fluffypony>** oh and pigeons had a PR too
**\<jollymort>** kenshi84 disposable addresses
**\<fluffypony>** and kenshi84
**\<fluffypony>** ok - anything else major I missed that happened in the last two weeks before we move on to 3?
**\<moneromooo>** All the new one time address stuff from knaccc, randomrun, kenshi, jollymort.
**\<knaccc>** yes subaddresses are back!
**\<moneromooo>** And luigi.
**\<fluffypony>** moneromooo: I was going to get to that in 3
**\<hyc>** ok, sounds like we move on to 3
**\<fluffypony>** since it's in the MRL repo
**\<fluffypony>** 3. Code + ticket discussion / Q & A
**\<jollymort>** I wasn't following that discussion, focused on study on fees atm
**\<fluffypony>** ok so there have been a few long-form discussions going on in various issues
**\<jollymort>** also the one for ring size
**\<fluffypony>** yeah the ring size one is one I wanted to bring up
**\<fluffypony>** I think the discussion has mostly been positive, nobody's gotten crazy out-of-hand or anything
**\<fluffypony>** it *is* a complex topic
**\<fluffypony>** and I think that we have enough time to figure out a good route forward
**\<fluffypony>** does anyone have an objection to it continuing in the GitHub issue?
**\<hyc>** seems like all the context is there
**\<hyc>** so it should continue there
**\<jollymort>** I feel like it's more suitable for an issue under MRL, any thoughts of moving it there (if possible)?
**\<jwinterm>** I haven't been following the issue too closely, but is there still some sentiment building around fixing ring size for all txs?
**\<fluffypony>** jollymort: I think the GH issue is fine, it can kinda be anywhere, but if we're going to turn that into a publication that explores the various options and reasons for recommendations then it would develop as PRs to the research-lab repo
**\* jwinterm** goes to github
**\<jollymort>** I meant, keep it as a GH issue, but under another repo so it doesn't get buried under all code/bug related issues
**\<jwinterm>** as someone not following the issue, it does kind of get lost in the noise with 164 open issues
**\<jwinterm>** #1673?
**\<fluffypony>** yeah it would be nice if GH let you subscribe to just a single issue
**\<fluffypony>** I'm not opposed to moving it to the research-lab repo
**\<fluffypony>** how would we do that tho
**\<hyc>** no idea
**\<pero>** someone creates a synopsis of where the discussion is at currently in the new ticket and links back to older ticket
**\<hyc>** yeah, new text
**\<hyc>** with @mentions of original participants
**\<fluffypony>** ok I'll suggest it in the thread
**\<fluffypony>** then on the topic of discussion
**\<fluffypony>** I'd like to encourage us to also take some Q&A / discussion items to StackExchange where we can
**\<fluffypony>** and to redirect people who open issues to just ask a question to StackExchange
**\<hyc>** hm, I would expect that SE is for "settled" questions
**\<fluffypony>** SE is a great place for canonical information that is updated over years
**\<jollymort>** I'd just like to add that SE is not really a format for discussions, more for things with an actual answer existing
**\<fluffypony>** hyc: nope, anyone can edit an accepted answer with new information
**\<jollymort>** like hyc said
**\<jollymort>** there's SE chat, though - which nobody uses
**\<fluffypony>** jollymort: some of the questions on GitHub issues are perfect for SE
**\<jollymort>** sure
**\<fluffypony>** https://github.com/monero-project/monero/issues/1751 as an example
**\<hyc>** monero clone?
**\<fluffypony>** hyc: probably, I thought that too
**\<fluffypony>** but that's a good question for SE
**\<fluffypony>** which also has a larger group of answer-ers than the GH repo
**\<taushet>** it is already answered though, sort of http://monero.stackexchange.com/questions/2886/how-can-i-create-a-new-monero-genesis-block
**\<fluffypony>** taushet: yes but SE has tools to close as a duplicate and redirect them to the answer
**\<fluffypony>** and moderators can do that without us needing to
**\<taushet>** fluffypony - agreed. also the 'issue' was not so much an issue with the code as much as it was a question but a user/tinkerer who could not get something to work
**\<taushet>** anyway
**\<fluffypony>** yeah exactly
**\<Slack> \<nanoakron>** What if someone went through and opened parallel SE questions for all those types of question, redirected the original asker, then we shut the issue?
**\<hyc>** sounds good
**\<fluffypony>** @NanoAkron yes that's exactly my recommendation
**\<Slack> \<nanoakron>** Ok I might see what I can do if I get any free time tonight
**\<fluffypony>** then you even get SE karma or points or rep or whatever it's called
**\<Slack> \<nanoakron>** Woo!
**\<fluffypony>** gamification ftw!
**\<fluffypony>** ok anything else under Q&A ?
**\<hyc>** specific tickets?
**\<hyc>** like 0MQ PR?
**\<fluffypony>** yep I believe tewinget said he had to check if it was working with RingCT
**\<fluffypony>** tewinget: ^^
**\<Slack> \<nanoakron>** Any thoughts about 0.10.2?
**\<fluffypony>** @NanoAkron yes
**\<fluffypony>** we've been discussing it
**\<fluffypony>** because it will coincide with beta 2 of the GUI
**\<Slack> \<nanoakron>** Oh nice
**\<fluffypony>** as we're marrying daemon / GUI versions
**\<Slack> \<nanoakron>** Makes good sense. Will #1746 be addressed too?
**\<jollymort>** do you intend to code in stuff for the next HF in 0.10.2?
**\<Slack> \<nanoakron>** I.e. Auto starting daemon
**\<fluffypony>** there are a few things that need to be done in the daemon / GUI before the next release
**\<tewinget>** sry
**\<fluffypony>** jollymort: no
**\<fluffypony>** we only have to finalise that by like July
**\<tewinget>** just got my second monitor back from a friend, was setting it up real quick.
**\<jollymort>** ok, thanks
**\<fluffypony>** @NanoAkron I don't see why we can't make sure 1746 is sorted, Jaquee any thoughts ?
**\<tewinget>** so Snipa was kind enough to chuck a battery of tests at my zmq branch, which is great. It seems there are a couple things I need to look at, which is expected, but his tests seem rather comprehensive, so once those are passing it should be good to go.
**\<moneromooo>** Does this keep a backward compat layr for the current JSON API ?
**\<tewinget>** moneromooo: currently it neither replaces nor modifies any current RPCs
**\<Slack> \<nanoakron>** Esp since the number of rpc commands has increased
**\<fluffypony>** moneromooo: long term yes - the current JSON API will be in its own binary, like monero-rpc-server, and that will use 0MQ to communicate with the daemon
**\<tewinget>** but also short-term yes because I haven't done anything to the existing RPCs
**\<Slack> \<nanoakron>** I heard it would be passing plaintext commands/JSON and not binary. Or am I mistaken?
**\<tewinget>** nanoakron: that is correct, everything is marshalled via json
**\<tewinget>** this is so that higher-level languages have no problem using the RPC
**\<pigeons>** or jaxx :P
**\<tewinget>** as the (de)serialization takes no time at all compared to the computations/fetching
**\<tewinget>** pigeons: hope springs eternal
**\<hyc>** this is for wallet-style client RPCs only then
**\<Slack> \<nanoakron>** Doesn't that mean that there are now two sets of commands to maintain in sync - JSON-RPC (won't be deprecated) and JSON-over-ZMQ?
**\<fluffypony>** JSON-RPC *will* be deprecated for the daemon
**\<fluffypony>** we won't add new RPC commands to it
**\<fluffypony>** JSON RPC for the wallet will continue to evolve and exist
**\<fluffypony>** because web apps rely on it
**\<fluffypony>** communication with the daemon will be relegated to 0MQ only
**\<moneromooo>** !bookie no-json-rpc-added-ever-again yes no
**\<Slack> \<nanoakron>** But in JSON format
**\<moneromooo>** aw...
**\<fluffypony>** (eventually)
**\<fluffypony>** @NanoAkron yes
**\<fluffypony>** so existing apps that interact with the daemon, eg. pool software, can continue by adding a 0MQ library
**\<fluffypony>** and modifying any calls that have changed
**\<tewinget>** (which won't be many, there were just a few that seemed silly in some ways, and changed accordingly, but none of that is set in stone)
**\<fluffypony>** anything else?
**\<fluffypony>** or I guess we can include that in the next item on the agenda
**\<fluffypony>** 4. Any additional meeting items
**\<Slack> \<nanoakron>** Neigh
**\<fluffypony>** lol
**\<fluffypony>** we should use HAY and NEIGH instead of ACK and NACK
**\<Slack> \<nanoakron>** Lol
**\<tewinget>** I'll keep updating over the next couple days, fwiw. Gotta get with Snipa to see if he can make a couple of modifications to the tests for me to make issues track-down-able, but he's afk until tomorrow.
**\<moneromooo>** Hmm, range sig reduction... multisig... fee formula change...
**\<Slack> \<nanoakron>** Yes
**\<pigeons>** Snipa: are these tests in your github?
**\<fluffypony>** oh I have an item for brief discussion
**\<jollymort>** it's not just the fee, penalty needs tweaking
**\<fluffypony>** as everyone knows, the dynamic block adjuster isn't adjusting very well since the txs became larger
**\<pero>** snipa is afk until tmrw iirc
**\<jollymort>** either by increasing the min. blocksize, or having a transition formula
**\<fluffypony>** does everyone think we should leave it as-is until September, with the occasional backlog
**\<fluffypony>** or should we have some intermediary hard fork ?
**\<ArticMine>** We may need one
**\<hyc>** If we have a fix now, would be nice to deplot it sooner
**\<hyc>** deploy
**\<Slack> \<nanoakron>** But it has to be smart enough to account for potential future changes in range proof and therefore Tx size
**\<jollymort>** it accounts :)
**\<pero>** september is a long time away
**\<Slack> \<nanoakron>** As well as ring size. Txes will become much more standardised in size and non-parametrically distributed
**\<fluffypony>** ok I think that's reasonable consensus, as soon as we have something workable we'll put it out to the community as a hard fork and see how they feel
**\<Slack> \<nanoakron>** So medians etc may not make statistical sense
**\<DaveyJones>** you could HF at around the time when originally the ringct hf was supposed to happen
**\<ArticMine>** nanoakron We are looking at a fall in tx size?
**\<Slack> \<nanoakron>** Hopefully. Size would fall will range proof improvements, but distribution of sizes would flatten with ring size standardisation. Parametric statistics would no longer apply.
**\<fluffypony>** DaveyJones: that's in March, too soon for a planned fork
**\<Slack> \<nanoakron>** So adjusting based on moving medians would be meaningless. We'd need to deploy alternate statistical tests.
**\<moneromooo>** Can you explain that ?
**\<fluffypony>** ok
**\<fluffypony>** anything else before we close the meeting ?
**\<fluffypony>** (we can discuss specifics after the meeting)
**\<Slack> \<nanoakron>** Even now with a mix of rct and non-rct transactions the median is meaningless because the size distribution is non parametric
**\<jollymort>** it's some typical size which is most important, currently at 13kB
**\<hyc>** calculate two separate medians. one for rct and one for non-rct.
**\<jollymort>** doesn't matter if it's +/- 1kB
**\<Slack> \<nanoakron>** It's instead bimodal
**\<hyc>** sounds like we're done with the meeting side of things then
**\<jollymort>** I mean, if you roll out some change to TX format, you already know the next typical size it will cause
**\<fluffypony>** last item is the next meeting time
**\<jollymort>** and you will need to HF anyway, so all you'd need to do is adjust one parameter for the dynamic blocksize/fee
**\<fluffypony>** 2 weeks from now
**\<fluffypony>** March 5th
**\<hyc>** cool
**\<fluffypony>** I will be on a plane to London, but should have wifi and should be able to attend the meeting
**\<fluffypony>** thanks guys
\ No newline at end of file
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment