mirror of
https://github.com/monero-project/monero-site.git
synced 2024-12-22 19:49:26 +00:00
Logs for the Dev (2018-01-14), Community (2018-01-20), and Bulletproofs (2018-01-21) meeting
Add research tag
This commit is contained in:
parent
8eef71bcb2
commit
ae3c59fd2f
3 changed files with 1353 additions and 0 deletions
412
_posts/2018-01-14-logs-for-the-dev-meeting-held-on-2018-01-14.md
Normal file
412
_posts/2018-01-14-logs-for-the-dev-meeting-held-on-2018-01-14.md
Normal file
|
@ -0,0 +1,412 @@
|
|||
---
|
||||
layout: post
|
||||
title: Logs for the Dev Meeting Held on 2018-01-14
|
||||
summary: Discussion of open PRs and issues, Bulletproofs, March HF, and miscellaneous
|
||||
tags: [dev diaries, core, crypto]
|
||||
author: dEBRUYNE / fluffypony
|
||||
---
|
||||
|
||||
# Logs
|
||||
|
||||
**\<rehrar>** https://github.com/monero-project/meta/issues/157
|
||||
**\<rehrar>** Here's the agenda.
|
||||
**\<rehrar>** We kinda did greetings, but if anyone else is present, please say "hi"
|
||||
**\<gingeropolous>** hi
|
||||
**\<jtgrassie>** hi!
|
||||
**\<pigeons>** hi!
|
||||
**\<Maxithi>** hi
|
||||
**\<pebx>** hi
|
||||
**\<ferretinjapan>** hi
|
||||
**\<binaryFate>** hi
|
||||
**\<rehrar>** alright, so let's get started then!
|
||||
**\<rehrar>** 2. Brief review of what's been completed since the previous meeting
|
||||
**\<rehrar>** Anyone have anything exciting or fun to report since our last meeting a month ago?
|
||||
**\<rehrar>** Get any fun gifts for the holidays maybe?
|
||||
**\<Maxithi>** 24 commits 4 days ago.
|
||||
**\<Maxithi>** On the main core. Nothing special. Maybe a little cheering for cslashm and hist first Ledger PR.
|
||||
**\<endogenic>** well we've made some progress with apple, fyi … confirmed there was an account mixup on their side with a human being and we're finally getting that sorted. will update you all as i hear things
|
||||
**\<rehrar>** that IS pretty exciting Maxithi
|
||||
**\<endogenic>** have to submit some docs, etc
|
||||
**\<hyc>** nothing much to report here
|
||||
**\<sgp>** hi
|
||||
**\<rehrar>** endogenic dude, that's gotta be thrilling to get some news finally
|
||||
**\<rehrar>** ArticMine, do you want to speak briefly about Kiev?
|
||||
**\<endogenic>** rehrar yeah i mean these things usually happen instantly so once i called them they were like yeah that's no good let'sget that sorted
|
||||
**\<ArticMine>** Sure, but it is not really dev related
|
||||
**\<rehrar>** just a brief four sentence thing should be alright
|
||||
**\<vtnerd>** after a discussion with luigi1111, I should be proposing an optimization for wallet scanning that mymonero is using - want to test with a standard wallet to give real world perf numbers before PR
|
||||
**\<vtnerd>** ah sorry ArticMine
|
||||
**\<rehrar>** no, go ahead vtnerd :) anyone and everyone with an update feel free to let us know
|
||||
**\<vtnerd>** ok, this optimization is separate from the ASM work in monero-project/supercop (still pending a PR), so it works with standard ref10 (i.e. all platforms)
|
||||
**\<vtnerd>** it will require a few changes to src/crypto.{h|c} so be on the lookout for that PR
|
||||
**\<gingeropolous>** is this just for your standard refresh? or related to remote viewkey scanning... or both?
|
||||
**\<vtnerd>** this is specifically for scanning receiving outputs on a primary address
|
||||
**\<vtnerd>** it does not benefit subaddresses, but does benefit simplewallet / GUI / anyone doing viewkey scanning
|
||||
**\<medusa>** lets talk about the elephant in the room ? bulletproof is in all varieties on testnet
|
||||
**\<rehrar>** Alright. Thanks. :) Anyone else? If not we'll move on.
|
||||
**\<rehrar>** Ye, that's next.
|
||||
**\<moneromooo>** Things of note since last time: build hardening (currently breaks static builds though), DNSSEC fix on windows, DB and sync hang fixes, secure memory wiping (wip), misc code review and fixes, updates now use HTTPS and can resume downloads
|
||||
**\<ArticMine>** In brief I attended BTC awards CIS and participated in the coins panel. There were two other coins present Dash, ZenCash. Overall it went very well and provided exposure to Monero among the CIS (Commonwealth of Independent state) crypto communities
|
||||
**\<endogenic>** medusa: last i heard MRL was looking for people to review and audit bulletproofs
|
||||
**\<endogenic>** sarang would be able to give you more information
|
||||
**\<ArticMine>** That is my brief update
|
||||
**\<ArticMine>** Whan it comes to bullteproof this has to move to September
|
||||
**\<endogenic>** moneromooo: beast mode
|
||||
**\<rehrar>** ArticMine, care to elaborate?
|
||||
**\<moneromooo>** Not all of this by me fwiw.
|
||||
**\<hyc>** Interesting ArticMine - CIS already has monero experience, thru the Karbo clone in Ukraine
|
||||
**\<medusa>** GUI is merging sub addresses finally, dsc is working on the black theme sucessfully and we hope to go live in march with 2 progress bars instead of 1 (sync and refresh separated). also we added a "change password" feature to the GUI
|
||||
**\<ArticMine>** FP spoke with Pieter Wuille who is recommending September
|
||||
**\<sarang>** Jumping in for any questions about BPs that I can answer
|
||||
**\<ArticMine>** Is there a plan for further review?
|
||||
**\<ArticMine>** of B
|
||||
**\<sarang>** Yes
|
||||
**\<ferretinjapan>** Are there any showstoppers on bullteproofs that would justify moving back rolling it out?
|
||||
**\<sarang>** Initiating contact w/ an audit group that fluffypony knows
|
||||
**\<sarang>** It's not fully clear what their scope of review can be, but I will find out shortly on a phone meeting with them
|
||||
**\<sarang>** The goal being additional third-party review
|
||||
**\<hyc>** ferretinjapan: there's no known problems. additional review is being planned to avoid unknown problems
|
||||
**\<rehrar>** Yeah, so we naturally moved onto third item on the agenda, which is code freeze, March hard fork. Bulletproof is the biggest one. Everyone's thoughts?
|
||||
**\<binaryFate>** beyond code review, sarang what is your opinion on the need of review of the math itself? I'm worried the paper has little time to go through peer-review. But maybe match checks out so obviously that it's not needed.
|
||||
**\<sarang>** The math is solid. Additional peer review is always a welcome thing, though with diminishing returns over time
|
||||
**\<binaryFate>** (talking about the BP paper -- not the Monero specific implementation)
|
||||
**\<sarang>** yes
|
||||
**\<sarang>** In the meantime, moneromooo and I have been working on some additional optimizations for proof verification that are independent of the math or specific proof implementation
|
||||
**\<ferretinjapan>** I guess thats the thing, how much "value adding" is an additional audit for now justified?
|
||||
**\<binaryFate>** nice
|
||||
**\<sarang>** We've had a select number of informal reviews
|
||||
**\<sarang>** but no formal third-party review yet
|
||||
**\<ArticMine>** ... but still this warrants a delay to September for BP
|
||||
**\<sarang>** To get the review done? Almost certainly
|
||||
**\<sarang>** The advantage to the delay is that we could bypass single-output BPs altogether
|
||||
**\<sarang>** figure out the multi-output fee structure, and release that
|
||||
**\<medusa>** multi output for march is a non option ?
|
||||
**\<sarang>** Correct
|
||||
**\<ferretinjapan>** seems incredibly wasteful :/
|
||||
**\<sarang>** It requires a change to the way fees are computed
|
||||
**\<hyc>** I'm in favor of skipping single-output. would be a lot of work for a very short-lived feature.
|
||||
**\<sarang>** Yes, though single-output proofs will verify with the multi-output code with no changes
|
||||
**\<ferretinjapan>** you'd be better served making sure that there is a fallback to BP instead of pushing back entirely.
|
||||
**\<rbrunner>** Isn't the work almost all done anyway?
|
||||
**\<ferretinjapan>** this is a classic case of perfect being the enemy of good.
|
||||
**\<endogenic>** realized we didnt ping anonimal
|
||||
**\<sarang>** We have multi code working now
|
||||
**\<sarang>** it's not in testnet yet
|
||||
**\<sarang>** and we don't have consensus about the fee structure
|
||||
**\<hyc>** ^^
|
||||
**\<binaryFate>** I lean towards satefy in general. The ringct bug was close enough
|
||||
**\<Maxithi>** hyc Same, better safe than sorry.
|
||||
**\<iDunk>** Agreed.
|
||||
**\<dEBRUYNE>** sarang: have you considered contacting the paper authors for review?
|
||||
**\<gingeropolous>** ferretinjapan, the push to sept is about additional code review, not really about multiout
|
||||
**\<dEBRUYNE>** \<binaryFate> I lean towards satefy in general. The ringct bug was close enough \<= I can't survive another mini heart-attack probably
|
||||
**\<sarang>** We've had informal review from one author, but the other authors are working on other implementations and I would not rely on them for a speedy review
|
||||
**\<hyc>** I suggested soliciting reviews on the Cryptography email list
|
||||
**\<endogenic>** nice idea
|
||||
**\<hyc>** could also solicit reviews on twitter
|
||||
**\<dEBRUYNE>** But presumably they would have some time somewhere between now and August?
|
||||
**\<endogenic>** that too
|
||||
**\<dEBRUYNE>** \^ sara
|
||||
**\<dEBRUYNE>** sarang\*
|
||||
**\<sarang>** hyc: are you ok with making such a solicitation?
|
||||
**\<sarang>** I could certainly try the other paper authors just in case
|
||||
**\<moneromooo>** bypass single-output BPs is not an advantage.
|
||||
**\<hyc>** Yes, can do. we need to decide if we'll offer a payment
|
||||
**\<sarang>** though they are much more of a long shot
|
||||
**\<moneromooo>** bypassing
|
||||
**\<ferretinjapan>** gingeropolous, yes, but noones really given a definitive reason to delay except for an overabundance of caution, and by then it'll be unnecessary to even release. :/
|
||||
**\<endogenic>** is there a blurb/call-to-actionabout the request to review which i can pass to my relevant mailing lists?
|
||||
**\<hyc>** moneromooo: waiting till sept means we can settle on the fees without rushing
|
||||
**\<sarang>** hyc: fluffypony indicated we could make funds available for the review, but you'll have to ask him for the details
|
||||
**\<moneromooo>** It's not a lot of work, since it exists now.
|
||||
**\<ArticMine>** We are only delaying single output not multi output
|
||||
**\<moneromooo>** Multi output bulletproofs are in C++, but not plugged into the consensus, which is the annoying part.
|
||||
**\<sarang>** Anyone interested in doing a review and wanting details can contact me at sarang.noether@protonmail.com
|
||||
**\<endogenic>** such as indicating where to look in the code or repo, background docs, review process, submission format, etc?
|
||||
**\<hyc>** endogenic I'll start drafting an email announcenemt
|
||||
**\<sarang>** I'll contact the other paper authors separately
|
||||
**\<sarang>** and will still press on with the audit group to see what their scope is
|
||||
**\<luigi1111w>** there's not much work saved by skipping single output BP
|
||||
**\<moneromooo>** waiting till sept does not change anything for fees, since multi out is september anyway.
|
||||
**\<luigi1111w>** but the review time is too close for my comfort for march
|
||||
**\<luigi1111w>** I think that's the general thought anyway though
|
||||
**\<hyc>** alternatively we could delay the March release into April
|
||||
**\<sarang>** fluffypony was very opposed to that idea hyc
|
||||
**\<hyc>** ok
|
||||
**\<ferretinjapan>** could always push back the march hard fork a month or two like last time for RCT.
|
||||
**\<sarang>** not saying that's the deciding factor though
|
||||
**\<luigi1111w>** rct was pushed forward actually
|
||||
**\<rbrunner>** What's fp's main argument?
|
||||
**\<ferretinjapan>** oops, I c.
|
||||
**\<sarang>** He thought that regular releases were an advantage
|
||||
**\<rehrar>** he says that people are getting used to the hard fork schedule
|
||||
**\<sarang>** due to predictability
|
||||
**\<endogenic>** rbrunner: for?
|
||||
**\<ferretinjapan>** rbrunner, probably his snity ;)
|
||||
**\<ferretinjapan>** \*sanity
|
||||
**\<rbrunner>** Against the 1 month delay
|
||||
**\<luigi1111w>** my own shed says 3 months with fork in June :D
|
||||
**\<endogenic>** bc it c hanges the hard fork periodicity etc
|
||||
**\<endogenic>** guessing
|
||||
**\<rehrar>** I think six months is not super long to wait for bulletproofs. It'd be another thing entirely if we were discussing putting it off for a year or so, but not much is lost by being a bit safe and waiting.
|
||||
**\<gingeropolous>** ^^
|
||||
**\<ferretinjapan>** 6 months is a looong time in crypto
|
||||
**\<luigi1111w>** did someone mention future pruning
|
||||
**\* luigi1111w** runs
|
||||
**\<sarang>** sigh
|
||||
**\<gingeropolous>** future pruning? you mean double blob?
|
||||
**\<endogenic>** ferretinjapan: better than there being no crypto bc we broke it
|
||||
**\* gingeropolous** runs
|
||||
**\<sarang>** People also want Lower Fees Now
|
||||
**\<sarang>** (tm)
|
||||
**\<vtnerd>** we all want ponies sarang
|
||||
**\<sarang>** or at least, a vocal minority does
|
||||
**\<dEBRUYNE>** \<rehrar> he says that people are getting used to the hard fork schedule \<= I doubt most of the economically sensitive nodes are aware of our schedule
|
||||
**\<ferretinjapan>** endogenic, touche, but there comes a point wher you gain nothing by waiting.
|
||||
**\<ErCiccione>** I think in this phase keeping the scheduled 6 months shouldn't be a priority. Agree with dEBRUYNE
|
||||
**\<rehrar>** If we were to push back by two months from March to May, would that be a good compromise in people's opinions?
|
||||
**\<luigi1111w>** no, but 3 months from March to June.....
|
||||
**\<sarang>** If we really want additional review, the timeline will need to be flexible to the reviewers
|
||||
**\<gingeropolous>** but not rushed
|
||||
**\<Maxithi>** I'd rather have 3 months than 6.
|
||||
**\<sarang>** academic review can be a frustratingly slow and unpredictable process
|
||||
**\<rehrar>** ok, from March to June then
|
||||
**\<endogenic>** i agree with sarang, we cant dictate when third parties deliver
|
||||
**\<iDunk>** This just looks like a repeat of the last meeting.
|
||||
**\<sarang>** basically
|
||||
**\<luigi1111w>** iDunk :)
|
||||
**\<rehrar>** it basically is :P
|
||||
**\<endogenic>** we also dont have enough info to know how long sufficient reviews would take at this stage
|
||||
**\<endogenic>** so not sure it's a good idea to judge things yet
|
||||
**\<ferretinjapan>** rehrar, I think so, but I think it's important to be realistic, rushing is bad I'll admit (we don't want stressed devs!), but unnecessarily putting it off is also bad
|
||||
**\<dEBRUYNE>** 8 months seems like ample time though
|
||||
**\<rehrar>** hard part of being decentralized with no leader is that consensus on stuff is hard
|
||||
**\<ArticMine>** Why not go ahead with March and if BP is ready then to an early September HF? for BP
|
||||
**\<endogenic>** oh yeah what about the meeting agenda?
|
||||
**\<luigi1111w>** well there's really nothing left for march
|
||||
**\<sarang>** Maybe best to wait to hear about potential reviewer interest
|
||||
**\<sarang>** otherwise this is all moot
|
||||
**\<luigi1111w>** but we can fork anyway to keep schedule
|
||||
**\<sarang>** a totally moo point
|
||||
**\<rehrar>** how long do we wait though, since code freeze is soon?
|
||||
**\<sgp>** Why not plan a hardfork a month after the BP review is ready, whenever that is?
|
||||
**\<endogenic>** mooot\*
|
||||
**\<ArticMine>** Multisig is in March
|
||||
**\<luigi1111w>** not forking
|
||||
**\<rehrar>** Multisig doesn't require a hard fork though
|
||||
**\<dEBRUYNE>** Multisig doesn't require a hard fork though
|
||||
**\<luigi1111w>** but in release yes
|
||||
**\<dEBRUYNE>** lol
|
||||
**\<luigi1111w>** you guys
|
||||
**\<rehrar>** lel dEBRUYNE
|
||||
**\<endogenic>** what the
|
||||
**\<rehrar>** of one mind
|
||||
**\<gingeropolous>** but still could provide bugs to squash
|
||||
**\<endogenic>** just got the heebies
|
||||
**\<dEBRUYNE>** bots rekt
|
||||
**\<pebx>** so we don't need any hard fork in march without bp?
|
||||
**\<ferretinjapan>** sgp, I think thats a solid idea, but "consistency" may be a factor in that.
|
||||
**\<luigi1111w>** pebx part of the idea of scheduled forks is to do them anyway
|
||||
**\<rehrar>** can we go through the rest of the meeting and come back to this topic?
|
||||
**\<sgp>** I think the rewards are so large it's worth considering breaking consistency
|
||||
**\<rehrar>** just so we make sure everything else gets done?
|
||||
**\<rehrar>** then we can discuss till the end of time at the end
|
||||
**\<luigi1111w>** or 1hr, whichever is less
|
||||
**\<endogenic>** rehrar: what are you, some kinda pragmatist?
|
||||
**\<ferretinjapan>** luigi1111w, noone said anything about FIXED schedules ;)
|
||||
**\<gingeropolous>** sgp, indeed, that was the logic begind the earlier than planned ringct fork
|
||||
**\<rehrar>** Some people gotta go or don't want more than an hour
|
||||
**\<luigi1111w>** lol
|
||||
**\<dEBRUYNE>** What else is there to discuss though
|
||||
**\<endogenic>** dEBRUYNE: how about what kind of soda you're going to get for rehrar?
|
||||
**\<iDunk>** Subaddresses and fees for the next fork.
|
||||
**\<rehrar>** *shrug* screw the agenda then. We're not beholden to it right. ;) Just trying to think of people who might want to discuss code or issues.
|
||||
**\<ArticMine>** I do not see a fee change without BP
|
||||
**\<pebx>** i'm not a mathematician, however i would prefer single output bp in march/april/may than waiting for multi output with the even more controversial change in fee structure
|
||||
**\<iDunk>** Even if the value has gone up ~40x since the last adjustment ?
|
||||
**\<endogenic>** rehrar: dont be silly, no one wants to discuss issues… :P
|
||||
**\<rehrar>** troo, ok BP it is
|
||||
**\<sarang>** pebx: the fee change shouldn't be that controversial
|
||||
**\<luigi1111w>** ArticMine smooth had some arguments for reducing fee
|
||||
**\<sarang>** the alternative is DOS
|
||||
**\<rehrar>** How soon should we be looking to come to a decision? This meeting? Next?
|
||||
**\<rbrunner>** What is DOS?
|
||||
**\<Maxithi>** endogenic: rehrar: dont be silly, no one wants to discuss issues… :P \<= I do, please label them so I don't have to make lists and have dEBRUYNE tag 150 of them at once ;)
|
||||
**\<endogenic>** rbrunner: denial of service?
|
||||
**\<rbrunner>** Regarding fees?
|
||||
**\<ArticMine>** WE can lower the min fee but people are not using it anyway
|
||||
**\<endogenic>** i.e. spam?
|
||||
**\<serhack>** hi
|
||||
**\<dEBRUYNE>** For the current range proofs you'd need to tweak the penalty
|
||||
**\<luigi1111w>** not gonna happen
|
||||
**\<luigi1111w>** by march
|
||||
**\<ArticMine>** Spam to the txpool is a risk if we go too low on the min fee
|
||||
**\<dEBRUYNE>** What's not going to happen by march luigi1111w?
|
||||
**\<luigi1111w>** tweaking the pentaly
|
||||
**\<pebx>** @ArticMine most users don't know about a minimum fee...
|
||||
**\<luigi1111w>** penalty
|
||||
**\<pebx>** I see this all day in the Telegram groups "why is the fee so high?"
|
||||
**\<ArticMine>** One option change the wallet default to the min fee
|
||||
**\<dEBRUYNE>** The per kB fee isn't even that high fwiw
|
||||
**\<pebx>** most services also use the default... like mymonero does
|
||||
**\<dEBRUYNE>** The transactions are just obscenely large
|
||||
**\<endogenic>** pebx: dont worry, i'm getting close to adding priority setting to new apps
|
||||
**\<pebx>** dEBURNE isn't that why bp is so important?
|
||||
**\<dEBRUYNE>** Right, but we shouldn't rush it
|
||||
**\<Maxithi>** @ArticMine: One option change the wallet default to the min fee \<= I actually consider that a good idea as no one uses that fee...
|
||||
**\<ErCiccione>** ^^
|
||||
**\<dEBRUYNE>** That's going to result in a clogged mempool if we want to expand
|
||||
**\<luigi1111w>** I use that fee
|
||||
**\<moneromooo>** Then noone would use the current fee once it's no longer the default.
|
||||
**\<iDunk>** So do I.
|
||||
**\<luigi1111w>** well I use both kinda depending
|
||||
**\<jtgrassie>** BP shoudnt be rushed but equally shouldnt be held back to a *schedule*
|
||||
**\<luigi1111w>** dEBRUYNE some of that is unavoidable
|
||||
**\<Maxithi>** Yeah but I mean none of the people here do used it. That's the issue
|
||||
**\<luigi1111w>** two opposing forces at work
|
||||
**\<rbrunner>** It's nice to have a fee level below default to be able to say "I can wait"
|
||||
**\<dEBRUYNE>** luigi1111w: According to smooth miners will just pick the default or higher fees and leave everything else in the mempool
|
||||
**\<dEBRUYNE>** Because they can only use the last transaction for the penalty
|
||||
**\<luigi1111w>** well I'm pretty sure that was originally according to me :)
|
||||
**\<dEBRUYNE>** So you can't have 23 min fee txes and then one default
|
||||
**\<binaryFate>** \<ArticMine> One option change the wallet default to the min fee \<-- +1
|
||||
**\<endogenic>** isn't that a bad idea? \^
|
||||
**\<moneromooo>** It is.
|
||||
**\<luigi1111w>** it's an idea
|
||||
**\<luigi1111w>** I'm not sure if it's bad or good
|
||||
**\<moneromooo>** Unless people don't use monero much for half a year.
|
||||
**\<endogenic>** hm it would be cool to model this
|
||||
**\<Maxithi>** got to go, see you guys
|
||||
**\<endogenic>** but Maxithi you didnt get to chat issues
|
||||
**\<luigi1111w>** sorry I got lunch gotta run too
|
||||
**\* luigi1111w** grumbles about meeting time, again
|
||||
**\<ArticMine>** It is the human herd mentality
|
||||
**\<Maxithi>** endogenic Yeah never mind, just wanted to ask people to label more issues to make it easier to know which one require assistance.
|
||||
**\* Maxithi** agrees with luigi1111w
|
||||
**\<dEBRUYNE>** What if the wallet changes the level dependent on the backlog?
|
||||
**\<endogenic>** Maxithi: maybe you could make an issue about that?
|
||||
**\<dEBRUYNE>** So it'd use min fee if mempool is \< 1000 kB and default if \> 1000 kB?
|
||||
**\<dEBRUYNE>** \^ just using arbitrary numbers
|
||||
**\<rbrunner>** Wouldn't that just result in a lot of angry people, like "Why the hell I paid so much"?
|
||||
**\<rbrunner>** If you don't make it *very* transparent
|
||||
**\<ArticMine>** dEBRUYNE What if the wallet changes the level dependent on the backlog? \<--- That would work
|
||||
**\<dEBRUYNE>** rbrunner: How so?
|
||||
**\<hyc>** endogenic, sarang: email draft https://pastebin.mozilla.org/9075994
|
||||
**\<dEBRUYNE>** You can add a note in the wallet
|
||||
**\<pebx>** isn't that even more confusing for users?
|
||||
**\<dEBRUYNE>** "changing fee level because of backlog"
|
||||
**\<rbrunner>** I am afraid people would not understand the mechanism
|
||||
**\<rbrunner>** compare fees, see that they are different for different people
|
||||
**\<rbrunner>** or different times
|
||||
**\<rbrunner>** and shout "scam" or so ...
|
||||
**\<ArticMine>** It is what Bitcoin does
|
||||
**\<endogenic>** hyc: term "output" used before definition
|
||||
**\<dEBRUYNE>** That seems a bit too far stretched
|
||||
**\<rbrunner>** Well, people now even don't "understand" they can go one level lower for the fee, right?
|
||||
**\<sarang>** hyc: I didn't see any Java code from the authors. I wrote our Java proto code
|
||||
**\<rbrunner>** Many of them, anyway
|
||||
**\<DaveyJones>** rbunner i don't think so ... most people arn't even schooled on default vs 0.25x fee
|
||||
**\<sarang>** hyc: line 5, I'd say "are confident" instead of "are pretty confident"
|
||||
**\<hyc>** sarang: ok
|
||||
**\<endogenic>** hyc: maybe capitalize 'Java' and add a 'Therefore, ' before "The Monero Project"
|
||||
**\<rbrunner>** Yes, how will they understand how that works if it get more complicated?
|
||||
**\<rbrunner>** That's my fear, basically
|
||||
**\<endogenic>** oops
|
||||
**\<endogenic>** "mainnet. The Monero Project"
|
||||
**\<rehrar>** I'm torn tbh. I see both sides.
|
||||
**\<pebx>** @ArticMine what bitcoin does is one of the major reasons, why people are looking into Monero... fees are one thing the average bitcoin user is always confused about
|
||||
**\<DaveyJones>** basically they don't need to understand most of people moaning about tax fee's are people just count the $ value of the fee... not how it was achieved
|
||||
**\<endogenic>** otherwise looks great, tyvm!
|
||||
**\<DaveyJones>** so they basically dont care about the mechanism but the price
|
||||
**\<DaveyJones>** and wasnt the proposed mempool fee sth that should happen automatic? or did i misunderstand that
|
||||
**\<ArticMine>** pebx Bitcoin has fundamental fee problems that have nothing to do with wallet choices.
|
||||
**\<sarang>** hyc: maybe state that we "recognize the value of independent third-party review" to assure other readers that we're doing this as a "belt and suspenders" approach, rather than a legitimate worry about correctness
|
||||
**\<binaryFate>** pebx Bitcoin is a clusterfuck of floating fees and fees competitiong for a fixed block size. Here it's just about choosing the default among the 4 different levels, that's it. Then flex block cap takes care of the rest so you don't have your transaction in mempool for 14 days
|
||||
**\<sarang>** I don't want some silly media report that we don't trust our own code
|
||||
**\<jtgrassie>** IMO default fees should derived from mempool size and be completely transparent to user
|
||||
**\<endogenic>** but sarang mass media never selectively reports
|
||||
**\<sarang>** -\_-
|
||||
**\<endogenic>** that wouldn't be true journalism!
|
||||
**\<ArticMine>** It can be done at he wallet level.
|
||||
**\<binaryFate>** It's just silly that when there is factually no backlog in the mempool, the fee does not default to low
|
||||
**\<rbrunner>** Can the wallet query tx pool size already?
|
||||
**\<endogenic>** binaryFate: simplewallet does warn at least
|
||||
**\<rbrunner>** Technically, is there a call?
|
||||
**\<endogenic>** "n block backlog at that fee"
|
||||
**\<endogenic>** oh, next meeting when? 2 wks?
|
||||
**\<sarang>** endogenic: I want to make it clear that we're taking a careful but confident approach that uses peer review, just as any good academic work does
|
||||
**\<rehrar>** It was suggested earlier that if single output BP's are not merged in March, that the fee should be adjusted. If we are saying that we don't want to adjust the fee in March, I think single output BPs should be merged
|
||||
**\<endogenic>** sarang: i completely agree
|
||||
**\<jtgrassie>** 13:02 **\< endogenic>** oh, next meeting when? 2 wks?
|
||||
**\<rehrar>** Ye, sorry. If anyone needs to leave. Next meeting two weeks.
|
||||
**\<rehrar>** 28th
|
||||
**\<binaryFate>** The warn makes people think "mmm should I use more fees", not the opposite. Who when using normal and seeing 0/1 block backlog cancels, and come back to use low fees? Nobody I guess, should be automatic maybe with just a y/n confirmation
|
||||
**\<sarang>** hyc endogenic: move discussion of BP review to #monero-research-lab after meeting?
|
||||
**\<endogenic>** yes good point
|
||||
**\<endogenic>** binaryFate
|
||||
**\<hyc>** ok
|
||||
**\<endogenic>** though i dont know about automatic, from a ux standpoint, but thats just me
|
||||
**\<rbrunner>** Automatic always takes away some choice, right?
|
||||
**\<endogenic>** not necessarily
|
||||
**\<endogenic>** if the result is displayed clearly so the user can confirm before implicitly agreeing
|
||||
**\<endogenic>** then it can be ok
|
||||
**\<endogenic>** question is
|
||||
**\<endogenic>** how do you do that in a CLI?
|
||||
**\<binaryFate>** What we're discussing is just selecting the default, not forcing the user
|
||||
**\<endogenic>** may end up needing some kind of prompt or to enhance it to update some kind of display in-place
|
||||
**\<endogenic>** yes
|
||||
**\<endogenic>** must be off, myself
|
||||
**\<endogenic>** o/
|
||||
**\<rehrar>** Can we maybe plan an "urgent" meeting sometime this week or next weekend?
|
||||
**\<rehrar>** Just to discuss BP's and make a decision?
|
||||
**\<endogenic>** rehrar i'll attend any meetings
|
||||
**\<rehrar>** Or is that not a good idea.
|
||||
**\<sarang>** rehrar: Do we want to wait on review feedback?
|
||||
**\<rbrunner>** It seems BP might merit that, a special meeting
|
||||
**\<sarang>** To at least see who if anyone will review?
|
||||
**\<endogenic>** sarang: personally i would
|
||||
**\<rehrar>** Sarang, do we have an ETA on that?
|
||||
**\<DaveyJones>** BP + fee talk ?
|
||||
**\<ArticMine>** I am fine with that say next Sunday
|
||||
**\<DaveyJones>** i guess both run a little short today
|
||||
**\<endogenic>** or else i would hold the meeting with the primary objective of resolving how we can solicit and accomplish the review
|
||||
**\<DaveyJones>** and need more thoughts
|
||||
**\<sarang>** rehrar: I have a phone meeting w/ the audit group on Tuesday
|
||||
**\<rehrar>** Perfect.
|
||||
**\<sarang>** I assume hyc can post the Call For Reviews after we finish proofreading it
|
||||
**\<rehrar>** I can make an issue depending on that.
|
||||
**\<sarang>** and I'll contact the other paper authors today
|
||||
**\<rehrar>** I will put a "tentative" next meeting for next Sunday
|
||||
**\<sarang>** roger
|
||||
**\<rbrunner>** Sounds good
|
||||
**\<rehrar>** And if anything changes, I'll change it.
|
||||
**\<sarang>** I'll post any updates on the research IRC as I hear back
|
||||
**\<rehrar>** You can comment on the GitHub issue too plz.
|
||||
**\<sarang>** sure thing
|
||||
**\<rbrunner>** I am sure companies would arrange meetings of whole days for something of the importance of BP
|
||||
**\<rbrunner>** Just saying :)
|
||||
**\<rbrunner>** Just to reach consensus
|
||||
**\<rehrar>** Good idea rbrunner. 4 hour meeting planned. Followed by a small snack break. Then another four hours.
|
||||
**\<rbrunner>** :)
|
||||
**\<ErCiccione>** can we talk about code freeze now? I really need to know the date for both the localization team and the GUI guide that will go in the binaries
|
||||
**\<rehrar>** Harder to discuss now that lots of people are gone unfortunately. :/
|
||||
**\<rehrar>** BPs took most of the time.
|
||||
**\<rbrunner>** With breakthrough still somewheat elusive, if you ask me ...
|
||||
**\<rbrunner>** But maybe that's a good thing.
|
||||
**\<ErCiccione>** rehrar: yep..but that mess things up a bit for me. still around mid February btw, right?
|
||||
**\<rehrar>** rbrunner, shows we're actually decentralized?
|
||||
**\<rehrar>** Dunno erciccione, I think it was supposed to be January, but don't quote me.
|
||||
**\<rbrunner>** rehrar: Yes.
|
||||
**\<sgp>** iirc it's supposed to be 2 months
|
||||
**\<sgp>** Before the hf
|
||||
**\<rbrunner>** Was one of the important points of fp's speech in Zurich that I could attend. Impressed folks, I think
|
||||
**\<ErCiccione>** rerhrar: it was, but last time i asked dEBRUYNE he said more or less around February. i guess i'll just wait to know more
|
||||
**\<binaryFate>** rbrunner what point?
|
||||
**\<sgp>** I think it's a good idea
|
||||
**\<rbrunner>** The good decentralization of Monero
|
||||
**\<binaryFate>** ErCiccione as long as hard fork date still somewhat open and discussed, I think it's fair to assume code freeze will not happen soon. That's probably the most you can get now.
|
||||
**\<sgp>** I think some localization stuff is low-risk though and could be merged a bit later as long as the binaries can be built with sufficient time. Not my deceion though
|
||||
**\<Billy>** I do think we need to resolve the BP issue ASAP. It needs a special meeting because these general meetings aren't going to do it.
|
||||
**\<rbrunner>** You could say that after two regular meetings, yes
|
||||
**\<rbrunner>** 1 hour is damn short, even if we don't have to emulate endless corporate meetings
|
||||
**\<ErCiccione>** ok, thanks binaryfate sgp the problem is that some translator keep asking that because they need to organize their time, but they don't want their work to be left out from the official release
|
|
@ -0,0 +1,243 @@
|
|||
---
|
||||
layout: post
|
||||
title: Logs for the Community Meeting Held on 2018-01-20
|
||||
summary: Community highlights, Forum Funding System updates, RFC-HWALLET-1, Kasisto, open ideas, and miscellaneous
|
||||
tags: [community, crypto]
|
||||
author: dEBRUYNE / fluffypony
|
||||
---
|
||||
|
||||
# Logs
|
||||
|
||||
**\<rehrar>** For newcomers, or those who don't know. The community meeting is a place where individuals or groups interested in making the Monero community a better, more helpful, more welcoming, and fun place can congregate and throw ideas around.
|
||||
**\<rehrar>** We've already sort of gone through 1. Greetings, but if there is anyone else out there in the peanut gallery that wants to say 'hi' and show your presence, by all means do so.
|
||||
**\<keledoro>** Heya!
|
||||
**\* ErCiccione** here but sick and getting worse, not going to be very communicative :(
|
||||
**\<rehrar>** you probably caught it from anonimal :/
|
||||
**\<vdo>** hi
|
||||
**\<suraeNoether>** howdy y'all
|
||||
**\<rehrar>** 2. Community highlights
|
||||
**\<vdo>** on mobile but here
|
||||
**\<rehrar>** You can see the Monero Observer for a good breakdown of what's happened in the past two bits of time since we've had our last meeting.
|
||||
**\<ErCiccione>** rehrar: lol. yeah, that germ spreader
|
||||
**\<rehrar>** But is there anything anyone wants to highlight in particular about the past couple weeks in regards to cool stuff our community (not necessarily just this workgroup) has done?
|
||||
**\<msvb-mob>** The Monero Observer is where? It sounds like revuo but is not.
|
||||
**\<rehrar>** http://monero-observer.com/
|
||||
**\<rehrar>** Observer is here, and covers more the day to day of Monero
|
||||
**\<serhack>** We are going to reach 100k subreddit users :O
|
||||
**\<cryptochangements>** the new Cake Wallet is out, and the dev intends to release source so that's exciting
|
||||
**\<rehrar>** The Revuo is coming! Promise. Just had to push back a bit since anonimal has been sick, but we're working on the Kovri part (the last part) this weekend hopefully.
|
||||
**\<rehrar>** Yes, I invited the Cake Wallet guys to the community meeting here when I chatted with him yesterday
|
||||
**\<rehrar>** hopefully he'll show :) He got on the mattermost
|
||||
**\<suraeNoether>** the community sent me to attend the conference RealWorldCrypto in Zurich, where I met up with Fluffypony, andytoshi, Peter Wuille (spelling?)
|
||||
**\<suraeNoether>** and is sending me and sarang to BPASE18 next week, too
|
||||
**\<onetwo22>** http://monero-observer.com/Monero%20Observer%20-%20Vol%2001%20No%2020.html
|
||||
**\<rehrar>** brief four sentences on your time in Zurich suraeNoether?
|
||||
**\<suraeNoether>** which is a really fantastic thing our community has done
|
||||
**\<monerodesigns>** oh, I'm featured in the Monero Observer :) nice. didn't even know this exists. cool project
|
||||
**\<rehrar>** oyoy, alright, we'll move on then :)
|
||||
**\<suraeNoether>** I attended Andrew Poelstra's talk (andytoshi) on MimbleWimble and scriptless scripts, which was the first talk of the conference that had any serious math in it, terrifying the venture capitalists. Fluffypony and I met up with several of the team members at Digital BitBox, a hardware wallet company that is doing some truly fantastic work, as well as the Operations Manager from Globee. The week was
|
||||
**\<suraeNoether>** productive, as andytoshi and I were able to discuss in person at least one idea I had for a rather crude refund transaction mechanism that could work in Monero. It was an honor to meet so many members of the cryptocurrency community, and it was fantastic to make new friends!
|
||||
**\<rehrar>** \^ thank you so much suraeNoether
|
||||
**\* suraeNoether** thumbs up
|
||||
**\<dEBRUYNE>** suraeNoether: BitBox is a hw wallet right? Did they have any intention to add Monero?
|
||||
**\<msvb-mob>** Shift Devices is now local to Zurich.
|
||||
**\<serhack>** cool suraeNoether!
|
||||
**\<suraeNoether>** dEBRUYNE: yes, monero stickers everywhere~
|
||||
**\<emesik>** transaction refund? sounds interesting
|
||||
**\<rehrar>** 3. FFS updates
|
||||
**\<msvb-mob>** dEBRUYNE: They want to add Monero and have no plans to add Monero (at the same time.)
|
||||
**\<rehrar>** Start with hardware wallet? msvb-mob, you wanna give us a thing or two?
|
||||
**\<msvb-mob>** Okay.
|
||||
**\<suraeNoether>** msvb-mob +1 yep exactly
|
||||
**\<msvb-mob>** We've made considerable progress in Firmware.
|
||||
**\<msvb-mob>** And USB logic, including obtaining Product IDs (provisionary.)
|
||||
**\<msvb-mob>** Work is ongoing to test a more anonymous distribution system (poste restante.)
|
||||
**\<monerodesigns>** nice
|
||||
**\<msvb-mob>** And another edition of BTC Manager is coming out reporting on us.
|
||||
**\<msvb-mob>** Bunch of stuff I found in China, like visiting a factory.
|
||||
**\<msvb-mob>** And we're planning a third hardware team meeting this week:
|
||||
**\<msvb-mob>** ...wait for it.
|
||||
**\<msvb-mob>** https://doodle.com/poll/c8hg5gs8kuvt92dp
|
||||
**\<msvb-mob>** rehrar: Thanks.
|
||||
**\<msvb-mob>** Any questions?
|
||||
**\<rehrar>** will we pull this off? or are we just a bunch of kids trying to play with the big boys?
|
||||
**\<rehrar>** but that may be for another time
|
||||
**\<rehrar>** serhack, my man. You wanted to speak a few words about Mastering Monero?
|
||||
**\<serhack>** oh, I thought about monero integrations too
|
||||
**\<rehrar>** do both
|
||||
**\<serhack>** Anyway for monero integrations, I am still working with cryptochangements for opencart gateway payment
|
||||
**\<rehrar>** you and cryptochangements
|
||||
**\<cryptochangements>** idk if there is much to say yey, but sure ;)
|
||||
**\<cryptochangements>** \*yet
|
||||
**\<serhack>** okay, let's talk about mastering monero now
|
||||
**\<cryptochangements>** sounds good
|
||||
**\<serhack>** I asked for FFS about Mastering Monero https://forum.getmonero.org/6/ideas/89797/mastering-monero-ffs
|
||||
**\<serhack>** At the moment, I have two chapters finished and the third is almost finished (exactly 47 pages)
|
||||
**\<serhack>** if you wanna tl;dr : Mastering Monero will be a book about the Monero world
|
||||
**\<serhack>** from Kovri to RingCT, mastering monero will have the answer for your questions about Monero!
|
||||
**\<serhack>** https://masteringmonero.com
|
||||
**\<serhack>** any questions?
|
||||
**\<rehrar>** You looking for illustrators?
|
||||
**\<rehrar>** for both infographics as well as general Monero illustrations?
|
||||
**\<serhack>** At the moment, I have baltsar as designer
|
||||
**\<zbert>** How many chapters are planned for now?
|
||||
**\<rehrar>** ok
|
||||
**\<msvb-mob>** Great choice, Baltsar makes super graphics. And nice to see a EPUB edition from the start.
|
||||
**\<serhack>** At the moment I planned about 7-8 chapters https://taiga.getmonero.org/project/serhack-mastering-monero/wiki/summary
|
||||
**\<serhack>** thanks msvb-mob
|
||||
**\<zbert>** serhack: thanks
|
||||
**\<serhack>** yw
|
||||
**\<monerodesigns>** who is the target audience?
|
||||
**\<monerodesigns>** everyman? or a crypto geek?
|
||||
**\<emesik>** from the summary it looks like addressing a broad audience
|
||||
**\<serhack>** expect the audience to be a mix of new, non-technical users and people who are more familiar with Monero and more technically advanced.
|
||||
**\<serhack>** I \*
|
||||
**\<rehrar>** alright, further questions can be fielded to serhack after the meeting, we've got more updates people
|
||||
**\<serhack>** emesik: sure!
|
||||
**\<monerodesigns>** a difficult target audience. great work so far!
|
||||
**\<serhack>** thanks a lot! :) send me a pm for questions
|
||||
**\<rehrar>** Now, it's time for: the man! the legend! amiuhle!!! *woooo* So tell us about Kasisto?
|
||||
**\<serhack>** go rehrar
|
||||
**\<amiuhle>** lol
|
||||
**\<amiuhle>** Kasisto in 22 seconds: https://imgur.com/a/aLFB3
|
||||
**\<serhack>** amiuhle the king whoaa!
|
||||
**\<amiuhle>** I'm done with Milestonen 1 / Alpha 2. Just wrapping things up with better documentation / overview in the README and technical details on how to set up the server
|
||||
**\<keledoro>** Awesome!
|
||||
**\<cryptochangements>** oh I havent yet got a chance to test out kasisto but that looks dope
|
||||
**\<serhack>** very good amiuhle! it's a perfect point of sale system
|
||||
**\<amiuhle>** I'll put that in the README. Maybe I'll do it again because it's a bit blurry
|
||||
**\<sarang>** That kasisto is faaaast
|
||||
**\<amiuhle>** Well to be fair, it's the same remote node
|
||||
**\<amiuhle>** So if it has to propagate through the network first it might be a bit slower
|
||||
**\<amiuhle>** Is anyone running a public v6 testnet node?
|
||||
**\<amiuhle>** binaryFate maybe?
|
||||
**\<emesik>** If there's a need for such node, I could set up one
|
||||
**\<amiuhle>** And Kasisto was tested at the last Berlin meetup and as I understand it's a permanent payment method there now
|
||||
**\<cryptochangements>** thats pretty awesome
|
||||
**\<amiuhle>** I think it'd be good to have a few of those, yes
|
||||
**\<vdo>** i'm running one and I'm organizing Barcelona meetup next wed
|
||||
**\<serhack>** For the new users, here it's kasisto : https://github.com/amiuhle/kasisto
|
||||
**\<vdo>** but the owner wants to use mobile wallet monerujo for now
|
||||
**\<rehrar>** dude, this is one of the things I am the most excited about.
|
||||
**\<phx[m]>** Yea very cool
|
||||
**\<amiuhle>** vdo: Have a testnet wallet ready so you can show the owner while you're there..
|
||||
**\<vdo>** yeah ok
|
||||
**\<amiuhle>** cool
|
||||
**\<vdo>** i need to explain view only wallets and such
|
||||
**\<rehrar>** alright, thanks so much!
|
||||
**\<rehrar>** Alright guys, let's sit back and relax. Take a breather. Put your thinking caps on.
|
||||
**\<amiuhle>** I'm hoping to wrap it all up and push the latest changes today / tomorrow and then I'll update the FFS post
|
||||
**\<rehrar>** Because it's time for 4. TBA
|
||||
**\<emesik>** wait
|
||||
**\<rehrar>** And we need to think what sgp wanted to put there
|
||||
**\<rehrar>** :P
|
||||
**\<rehrar>** what's up emesik?
|
||||
**\<emesik>** an update on python module FFS
|
||||
**\<serhack>** TBA ? The big algorithm? LoL
|
||||
**\<emesik>** so, basically the code for first release is almost ready
|
||||
**\<rehrar>** oh perfect. I'm so sorry. Go for it.
|
||||
**\<emesik>** I'm writing the docs, both API and tutorial
|
||||
**\<emesik>** I think the first release will be available in early february
|
||||
**\<rehrar>** awesome!
|
||||
**\<emesik>** it will already allow to read wallet data, retrieve list of transactions (in and out), and of course send them
|
||||
**\<emesik>** for sending I already have two ways, simple transfer by the wallet
|
||||
**\<emesik>** or retrieving a blob to be posted to daemon directly
|
||||
**\<emesik>** I'd be happy to add payment proofs to the first release
|
||||
**\<emesik>** but will see if time allows for that
|
||||
**\<emesik>** anyway, the development won't stop with the FFS milestone completed
|
||||
**\<emesik>** there's a lot of things to do further on
|
||||
**\<emesik>** multisig for example, or libwallet
|
||||
**\<emesik>** the code is here: https://github.com/emesik/monero-python
|
||||
**\<amiuhle>** Good to see a tests folder there :+1:
|
||||
**\<emesik>** and good news, the module is going to be ahead of Monero itself, already handling accounts and subaddresses
|
||||
**\<emesik>** any questions?
|
||||
**\<rehrar>** this conglomerate of passionate individuals is honestly the most inspiring thing. It may even inspire me to get involved and do something.
|
||||
**\<rehrar>** thank you emesik for the update!
|
||||
**\<rehrar>** Just a fun FFS to look at. If you liked the Monero Cat comics, the guy who made them opened a FFS proposal to make more (bigger): https://forum.getmonero.org/6/ideas/89764/i-d-like-to-develop-a-new-webcomic-series-starring-monerocat-and-the-justice-league-of-crypto
|
||||
**\<rehrar>** feel free to read it through and comment on it
|
||||
**\<rehrar>** Alright, we can move into 5. Open ideas time
|
||||
**\<rehrar>** This is a time where we as a community workgroup put our heads together and throw ideas out there about how to improve Monero, the community, and more.
|
||||
**\<rehrar>** So, have at it. Any ideas or things you want to say?
|
||||
**\<monerodesigns>** ok, i don't know if this is the best time, I just wanted to say hi... I'm the guy behind the Monero Designs wallpapers and those pizzaboy images...
|
||||
**\<monerodesigns>** and I just wanted to say thanks to everyone for the cool feedback and everything
|
||||
**\<serhack>** Hi monerodesigns and welcome to Monero community!
|
||||
**\<monerodesigns>** I have a couple of new ideas in the works... if there's ever anyone that wants to reach out or anything, I'm very excited about monero... been following the project since january last year
|
||||
**\<serhack>** I would like to mark a little thing: Mastering Monero is basically a Monero Marketing Campaign by a book
|
||||
**\<serhack>** so if you have any ideas about marketing, please let us know!
|
||||
**\<emesik>** #dontbuymonero stickers on your local ATM ;)
|
||||
**\<monerodesigns>** anyway, just wanted to say that what made me start doing this was a reddit post a couple of months ago about how there aren't any posters like there are for bitcoin
|
||||
**\<monerodesigns>** that's it, rant over :)
|
||||
**\<emesik>** monerodesigns: coul you paste a link to your works, please?
|
||||
**\<monerodesigns>** i think what the community is doing now is the best thing it can be doing... just making others aware of this awesome project, without any hype or anything
|
||||
**\<cryptochangements>** gingeropolous made this reddit post https://www.reddit.com/r/Monero/comments/7rn6el/moneroworld_remote_nodes_geo_lists/?utm_source=reddit-android about moneroworld remote nodes. in there he mentions funding powerful servers for nodes. It looks like the general donation fund on moneroworld.com is where we can direct donations for anybody thay wants to.
|
||||
**\<monerodesigns>** monerodesigns.com (the website is a mess... this is just something I'm doing on the side... lol)
|
||||
**\<emesik>** monerodesigns: thx!
|
||||
**\<emesik>** I like them!
|
||||
**\<monerodesigns>** i liked that whole "run your own node." campaign by the bitcoin community. i think that's a good thing... it was what made me start a monero node a couple of months ago
|
||||
**\<monerodesigns>** (ironically, it was the bitcoin posters that made me start my monero node lol)
|
||||
**\<rehrar>** I'm thinking of holding another mini-privacy conference over youtube like I did before. I think most everyone missed it because it the circumstances around it were...different. :P
|
||||
**\<monerodesigns>** @michalthanks!
|
||||
**\<cryptochangements>** more personal nodes totally helps oit the network, but unfortunatly remote nodes that new users use is kinda centralized at the moment
|
||||
**\<monerodesigns>** where are they located?
|
||||
**\<rehrar>** I just pop online and talk about privacy and get to do my infamous 'rehrar rants' without any interruption. Most people don't know how hard real privacy is in this day and age, and they think it's as easy as using one or two tools or doing one or two things
|
||||
**\<monerodesigns>** or are there just not enough?
|
||||
**\<cryptochangements>** rehrar i missed that! you got a link?
|
||||
**\<miziel>** there will be a need for some poster/sticker campaign after the new slogan will be "forged"
|
||||
**\<keledoro>** I'd watch it @rehrar. Make sure to announce it a couple of days before you're going to livestream it
|
||||
**\<monerodesigns>** I run my node on my miner, and it barely takes away any hashrate... i think if lots of miners ran their nodes...
|
||||
**\<rehrar>** link to last one: https://www.youtube.com/watch?v=GRZzyvN_gS0
|
||||
**\<emesik>** monerodesigns: Opposite here. I had to buy a bigger VPS to accommodate the blockchain. As result I got 3 spare cores that are hashing right now :)
|
||||
**\<phx[m]>** monerodesigns: good to see some memes. People tend to underestimate their power
|
||||
**\<vdo>** scaleway.com is working quite well for me
|
||||
**\<rehrar>** alright, if there's not that much more to discuss, then maybe we can call it early, unless someone wants to share an idea
|
||||
**\<vdo>** at a reasonable price for ssd
|
||||
**\<keledoro>** With the latest increase in merchants adoption, how about we setup a new fancy, "browsable" directory instead of listing all merchants on one page (getmonero.org/community/merchants)? Making it possible to browse by product category, type of service etc. Also making it easier to add new merchants, because right now you need a github acc. in order to add a new one
|
||||
**\<keledoro>** What do you guys think?
|
||||
**\<rehrar>** moneromerchants.com?
|
||||
**\<serhack>** why not updating css style on https://forum.getmonero.org/ rehrar?
|
||||
**\<vdo>** there's one list at monero.how
|
||||
**\<rehrar>** it's supposed to be replaced serhack with getmonero.org/forum-funding-system
|
||||
**\<keledoro>** just had to check if moneromerchants.com is a thing :D
|
||||
**\<rehrar>** waiting on fp for a couple things for this to move forward, and I can't move forward without it
|
||||
**\<rehrar>** someone can buy moneromerchants.com if it's not taken already
|
||||
**\<rehrar>** and the community can throw together something like that. I'd be willing to help contribute as a web dev
|
||||
**\<serhack>** moneromerchants.com is taken :/
|
||||
**\<monerodesigns>** yeah, thanks... I have a couple of ideas in the works at the moment... It's just hard to get some of the nuance of fungibility across in a short meme-like format
|
||||
**\<cryptochangements>** i think that's a good idea to clean it up, but I think it should still be done by github PRs if youre gonna use getmonero otherwise it will just get filled with spam
|
||||
**\<amiuhle>** Does anyone know who runs dis.gratis? I'd like to have a clone for the v6 testnet
|
||||
**\<rehrar>** monerodirectory.com?
|
||||
**\<emesik>** amiuhle: how actually can we choose the testnet version right now?
|
||||
**\<emesik>** if I understand, there are 2 forks
|
||||
**\<amiuhle>** Depends on the binary you're running
|
||||
**\<emesik>** always latest master
|
||||
**\<keledoro>** Would be available
|
||||
**\<amiuhle>** Release binaries with --testnet is the v6 fork, master build is v7
|
||||
**\<emesik>** ok!
|
||||
**\<keledoro>** Well, anyway I just wanted to start a conversation about having a more organized merchants directory
|
||||
**\<keledoro>** Maybe it's a bit too early, since it all still fits on one page
|
||||
**\<amiuhle>** I like the idea, could come with a map for POS
|
||||
**\<monerodesigns>** @keledoro I think it's a good idea
|
||||
**\<emesik>** keledoro: Merchants are precious now, we should take care to promote them
|
||||
**\<monerodesigns>** @michal I agree!
|
||||
**\<vdo>** is something like xmr.to with LN support planned?
|
||||
**\<emesik>** btw, do you think we should mention darknet markets accepting monero on the official project pages?
|
||||
**\<rehrar>** no
|
||||
**\<amiuhle>** no
|
||||
**\<monerodesigns>** no :)
|
||||
**\<emesik>** ok :D
|
||||
**\<rehrar>** alright everyone, I think we'll call it
|
||||
**\<rehrar>** so, next meeting date/time
|
||||
**\<rehrar>** two weeks from now
|
||||
**\<rehrar>** the third of Febz
|
||||
**\<rehrar>** Thanks for coming by the meeting. It's good to hear all the progress that's being made.
|
||||
**\<monerodesigns>** same time yeah?
|
||||
**\<rehrar>** Ye.
|
||||
**\<keledoro>** See you around!
|
||||
**\<rehrar>** Meeting over. Have good lives.
|
||||
**\<monerodesigns>** (i wont be able to attend, but see around at the next one)
|
||||
**\<emesik>** see you!
|
||||
**\<amiuhle>** See you guys!
|
||||
**\<monerodesigns>** see ya
|
||||
**\<cryptochangements>** see y'all
|
||||
**\<serhack>** Bye
|
||||
**\<vdo>** bye
|
|
@ -0,0 +1,698 @@
|
|||
---
|
||||
layout: post
|
||||
title: Logs for the Bulletproofs Meeting Held on 2018-01-21
|
||||
summary: Bulletproofs, fees, hardforks, and miscellaneous
|
||||
tags: [community, crypto, research]
|
||||
author: dEBRUYNE / fluffypony
|
||||
---
|
||||
|
||||
# Logs
|
||||
|
||||
**\<rehrar>** heyo everyone! Meeting time.
|
||||
**\<rehrar>** https://github.com/monero-project/meta/issues/161
|
||||
**\<rbrunner>** Hi, was already afraid nobody around or wrong time :)
|
||||
**\<rehrar>** this meeting is all about Bulletproofs, and discussing when/how, audit stuff, finance stuff, and more
|
||||
**\<rehrar>** fluffypony smooth ArticMine luigi1111 luigi1111w hyc (said he can't be here though) moneromooo gingeropolous endogenic anonimal
|
||||
**\<rehrar>** binaryFate sarang suraeNoether stoffu
|
||||
**\<sarang>** this channel?
|
||||
**\<rehrar>** and feel free to ping anyone else
|
||||
**\<rehrar>** oh, we doing it in MRL? We can if that's what we want.
|
||||
**\<sarang>** Either. I couldn't recall which
|
||||
**\<sarang>** Your pick
|
||||
**\<rehrar>** The Github issue says #monero-dev
|
||||
**\<sarang>** k
|
||||
**\<rehrar>** and more people can see in Slack and Mattermost since MRL is not relayed
|
||||
**\<sarang>** roger
|
||||
**\<rehrar>** so first order of business, as always, is 1. Greetings.
|
||||
**\<rehrar>** If you're here, say hi. :)
|
||||
**\<sarang>** yo
|
||||
**\<rbrunner>** Hi
|
||||
**\<sgp>** Hi
|
||||
**\<dsc>** Hi
|
||||
**\<pigeons1[m]>** Hi
|
||||
**\<geozdr>** hi
|
||||
**\<rehrar>** well, that's a decent group so far. Perhaps a few others will join as time passes.
|
||||
**\<rehrar>** dEBRUYNE, Jaquee, vtnerd
|
||||
**\<dEBRUYNE>** I am here
|
||||
**\<rehrar>** In the meantime, let's begin discussion.
|
||||
**\<rehrar>** Does MRL have an update for us regarding audit outreach?
|
||||
**\<sarang>** Yes
|
||||
**\<suraeNoether>** howdy
|
||||
**\<sarang>** So
|
||||
**\<rehrar>** and I know hyc isn't here atm, but does someone know about how the mailing list outreach went also?
|
||||
**\<rehrar>** (sorry, go ahead sarang)
|
||||
**\<sarang>** There are three groups to whom we are reaching out
|
||||
**\<sarang>** One is professional auditing/security roups
|
||||
**\<sarang>** \*groups
|
||||
**\<sarang>** Second is targeted individuals who know the material
|
||||
**\<sarang>** Third is volunteers without necessarily any particular credentials, but who want to help the project
|
||||
**\<sarang>** All are valuable
|
||||
**\<Maxithi>** Perhaps a few others will join as time passes. \<= Joined
|
||||
**\<sarang>** Let's start with targeted individuals
|
||||
**\<sarang>** Benedikt Buenz is an author on the original paper. He may be available after Feb 20 and has shown interest but not a commitment yet
|
||||
**\<sarang>** Jonathan Bootle is another author. He is unavailable but will pass on word to his colleagues
|
||||
**\<sarang>** I reached out to Greg Maxwell who's newly independent, and haven't heard back
|
||||
**\<sarang>** It was assumed that we would offer compensation to these individuals for their time, with no details on amount
|
||||
**\<sarang>** Next up is volunteers
|
||||
**\<sarang>** I've heard from ~5 people who'd like to help out
|
||||
**\<sarang>** I'm setting them loose with as much information as I can
|
||||
**\<sarang>** This would be on a volunteer basis, but we'd credit them publicly for their help
|
||||
**\<sarang>** Finally is the pro groups
|
||||
**\<sarang>** fluffypony put me in touch with one group that has given me a quote of $40K
|
||||
**\<sarang>** Downsides: it'd be for internal-only reports, but obviously any changes would become public right away
|
||||
**\<sarang>** We also couldn't credit them by name
|
||||
**\<sarang>** I'm having them check with their attorneys on exactly what we could share
|
||||
**\<sarang>** OSTIF works with a lot of different groups, and has been in contact with several, quotes pending
|
||||
**\<sarang>** OSTIF's policy is only to work with groups that allow public disclosure
|
||||
**\<sarang>** They are also willing to accept XMR (which they transfer to the groups in their currency of choice) and has agreed not to take a cut
|
||||
**\<sarang>** Any questions from the group on this wall of info?
|
||||
**\<suraeNoether>** were we also not contacted in a cold-call situation?
|
||||
**\<sarang>** Yes, one pro group did a cold-call. Turns out OSTIF was in contact with them too, so I'm lumping them in with OSTIF
|
||||
**\<sarang>** That cold-call group's rough estimate was $25-35K
|
||||
**\<suraeNoether>** oh ok
|
||||
**\<rbrunner>** Is that USD 40K in the right ballpark for work like that, from a "pro group"?
|
||||
**\<sarang>** So I had expected less, but only because of the limited scope of the BP code; it's relatively small and self-contained
|
||||
**\<sarang>** But the quotes are reasonably consistent with each other
|
||||
**\<suraeNoether>** rbrunner: it's in line with similar quotes obtained back when we pushed ringct, which was around 50k iirc. so somewhere between 40 and 50k is sort of what i expected, personally... the 25-35k was a little bit of a surprise
|
||||
**\<sarang>** and assumes $1-2K per person-day
|
||||
**\<rbrunner>** Ok
|
||||
**\<sarang>** The timeline would be between 10-25 work days once it starts
|
||||
**\<sarang>** Again, OSTIF is still waiting on additional quotes and will report to me when they have them
|
||||
**\<rehrar>** So there is at least some interest being generated.
|
||||
**\<sarang>** So for now, assume that we definitely have options for pro audits in the range of $25-40K
|
||||
**\<sarang>** I also love the idea of getting Buenz or Maxwell to audit individually
|
||||
**\<sarang>** but there are no commitments from them, and may not be. They have a lot going on
|
||||
**\<sarang>** But
|
||||
**\<sarang>** We need to know how to fund this shiz
|
||||
**\<rehrar>** alright, and this doesn't include hyc's outreach stuff too, correct?
|
||||
**\<suraeNoether>** i believe that's the case rehrar.
|
||||
**\<Maxithi>** How did BP get funded?
|
||||
**\<sarang>** hyc's outreach to the list has generated a few contacts within the groups I mentioned
|
||||
**\<Maxithi>** \*RCT
|
||||
**\<rehrar>** ok, great
|
||||
**\<suraeNoether>** Maxithi: I believe we chose to not do the audit back then
|
||||
**\<sarang>** The RingCT audit didn't happen, IIUC
|
||||
**\<rehrar>** maybe MRL can do RingCT audit? :P What would you guys quote us?
|
||||
**\<rbrunner>** That about RingCT is ... surprising
|
||||
**\<suraeNoether>** rbrunner the math was a lot more straightforward for original RingCT
|
||||
**\<rehrar>** Wasn't that one of the reasons for bad blood with Shen?
|
||||
**\<rehrar>** anyways, off-topic.
|
||||
**\<sarang>** It was suggested that perhaps some general funding might be available, but otherwise an FFS
|
||||
**\<suraeNoether>** i think it would be nice to get buenz, but since he's on the late-feb timeline, that conflicts with our hard fork
|
||||
**\<rehrar>** I think we should try to raise the full amount with FFS, and anything that is not covered in reasonable time can be covered with the General Fund
|
||||
**\<sarang>** We'd be cutting it close to March with any group
|
||||
**\<sarang>** And there's no guarantee of an immediate start
|
||||
**\<rehrar>** suraeNoether it only conflicts if we try to roll out BP in March, no?
|
||||
**\<suraeNoether>** rehrar yes
|
||||
**\<rehrar>** I think this info gives strong pushes to rolling out in September
|
||||
**\<sarang>** Also, in terms of scope I've asked them to only review the multi-BP code
|
||||
**\<rehrar>** Because we also need the time to raise the requested funds
|
||||
**\<dEBRUYNE>** \<rehrar> Wasn't that one of the reasons for bad blood with Shen? \<= No.
|
||||
**\<suraeNoether>** IMO, if we can't reasonably expect an audit to be completed before the march hard fork
|
||||
**\<rehrar>** \<dEBRUYNE> \<rehrar> Wasn't that one of the reasons for bad blood with Shen? \<= No. \<= K. Thanks.
|
||||
**\<dEBRUYNE>** We should just put the "include it in the March HF" out of our heads tbh
|
||||
**\<suraeNoether>** dEBRUYNE: +1
|
||||
**\<rehrar>** agreed
|
||||
**\<suraeNoether>** in that case, I think we should just go with Buenz and Maxwell
|
||||
**\<suraeNoether>** and/or
|
||||
**\<sgp>** Unless there is a strong reason to hardfork in March, why not delay it until whenever the review is ready?
|
||||
**\<suraeNoether>** continue to try to talk to them
|
||||
**\<suraeNoether>** sgp: because delaying hard forks sets a very disagreeable precedent
|
||||
**\<sarang>** Keep in mind there's no guarantee that Buenz and Maxwell are even going to be available to do it
|
||||
**\<sarang>** We'll have professional options available for sure
|
||||
**\<suraeNoether>** sarang: ok, if they turn us down then we go with one of the other options: what you are saying is that no one has committed, so that statement is not really helpful for any of our optiosn rihgt now. :P
|
||||
**\<sarang>** Heck, I have a contract from the non-public group already
|
||||
**\<rbrunner>** You mean ready to sign?
|
||||
**\<dEBRUYNE>** \<suraeNoether> sarang: ok, if they turn us down then we go with one of the other options: \<= Imo should just take on multiple options
|
||||
**\<rehrar>** non-public group doesn't sound quite so useful tbh. But maybe I just don't understand how these things work. But they're like: "We can't share hardly anything publicly." So what's the point?
|
||||
**\<dEBRUYNE>** re: funding, the general dev fund could kickstart it and then the community could fund the remainder
|
||||
**\<sgp>** @surae RingCT warranted moving the fork. I'd hate to have the review done in May but have to wait until September to include this important code
|
||||
**\<sarang>** rbrunner: they're ready to sign if/when we are, but we're under no obligation with them
|
||||
**\<suraeNoether>** dEBRUYNE: i'm fine with that too, assuming we have infinite funding available
|
||||
**\<dEBRUYNE>** rehrar: they can still disclose vulnerabilities privately
|
||||
**\<dEBRUYNE>** and we can fix them
|
||||
**\<rehrar>** ah, k. Don't know why that didn't cross my mind. :P
|
||||
**\<suraeNoether>** rehrar: we can share whether they have recommended changes, and if they do recommended change, we will end up communicating all of them to the community. they just don't want their company name or the report itself to be made public afaik?
|
||||
**\<sarang>** dEBRUYNE: rehrar: the changes are all public, and we can likely discuss the vulnerabilities
|
||||
**\<sarang>** just not release their review
|
||||
**\<Maxithi>** What I fear with internal report is that the community would be less willing to support it as they haven't any view on how the funds were used.
|
||||
**\<sarang>** And we can't say who did the review. They can do a more public audit but they said it'd be a lot more $ and time
|
||||
**\<dEBRUYNE>** assuming we have infinite funding available \<= not infinite, but if the community can raise 450k $ for globee, I am sure we can raise a few hunderd k $ for this too
|
||||
**\<sarang>** Again, I'm working with them and their lawyers to get as much public as possible
|
||||
**\<rehrar>** And it gives 'poking power' to naysayers of Monero who say that we don't release the name of people who did the audit. It could have been Joe Schmoe
|
||||
**\<rbrunner>** Why do they work so secretly? In a few words ...?
|
||||
**\<sarang>** Fortunately all of the OSTIF quotes will be for fully public audits
|
||||
**\<sarang>** rbrunner: it's not working in secret
|
||||
**\<sarang>** It's not wanting to be seen as an endorsement
|
||||
**\<sarang>** They do either internal audits (like this one), or much more comprehensive public-facing ones
|
||||
**\<pigeons1[m]>** Do they not want to be blamed for what they miss?
|
||||
**\<sgp>** pigeons I'm sure that's part of it
|
||||
**\<rehrar>** I see the not wanting to be viewed as an endorsement unless they are adequately compensated for that
|
||||
**\<sarang>** Fortunately they won't be the only option, just the first to prepare a quote and contract
|
||||
**\<suraeNoether>** sgp: moving HF dates is not on the table, in my mind. 6 months of data on the blockchain is marginal in the long run; delaying HFs sets an unfortunate precedent.
|
||||
**\<sarang>** I think the community will appreciate the openness of an OSTIF group
|
||||
**\<rehrar>** but because Monero always prides itself in doing most things in the open, I think we should try the other more public options first
|
||||
**\<sarang>** and/or Buenz and/or Maxwell
|
||||
**\<sarang>** rehrar: I agree
|
||||
**\<rbrunner>** Agree also
|
||||
**\<Maxithi>** Agree
|
||||
**\<suraeNoether>** rehrar sarang +1
|
||||
**\<sarang>** We should get a sense of how much we think is reasonable to raise in funds
|
||||
**\<sarang>** since that determines how many groups/peeps we can get
|
||||
**\<rehrar>** well, it should also be said that perhaps we should raise a 'vetting pool' of funds for not just BP, but any future work that needs to be looked at
|
||||
**\<suraeNoether>** rehrar great minds, buddy
|
||||
**\<suraeNoether>** i was just thinking about that
|
||||
**\<rehrar>** could be managed by MRL how they see fit, and reported to the community
|
||||
**\<Maxithi>** That would be great!
|
||||
**\<rehrar>** suraeNoether, in Russia the saying is: "Two fools are of the same mind."
|
||||
**\<sarang>** We have the bounty funds, but those can't be used for reviews
|
||||
**\<sarang>** So this would need to be separate
|
||||
**\<suraeNoether>** rehrar: I don't know about MRL being exclusively in control of vetting funds... i think multisig would be a better option :P
|
||||
**\<sarang>** But any reported flaws could be bountied
|
||||
**\<rehrar>** The stipulations of the pool would be that MRL manages, gets counsel from the Core Team, and reports spending to the community
|
||||
**\<rehrar>** or something along those lines anyways
|
||||
**\<suraeNoether>** right
|
||||
**\<sarang>** I'm sure someone will complain "isn't review what MRL is for????!?!?111!?"
|
||||
**\<rehrar>** I think reported flaws would go through the HackerOne bounty system, and the pool would be for formal review compensation
|
||||
**\<sarang>** But you can't do first-person peer review =p
|
||||
**\<sarang>** rehrar: yes
|
||||
**\<suraeNoether>** sarang +1
|
||||
**\<suraeNoether>** i was wondering what a good snappy response to that should be
|
||||
**\<suraeNoether>** thank you for that. :P it's been on my mind
|
||||
**\<sarang>** I like to think of it as belt and suspenders
|
||||
**\<rehrar>** Raise half a million. Increase as necessary. Sound good?
|
||||
**\<Maxithi>** isn't review what MRL is for????!?!?111!? \<= Nope, the R stands for Research not Review
|
||||
**\<rbrunner>** Somebody always complains :)
|
||||
**\<sarang>** and that I've had spinach caught in my teeth and not noticed for hours
|
||||
**\<geozdr>** maybe not set public targets for raising funds before you get all the quotes? that would hurt our negotiating position.
|
||||
**\<suraeNoether>** geozdr +1 also
|
||||
**\<Maxithi>** Can you have "private funding" on the forum?
|
||||
**\<sarang>** We certainly don't have numbers for paying targeted individuals
|
||||
**\<rehrar>** geozdr, but not all funds will be for BP, so we can internally set a 'BP budget' that is not advertised to potential reviewers
|
||||
**\<suraeNoether>** they'll also have to provide us with a quote sarang imo
|
||||
**\<sarang>** Yes, and I asked Buenz about thi
|
||||
**\<sarang>** \*this
|
||||
**\<sarang>** didn't hear back yet
|
||||
**\<rehrar>** just because we raise a public amount, doesn't mean all of that amount is available for Bulletproof review, and if anyone tries to negotiate based on total amount raised, we push back with that fact, and that BP has a budget
|
||||
**\<rehrar>** *cracks knuckles* and I'll let those tech nerds know that we like our money here, and it will not be easily parted with
|
||||
**\<rehrar>** what about andytoshie, wasn't he approached about review also?
|
||||
**\<rehrar>** \*andytoshi
|
||||
**\<suraeNoether>** sarang do you think that since andytoshi sort of helped with the development, he falls into the "self-peer-review" category
|
||||
**\<suraeNoether>** ?
|
||||
**\<sarang>** andytoshi has provided useful guidance on bulletproofs but I don't believe he's available for a formal audit
|
||||
**\<suraeNoether>** ah, that answers that question
|
||||
**\<sarang>** He's also expressed that he doesn't necessarily want to be seen as endorsing particular projects, but I don't want to put words into his mouth
|
||||
**\<rehrar>** So...since it's pretty much unanimously agreed that BP should not be in March, do you think MRL can put together a formal little news bulletin (I can help), explaining that and why?
|
||||
**\<rehrar>** It'd be helpful to the community, and could help with explaining to some grumblers the benefits and reasons for waiting
|
||||
**\<rbrunner>** Other "heavyweights" are known to be against March?
|
||||
**\<rbrunner>** Not present now
|
||||
**\<rehrar>** luigi and ArticMine both come to mind
|
||||
**\<suraeNoether>** rbrunner: I have a text message from fluffypony describing his position on it, but that's hearsay without a PGP signature. :P
|
||||
**\<rehrar>** I think smooth as well, but don't quote me on that
|
||||
**\<suraeNoether>** so, it seems like there is a weak consensus here that we should start an FFS to fund up a general "new scheme and code" auditing fund. either for MRL to spend as we feel we need to (with as much transparency as possible) or with several core members on board with distribution of those funds also.
|
||||
**\<rbrunner>** Yes, and with a catchy name
|
||||
**\<rehrar>** Yes.
|
||||
**\<sarang>** Setting up a more general fund is also really good optics against the naysayers
|
||||
**\<rbrunner>** as this review stuff is quite dry :)
|
||||
**\<suraeNoether>** if we are going to assume the march HF is out the window, then we can spend another few weeks working out the details on that
|
||||
**\<pebx>** suraeNoether I think we trust you that you don't fake a message from fluffy...
|
||||
**\<sarang>** It shows that we have a plan for BPs, and also for future big changes that need audits
|
||||
**\<rehrar>** Monero Auditing Interest Department So Audits Frequently get Done or MAIDSAFE for short
|
||||
**\<rbrunner>** Monero security fund, or so
|
||||
**\<Maxithi>** MAIDSAFE lol
|
||||
**\<rehrar>** oops, fail on that last letter though
|
||||
**\<suraeNoether>** pebx: heh, well he basically said we shouldn't worry about the optics of pushing it back or about the added blockchain space. in the long run, those things become quite marginal
|
||||
**\<rbrunner>** Did you come up with that right now? Wow
|
||||
**\<sgp>** @rehrar is now a good time to discuss the hard fork schedule? I want to express some dissenting opinion
|
||||
**\<suraeNoether>** fluffypony \^
|
||||
**\<rehrar>** of pushing back March hardfork you mean?
|
||||
**\<rehrar>** oh, of pushing back BPs
|
||||
**\<rehrar>** sgp, speak my child.
|
||||
**\<rehrar>** (So Audits Frequently Execute, there's the E)
|
||||
**\<sgp>** I'm totally fine not including BPs in the March hard fork since it seems a review will not be completed yet. I get that
|
||||
**\<sgp>** If people want to stick with the March harkfork for precedent reasons, I'm fine with that too
|
||||
**\<sgp>** But I really think it's a bad idea to wait until September to add the BP code once it has passed review
|
||||
**\<sarang>** Why?
|
||||
**\<sgp>** There are many practical reasons to have another hardfork
|
||||
**\<sarang>** Blockchain waste?
|
||||
**\<sgp>** Smaller transaction sizes, smaller fees, smaller blockchain
|
||||
**\<rehrar>** Sumokoin will implement, then we're screwed
|
||||
**\<sgp>** Yes, basically
|
||||
**\<sgp>** And I think the precedent argument is pretty weak. Last year, the community agreed upon moving the date of one hardfork and adding another
|
||||
**\<gingeropolous>** y are we screwed?
|
||||
**\<rehrar>** I was joking
|
||||
**\<gingeropolous>** :)
|
||||
**\<rehrar>** thought of another name for the fund btw, but I'll save it for after meeting
|
||||
**\<rbrunner>** rehrar, MAIDSAFE is great
|
||||
**\<medusa>** initially it was planned to use the general dev fund for reviews afaik
|
||||
**\<pebx>** I'm totally with sgp
|
||||
**\<medusa>** if there is no money left we can run an ffs, but that should be checked first in my opinion
|
||||
**\<sgp>** So my vote is to either have another hardfork after the BP review, or to push back the March hardfork if there's no real reason to have a hardfork in March for another feature
|
||||
**\<pebx>** as far as i know there is no other feature which needs a hard fork actually
|
||||
**\<rehrar>** rbrunner, not as good as Ze Cryptography Auditing Software Hoard Foundation
|
||||
**\<rbrunner>** Might not be a bad idea, with so many thing into service waiting
|
||||
**\<sarang>** -\_-
|
||||
**\<sgp>** @pebx exactly, unless there was consensus on a larger ringsize or something
|
||||
**\<rbrunner>** I know, some things do not technically need a hard fork, but a hard fork forces updates, which is nice
|
||||
**\<medusa>** we use hardforks to force ppl to upgrade the software..this has an effect on support work on redit, relegram etc. thats the main reason
|
||||
**\<sgp>** Which I don't think will happen
|
||||
**\<suraeNoether>** "And I think the precedent argument is pretty weak. Last year, the community agreed upon moving the date of one hardfork and adding another" \<-- you just used precedent to demonstrate that precedents don't matter?
|
||||
**\<suraeNoether>** and btw this is exactly the discussion that we wanted to avoid with the HFs... "So my vote is to either have another hardfork after the BP review, or to push back the March hardfork if there's no real reason to have a hardfork in March for another feature" \<--- we hard fork twice a year, how much is enough?
|
||||
**\<pebx>** i can say you as of telegram: people are really expecting BP or at least lower fees... but lowering the fees manually is in my opinion some kind of doctoring around without a real scop
|
||||
**\<sgp>** I'm saying your argument of needing to stick with precedent should be more flexible
|
||||
**\<pebx>** \*scope
|
||||
**\<rbrunner>** Well, the reaction on the Monero subreddit in face of a move into September was surprisingly subdued
|
||||
**\<rehrar>** delaying until September has other benefits not related to the Monero implementation
|
||||
**\<suraeNoether>** sgp and you are using precedents of previous moving HF schedules to show why it's not a big deal to move HFs... but the entire point is *these precedents need to be avoided*
|
||||
**\<rehrar>** it lets the BP paper itself have more time in existence
|
||||
**\<sarang>** And the audits specifically are not testing the BP math/paper
|
||||
**\<rehrar>** and there may be some people interested in reviewing the paper itself (Without carin about the Monero implementation) that would be useful to us
|
||||
**\<sarang>** It's way out of scope for those groups
|
||||
**\<sgp>** Why? If there's a legitimate reason to, what's the harm?
|
||||
**\<suraeNoether>** just the code
|
||||
**\<sarang>** sgp: you mean why are they not reviewing the math?
|
||||
**\<sarang>** Because it's an entirely different kind of review, altogether
|
||||
**\<suraeNoether>** i think sgp means "why not have three HFs this year
|
||||
**\<sgp>** No, not that
|
||||
**\<sarang>** k
|
||||
**\<pebx>** but let's be realistic: probably most interested people start to look into it only 1-2 weeks before it will be implemented anyway
|
||||
**\<sgp>** If we don't add another hardfork, we're committing at least 12 GB of extra blockchain data, assuming transaction volume stays the same
|
||||
**\<rehrar>** that was the argument before pebx, yes
|
||||
**\<pebx>** i would rather prefer to move the hard fork to april or may with BP than hard forking in march just for the case
|
||||
**\<rehrar>** but now there is demonstrated interest in getting the reviews done for financial compensation
|
||||
**\<suraeNoether>** sgp: we have to freeze the code 3+ weeks before each HF and begin implementation. HFing monero to implement BPs is not simple as creating a new email account.
|
||||
**\<suraeNoether>** think of each HF as rolling out a new year/model of car.
|
||||
**\<sgp>** I understand that surae
|
||||
**\<sgp>** But you could easily schedule a hardfork a month after you felt comfortable with the review
|
||||
**\<suraeNoether>** and if that happens to be August
|
||||
**\<suraeNoether>** does that mean we then HF immediately again in September, or also put that one off?
|
||||
**\<suraeNoether>** etc
|
||||
**\<suraeNoether>** etc
|
||||
**\<sarang>** So to move this talk forward... really the question is between (a) doing March and then BP when it's ready, (b) doing no fork until BP is ready, or (c) doing March and waiting on BP until Sept
|
||||
**\<sgp>** Then don't add another one in that case
|
||||
**\<sgp>** But it seems like from your estimate the review should take less than a month
|
||||
**\<pebx>** sarang i'm for b
|
||||
**\* iDunk** likes how MRL is making sense
|
||||
**\<suraeNoether>** sarang no, this is not the question
|
||||
**\<pebx>** i really don't see a need for the march hard fork
|
||||
**\<suraeNoether>** not to mention
|
||||
**\<suraeNoether>** screwing with HF schedules
|
||||
**\<suraeNoether>** completely BLOWS for HW wallet developers
|
||||
**\<iDunk>** Postpones subaddresses
|
||||
**\<suraeNoether>** sarang: we had a weak agreement, even sgp agreed... that the March HF should go forward, and BPs should probably not be included.
|
||||
**\<rehrar>** suraeNoether, you say that the best thing for new cryptography is time
|
||||
**\<medusa>** C is the only option
|
||||
**\<rehrar>** correct?
|
||||
**\<suraeNoether>** agreed with medusa
|
||||
**\<suraeNoether>** rehrar: always yes
|
||||
**\<sgp>** I've expressed my support for A or B
|
||||
**\<rehrar>** then C is the only option
|
||||
**\<rbrunner>** Maybe the least bad
|
||||
**\<thrmo>** second B
|
||||
**\<rehrar>** we are responsible for people's money, freedom, and lives, remember?
|
||||
**\<iDunk>** I'm for C.
|
||||
**\<suraeNoether>** any concerns about getting BPs implemented *quickly* are not thinking about what Monero is going to look like in 2022
|
||||
**\<Maxithi>** Mind to make a quick run up to explain in one sentence A, B and C?
|
||||
**\<thrmo>** suraeNoether, B doesn't have to be quickly
|
||||
**\<sarang>** The real downside in a March/Sept is the blockchain size
|
||||
**\<thrmo>** Maxithi, **\<sarang>** So to move this talk forward... really the question is between (a) doing March and then BP when it's ready, (b) doing no fork until BP is ready, or (c) doing March and waiting on BP until Sept
|
||||
**\<sarang>** if that's something you care about
|
||||
**\<pebx>** i somehow miss smooth, moneromoo and fluffypony in this discussion... i know, i have been late today but what's their opinion?
|
||||
**\<suraeNoether>** fluffypony is in Miami right now iirc, so he's probably sleeping on a pile of money and hookers
|
||||
**\<endogenic>** sarang: without bps coming along we wouldnt hve been able to avoid that
|
||||
**\<Maxithi>** thrmo Thx
|
||||
**\<pebx>** sarang the real downside in september is the community which is expecting it
|
||||
**\<pebx>** even more after fluffy announced it on twitter
|
||||
**\<iDunk>** Why are they expectiong it ?
|
||||
**\<pebx>** to be in march
|
||||
**\<medusa>** that not an argument rly
|
||||
**\<medusa>** ofc they want it
|
||||
**\<iDunk>** Who told them it would be in March ?
|
||||
**\<endogenic>** i want 0kb transactions and i want them now
|
||||
**\<rbrunner>** It was "word on the street" for a long time
|
||||
**\<sgp>** It just means we need a press release saying why the decision changed
|
||||
**\<rehrar>** I'm sure they also want other things asap.
|
||||
**\<suraeNoether>** sgp: we never announced any decisions on bulletproofs
|
||||
**\<rehrar>** hence my suggestion for MRL to put out a little news bulletin with a formal recommendation to wait
|
||||
**\<thrmo>** Without BP what consensus rules changes NEED an hardfork by march?
|
||||
**\<sarang>** We said March if it was ready
|
||||
**\<sarang>** We should do a press thing, yes
|
||||
**\<dEBRUYNE>** \<rbrunner> It was "word on the street" for a long time \<= Not really
|
||||
**\<pebx>** iDunk fluffy announced it to be implemented in march hard fork. that's also the reason why i miss him in the whole discussion
|
||||
**\<suraeNoether>** so our bulletin announcemennt that rehrar suggested will be the *first* formal announcmenet about BPs coming from monero.
|
||||
**\<sarang>** regardless of our choice
|
||||
**\<rehrar>** if community whines, we point to the bulletin
|
||||
**\<rbrunner>** Pushing people to update needs a hardfork in any case, IMHO
|
||||
**\<iDunk>** Well, fluffypony jumped the gun then.
|
||||
**\<rehrar>** if they REALLY disagree, I'm sorry to say, they can fork :P
|
||||
**\<dEBRUYNE>** fluffypony strongly favors adherence to the schedule fwiw
|
||||
**\<suraeNoether>** pebx: where did he announce that? can you send me a link?
|
||||
**\<pebx>** one second, i have to search on twitter...
|
||||
**\<thrmo>** dEBRUYNE, the schedule was never meant to be set in stone
|
||||
**\<gingeropolous>** was double blob brought up at all as an option? or am i just chasing windmills
|
||||
**\<thrmo>** It will eventually be changed, maybe now would be a good time to do it.
|
||||
**\<rbrunner>** double blob?
|
||||
**\<dEBRUYNE>** thrmo: need a source on that
|
||||
**\<iDunk>** You are chasing windmills :)
|
||||
**\<suraeNoether>** gingeropolous: not brought up at all. care to explain how that would work?
|
||||
**\<suraeNoether>** one thing i want to make perfectly clear to everyone in this room
|
||||
**\<endogenic>** thrmo: what necessitates breaking the existing schedule?
|
||||
**\<thrmo>** dEBRUYNE, fluffy mentioned it several times iirc (and others) that eventually the scheduled would be changed and the rate of HFs diminished.
|
||||
**\<Maxithi>** Double Blob https://github.com/monero-project/monero/issues/3154
|
||||
**\<gingeropolous>** u make a transaction with a borromean and a bullet proof. You only work with the borromean for n months. Eventually, bulletproofs are trusted. You can then prune the borromean from the chain.
|
||||
**\<dEBRUYNE>** thrmo: Then we'd change to once a year probably
|
||||
**\<dEBRUYNE>** and either march or september would be thrown out
|
||||
**\<suraeNoether>** gingeropolous: ah, there could be some security issues with that
|
||||
**\<endogenic>** thrmo: he mentioned that in the context of monero stabilizing in the future didnt he
|
||||
**\<rehrar>** thrmo, this is true when we get to a point that Monero has so many users that HFs become more and more difficult to pull off, not as a result of new tech as I understand it
|
||||
**\<thrmo>** endogenic, unnecessary blockchain growth for one, and why exactly do we NEED to hardfork in march?
|
||||
**\<gingeropolous>** in various conversations it seems that the issues aren't as severe as they seem.
|
||||
**\<endogenic>** thrmo: a hard fork causes blockchain growth?
|
||||
**\<rehrar>** to force upgrades to newer, more stable software is as good a reason for me as any
|
||||
**\<thrmo>** endogenic, adopting BPs later rather than sooner.
|
||||
**\<suraeNoether>** gingeropolous: it would take more time for us to vet the double blob technique than it would for us to audit the BP code alone and push it. :P
|
||||
**\<rehrar>** suraeNoether, what did you want to make perfectly clear?
|
||||
**\<thrmo>** rehrar, why do you need to fork for that?
|
||||
**\<suraeNoether>** so what i wanted to make clear: if you are hoping to get BPs implemented before September in order to get a price bump, or to avoid a price crash in Monero...
|
||||
**\<gingeropolous>** suraeNoether, perhaps.. but here I tried to fully explain it: https://github.com/monero-project/monero/issues/3154
|
||||
**\<medusa>** we usually use the fork to roll out cleints, so we just have 1 version to support
|
||||
**\<gingeropolous>** and furthermore, this isn't going to be the last time some amazing tech comes through to reduce transaction size
|
||||
**\<endogenic>** thrmo: changing the existing schedule needs to be justified more than not doing so in the absence of a problem making it necessary, and people agree that bulletproofs and its implementation needs to be audited right?
|
||||
**\<thrmo>** medusa, i know, it doesn't need to be that though.
|
||||
**\<rehrar>** can I speak bluntly?
|
||||
**\<gingeropolous>** so it'd be great if we had a mechanism to transition to fresh tech without wondering if the whole thing'll come crashing down
|
||||
**\<suraeNoether>** then your logic is already flawed... if you think Monero will hit 10,000 USD faster if we get BPs implemented in June instead of September, you are... well, i can't say for sure that you are wrong, but your logic circuits may need some dusting.
|
||||
**\<endogenic>** agree surae
|
||||
**\<endogenic>** also fees
|
||||
**\<thrmo>** endogenic, I do agree too, I just don't think that adherence to the schedule is as a big thing as it's been portrayed.
|
||||
**\<suraeNoether>** fees are going to be changing in this HF either way
|
||||
**\<sgp>** @surae please, I've been in the community for several years. I don't care about the price nearly as much as I care about the practical benefits of lower transaction fees and reduced blockchain bloat
|
||||
**\<endogenic>** if they are lowered at the expense of monero's security
|
||||
**\<endogenic>** what's even the point
|
||||
**\<gingeropolous>** ^^
|
||||
**\<suraeNoether>** sgp: *good* but our fees are going to be reduced anyway, and blockchain bloat is literally going to be marginal as time goes on
|
||||
**\<rehrar>** this is a moot conversation honestly, and it's silly that we are having it. Again, the responsibility on our shoulders is very large. Money, freedom, and lives. And if the best thing for this new crypto is time, then the LEAST we can do is give it an extra six months.
|
||||
**\<thrmo>** I couldn't care less about the price either.
|
||||
**\<endogenic>** i dunno thrmo imo it's a matter of what precedent we implicitly accept by agreeing to an action even if we arent aware of the consequences
|
||||
**\<endogenic>** people will use that precedent for their own reasons
|
||||
**\<endogenic>** just my two cents :p
|
||||
**\<sgp>** @rehrar we would be at the point though where the review(s) would have already been completed
|
||||
**\<suraeNoether>** sgp: and please don't take my comment as accusing you of being only interested in monero's price, i know that you are a long-time member of the community and we have had several good discussions in the past. i value your opinion
|
||||
**\<rehrar>** again sgp, it's not just the code that needs time to be
|
||||
**\<rehrar>** it's also the paper of BP itself
|
||||
**\<suraeNoether>** i just wanted to make that clear to anyone who ends up reading the logs later, or any lurkers who are thinking "but oh man i could totally get rich if they push this in June."
|
||||
**\<rehrar>** what if there is an exploitation in the crypto itself that has gone unnoticed at this point in time
|
||||
**\<rehrar>** the reviews will review our code implementation, not the paper
|
||||
**\<suraeNoether>** *nod* similar to the ASNL ring signatures in the original ringct paper
|
||||
**\<rehrar>** the crypto itself needs time to breathe
|
||||
**\<thrmo>** endogenic, there are some costs for "unnecessary" hardforks too, even if they are on schedule.
|
||||
**\<suraeNoether>** \*which wasn't caught until after the paper was published, put through peer review, and after I believe we had gone live with code.\*
|
||||
**\<rehrar>** this itself is an argument to wait
|
||||
**\<rehrar>** as I said before, there may be third parties that will review the BP paper itself (not our implementation of it) for their own reasons
|
||||
**\<iDunk>** It was live on testnet, not in mainnet.
|
||||
**\<rehrar>** and we can benefit from that
|
||||
**\<thrmo>** Hard forks momentarily weaken the security of the network, so doing it because of no other good reason than schedule seems silly to me.
|
||||
**\<endogenic>** thrmo to say they are technically unnecessary only speaks to part of the hypothetical necessity which must be evaluated. that's everything i'm saying
|
||||
**\<pigeons1[m]>** The code was only live on testnet
|
||||
**\<sarang>** We're definitely not the only ones interested in BPs, so there will be good eyes on it going forward
|
||||
**\<thrmo>** as rehrar pointed above, money, freedom and lives are at stake.
|
||||
**\<sgp>** We discussed this in previous meetings. There's always an argument to wait. If the community wants more review on the math, we should get an audit of that too
|
||||
**\<gingeropolous>** \<thrmo> Hard forks momentarily weaken the security of the network \<= what?
|
||||
**\<thrmo>** gingeropolous, Node count drops, hashrate drops, etc
|
||||
**\<suraeNoether>** thrmo we are modifying fees in the next hf so its not merely to accommodate schedules
|
||||
**\<sgp>** If we knew of researchers in the process of looking at the math I would agree with you, but it seems odd to wait in hopes someone is looking at it
|
||||
**\<rehrar>** sorry sgp, but the argument is not to wait indefinitely, it's to wait until September
|
||||
**\<rehrar>** it was mentioned in a previous meeting
|
||||
**\<gingeropolous>** and what if there aren't any reviews by then?
|
||||
**\<rehrar>** if we wait until September, that more than doubles the time that the BP paper has been in existence
|
||||
**\<dEBRUYNE>** sgp: Waiting until August / September literally triples the time the paper has been out in existence
|
||||
**\<dEBRUYNE>** That's a convex pay off
|
||||
**\<pebx>** https://twitter.com/fluffypony/status/945706717421195266
|
||||
**\<rehrar>** dEBRUYNE is more right than me \^ :P
|
||||
**\<pebx>** sorry took me longer than i thought, twitter search is unfortunately not the best
|
||||
**\<rehrar>** although I guess triples is technically "more than doubles"
|
||||
**\<thrmo>** pebx, fluffypony doesn't decide the community does.
|
||||
**\<rehrar>** also, the second time me and dEBRUYNE said remarkably similar things. Just a thought.
|
||||
**\<dEBRUYNE>** rehrar: :P
|
||||
**\<rbrunner>** Yes, but that was word on the street :)
|
||||
**\<gingeropolous>** nonsense! He is our god! Such blasphemy!
|
||||
**\<pebx>** i know, but the community expects this now... that's why i miss fluffy in the discussion
|
||||
**\<sgp>** He was just finding the tweet that others asked for
|
||||
**\<dEBRUYNE>** Whether the community expects BP in March is at most ambigous imo
|
||||
**\<rehrar>** ok, let's end this conversation with one question
|
||||
**\<suraeNoether>** pebx thanks for finding that. He shouldn't have said that, number one
|
||||
**\<dEBRUYNE>** at best\*
|
||||
**\<rehrar>** MRL: what is your formal recommendation to us at this point?
|
||||
**\<iDunk>** That tweet was unfortunate.
|
||||
**\<pebx>** suraeNoether that's the thing i'm talking about...
|
||||
**\<endogenic>** the code IS merged though
|
||||
**\<endogenic>** to master
|
||||
**\<sarang>** single output
|
||||
**\<pebx>** he is still some kind of project leader, but he missed last sunday's discussion and now too
|
||||
**\<iDunk>** And is live on testnet :)
|
||||
**\<rbrunner>** Yes, and live on Testnet
|
||||
**\<sarang>** multi is not yet
|
||||
**\<sarang>** and that's what we want audited
|
||||
**\<endogenic>** yes but aside from tagging an old commit
|
||||
**\<endogenic>** does this raise the issue of whether it should have been merged?
|
||||
**\<suraeNoether>** rehrar: Sarang, correct me on this if need be: our formal recommendation to pay an OSTIF group to audit the code, funded through a new acronym, and to include BPs in September.
|
||||
**\<dEBRUYNE>** I wouldn't confine the audit to the OSTIF group
|
||||
**\<rehrar>** sarang? you second this?
|
||||
**\<suraeNoether>** dEBRUYNE: just my recommendation based on what we've seen and heard so far. if another group feels more right, we can goi with them instead.
|
||||
**\<sarang>** I don't have a particular opinion on September vs pushing the March, since there are many other parties involved and I don't work closely enough with them to fully appreciate their needs
|
||||
**\<sarang>** I agree on the rest from a research perspective
|
||||
**\<rehrar>** ignoring needs of others for the time being, just think of the crypto
|
||||
**\<suraeNoether>** the delay of HF schedules, etc, this is all not even really MRL's job to make decisions about. the quesiton is: will BPs be implemented in the next scheduled HF for May? And I dont' think the answer to that is yes, from either me or sarang
|
||||
**\<suraeNoether>** and by "will" i mean "should"
|
||||
**\<sarang>** I consider the crypto pretty independent from the fork schedule
|
||||
**\<gingeropolous>** and by may u mean march
|
||||
**\<suraeNoether>** yeah the one starting with "ma"
|
||||
**\<rehrar>** and by dont', you mean "don't"
|
||||
**\<sarang>** Using the double blob method would be a good way to mitigate issues
|
||||
**\<sarang>** but we haven't used it before
|
||||
**\<suraeNoether>** sarang do you have expectations of security if two range proofs for the same masked amount are provided? because I can imagine at least two different ways that could go wrong if done incorrectly.
|
||||
**\<suraeNoether>** but that's highly dependent on the algebra and boosting negligible event probabilities into more likely events.
|
||||
**\<sarang>** suraeNoether: I am not worried about the two-proof method in that way
|
||||
**\<dEBRUYNE>** suraeNoether: we can go with multiple groups as well
|
||||
**\<suraeNoether>** sarang: ok we should talk more about it later then i guess
|
||||
**\<sarang>** yes
|
||||
**\<rehrar>** well, hard fork times aside, it's agreed it shouldn't be in March, and that's enough for the time being
|
||||
**\<sarang>** yes
|
||||
**\<rehrar>** good updates on the audit front
|
||||
**\<rbrunner>** But a HF in March is not entirely agreed, it seems to me ...
|
||||
**\<sarang>** But he means BPs will not be in March
|
||||
**\<sarang>** Too many audit steps before then
|
||||
**\<suraeNoether>** rbrunner: this meeting was never about HF schedules
|
||||
**\<sarang>** I'll keep everyone updated in #monero-research-lab on the OSTIF quotes
|
||||
**\<pebx>** sarang what's a real timeframe to be ready with audits?
|
||||
**\<rehrar>** MRL, let's talk about the Z.C.A.S.H (name pending) fund later today?
|
||||
**\<sarang>** Once the funds are raised and the group has a start date? A month, maybe 25 biz days
|
||||
**\<sarang>** But start dates depend on the groups' availabilities
|
||||
**\<pebx>** okay, so i'm still for delaying the hf to april or may but then with bp
|
||||
**\<rehrar>** last question, should we still have dev meeting next week, or push to three weeks from now?
|
||||
**\<pebx>** otherwise some sumo will have it before monero
|
||||
**\<janeropicasso>** Hi guys I'm new been reading along. I'd just like to say one thing. I think keeping an eye on the long term view is much better than any short term benefits unless the situation is dire. In my experience hard deadlines on things never work. Security, Privacy and Untraceability is what separates Monero high tx fees can wait.
|
||||
**\<iDunk>** I don't see this as a dev meeting.
|
||||
**\<pebx>** i would be for a dev meeting next week, but who i am...
|
||||
**\<rehrar>** alright, I'll make an issue for it on the Githubz
|
||||
**\<rbrunner>** Meet again next week, I would say, in any case.
|
||||
**\<dEBRUYNE>** janeropicasso: There will be a partial solution for fees in the next release
|
||||
**\<iDunk>** Next week is the normal schedule.
|
||||
**\<rehrar>** just don't want burnout
|
||||
**\<rbrunner>** Critical times
|
||||
**\<pebx>** rbrunner this.
|
||||
**\<rehrar>** Alright. Anything anyone else wants to say on this?
|
||||
**\<rehrar>** dEBRUYNE, can we get the logs for this too?
|
||||
**\<dEBRUYNE>** Sure
|
||||
**\<dEBRUYNE>** No ETA though :P
|
||||
**\<sgp>** I suppose I'd like to hear a bit more about fees
|
||||
**\<gingeropolous>** so, just throwing it out there - could we get one of the clones to implement? Then there's a worthy target to exploit ..
|
||||
**\<rehrar>** sgp outside the scope of this meeting I think?
|
||||
**\<rbrunner>** Yes, I don't fear Sumo implementing it at all
|
||||
**\<rbrunner>** Our fall guys :)
|
||||
**\<endogenic>** janeropicasso: i do wonder what people will prioritize. history is scary
|
||||
**\<sgp>** "Bulletproof/fees meeting" lol
|
||||
**\<rehrar>** Ah, good point.
|
||||
**\<rbrunner>** Just think that currencies normally work within time frames of decades
|
||||
**\<pebx>** rbrunner well it's some kind of an issue if someone will implement monero developed code before monero does...
|
||||
**\<sarang>** That's part of what we're trying to avoid
|
||||
**\<pebx>** at least for observers
|
||||
**\<sgp>** @dEBUYNE can you speak about what you meant by "partial fix"?
|
||||
**\<sgp>** @dEBRUYNE
|
||||
**\<rbrunner>** pebx: Reminds me of my Windows installer and the X12 coin :)
|
||||
**\<gingeropolous>** pebx, what do u mean by observers?
|
||||
**\<dEBRUYNE>** So the wallet will use low priority by default when there's no or low backlog and the last N blocks are below X size
|
||||
**\<dEBRUYNE>** Then switch to the old default once activity picks up
|
||||
**\<dEBRUYNE>** And we reasonably assume miners are going to expand the blocksize
|
||||
**\<dEBRUYNE>** It's still a bit crude and there's no perfect solution, but at least we got something going
|
||||
**\<rbrunner>** Throwing people a bone
|
||||
**\<sgp>** @dEBRUYNE, ok cool. Just curious if there was something else I missed
|
||||
**\<dEBRUYNE>** Some talk about whether we should lower the unimportant level, because it's arbitrary anyway
|
||||
**\<sarang>** So any action items before next meeting?
|
||||
**\<sarang>** Besides carry on w/ audit and start to plan funding?
|
||||
**\<sarang>** We'll need more input from core folks about the role of general funds
|
||||
**\<pebx>** gingeropolous people out of the community and people trying to attack monero and spreading disinformation...
|
||||
**\<rehrar>** hmmmm...
|
||||
**\<pebx>** i am moderating the groups on telegram so i see the "normal people talk"
|
||||
**\<rehrar>** nothing else from me on this meeting?
|
||||
**\<rehrar>** sarang even with availability of general funds, I'd like to try at least some with FFS. It's just good 'marketing'.
|
||||
**\<pebx>** but i wouldn't like to rush it either into march if it's not ready to be released...
|
||||
**\<rehrar>** Monero raises grassroots money for review
|
||||
**\<sarang>** In that case we should at least set a goal amount for this review fund
|
||||
**\<pebx>** that's a good point rehrar
|
||||
**\<sgp>** Is $50k a good goal?
|
||||
**\<rehrar>** So much is said in that Monero crowdfunds two full time researchers, two full time coders, and other stuff
|
||||
**\<rehrar>** I think add a zero to that sgp
|
||||
**\<rehrar>** if this will be used for multiple reviews over multiple years
|
||||
**\<sarang>** $50K would fund a pro audit and maybe one individual
|
||||
**\<sgp>** Ok, thought that was initial goal scope
|
||||
**\<suraeNoether>** rehrar i think if we shoot for 75-100k, and we have to pay, say, 50k this year... well... that's 25k in monero that could be worth several extra zeros by the next time we need an audit going
|
||||
**\<rehrar>** or could be worth several less zeros :P
|
||||
**\<pebx>** 500k is quite a figure... but if we can raise that for some merchandise stores to accept monero, it should be possible to do so for the tech
|
||||
**\<suraeNoether>** yeah, we can always FFS again to refresh the fund
|
||||
**\<suraeNoether>** pebx +1
|
||||
**\<sgp>** I think 100k is manageable. 500k is unrealistic to start imo. GloBee is an exception, not the norm
|
||||
**\<rehrar>** but if we think 100k is good enough to start, we can shoot for that
|
||||
**\<gingeropolous>** f'real
|
||||
**\<suraeNoether>** sgp: +1 also on that
|
||||
**\<suraeNoether>** if we need to re-up, we can
|
||||
**\<rehrar>** it can also be like the HackerOne fund
|
||||
**\<rbrunner>** Yes, it's not sexy enough for 500K
|
||||
**\<rehrar>** the goal has been met and extended a few times
|
||||
**\<sarang>** OK, I'm out for now but will keep everyone informed on audit progress
|
||||
**\<rehrar>** ok, thanks sarang
|
||||
**\<rehrar>** thanks everyone for coming. Was fairly productive I think.
|
||||
**\<pebx>** thanks sarang!
|
||||
**\<rbrunner>** Certainly interesting. Thanks!
|
||||
**\<suraeNoether>** rehrar shoot me an email at my protonmail address and cc sarang on it and we'll start talking about a review fund and the FFS post for it
|
||||
**\<rehrar>** sure thing
|
||||
**\<sarang>** or in the MRL IRC if you want it public
|
||||
**\<rehrar>** I prefer sneaking behind closed doors
|
||||
**\<suraeNoether>** hmm. i was thinking its not totally on topic for #monero-research-lab but maybe it is...
|
||||
**\<dEBRUYNE>** 100k seems a bit on the lower end, whereas 500k seems a bit on the high end
|
||||
**\<rehrar>** the research lounge
|
||||
**\<dEBRUYNE>** Perhaps something in between would be best
|
||||
**\<rehrar>** discuss it over a vape
|
||||
**\<sarang>** $133,700
|
||||
**\<rehrar>** $250k? dEBRUYNE?
|
||||
**\<pebx>** 222.222
|
||||
**\<rehrar>** sarang: and fifty two cents
|
||||
**\<rbrunner>** Don't we have any nice prime number somewhere there?
|
||||
**\<pebx>** however, why are we talking in fiat?
|
||||
**\<dEBRUYNE>** rehrar: something like that
|
||||
**\<sarang>** pebx because The Man has taught me to think in fiat
|
||||
**\<rehrar>** wonder how many of these reviewers would accept XMR directly
|
||||
**\<suraeNoether>** the OSTIF accepts crypto apparently
|
||||
**\<suraeNoether>** but they pay the groups in fiat
|
||||
**\<sarang>** OSTIF will do the exchange for us fee-free
|
||||
**\<suraeNoether>** that's nice
|
||||
**\<sarang>** and OSTIF agreed to take no cut themselves if we credit them
|
||||
**\<rehrar>** they want the Monrus
|
||||
**\<sarang>** they want to drum up publicity for a larger upcoming audit
|
||||
**\<pebx>** 727 XMR would be a prime number ;)
|
||||
**\<rehrar>** alright friends, Imma kick rocks. Catch you all later.
|
||||
**\<manifest>** there probably isnt a tool for monero where you could monitor and control multiple wallets easily for testing purposes
|
||||
**\<fluffypony>** pebx: I was arguing with a BCash shill, and it was at a time when we were more confident about March
|
||||
**\<sarang>** We can still present the delay positively
|
||||
**\<sarang>** We're trailblazing but doing it correctly
|
||||
**\<fluffypony>** was there a reasonable sense of consensus on the way forward wrt the HF schedule?
|
||||
**\<Maxithi>** fluffypony Not really, there are two main options and we didn't find an global agreement.
|
||||
**\<fluffypony>** we're starting to run tight on time
|
||||
**\<Maxithi>** fluffypony Yeah, however everyone did agree that by postponing BP we still have 2-3 weeks to find a consensus on the HF.
|
||||
**\<fluffypony>** in situations like this the best thing to do is the thing that isn't controversial, which means not including it until it's ready
|
||||
**\<fluffypony>** we wanted to do code freeze at the end of Dec / beginning of Jan
|
||||
**\<fluffypony>** so not really
|
||||
**\<iDunk>** Is there going to be a new branch for the new release ?
|
||||
**\<Maxithi>** Main arguments were PRO: HF forces community to update software. AGAINST: No protocol update requires HF.
|
||||
**\<fluffypony>** yes
|
||||
**\<Maxithi>** And then the fact that HF are "supposed" to be on a regular basis (based on HF history).
|
||||
**\<Maxithi>** And again some Pro and Against
|
||||
**\<fluffypony>** we've always maintained that the HF should happen even if there's no protocol update
|
||||
**\<fluffypony>** to keep active versions in line
|
||||
**\<fluffypony>** and prevent things like the Bitcoin leveldb / bdb bug
|
||||
**\<Maxithi>** @fluffypony: we've always maintained that the HF should happen even if there's no protocol update \<= No one brought that argument up, would have been a good one.
|
||||
**\<iDunk>** In this case, using subaddresses and multisig will require using the new release.
|
||||
**\<endogenic>** yes i did :P
|
||||
**\<iDunk>** And having people be forced to upgrade avoids support nightmares.
|
||||
**\<fluffypony>** yep
|
||||
**\<fluffypony>** I mean, unless there's a strong reason NOT to do a March fork we should go ahead with it
|
||||
**\<Maxithi>** endogenic: yes i did :P \<= Than it is my mistake. Didn't understand that it was stated as a previous consensus. I read it rather as a habbit.
|
||||
**\<endogenic>** Maxithi: i was just being more socratic about it :P
|
||||
**\<endogenic>** Maxithi: since i dont know what i know yet
|
||||
**\<Maxithi>** endogenic You should have been more straight forward.
|
||||
**\<fluffypony>** and then leave it open-ended for Bulletproofs
|
||||
**\<endogenic>** Maxithi: i was
|
||||
**\<endogenic>** Maxithi: i was responding to someone else and he understood and agreed with me
|
||||
**\<Maxithi>** Why hasn't this been written down already? We should put up these kind of consensus rules and drop them on git to prevent future disagreements.
|
||||
**\<Maxithi>** endogenic My bad, didn't catch that through the lines.
|
||||
**\<endogenic>** Maxithi: arent consensus rules derived from people not documents
|
||||
**\<endogenic>** besides who wants to prevent discussion
|
||||
**\<fluffypony>** it's a good idea to at least write down how we generally feel things should be handled
|
||||
**\<fluffypony>** almost like a doctrine, not really a list of rules
|
||||
**\<Maxithi>** endogenic Agree but this could prevent from turning 1 meeting into 4
|
||||
**\<Maxithi>** Doesn't mean we can't change it ;) Only that we take what we previously achieved and discuss on top of that
|
||||
**\<endogenic>** now that BPs have been merged, can a new release which excludes BPs be done?
|
||||
**\<endogenic>** single output , if specificity is needed
|
||||
**\<fluffypony>** endogenic: they're merged but dormant
|
||||
**\<endogenic>** ah, of course, that makes sense
|
||||
**\<rbrunner>** But we probably new a second, non-BP testnet
|
||||
**\<fluffypony>** yes I agree on the testnet / devnet thing
|
||||
**\<rbrunner>** Ah, yes, those were the proposed names
|
||||
**\<fluffypony>** I think the real problem here is that Bulletproofs doesn't have a cool name
|
||||
**\<fluffypony>** I mean, it's reasonably cool
|
||||
**\<fluffypony>** but how can we compete with VVraith Protocol?
|
||||
**\<rbrunner>** :)
|
||||
**\<chachasmooth>** is wraith the guy who claimed to be satoshi?
|
||||
**\<fluffypony>** chachasmooth: no, it's the stealth addresses thing that Verge is doing
|
||||
**\<chachasmooth>** oh, right. both are shit, that's what I remember
|
||||
**\<chachasmooth>** wraith is still not implemented?
|
||||
**\* fluffypony** shrugs
|
||||
**\<chachasmooth>** fluffypony what happened to the majority of forum posts? did you take them offline on purpose?
|
||||
**\<fluffypony>** censored by Blockstream
|
||||
**\<fluffypony>** kidding, we disabled them because of the spam, I'll fiddle with the settings so that they're still visible
|
||||
**\<Maxithi>** fluffypony About spam, the forum has some https://forum.getmonero.org/6/ideas/89759/advice-for-you-to-get-free-600m-swtor-credits-cheap-on-swtor2credits-jan-17
|
||||
**\<Maxithi>** Who can remove these?
|
||||
**\<fluffypony>** tks
|
||||
**\<fluffypony>** any of the mods
|
||||
**\<fluffypony>** but I'm pretty much the only one active
|
||||
**\<Maxithi>** I'm sure your schedule is empty and you love handling this kind of stuff ;)
|
||||
**\<fluffypony>** lol
|
||||
**\<rbrunner>** Just checked: Wraith is really, finally online, but seems to have some teething problems: https://steemit.com/bitcoin/@siddm96/verge-hardfork-for-stealth-transaction-3a0509e274618
|
||||
**\<rbrunner>** See? Other coins can hardfork just like that. Why can't we?
|
||||
**\<rbrunner>** Was checking about 30 transactions on the Verge blockchain and did not encounter a single one with stealth addresses. Roaring success, it seems
|
||||
**\<fluffypony>** lol
|
||||
**\<iDunk>** Imagine if subaddresses were being without a hard fork :)
|
||||
**\<iDunk>** Major clusterfuck.
|
||||
**\<rbrunner>** That's my opinion: We need the March hardfork just to force lazy people to update their software
|
||||
**\<iDunk>** Exactly.
|
||||
**\* sgp** sent a long message: https://matrix.org/_matrix/media/v1/download/matrix.org/BarHGxHdPoPajSqUqUpcKEFm
|
||||
**\<gingeropolous>** thanks matrix
|
||||
**\<bibble>** lol
|
||||
**\<bibble>** guess #3 would mean more pumps, more money ??
|
||||
**\<sarang>** That's not quite correct. We aren't planning on having single-output audited
|
||||
**\<sarang>** If there's a pressing need for single, we restrict transactions to a single-output proof within the multi code
|
||||
**\<sarang>** A single-output proof is just the degenerate case of a multi-output
|
||||
**\<chachasmooth>** what benefits do regular hard forks bring?
|
||||
**\<jorko>** regular upgrades. avoids the Bitcoin clusterfuck where consensus = no protocol upgrades, ever.
|
||||
**\<gingeropolous>** it also helps improve the software, because everyone is running the same thing. So we all have the same bugs if they are present.
|
||||
**\<sgp>** @sarang my apologies, I didn't know that
|
||||
**\<sgp>** I'll have to think harder about this
|
||||
**\<sarang>** When we think about single vs multi output proofs from now on, we should consider that they're really different cases of the same final code
|
||||
**\<sarang>** The difference is really in whatever we decide to do for the corresponding fee structure
|
||||
**\<sarang>** Yes, the original "single only" code is on testnet, but moneromooo has the multi code worked up now
|
||||
**\<sgp>** @sarang once the multi-output code has been reviewed, is there a reason to add it separately from single-output, or would you feel comfortable adding both at the same time?
|
||||
**\<sarang>** The multi code completely replaces the single code
|
||||
**\<sarang>** development was done separately in case we finished single first and wanted to deploy sooner
|
||||
**\<sarang>** a single-output proof is just a multi-output proof with one output
|
||||
**\<sgp>** So realistically the community has decided that single-output is a waste of time because multi-output is basically done and the community wants it audited
|
||||
**\<sarang>** Given the desire for an audit, it makes sense to jump straight to multi and have the fee discussion surrounding it
|
||||
**\<sgp>** Ok, makes sense
|
||||
**\<sgp>** So it's basically just a question of whether Monero hardforks soon after the code is complete and reviewed or in September
|
||||
**\<sgp>** For some reason I still thought single and multi-output would be rolled out separately
|
||||
**\<sarang>** Single doesn't require that the fee structure be switched away from size-based, but that's about it
|
||||
**\<sarang>** Might as well pay for only one audit
|
||||
**\<sgp>** I understand skipping single-output bulletproofs
|
||||
**\<sarang>** What it does mean is that the BP code on testnet is NOT the code that will be audited or eventually deployed
|
||||
**\<sarang>** for whatever that's worth
|
||||
**\<sarang>** Multi is here: https://github.com/moneromooo-monero/bitmonero/tree/bp-multi/src/ringct
|
||||
|
Loading…
Reference in a new issue