Monero Dev Meeting Note Highlights – 2019-03-31
Logs
351 lines
hyctime
dEBRUYNETime to start!
dEBRUYNEcc hyc, fluffypony, moneromooo, jtgrassie, vtnerd, sarang, suraeNoether, and anyone else I forgot :p
sgp_hello :)
rbrunnerHi
hychey
oneiric_hio
vtnerd__hello
dEBRUYNELet's start with the main topic of this meeting, the point release
kovri-slack<woodser> hello
saranghi
dEBRUYNEmoneromooo: could you perhaps tell us what basically remains to be done / merged before we can tag the point release?
fluffypony5239 5287 5288 5289 5290 5291 5292 5294 5295 5297 5298 5299 5302 5303 5305 5306 5307 5308 5309 5313 5317 5318 5319 5322 5325 5326 5327 5329 5331
fluffyponyalso waiting on 5121 to be squashed, probably going to give up on that
moneromoooI don't think there's anything really showstopper, so it'll be whenever we drain github.
mrantraxhello
moneromoooI'd like to get the SSL changes from vtnerd__, and the rpc tests if possible.
fluffyponygingeropolous: please rebase 5221
fluffypony5320 is in "do not merge" for now
moneromoooOh, and the pay for service stuff, but this might require too much review time.
fluffypony5332 is still in review
moneromoooActually 5352 will need to go in before the release.
moneromoooThe 100k lookups hit HDDs hard.
fluffypony100%, it's on my list
dEBRUYNESo we can basically tag after that list is merged
fluffyponydEBRUYNE: no
fluffyponymerge + give it like a week or two for issues
dEBRUYNEPerhaps I should've said branch :P
fluffyponyyeah we can branch
dEBRUYNESo branch after that list is merged, then test 1-2 or two weeks and merge any fixes into the branch
dEBRUYNEThereafter, tag :p
moneromoooThe list above is basically what's 10 days old.
dEBRUYNEPerhaps we could use Monero's birthday (April 18) as target date
fluffyponydepends on if people review things :-P
moneromoooAnd we need to make sure the ledger stuff is all ok. I'm not 100% sure whether 5332 is all we need.
dEBRUYNEmoneromooo: I think stoffu said he'd extensively review and test the Ledger PRs
moneromoooOK
dEBRUYNEmoneromooo: Anything else you'd like to mention or discuss?
sgp_Birthday would be pretty cool
moneromoooJust that it would be really really nice if people were to review 5357 (pay for rpc).
moneromoooIt's possibly going to give us a noticeable hash rate boost.
moneromoooIt's got all the incentives in the right direction I think.
moneromoooAnd if someone wanted to go add optional pay-for-service to a bittorrent client, that could be a massive thing :)
dEBRUYNEFor anyone reading, #5357 basically allows a remote node to add a pay for service feature, where the remote node users would use hashes to pay for the remote node service
rbrunnerIs there an outline of the basic idea somewhere?
moneromoooThere is a long commit message.
fluffyponysgp_: it's not a birthday, it's a Moneroversary :-P
rbrunnerOk, got that commit message, thanks
dEBRUYNEsarang: Do you perhaps want to give a quick update on MRL stuff?
sarangWe wrapped up some simulations on output selection, working on a proposed ring signature scheme to make transactions smaller, among other things
sarangI don't know what the timeline would be on this scheme, if it was decided to implement it
rbrunnerHow much smaller?
sarangit would save 320 bytes per spent input
sarangVerification time should be a wash, or a bit faster than right now
sarangWe're finishing up security proofs on the scheme
dEBRUYNEThat's a significant shave of transaction size
sarangIt is
charutowill return addresses make it in the next hard fork?
dEBRUYNEsarang: Would it be worthwhile to get some independent auditor to look at the new scheme as wel?
dEBRUYNEas well*
sarangExternal audits are always beneficial
sarangand the scheme itself is quite straightforward
sarangExample code: https://github.com/SarangNoether/skunkworks/blob/clsag/clsag/clsag.py
dEBRUYNEWouldn't hurt indeed
sarangcharuto: at least one return address scheme (by knaccc) would not require a fork at all (all client side using txextra)
dEBRUYNEI presume the changes would need a hard fork to get activated?
sarangdEBRUYNE: for CLSAG? yes
dEBRUYNEYeah
sarangIt could be decided to allow both sig schemes, but that seems unnecessary if the savings are all in our favor
charutois txextra what is currently used for standalone unencrypted payment ids? i've heard the suggestion of using the old paymentid field as a return address
sarangThe dual-address DLSAG signature model would also allow for refunds, but would require a hard fork and a lot of other changes
sarangcharuto: this is (more or less) what knaccc's idea does, but for multi-output transactions in a clever way
dEBRUYNEsarang: Yeah, especially if they are audited
sarangCLSAG != DLSAG
dEBRUYNEsarang: Speaking of DLSAG, is the paper set to be released soon?
sarangif that's what you mean
sarangI'm going to be checking in with our coauthors tomorrow about this. There was a rolling deadline for the paper submission
kayrontif I may interject, any updates on that interesting return address feature that was thrown around some weeks ago?
charutothanks for the info sarang , personally i think the feature is well worth the additional transaction bytes, hope it makes it sooner or later
sarangkayront: was that knaccc's approach?
sarang(there have been a few different ideas for refunds)
kayrontdon't recall sarang , i think the first time I saw it it was someone else, I remember not recognizing the nickname. not sure if there have been further refinements to the idea since
sarangRegardless of the eventual decision on DLSAG, I support moving to the smaller CLSAG signature scheme if/when it's deemed ready
hycthese are independent schemes? both can be combined?
sarangPossibly. There a few different architectures for CLSAG
charutoalso, any news on the other bulletproofs implementation? multiple output bulletproofs i believe it was called
sarangWe already have multi-output BPs charuto
moneromoooMPC maybe ?
sarangDo you mean the multiparty computation for them?
sarangThere's example code already. Questions remain on the security guarantees if you try to reduce the rounds in the MPC
charutohold on let me search a bit
charutoi believe it was multi-output BPs
charutodidnt you guys at MRL start by only looking and implementing single-output BPs?
sarangOh, well those were ready when BPs were first deployed
sarangWe started to, but the timeline worked out to do multi-output right away
sarangI believe it's a consensus rule to aggregate outputs, in fact
sarangWe did recently get some additional BP verification time improvements added
charutooh, so single-output BPs never made it live? we skipped them and went directly to multi-output when BPs got introduced? great
kayrontoh, also, how's that tor integration going? haven't heard of it for some time
sarangbut those are not consensus (purely client-side algebra changes)
sarangcharuto: yep
dEBRUYNEkayront: That PR got merged recently
sarangthe BP MPC was an idea that moneromooo was interested in for a coinjoin-style construction
kayrontdEBRUYNE: do you have a link?
dEBRUYNEkayront: https://twitter.com/JEhrenhofer/status/1110942633348816896
dEBRUYNEsarang: Thanks for your update :) To be clear, for a standard 2 input 2 output transaction, the savings would be approximately 25-30% right?
sarangFor CLSAG?
dEBRUYNEYes
sarangYes, approximately 25% savings sounds right for a 2-2 w/ encrypted pID
sarangOf course, this all assumes favorable verification times and completed security proofs (and any other audit/review that's desired)
sarangthanks to RandomRun for the clever idea on this
dEBRUYNECool!
dEBRUYNEdsc provided an update for the GUI yesterday in -community, which I'll just paste
dEBRUYNE<dsc_> GUI update
dEBRUYNE<dsc_> Currently I'm implementing a white theme for the GUI. Will take a while to complete (ETA: 2 weeks). I also finished a redesign of the history page, now called transactions. Not only does it perform well when the user has a lot of historic data, it's also an improvement to UX.
dEBRUYNE<dsc_> kneuffelbund, designer of the GUI, did some IRL testing with *real* people and made notes. He is now designing/tweaking the wizards. https://github.com/monero-project/monero-gui/issues/2040
dEBRUYNE<dsc_> Me, Selsta and rbrunner7 worked on monero:// URI support on Windows/Linux/OSX. Selsta is working on xmr<->fiat conversions and xiphon is afaik. working on a decentralized node-o-matic.
dEBRUYNE<dsc_> Currently we are investigating a migration to Qt 5.9.7, which should give *some* extra performance and allow us to use newer Qt features.
dEBRUYNE<dsc_> After next point release, I will most likely focus on either i2p/tor integrations or android support.
sgp_On top of this, I've begun chatting with the gui team on how to approach the networking UI for Tor/i2p/dandelion. Still in early stages, but I have some design examples
sarangWhat UI would be needed for dandelion?
sgp_for just dandelion, just an on/off toggle
sarangWhy have the option to toggle at all?
moneromoooWhy would you want an off toggle ?
sarangThe dandelion++ protocol basically reverts to standard diffusion if something goes wonky (like a malicious peer)
sgp_moneromooo: I believe dandelion leaks more information to the first selected node
moneromoooWhat information ?
dEBRUYNEThe normal information. I think the difference is that in dandelion++, that node actually knows it is the first
dEBRUYNEWhereas normally it is a guess
sgp_dEBRUYNE: exactly, yes
sarangIt does not know it is the first, without other information
sarangIt knows only that it's part of a stem-mode relay
sarangusing parameters from other projects, the average stem length is 10 hops
sgp_10? I figured it was more like 2-3
sarangIt's tuneable
sarangBIP and Grin use 10% fluff probability IIRC
sarangand the stem topology changes every 10 minutes (also tuneable)
sgp_I would like to have a quick discussion on this sometime elsewhere before I agree the option for non-dandelion should be removed from expert mode, but dandelion is a minor part of the page design anyway. If it indeed doesn't leak any more information, then I agree it shouldn't be a configurable option
sarangWell, we don't have any concrete plans on Dandelion yet anyway :D
moneromoooI'm certaonly not going to be adding an off option unless you show there is leakage.
vtnerdI was also investigating dandelion over Tor, which separates the IP further. Although it may be "unnecessary" if other tweaks were done to p2p links, still lookign into this
moneromoooAh, unless vtnerd gets there first :D
sgp_Yes, I am aware of dandelion + Tor/i2p options too
dEBRUYNE<sarang> It does not know it is the first, without other information <= So thi sis not true? "that node actually knows it is the first"
dEBRUYNEin dandelion++
sarangUnless it has other network information, it only sees a relayed transaction that's marked to be in stem mode
sarangno data on the stem length is transmitted
dEBRUYNEOK
sarangalso FWIW dandelion++ does not address targeted network-level attacks
dEBRUYNEThen I see no reason to turn it off :-P
vtnerdI dont see why the node would necessarily know that its the first, unless it was simultaneously monitoring all links from that peer (ISP level packet monitoring)
sgp_I think I mostly used deduction in my analysis with only 2 stem nodes. With more, I'm more confident there is ambiguity
moneromoooIn which case it'd also know without dandelion.
sarangyeah vtnerd dandelion++ is intended to mitigate against larger-scale network observation
vtnerdthats why I was looking into injecting noise over Tor, this makes ISP level stuff much harder
sarangThe nice thing about dandelion is that it cares only about peer topology, and not about anything else at the network level
vtnerdcorrect, its a simple technique for making the techniques that coinbase or whatever are trying to do
sarangBTW I'm pretty sure the current BIP has a slightly incorrect implementation when it comes to the stem-fluff transition, that Grin recently changed away from
oneiric_ntcp2 in i2p gives approximately 65kB packets to play with too, plenty of room for padding noise
vtnerd*mitigate the observation that…
sgp_I changed my mind. Dandelion with stem nodes >2 should be automatic imo
sarangThe formal analysis also assumes a slow and small rollout
sarangso the network benefits even if only a portion of nodes upgrade to support it
sarang(not really as applicable for us, but good to know anyway)
vtnerdoneiric_ : its a bit more inolved than simple padding, you have to be careful about "burstiness" - if the link suddenly starts sending out lots of data just before a new tx appears in the mempool, its a potential giveaway too
vtnerdtheres a certain pattern to the epee p2p protocol chatter
sarangWe can also discuss Dandelion++ details at tomorrow's MRL meeting if this is useful for anyone
oneiric_yeah, in my test code i do uniform sample of full range
sarang(17:00 UTC)
vtnerdor should be, I have to look at some wireshark captures a bit to say more
moneromoooLong ago, I intended to relay txes on a fixed timer. Though it may be best to do this on a poisson timer.
sarangYes, this is a good idea for diffusion mode
moneromooo(because then you can your tx at once, and reset a poisson delay)
moneromoooAnd relay some random tx when it fires.
sarangand in fact for the Dandelion++ protocol, the recommendation for a block stem txn is a random delay before a diffusion
vtnerdfixed timers can be iffy, I posted a link to a paper in #monero-research-lab about this. all branches need same timing or you can see which branch someone took based on the small delay of when it appears on the wire
sarang*blocked
sgp_vtnerd what's the status of #4139 (MyMonero compatible server)? Still need reviewers? I've had several people express to me that this PR is important for other ecosystem projects
moneromoooI don't think anyone reviewed yet.
vtnerdhmm, I missed that part sarang thats interesting. that may work nicely with some of the stuff I prposed for the tor-part2 ffs/ccs
sarangYeah, it assumes both that diffusion has a random delay, and that nodes use a random timer that checks for blocked stem relays
vtnerdsgp_ I posted an update that unfortunately, I will be changing the DB format to fix a bug. no one has contacted me indicating they are using it, and therefore need code to upgrade the DB, so I should push those changes out
sarangthe call it the embargo timer
vtnerdit is also probably worth breaking that review into at least one other PR to make it easier to review. otherwise, after the next push I'll do, it would be considered stable if anyone was willing to run it
dEBRUYNEvtnerd: Talking about lightservers, have you seen knaccc's proposal to improve privacy? https://github.com/monero-project/monero/issues/5145
vtnerdit seems like most people won't run it until has builds _somewhere_, so yeah I dunno
knacccit's more random thoughts than a proposal :) it's far from a perfect solution
vtnerdI'm not sure what knacc was proposing with that really. Limiting the leaks of subaddress info I guess?
knacccit means that light-wallet servers can't know the amounts of any outputs, even if it knows which outputs the connecting user owns
knacccand also can't know which outputs the user owns, if it's fully implemented
vtnerdthat would require a hardfork protocol change
knacccyes, that's one of the many reasons it's far from perfect
vtnerdso - just forward all txes to the frontend for scanning. Thats alwasy been a proposal, and can be done with monerujo or similar right? The only advantage is eventually coming up with a faster/"lighter" protocol format
knacccwell just changing the way that output amounts are encrypted so that the lightwallet can't know which users are rich would be quite good
knacccit would mean light-wallet servers could not be required to report high value accounts
knacccagain, to be clear, i'm not proposiing people consider this seriously for implementation. it's just to spark thoughts that could lead to perhaps even better ideas
moneromoooDoes anyone have anything they want in 0.14.1.0 that's not PRed yet ?
sarangAre we doing anything with output selection?
sarangRight now the selection algorithm selects outputs with poor weighting (relative to block density)
sarangthis leads to, for example, overselection of coinbase
sarang(apologies if this already appears in a PR that I haven't seen yet)
moneromoooIt does not. Last I knew it was waiting for more analysis.
sarangand I was waiting to hear what analysis people actually wanted
moneromoooAnd also there was this tantalizing comment about the numerical instability only applying to one way of doing the right thing…
sarangI still strongly suspect that a discrete density-weighted block selection will yield statistically the same results
moneromoooWell, as far as I'm concerned, it it makes things substantially better, I'm for adding it. We can always re-improve it again later.
sarangbut I don't have an efficient and stable way of doing that right now
sarangOK
sarangI request additional eyes on the algorithm
sarangIt's the output_lineup method from these simulations: https://github.com/SarangNoether/skunkworks/blob/outputs/outputs/simulate.py
moneromoooOh, there was also talk of making the scaling dependent on the last year or so, rather than the full chain.
sarangThis is tuneable in the simulation
sarangand I agree that it's a good modification
oneiric_sarang: select_lineup? #L128
sarangWhoops, yes, thank you
oneiric_np
sarangthe statistics relating to output types refers to the size of the block (in outputs) from which the draw occurred
sarangso a type-1 output is always coinbase (but not vice versa)
sarangNo output selection algorithm performs ideally under all possible chain conditions
sarange.g. if transaction volumes plummet for an extended period
sarangbut I believe that the lineup method does the most reasonable job under most conditions
sarangIf someone has an efficient way to do a gamma CDF (which would allow a direct discrete weighting of block selection by their size/density) please let me know
oneiric_what are the failure conditions? how bad is the failure if it happens (compared with alternatives)?
dEBRUYNEWe're a bit over time, so I kind of want to wrap this up. Does anyone have anything else to add?
dEBRUYNE(discussions can of course continue after the meeting)
sarangoneiric_: try the feast or famine conditions
moneromoooFWIW, the CDF can be calculated only every, say, 1k blocks. Then interpolation.
sarangI wonder how quickly that breaks down for the head and tail of the distribution
sarang(which would affect the ability to spend very new or very old coins)
sarangI am very open to a discrete CDF method if it performs better than lineup
moneromoooTail, likely nothing. But yes, it probably warrants having more samples at the head.
dEBRUYNEGoing to call the end of the meeting. Thanks all for coming and providing input!
Sources and notes
- Meeting log: Overview and Logs for the Dev Meeting Held on 2019-03-31, getmonero.org. The official post carried the raw log and pointed readers to Hello Monero for the overview.
- Original Hello Monero URL slug recovered from the Wayback Machine index; the original page content did not survive, so this reconstruction carries the log as archived by the Monero Project.