Skip to content
Snippets Groups Projects
Commit c682d898 authored by luigi1111's avatar luigi1111
Browse files

Merge !1005 

Latest MRL meeting logs (2019-02-04/11/25)

See merge request !1005
parents 8f7ef181 5a07115d
No related branches found
No related tags found
1 merge request!1005Latest MRL meeting logs (2019-02-04/11/25)
Hide whitespace changes
Inline Side-by-side
_posts/2019-02-04-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-02-04.md 0 → 100644
+ 345
− 0
View file @ c682d898
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-02-04
summary: Network upgrade, MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** OK, let's begin
**\<sarang>** 1. GREETINGS
**\<sarang>** hello everyone
**\<ArticMine>** Hi
**\<sgp\_>** hello!
**\<Xeagu>** Hey!
**\<chron0>** oi
**\<sarang>** a special ping to moneromooo as well, since he has a PR that I wish to discuss
**\<sarang>** Since it approaches, let's discuss 2. NETWORK UPGRADE REVIEW
**\<xmrmatterbridge> \<serhack>** Hi!
**\<sgp\_>** we know the topic is important since it's in ALL CAPS
**\<suraeNoether>** hi guys!
**\<sarang>** As linked in the agenda, the current plan for payment IDs has been subject to much discussion, so please read through the notes at that link
**\<sarang>** I don't want to discuss opinions on that at this meeting, only to remind of what the timeline has been
**\<needmoney90>** Hey!
**\<sarang>** Of more pressing interest is the block size algorithm
**\<Mochi101>** You guys going to introduce more tools for sub-addresses too?
**\<Mochi101>** Like being able to query last sub-address generated?
**\<sarang>** You may recall that we were looking at a few different options for block size scaling, to allow for growth while protecting from cheap spam
**\<suraeNoether>** for the audience: The current pull request for changing the dynamic block size adjustment method is proposed by ArticMine (see PR 5124 here: https://github.com/monero-project/monero/pull/5124/files ) and it occurs to me that we are intricately in the weeds of fees, incentives, and block sizes right now.
**\<sarang>** Mochi101: probably better for #monero-dev
**\<Mochi101>** ah ok
**\<suraeNoether>** I have concerns about this proposal for a few reasons.
**\<sarang>** The reason I bring this up is because we have essentially two methods on the table: a simple dual-median approach, and the one linked in the PR which uses a long-term median weighting
**\<sarang>** The PR contains moneromooo's implementation of the latter
**\<ArticMine>** Actually There were 3 option for block weight scaling
**\<ArticMine>** That were formalized
**\<ArticMine>** 1) The double median
**\<ArticMine>** 2) The double median with smooths change
**\<sarang>** Please remind the room of the change for (2)
**\<suraeNoether>** ^ thanks sarang :P
**\<ArticMine>** 3) My last proposal that moneromooo implemented in PR 5124
**\<suraeNoether>** i far prefer the dual median approach than PR 5124
**\<ArticMine>** In the first option the full blockweight including the burst portion was used to scale the long term median
**\<ArticMine>** This allowed the burst to work with scaling but had the problem of using the entire burst to scale the long term median
**\<suraeNoether>** PR 5124 concerns me for a couple of reasons. firstly, demonstrating the long-term stability of it... proving that stability... is difficult, and finding parameters that seem to be good is an exercise in hand-tuning. additionally, it's not clear what we gain from using the more complicated method in the short term. if we are pushing more complicated code, it should be because we have a clear advantage from
**\<suraeNoether>** using it, some clear efficiency or security gain
**\<sarang>** Given an unbounded adversary, all proposals allow chain bloat of O(10-100 GB) over, say, a weeklong sustained max-bloat attack
**\<sarang>** With resulting block sizes 15-30 MB
**\<suraeNoether>** how much does it cost to do that in all the proposals?
**\<ArticMine>** 2) smooth's modification was to not use the 50x burst in scaling the long term median
**\<suraeNoether>** if all proposals have the same total consequence for the blockchain and the same approximate cost for the attacker, there is zero reason to use something complicated instead of something simple.
**\<sarang>** O($1-10 M) depending on whether you assume the miners are purely breaking even or not
**\<sarang>** Under ArticMine's 4x-rational-miner assumption, they scale 4x from that
**\<ArticMine>** This had the serious problem of killing the burst over time.
**\<moneromooo>** If all proposals have the same total consequence for the blockchain and the same approximate cost for the attacker, then you use "normal use" behaviour to select which one is the best.
**\<moneromooo>** It's not enough to resist attacks, it must also be useful for normal use.
**\<ArticMine>** My final proposal addressed the problem in both 1) and 2) b only using the portion of the block weight that would have been allowed under the long term median to scale the long term median
**\<sarang>** ArticMine: does moneromooo's code accurately reflect your proposal?
**\<sarang>** And does my Python code?
**\<sarang>** I want to make absolutely sure we are all operating on the same assumptions for bloat and cost possibilities
**\<sarang>** Otherwise we are debating unknowns
**\<suraeNoether>** ^
**\<moneromooo>** The python code I saw from... sarang I assume, can't recall now :) and my code agreed on the results when pushing blocks with the max allowed weight.
**\<moneromooo>** Also agreed with some python code I made.
**\<sarang>** For example, a recent change in minimum fee computation to include the long-term weight (and not short-term median) switches from applying the 4x penalty to using the min fee, for example
**\<ArticMine>** sarang Your python code uses the penalty rather than 4x the penalty
**\<sarang>** and that spiked the total cost
**\<suraeNoether>** i am so wildly uncomfortable with this conversation, tbh
**\<ArticMine>** But it was switched to 4x penalty
**\<sarang>** Let's assume we are all talking about this paste: http://paste.debian.net/hidden/292e473f/
**\<sarang>** Note line 56 please
**\<Xeagu>** Whatever is implemented should have a clear way to explain to the rest of the ecosystem.
**\<sarang>** It used the short-term median in the min fee computation, but was changed in line 57 to the lt-weight
**\<sarang>** This spikes the total cost by order of magnitude, so clearly it means the min fee is applying, rather than the 4x penalty
**\<sarang>** We should ensure that we are clear of this
**\<sarang>** \*clear on this
**\<sarang>** So my current questions are: ArticMine is this your intention? moneromooo is the current paste (not the commented-out line) what is in the PR?
**\<moneromooo>** AFAIK, yes.
**\<ArticMine>** The past reflect the rational miner so yes
**\<ArticMine>** paste
**\<moneromooo>** I do not agre with the rational miner comment though :P
**\<sarang>** ArticMine: what about the difference between lines 56 and 57?
**\<moneromooo>** A rational miner would also accept smaller fees, unless I can be convinced otherwise.
**\<sarang>** That has a \_massive\_ effect on the cost assumption
**\<ArticMine>** The difference is between 4x penalty and 1x
**\<sarang>** No
**\<sarang>** The difference between 56 and 57 is in how the min fee is scaling
**\<sarang>** the penalty applies in the next line
**\<suraeNoether>** there has not been an effort to formalize the design goals of our blocksize adjustment algorithm, so even if we have a new proposal, all we do is say "hmm, how fast can the blockchain grow? hmm how much does that cost?"
**\<suraeNoether>** we may as well be picking random functions and seeing if they do what we want them to do, if we aren't going to start with design principles or urgent needs first and move forward from there.
**\<suraeNoether>** With that in mind, our primary urgent need is to prevent a bloatocalypse before the next fork. Keeping next block size at something like R\*Median(N) is still rational, we just need to boost N and decrease R to make it so that 6 months can't give us more than a certain growth over the trendline, selecting N to dictate how long the attacker needs to blow fees.
**\<oneiric\_>** what is the practical urgency of implementing one of the suggested modifications to blocksize adjustment?
**\<suraeNoether>** in the meantime, I am willing to make a formal bet that the only reason we could possibly need a 50x boost in block size in the next 180 days is a bloat attack. i see no good reason to take the short-term xmas day factor into account for this immediate next hard fork, for a lot of design reasons
**\<ArticMine>** No it is not
**\<suraeNoether>** ArticMine: ??
**\<ArticMine>** The urgency here is questionable at most
**\<suraeNoether>** ArticMine: i absolutely disagree
**\<oneiric\_>** so postponing for 1-2 forks is not the worst-case scenario?
**\<suraeNoether>** i don't want to be chicken little here
**\<suraeNoether>** the sky is falling yada yada
**\<suraeNoether>** but guys, for essentially the cost of an apartment building, someone could take the monero blockchain and make it bigger than ethereum's
**\<suraeNoether>** i find this to be an intolerably insecure property of our block size adjustment algorithm
**\<suraeNoether>** it's a whim for the winklevii
**\<ArticMine>** If we rush into this without taking into consideration the implication on Monero ability to scale we can destroy a critical component of Monero's social covenant
**\<ArticMine>** Or cripple it
**\<suraeNoether>** ArticMine: our social contract is to ensure that our currency remains functional
**\<suraeNoether>** a 160GB blockchain is not functional
**\<ArticMine>** It has been functional for 4 years
**\<moneromooo>** The fees were just dropped to ~nothing recently though.
**\<oneiric\_>** is there any indication that 160GB is near?
**\<suraeNoether>** "the attack hasn't happened yet" != "the attack will not happen or is not incentivized to happen"
**\<xmrmatterbridge> \<serhack>** ArticMine: Yes, but that does not mean that could work for the next years.
**\<moneromooo>** Actually I take that back. It was still the same penalty.
**\<suraeNoether>** since any change we make in this fork can be undone in the next fork, your argument about long term scaling and the social contract doesn't hold up
**\<ArticMine>** This is a theoretical attack that is more expensive than a 51% attack
**\<Xeagu>** Do we have simulations of upper bound organic growth in x time? Say Monero gets added to Open Bazaar or something - what is the realistic transaction growth we might expect?
**\<suraeNoether>** it's about as expensive as a 51% attack, with the difference that it requires no hardware
**\<suraeNoether>** xeagu no, we have no data on adoption rate into new markets, although we could ballpark some estimates of what we think are reasonable, we are still just hand-tuning our approach
**\<ArticMine>** a 515 attack include the cost of hardware
**\<ArticMine>** 51%
**\<suraeNoether>** ArticMine: in order to pull off a 51% attack, i need i) the money and ii) some miners willing to take my bribe at the cost of the value of their xmr
**\<suraeNoether>** in order to do a bloat attack, i just need a bunch of xmr outputs
**\<ArticMine>** You have to pay for both
**\<suraeNoether>** so the cost may be equivalent in terms of USD, but the social friction to one attack is much lower compared to the other
**\<Xeagu>** One is permissionless
**\<ArticMine>** So it the other
**\<ArticMine>** is
**\<suraeNoether>** ArticMine: nah, you need to go find miners to work with
**\<ArticMine>** Rent the hard ware
**\<suraeNoether>** even if you have to spin up AWS, that means you have to go through amazon
**\<suraeNoether>** that isn't permissionless
**\<suraeNoether>** anyway
**\<ArticMine>** or buy it
**\<suraeNoether>** we are going down a rabbit hole
**\<sarang>** OK, so
**\<suraeNoether>** I'm advocating that we merely modify our growth rate and sample size and then spend the next 6 months making a non-rushed decision
**\<sarang>** What is on the table right now is a proposed PR, which you may or may not think is too complex
**\<sarang>** I want to know that PR 5124 matches the linked paste
**\<sarang>** and that the cost computation in the paste is accurate
**\<sarang>** then we \_at least\_ know what the cost and bloat effects of 5124 are
**\<ArticMine>** My point is we have created artificial urgency and as a consequence could destroy a critical component of Monero
**\<suraeNoether>** articmine: tweaking R and N can not destroy a critical component of monero
**\<suraeNoether>** but implementing a complicated blocksize adjustment algorithm with 18 parantheses that is hard to intuit or reason about? that could.
**\<ArticMine>** That is the trouble with the artificial urgency
**\<suraeNoether>** okay, i said my piece
**\<moneromooo>** Having ArticMine's change in does not prevent it being changed later if something more appropriate is found. Which may be the case if suraeNoether does the study he advocated earlier.
**\<sarang>** I am currently advocating for nothing, since I have received no satisfactory guidance about whether 5124 matches the numbers we have been basing assumptions on
**\<ArticMine>** I am in the process of evaluating just that
**\<moneromooo>** It matches the numbers for max sized blocks.
**\<moneromooo>** I did not try non-max size blocks though. I will try that.
**\<sarang>** ty ArticMine. In particular: please try switching between lines 56 and 57 and note the cost change
**\<sarang>** and ensure we are comfortable with that
**\<ArticMine>** In hour paste
**\<ArticMine>** your
**\<sarang>** moneromooo: right, the question is fee and cost, not blocksize, between those lines' changes
**\<Xeagu>** If we implement ArticMine's change, can we also come up with a ELI5 explanation of what is going on?
**\<sarang>** ArticMine: yes, 56-57 in my paste, linked again here: http://paste.debian.net/hidden/292e473f/
**\<sarang>** Xeagu: yes
**\<moneromooo>** Oh OK. I did not do anything with fee with my code.
**\<sarang>** moneromooo: you had specifically requested the line 57 change
**\<sarang>** IIRC
**\<moneromooo>** s/do/test, log, etc/
**\<moneromooo>** Yes, the change is what ArticMine suggested a while back to make the attack more expensive.
**\<moneromooo>** (and I do not agree it does make it more expensive fwiw)
**\<moneromooo>** That change is what the second commit in 5124 does.
**\<ArticMine>** Yes 57 addresses maintenance cost of keeping the locks bloated
**\<ArticMine>** Which is what I recommended
**\<sarang>** OK, so in your opinion ArticMine, running that paste in its current form will provide the cost to an attacker, assuming rational miners
**\<sarang>** ?
**\<ArticMine>** Yes
**\<sarang>** thank you
**\<sarang>** note to moneromooo ^
**\<moneromooo>** who still does not think it works
**\<sarang>** At least we agree on the final bloat and blocksize :/
**\<sarang>** (using the "attacker with infinite money and rage" model)
**\<ArticMine>** This all comes back to suraeNoether point what are our design parameters?
**\<sarang>** We have not formally defined them
**\<suraeNoether>** after the meeting i'm going to host an impromptu brain session on that i think articmine
**\<Xeagu>** Fwiw none of these measures seem to prevent slower bloat with min fee txs flooding the mempool and eventually getting confirmed over time
**\<ArticMine>** Yes
**\<suraeNoether>** i have some formal ideas
**\<sarang>** OK, so let's move on for now perhaps. Right now we have the current scheme, and the PR, and a dual-median idea that's not in a PR
**\<sarang>** After meeting, more discussion
**\<sarang>** Output selection is also being worked on, with no final changes yet
**\<sarang>** The idea being to weight block selection for ring decoys by the number of outputs, consistent with our gamma spend distribution
**\<suraeNoether>** isthmus and i had some discussion on output selection
**\<ArticMine>** If we are trying to minimize the risk of bloat without any other considerations then we end up destroying the adaptive blocksize
**\<sarang>** ArticMine: let's discuss after meeting
**\<ArticMine>** Sure
**\<sarang>** Please go ahead with output selection suraeNoether
**\<suraeNoether>** one thing isthmus pointed out is the classic problem with multi-input transactions
**\<suraeNoether>** for example, if I produce a ring signature with ring {A, B, C} and a ring signature with ring {D, E, F} in the same transaction, and A and D both have the same age, then it's "obvious" who the true spender is
**\<suraeNoether>** or rather, allows for heuristic'in
**\<sarang>** monerocoinjoin helps to break this, fwiw
**\<suraeNoether>** and after more and more discussion, i'm finally coming around on the idea of binning inputs
**\<suraeNoether>** sarang ^ yes
**\<sarang>** s/helps/could help someday
**\<sarang>** The major issue at hand \_that was recently introduced\_ is biased coinbase selection (and biased selection in general)
**\<Xeagu>** Input age heuristic for multi ring transactions is an interesting consideration
**\<Inge->** 18:25 < ArticMine> is
**\<sarang>** IMO we should iteratively first focus on removing some of the selection bias, and then later move to address other multi-in heuristics
**\<Xeagu>** Got it
**\<sarang>** Is there opposition to a move to a weighted selection that accounts for this bias?
**\<Xeagu>** What is the biased coinbase selection problem?
**\<sarang>** If you select a block and then an output within it, you are likely to have bad distributions that aren't representative of the whole chain, due to variance in block sizes
**\<moneromooo>** The fewer outputs in a block, the more likely they are to be chosen as fake outs.
**\<sarang>** If you weight based on # of outputs, you can remove this
**\<sarang>** doing it efficiently is the tricky part, due to the gamma requirement
**\<sarang>** I only bring it up here to see if there is opposition to moving to such an approach, and then later continuing to iterate if needed
**\<Xeagu>** It's almost like you need extra decoy outputs as padding in each block so there is not much variance in total outputs between blocks
**\<suraeNoether>** i can spend about 30 minutes today writing up some pseudocode if that helps with the distribution stuff...
**\<sgp\_>** I think it's a good stopgap
**\<suraeNoether>** xeagu no, extra decoy outputs have their own security problems
**\<moneromooo>** No. Do not spam the chain.
**\<suraeNoether>** ^
**\<sarang>** Xeagu: we really don't
**\<sarang>** weighting accounts for variance
**\<sarang>** that's the point
**\<Xeagu>** Noted
**\<sarang>** suraeNoether: please write up your pseudocode ASAP, and I will as well
**\<sarang>** this is not consensus, but the upgrade is a good time to do it if possible
**\<suraeNoether>** yeah, essentially, for the stats nerds in the audience
**\<moneromooo>** If someone tells me how to calculate the gamma CDF (or something that's close enough), I can do that code. It's the only thing I'm missing.
**\<sarang>** moneromooo: this assumes you're recalculating the product (this block's gamma factor)\*(this block's weight) for each block, every time a new block arrives?
**\<sarang>** that was the inefficiency I wanted to address
**\<moneromooo>** Every time someone wants to make a tx. Which is hopefully less often.
**\<sarang>** OK, but it's for the entire chain?
**\<moneromooo>** OK. Good to have if you can, sure.
**\<moneromooo>** Yes.
**\<sarang>** got it
**\<sarang>** there was talk about a cutoff point, but that renders old outputs detectable
**\<moneromooo>** Well, technically the whole chain since rct started.
**\<sarang>** heh sure
**\<suraeNoether>** we are transitioning from "drawing randomly from an ideal distribution ignoring the current blockchain state (in terms of density of txns per block)" to "drawing randomly from a partially empirical distribution based both on an ideal distribution and the observation of the current blockchain state.
**\<sarang>** so in fact that does allow a cutoff of sorts...
**\<sarang>** Cool, we shall prioritize that to get it in before freeze
**\<sarang>** Let's move to 3. OTHER WORK
**\<sarang>** I continue to work on a few things listed in the agenda
**\<moneromooo>** I'll use some interpolation as smooth suggested, so you'll have to calc gamma for 1/100 points or whatever in practice.
**\<sarang>** in addition to the upgrade items
**\<suraeNoether>** but i do want to go back to the multi-input thing this week, because i think it's a critical security concern that we have merely gotten used to because we've known about it for awhile and didn't have a solution for... but we have more pressing stuff to take care of immediately
**\<sarang>** Yes we do
**\<sarang>** an interesting point is Dandelion, which I've been looking into more deeply
**\<oneiric\_>** ^
**\<sarang>** there was talk among btc devs about possible DoS avenues in the stem phase of routing
**\<suraeNoether>** the more i read about dandelion++ the more i like it, but hte more i wish they stuck with a single +
**\<sarang>** having to do with the mempool
**\<sarang>** These may not apply to us, but I'm reading up on their concerns
**\<sarang>** They also had issues relating to unconfirmed txs relying on each other that we don't care about
**\<sarang>** Any specific questions for me regarding my agenda-listed items?
**\<sarang>** My first priorities are upgrade items, of course
**\<Xeagu>** Not mentioned is mining algo. Is that planning on being changed next fork?
**\<sarang>** yes
**\<moneromooo>** Yes.
**\<sarang>** details tbd
**\<Xeagu>** Got it
**\<oneiric\_>** are the candidates known atm?
**\<sarang>** I also consider that outside the scope of this room, for the most part
**\<sarang>** I hear CN-R with tbd tweak(s)
**\<oneiric\_>** thanks sarang
**\<sarang>** OK, suraeNoether ?
**\<sarang>** your updates?
**\<suraeNoether>** Well, I finally realized how to formally hypothesize about the EAE attack in the bipartite graph setting for MRL11, which has allowed me to start writing up simulations
**\<sarang>** neat!
**\<suraeNoether>** basically: i'm assuming blocks arrive one at a time linearly for the sake of simplicity, i assume transaction density in each block is poisson distributed, and i assume each transaction is M-in, N-out according to some distribution I haven't selected yet (but will probably be empirical from our blockchain)
**\<suraeNoether>** I do this for a number of blocks T, to simulate a fake blockchain that exists before the game begins
**\<suraeNoether>** then, in addition to the random block density I just described, a single user is going to churn K times
**\<sarang>** What timing distribution?
**\<suraeNoether>** the wallet distribution
**\<sarang>** define plz
**\<sarang>** I mean, how often do they churn?
**\<suraeNoether>** oh, i'm going to explore that as a parameter with K=1 to K=15 or so
**\<sarang>** roger
**\<suraeNoether>** then i'm going to run the matching algorithm and see the probability that the person "gets caught" meaning their transactions are labeled/matched
**\<sarang>** sweet
**\<suraeNoether>** we already have ideas on timing, so we can figure out how this scales to a big parallel process, and we can generate a confusion table
**\<moneromooo>** Is this the same thing as a confusion matrix ?
**\<suraeNoether>** yeash
**\<suraeNoether>** yes\*
**\<suraeNoether>** so the idea is to ask the question 'under certain user behavior, which is what we recommend for churn, what sort of security can someone practically expect?'
**\<suraeNoether>** concretely
**\<sarang>** Awesome, please keep us updated on the sim results. This will be very useful to those needing to churn safely
**\<suraeNoether>** i also have an alternative model where only coinbase outputs are added to the system but they get sent with wait-times equal to the wallet distribution also
**\<suraeNoether>** will do
**\<Xeagu>** You testing if there is a limit to churning that begins to weaken security?
**\<suraeNoether>** xeagu trying to formalize "how much should you churn for the following security level"
**\<Xeagu>** Got it
**\<suraeNoether>** it'd be interesting to see if churning too much gives it away
**\<suraeNoether>** which is an old hypothesis of mine :D
**\<sarang>** Anything else you're working on?
**\<suraeNoether>** the blocksize dynamic adaptability problem, of course, and my December + January end of month report
**\<sarang>** Neat
**\<suraeNoether>** i like giving plenty of time for comments. \*cough\*
**\<sarang>** Before we review action items, any specific directed questions, or other work to share?
**\<suraeNoether>** oh i read a paper
**\<suraeNoether>** oh oh
**\<needmoney90>** Have you considered the alternative funding avenue discussed in Palo alto?
**\<suraeNoether>** https://eprint.iacr.org/2018/379
**\<sarang>** our old friend Liu
**\<sarang>** needmoney90: remind the room of this funding avenue
**\<needmoney90>** Patreon or a similar system
**\<suraeNoether>** oh yes
**\<needmoney90>** With the unfunded part going to the MFS
**\<needmoney90>** Gives more assurance of future funding
**\<sarang>** It would increase the funding timeline
**\<suraeNoether>** needmoney90 brought up the idea of doing a patreon for MRL so that researchers can get a little bit of reliability in getting paid in USD
**\<sarang>** Keep in mind we can now also request immediate MFS payout if this is clearly stated
**\<suraeNoether>** i honestl haven't thought about it much, but the centralization risk of going through patreon is a concern... even though it's mitigated by the MFS
**\<sarang>** suraeNoether: nobody has to use patreon
**\<sarang>** they can donate via mfs
**\<needmoney90>** Yup, this prevents the whole 'Will we get funded' thing, where you know you have a baseline level of contribution even if the MFS falls through
**\<moneromooo>** What is MFS ?
**\<sarang>** Nice. I'm not opposed to it as another option
**\<sarang>** apparently the renaming for NewFFS
**\<needmoney90>** Monero funding system
**\<needmoney90>** It's no longer on a forum
**\<sgp\_>** I thought it was the CCS
**\<sarang>** -\_\_\_\_\_-
**\<needmoney90>** No one told me :(
**\<Xeagu>** For F\*\*\* Sake I liked FFS
**\<sarang>** Anyway
**\<oneiric\_>** lol
**\<sarang>** To keep things tight, 5. ACTION ITEMS
**\<sarang>** Deciding on block size algorithm, if any, should be a priority
**\<sarang>** otherwise nothing will happen
**\<sarang>** After meeting will be a chance to discuss formal requirements for this
**\<sarang>** Next
**\<sarang>** suraeNoether and I have different ideas on weighted output selection that need to be tested and shared for possible inclusion in the upgrade
**\<sarang>** suraeNoether will be working on churn sims
**\<sarang>** I will be trying my darndest to get back to the bulletproofs MPC, and understanding DoS risks in Dandelion routing
**\<sarang>** Any last comments before we officially adjourn?
**\<oneiric\_>** what are the chances of something like the btc key-reuse in monero?
**\<sarang>** what does this mean
**\<oneiric\_>** there was that paper recently about computing btc addresses iirc
**\<moneromooo>** About weighted output selection: if I have the code for calculating gamma before any fancy opt is found, I can add the code already. Then add the fancy opts on top.
**\<sarang>** ty moneromooo
**\<sarang>** oneiric\_: linkylinky
**\<sarang>** We can at least get a series approximation for later interpolation
**\<oneiric\_>** https://eprint.iacr.org/2019/023.pdf
**\<sarang>** any bias in that approximation will be a wash
**\<sarang>** Ah yes. Don't use silly RNGs
**\<moneromooo>** I'm fine with a way to compute an approximation.
**\<oneiric\_>** right, but is monero vulnerable to that style of attack?
**\<sarang>** Thanks, everyone. Meeting adjourned
_posts/2019-02-11-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-02-11.md 0 → 100644
+ 259
− 0
View file @ c682d898
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-02-11
summary: Network upgrade, MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** 1. GREETINGS
**\<sarang>** What a day; hello
**\<Xeagu>** Hey everyone
**\<oneiric\_>** hallo
**\<suraeNoether>** howdy
**\<ArticMine>** hello
**\<sarang>** I have not been able to follow the last couple of days' updates (was involved in an accident) but much has happened
**\<sarang>** Leading us to 2. NETWORK UPGRADE
**\<sarang>** A surprise announcement in -dev yesterday means the upgrade is set for earlier than had been expected
**\<sarang>** There is not currently a good central resource for what exactly is changing
**\<sarang>** Anyone with knowledge is welcome to summarize here
**\<sarang>** We should all be on the same page when asked
**\<moneromooo>** new PoW, new block weight algorithm, more notifications, payment id changes, ability to spend unmixable outs (broke at v10) and smaller ringct sigs.
**\<moneromooo>** s/v10/v8/
**\<sarang>** Smaller sigs != changes to output structure?
**\<Xeagu>** What is the new block weigh algo?
**\<Xeagu>** \*weight
**\<moneromooo>** Yesh... it's knaccc's changes for deterministic mask and less amount bits.
**\<sarang>** ty
**\<moneromooo>** The new block weight algorithm is the one from ArticMine that has been discussed here for a while.
**\<sarang>** PR 5124 still?
**\<ArticMine>** Yes
**\<oneiric\_>** why is everything moving up, and not just pow changes?
**\<moneromooo>** Yes.
**\<moneromooo>** Because people did not want two forks.
**\<Xeagu>** Okay so future to-do is explaining that block weight algo in simple terms for the Masses
**\<sarang>** "It helps us accommodate short-term behavior while protecting against bloat"
**\<Xeagu>** I understand the why but not the how.
**\<sarang>** The how is in the PR and the Python code
**\<sarang>** You can only explain algorithm so much before you get to "look at the algorithm"
**\<moneromooo>** By allowing short term spikes but keeping a longer term median to push things down.
**\<Xeagu>** We need explainable, English terms on how the algorithm works. I believe such goals are possible.
**\<oneiric\_>** is there an option to push back the non-critical changes to a feature "fork" in summer/fall?
**\<sarang>** I'd be glad to put the Python toy code onto GitHub
**\<moneromooo>** Yes.
**\<sarang>** oneiric\_: there are non-consensus changes that will have to be deployed later
**\<sarang>** moneromooo: is there a timeline estimate for when those will go in?
**\<Xeagu>** I'll read the Python code and try to understand / explain it
**\<oneiric\_>** thinking about concentrating community review resources around pow and consensus changes
**\<sarang>** e.g. output selection, BP speedups
**\<moneromooo>** No, but fluffypony said he'd be fine doing it shortly after the fork.
**\<sarang>** At least there's no fire to get it done ASAP
**\<moneromooo>** sarang's python code's also in 5124 as a test.
**\<endogenic>** oneiric\_: it'd be helpful for wallets like mymonero as well .. i'd love if we were able to be told in a more concentrated manner what we have to remain compatible with.. it's hard to keep on top of all the changes and logs sometimes
**\<sarang>** and separately in this paste, which I'll put on github: http://paste.debian.net/hidden/c101e46d/
**\<endogenic>** mymonero's the only wallet that actually reimplements Monero rather than uses wallet2 directly afaik though
**\<moneromooo>** endogenic: all the consensus changes are included in the magic-beans-0.13 branch.
**\<endogenic>** that's a lot of code to review though..
**\<endogenic>** and it's not clear what's a blocker / compat issue
**\<moneromooo>** I'll list the commits you have to care about:
**\<endogenic>** just from a review
**\<Xeagu>** I'd also like to understand the payment id changes
**\<sarang>** 1. Avoid encrypted payment IDs. 2. Really avoid unencrypted payment IDs
**\<moneromooo>** 5818191fd2a47246b26cdc1f67a9a500d26ea2ac 81cb665926bce82c3e89977c33c6d4230a427362 dddebcf92437c93e94f65ea9594c1fb797e4f4b8 3472e6d196a2bf86289a86035d916c84e11136ea
**\<moneromooo>** That should be pretty minimal.
**\<moneromooo>** endogenic: ^
**\<endogenic>** thanks mooo - lifesaver as usual
**\<sarang>** sgp\_ is working up a formal announcement
**\<Xeagu>** sarang: so this is part of phasing out payment ids?
**\<sarang>** but an earlier draft of it was incorrect
**\<sarang>** Xeagu: sure
**\<endogenic>** it could be good for the growth of the ecosystem to have a central place to post these sorts of things
**\<suraeNoether>** xeagu: presently we allow any sort of payid, either encrypted or unencrypted, or people can use subaddresses instead. for reasons including elegance and "we want our transactions to be indistinguishable from each other" we are pushing to get rid of both encrypted and unencrypted payids, since subaddresses technically can hit all the same use cases
**\<suraeNoether>** endogenic: i agree
**\<Xeagu>** suraeNoether: golden. Thank you
**\<sarang>** So if anyone asks, this decision was made after some private discussion between Core Team and select devs
**\<moneromooo>** About payment ids, the changes \*in this coming fork\* are: make it annoying to specify a long payment id, and auto include a short one if none is used.
**\<Xeagu>** Ability to spend unmixable outputs? What does this mean?
**\<sarang>** I presume we can/should point affected parties to -dev for more details
**\<sarang>** I believe this only affects certain pre-CT outputs
**\<sarang>** (i.e. denominated outputs)
**\<ArticMine>** This was broken recently?
**\<moneromooo>** It means that if you have an unspent pre-rct output of amount A, and the chain has fewer than 11 outputs of this amount, you could not spend it (bug). This is now fixed.
**\<Xeagu>** Got it. This makes sense.
**\<moneromooo>** It was broken when the ring size was fixed at 11. I did not leave a special case for these.
**\<sarang>** Xeagu: most users would have been unaffected by this, and now nobody will be affected by it
**\<ArticMine>** That makes sense
**\<sarang>** Any other questions for moneromooo/ArticMine regarding the accelerated upgrade?
**\<endogenic>** mooo, as well, not having these things in the monero-project repo can be very confusing for many
**\<Xeagu>** Cool. And finally smaller ringct sigs. This is intuitive.
**\<moneromooo>** endogenic: I don't understand, can you rephrase ?
**\<suraeNoether>** i have questions about the block size thing but i'm either going to wait till later today or take it to PM with AM (hahhah)
**\<endogenic>** moneromooo: as they're in your fork
**\<sarang>** suraeNoether: can you give the gist of your question at least?
**\<moneromooo>** Those patches are also all in master.
**\<sarang>** Unless it isn't relevant to the group
**\<endogenic>** oh
**\<moneromooo>** er, no
**\<moneromooo>** Sorry. Either in master or in PRs :)
**\<endogenic>** hmmm
**\<sarang>** The formal writeup should include the PR numbers
**\<moneromooo>** I think only ArticMine's changes are yet to be merged.
**\<sarang>** Or moneromooo will end up repeating himself many times
**\<sarang>** !
**\<sarang>** oh ok
**\<moneromooo>** Too late sarang :D
**\<sarang>** ^
**\<sarang>** OK, last call for network upgrade questions
**\<learninandlurkin>** I have question: is there any hope of having the blocksize algorithm incentivize shrinking blocksize over time when the blocks are consistently not full, before the fork?
**\<moneromooo>** No.
**\<sarang>** no
**\<moneromooo>** It was considered.
**\<sarang>** it's an interesting idea, but not tested
**\<learninandlurkin>** Fair enough. I think that would be a useful iteration on the algo for the next fork. Not critical to stopping bloat attacks I guess.
**\<sarang>** learninandlurkin: continue lurking until the next fork, and learnin :D
**\<suraeNoether>** sarang: i want a good example of a dynamical situation in which the AM method of blocksize adjustment has some desirable property over the simple two-median method
**\<sarang>** I personally like the idea, depending on the consequences of it
**\<sarang>** Ah ok, yeah probably a good question for ArticMine after meeting
**\<sarang>** (I will be interested to hear the answer)
**\<suraeNoether>** i like the idea of the incentivzation approach learninandlurkin mentions
**\<learninandlurkin>** sarang: eventually I will actually drop a nice contribution, if all goes to plan... (forever lurking and learning though)
**\<sarang>** Until then, 3. OTHER WORK
**\<smooth>** suraeNoether: what is this "simple two-median method"? I would describe articmine's method as precisely a simple two-median method
**\<sarang>** This week, I have been working on output selection, some timing information for a forthcoming paper on signatures, Breaking Monero recording, and learning from the recent Zcash disclosure
**\<sarang>** An interesting result is that, using an empirical chain distribution, a slight tweak to the output selection to use the window approach better can fix the coinbase-per-ring problem
**\<sarang>** Right now, we use a small window of blocks to pick outputs, but we don't use the entire window necessarily
**\<sarang>** If we used the entire window, it smooths the selection process much more
**\<suraeNoether>** smooth: let's carry hold on that conversation until after the meeting. block size conversations are a black hole and we want to get to other things
**\<sarang>** For this week, I will continue with output selection experiments and try to finish up the Bulletproofs MPC that keeps getting delayed
**\<sarang>** Any questions from me, before suraeNoether shares?
**\<suraeNoether>** sarang why use a windowing method instead of a precise selection method like the one I presented last week? simpler to implement given our current code?
**\<moneromooo>** There's no rush whatsoever about that BP MPC fwiw
**\<Xeagu>** I was at TabConf with Rehrar and Midipoet. More marketing than MRL but an important element of information distribution I think.
**\<sarang>** I'm not saying that I favor the full-window method as optimal
**\<sarang>** Only that it's a very simple change
**\<sarang>** it's one of several numerical experiments
**\<suraeNoether>** gotcha
**\<sarang>** So if the timeline were rushed, I'd support it as a temporary fix
**\<sarang>** But yesterday's announcement removes that fire
**\<sarang>** I'll be posting all the sims to github
**\<Xeagu>** Would planning the Monero Konference be MRL relevant?
**\<sarang>** Probably at the end, sure
**\<sarang>** or after
**\<sarang>** suraeNoether: do you wish to share now?
**\<suraeNoether>** allright, my work this past week has been 1) simulations for matching 2) computations for output selection, and 3) some proofs for a semisecret project that has an impending deadline, after which I believe it will no longer be secret.
**\<suraeNoether>** xeagu yeah that's a good meeting ender actually
**\<sarang>** suraeNoether's security proofs are related to the timing data I'm working on; it's for a paper in collaboration with other researchers that will be submitted shortly for a conference
**\<suraeNoether>** next week, sarang and endogenic and I are meeting in nashville for another monero workshop/face-to-face worktime
**\<sarang>** The secrecy has nothing to do with vulnerabilities or flaws, only professional courtesy for the submission process
**\<endogenic>** they will be doing a talk at the Nashville Blockchain Meetup as well on 2/20 for anyone interested
**\<sarang>** Will the talks be recorded endogenic ?
**\<endogenic>** at WeWork around.. i think. 5-6pm
**\<suraeNoether>** ah yeah i forgot about that
**\<suraeNoether>** i'm excited for that
**\<endogenic>** i've been trying to find out.. i think so. if not, we can get a camera
**\<sarang>** Cool. Would be fun to stream/post if it works out
**\<suraeNoether>** between now and then i have several doctor's appointments, some personal business to attend to, and immediately after that trip, i have a surgical procedure, so my presence online is going to be 50/50 over the next few days, unfortunately; my goal is to finish my matching sims before the trip to nashville, and i \*have\* to finish proofs by then
**\<sarang>** If not, oh well
**\<learninandlurkin>** If it in collaboration with another group, this means it will not be published as/with the other MRL papers?
**\<sarang>** We can certainly link to the preprint if we want
**\<suraeNoether>** learninandlurkin: this one, similar to the thring signature paper, is intended for peer review publicatin
**\<Xeagu>** I might be able to make it to the 2/20 Nashville meetup
**\<sarang>** and the preprint is always publicly freely available
**\<suraeNoether>** oh i should pick a journal and submit that this week, too
**\<sarang>** In general, we should probably submit more of our future MRL stuff to the IACR preprint archive for broader distribution
**\<sarang>** Any other questions for suraeNoether ?
**\<suraeNoether>** sarang agreed
**\<learninandlurkin>** Makes sense but I think there should be links to those papers on the page with all the MRL stuff, if possible
**\<sarang>** Yup, for sure
**\<learninandlurkin>** awesome
**\<suraeNoether>** oh, and i have a bunch of monero konferenco stuff happening this week like signing a contract for our venue and starting to nail down plane tickets for speakers.
**\<sarang>** The thing sig preprint was separately published on MRL site with our fancy logo, just for fun
**\<sarang>** Keep in mind that we generally cannot repost final journal copies of any papers
**\<sarang>** only preprints
**\<sarang>** However, we'll try to do open release with journals if it's reasonable cost
**\<hyc>** journals = racket ...
**\<sarang>** ikr
**\<learninandlurkin>** arXiv not an option?
**\<sarang>** Yes, but only for preprints
**\<learninandlurkin>** what hyc said ++++
**\<sarang>** arxiv ~ IACR
**\<sarang>** More journals are moving to open access, at least for a fee
**\<Xeagu>** I'm working on a speaker proposal submission for the Konferenco
**\<sarang>** Excellent
**\<sarang>** Anyone who wishes to apply to speak should do so!
**\<sarang>** https://monerokon.com/
**\<suraeNoether>** yep!
**\<sarang>** Any other recent research to share from anyone?
**\<oneiric\_>** cant help reading that url in cutesie anime voice
**\<sarang>** heh
**\<sarang>** suraeNoether also got conference.money and konferenco.xyz
**\<oneiric\_>** \*monero kun\* wmw
**\<sarang>** I'm shocked that conference.money was available
**\<sarang>** OK, looks like no other big research to cover. So, let's first go over action items for the week, and then open up to questions about earlier/other topics
**\<learninandlurkin>** Seperate from research: with you guys getting hit by bikes and having surgery, please take time to relax/recover. Y'all need it.
**\<endogenic>** ^
**\<sarang>** Yeah, getting hit on my bike was... unpleasant
**\<sarang>** Dealing with insurers is... also unpleasant
**\<endogenic>** are you ok, btw?
**\<sarang>** Fortunately, I'm recovering very well. Nothing fractured, just a hurt-like-hell situation for a while
**\<sarang>** moneromooo: ArticMine: anything needed from MRL for the upcoming surprise fork?
**\<Xeagu>** Lost all your private keys in a tragic biking accident
**\<sarang>** YES
**\<sarang>** I mean, NO
**\<suraeNoether>** xeagu that's what happens when you use brain wallets and then get your head knocked around
**\<suraeNoether>** lose your privkeys
**\<suraeNoether>** fosho
**\<sarang>** My action items for the week are to finalize and post the sim code for (a) block size analysis, and (b) output selection
**\<moneromooo>** I don't think so, unless you want to review the patches.
**\<sarang>** as well as the stuff for this collaboration paper (will post when the preprint is up)
**\<moneromooo>** Or suggest new unit tests.
**\<sarang>** moneromooo: got it
**\<sarang>** suraeNoether: your action items?
**\<sarang>** (I know "action items" sounds super corporate, but I find them useful)
**\<suraeNoether>** i need to finish these proofs for this deadline
**\<suraeNoether>** that's my top priority
**\<sarang>** The proofs are also interesting for our current signatures, it seems
**\<suraeNoether>** i have a few other action items, but if i get those proofs done before heading to nashville, i'll be satisfied
**\<sarang>** OK, I think that wraps those up nicely. Any questions relating to meeting topics, before we formally adjourn?
**\<oneiric\_>** does MRL have contacts in academia/industry that are PoW experts?
**\<sarang>** (formally adjourn just means "end the paste of logs")
**\<sarang>** Ooh, good question
**\<sarang>** I don't know many hardware architecture experts, personally
**\<sarang>** The ones I know of are otherwise employed
**\<oneiric\_>** would any be open to a bounty/audit-style engagement?
**\<sarang>** Hmm interesting idea
**\<oneiric\_>** even if not full-time?
**\<sarang>** What would be the timeline?
**\<sarang>** I can bring it up in other channels and see if anyone bites
**\<oneiric\_>** for this fork, too late. thinking going forward though
**\<sarang>** right
**\<sarang>** I like the idea
**\<sarang>** If the person is trusted enough not to blab to manufacturers...
**\<sarang>** Any other questions on earlier meeting subjects?
**\<oneiric\_>** maybe, proposed pow 1-2 month before impl, with minor tweaks disclosed for review 1-2 week before impl
**\<sarang>** That sounds reasonable
**\<oneiric\_>** alright, thanks sarang
**\<sarang>** Most questions on the upcoming upgrade are probably best suited for -dev, FWIW
**\<sarang>** I know nothing more than has been talked about here/there
**\<learninandlurkin>** I did ask earlier but if there's no time it's fine: I'd just like to hear MRL's opinions on multi-algorithm PoWs
**\<sarang>** I do not support such a scheme in the forms that I've seen so far
**\<strofenig>** what prevents asic building on both pow algos?
**\<sarang>** It changes the incentives, economics, and structure of attacks, often in subtle and tricky ways
**\<sarang>** A great resource is the multi-month Zcash thread on their research into this
**\<sarang>** Conclusion: not sufficiently studied or safe to deploy on their network
**\<sarang>** I believe this is the relevant thread, which is a good read: https://github.com/zcash/zcash/issues/3672
**\<learninandlurkin>** I only ask because there's some shilling of the idea and I know very little of it
**\<sgp\_>** I love that discussion
**\<learninandlurkin>** oh cool
**\<learninandlurkin>** I'll dive into that then
**\<sarang>** I recommend anyone read it before proposing such a scheme
**\<sarang>** For that topic, I like the Mencken quote: "For every complex problem there is an answer that is clear, simple, and wrong"
**\<sarang>** OK, last call for questions before we adjourn
**\<moneromooo>** Can you speed up BPs some more ?
**\<sarang>** Sigh, FINE
**\<moneromooo>** Thank you!
**\<sarang>** Thanks to everyone for attending. Logs for this meeting will be posted to the GitHub agenda issue
**\<sarang>** Feel free to continue discussion, but we are now adjourned
**\<oneiric\_>** \\./
_posts/2019-02-25-logs-for-the-Monero-Research-Lab-meeting-held-on-2019-02-25.md 0 → 100644
+ 226
− 0
View file @ c682d898
---
layout: post
title: Logs for the Monero Research Lab Meeting Held on 2019-02-25
summary: Output Selection, MRL work, and miscellaneous
tags: [community, crypto, research]
author: el00ruobuob / sarang
---
# Logs
**\<sarang>** We'll start momentarily; see agenda in topic
**\<suraeNoether>** good mooooorning mrl
**\<sarang>** Hullo all
**\<sarang>** Let's get started!
**\<ArticMine>** hi
**\<sarang>** 1. Greetings
**\<sarang>** A very talkative bunch we are today
**\<suraeNoether>** howdy :D
**\<vtnerd>** hello
**\<moneromooo>** Mooooo.
**\<sarang>** A particular topic I added to the agenda is 2. Output selection
**\<sarang>** I have a short writeup and some sim results on the agenda issue: https://github.com/monero-project/meta/issues/307#issuecomment-466514757
**\<sarang>** The problem is that our current algo overselects outputs from small blocks
**\<suraeNoether>** Sarang and I last week in person nailed down some distributional stuff for output selection and coded up a few different ways of assessing the results.
**\<sarang>** You'll see 4 different algos tested, each for 4 different chain output density scenarios
**\<suraeNoether>** each of these scenarios represents a different plausible situation our economy could undergo
**\<suraeNoether>** a feast scenario is one in which we get popular, a famine scenario is one in which monero usage drops
**\<sarang>** Under normal chain conditions, each of the 3 alternatives (the fourth is the current method) does a better job than what we have now
**\<sgp\_>** o/
**\<sarang>** Under extreme conditions, there are tradeoffs
**\<sarang>** Here is what I want to know from this group:
**\<sarang>** if the chain density hits a low point, what should selection do?
**\<sarang>** If it stays true to chain condition, we'll overselect (for example) coinbase... but if we skew to older outputs, we maintain a better weighted ratio
**\<suraeNoether>** so, here is my thinking
**\<suraeNoether>** if chain density is dropping, then spend-times are getting longer and longer
**\<sarang>** yep
**\<suraeNoether>** that's economicalliy a depression
**\<suraeNoether>** so the average age of ring members should also increase to reflect the "true" spend-time distribution
**\<suraeNoether>** on the other hand, during a feast scenario, the opposite is happening
**\<sarang>** Based on that, the output-lineup algo does a better job
**\<suraeNoether>** in that regard, it seems like the lineup method performs better htan others
**\<suraeNoether>** yep
**\<sarang>** under those extreme densities, it skews the ages
**\<suraeNoether>** btw i look at geometric as a flavor of the famine scenario
**\<suraeNoether>** oh wait, feast i mean
**\<sarang>** Geometric was intended as a 0-order approximation of real conditions; it's not very good but it's something to use for comparison
**\<suraeNoether>** in addition to comparing these different sampling methods, a method of directly estimating our true spend-time distribution occurred to me last night, and i'm writing it up now
**\<sarang>** Does anyone else have any thoughts on these?
**\<sarang>** RandomRun made a good suggestion for a more general set of quantities to test, that I'll write up and add to the table
**\<moneromooo>** Did you try the gamma \* num-outs-per-block combo ?
**\<sarang>** (see their comment on the issue)
**\<sarang>** suraeNoether worked up a version of that but was not happy with its outcome
**\<suraeNoether>** moneromooo: the lineup and bias methods are designed to estimate that method moneromooo since computing it directly runs into certain numerical problems
**\<ArticMine>** If I understand correctly chain density is a measure of velocity
**\<sarang>** chain density = distribution of number of outputs per block
**\<sarang>** I don't know how much this applies to velocity if amounts and destinations cannot be known
**\<ArticMine>** Which given a fixed money supply is a measure of velocity.
**\<sarang>** ok
**\<suraeNoether>** ArticMine: yes, although the specific interpretation of velocity is tricky in this context
**\<sarang>** Does this lead you to conclusions about how the selection should behave?
**\<ArticMine>** It relates it to market conditions
**\<suraeNoether>** yes
**\<ArticMine>** and also block weight
**\<suraeNoether>** a long spend-time distribution is a recession. a short spend-time distribution is a boom.
**\<sarang>** Unless the results from RandomRun's suggestion indicate otherwise, I'll recommend moving to the output-lineup algorithm at an upcoming release
**\<suraeNoether>** I'm also going to mess around with sampling methods, but I'm not expecting to get something that appears to perform better than the lineup method before the next fork
**\<sarang>** OK, moving on for now... related to this, from time to time there have been suggestions of whether to treat coinbase outputs differently for the purposes of decoy selection
**\<ArticMine>** My question is outliers in the spends
**\<sarang>** ArticMine: in what way
**\<ArticMine>** Namely spend that are very different from the norm at a given point in time
**\<suraeNoether>** articmine: this is the classic(tm) problem with spend-time distributions
**\<sarang>** Selecting from the best known distribution is intended to account for this as much as is reasonable
**\<sarang>** Of course, multiple rings spending outliers from the same point in time are problematic for different reasons
**\<sarang>** Any, back to the previous statement I made about coinbase outputs...
**\<sarang>** It is probable that they are spent with a different distribution that is (as of now) not tested
**\<sarang>** I don't support treating them differently
**\<sarang>** But I thought that I would mention it in the context of output selection anyway
**\<sarang>** Using a properly weighted selection algorithm will reduce their occurrence in rings as a consequence, which seems reasonable to me
**\<ArticMine>** but not their elimination
**\<sarang>** No, of course not
**\<ArticMine>** good
**\<sarang>** With the proposed algo change, their selection will be reduced toward the fraction of their occurrence on the chain
**\<sarang>** and will do the same for all outputs based on how dense their blocks are, of course
**\<sarang>** Anyway, please comment after the meeting or on the GitHub agenda issue with any other thoughts on output selection
**\<suraeNoether>** i don't support treating coinbase differently because then the next question is whether we should treat rings with ring members that come from coinbase transactions differently. and so on; the natural conclusion is to ensure transaction trees are sort of homogeneous in their depth and stuff, and that partitions the entire space way too much. it's an over-optimization with dubious benefits, imo
**\<sgp\_>** It's my opinion that coinbase outputs will never be spent in the incredible vast majority of transactions of normal users. A heuristic to eliminate the coinbase has high accuracy for anyone not suspected of mining
**\<suraeNoether>** sgp\_: high sensitivity but awful specificity
**\<sarang>** ^
**\<sgp\_>** Under normal Monero network conditions, over 75% of the hashrate is allocated to public pools. These are all transparent
**\<ArticMine>** Who then promptly spend the coinbase
**\<sgp\_>** yes, and it's clear which transactions spend the coinbase too
**\<sgp\_>** so these outputs are effectively dead
**\<sarang>** Like I said, there is probably a different spend pattern that would be interesting to examine, both in Bitcoin and in our older discernible spends
**\<sarang>** and of course the pool issue that sgp\_ mentions
**\<sarang>** Requiring a mix of coinbase-only in rings moves the problem up one level in the txn graph
**\<suraeNoether>** sgp\_: protecting coinbase transactions when miners can merely churn for almost no fees is not super rational. there will always be some effectively dead outputs. i'm much more concened about the privacy problems induced b y multiple-input trnasactions that are all spending inputs from similar time periods.
**\<sgp\_>** yes, that one level doesn't eliminate the problem, but it makes it much better than it is today
**\<suraeNoether>** sgp\_: i don't think that's been quantified, though
**\<ArticMine>** Yes but overall there is merit to including coinbase because of outliers
**\<ArticMine>** among coinbase
**\<sgp\_>** suraeNoether: I argue against protecting coinbase outputs. I want to call them all essentially transparent
**\<suraeNoether>** sgp\_: ah, i'm okay with that
**\<suraeNoether>** sgp\_: hmm wait
**\<sgp\_>** Since in most cases, the vast majority are already
**\<suraeNoether>** sgp\_: let me think about that
**\<ArticMine>** I am not so sure. In most but not all cases
**\<sgp\_>** Public pools don't care since they make the info transparent anyway. We don't need to "protect" them
**\<suraeNoether>** sgp\_: i disagree that they are essentially transparent
**\<sgp\_>** suraeNoether: why, because it's a pool-reported heuristic?
**\<suraeNoether>** no no; i mean i disagree that coinbase transactions are essentially transparent despite the public information posted by pools
**\<suraeNoether>** i can still manage to spend coinbase transactions with a high degree of plausible deniability
**\<sarang>** If their payout txns are reported...
**\<sgp\_>** Perhaps it's more accurate for me to say: we know exactly what transactions these coinbase outputs are spent in
**\<sgp\_>** Which pronounces them dead in other transactions
**\<sgp\_>** known decoys
**\<suraeNoether>** yes; i thought you were tr ying to apply the blanket term to \*all\* coinbase transactions. #notallcoinbases
**\<sgp\_>** no, only public pool transactions spending coinbase outputs
**\<suraeNoether>** o kay, so is \*anyone\* in favor of treating coinbase transactions differently?
**\<sarang>** To sum up: sgp\_ had previously advocated for a default/rule that a ring with a coinbase must contain only coinbase
**\<ArticMine>** It comes down to the outliers issue. Not all coinbase outputs are dead. With a ring size of 11 we can afford to spend 1 ring on this
**\<ArticMine>** If the ring size were say 3 I would support sgp\_s position
**\<moneromooo>** If you want to avoid pool coinbase outs as fake outs, use a blackball list with them.
**\<sgp\_>** ArticMine: in my opinion, the cost of wasting 1 ouptput per tx is worse than the harm' to solo miners if we avoid coinbase outputs entirely
**\<sgp\_>** moneromooo: we want to avoid interactivity. That's really cumbersome to expect of users, and it allows for pool fuckery if they report bad info to wallet clients
**\<sarang>** I assume moneromooo meant a blackball list with sources chosen by the user
**\<moneromooo>** People don't have to do anything. They only do anything if they want to avoid those outputs.
**\<sarang>** not some global version that can be DoS
**\<ArticMine>** But you agree tat the issue is way less wit ring 11 tan say ring 3
**\<sgp\_>** ArticMine: yes, a larger ringsize mitigates these issues
**\<sarang>** I think that the idea of coinbase-only rings deserves more careful analysis to numerically examine the benefits and chain costs
**\<sgp\_>** But I still advocate for this at any feasible ringsize
**\<moneromooo>** If it was automated and everyone was magically using that system, non pool miners would be spenidng at effective mixin 0.
**\<sgp\_>** moneromooo: yes
**\<sgp\_>** problem is unless we avoid the coinbase outputs, wallets will select this "0-mixin" outputs in their rings
**\<sarang>** I recommend we table this in the absence of any numerical evidence
**\<sarang>** but that we obtain this evidence if it exists
**\<ArticMine>** I agree
**\<sarang>** And we can discuss after the meeting (but I wish to respect our 1-hour goal and others' time)
**\<sarang>** On to 3. Other work
**\<sgp\_>** I understand your point of view sarang, but the main concept isn't very difficult. You see x% of public pools which also mine and make transparent x% of new coinbase outputs
**\<sgp\_>** but we can move on sure
**\<sarang>** I have been working on output selection, finalizing data on block size algos, gave a talk in Nashville to a meetup
**\<sarang>** One meta-item: the Loki Foundation wishes to fund me and/or suraeNoether in part for the next funding round
**\<sarang>** but it comes with a contract
**\<endogenic>** sarang's talk: https://www.youtube.com/watch?v=H8ijX02J7Y0
**\<endogenic>** surae's talk: https://www.youtube.com/watch?v=9srtIk9M2yg
**\<sarang>** I'm hesitant because I'm sure the contract terms could be abused if they were out for PR or other ends
**\<sarang>** I am going to request that the contract terms be made public, since I am not a lawyer
**\<suraeNoether>** i think that's true of any contract
**\<moneromooo>** I don't remember them as PR whores fwiw.
**\<sarang>** cool
**\<moneromooo>** I didn't exactly look for it though.
**\<suraeNoether>** however, i think we could propose amendments re: anticipated problems
**\<sarang>** I'm trying to maintain healthy skepticism while appreciating their offer
**\<sarang>** Yeah. If we can publish the contract and there are no serious objections, it reduces the community funding burden while not changing our research goals
**\<ArticMine>** Making te contract public is a reasonable approach
**\<sarang>** the total would be 15K USD, split between 1 or 2 people
**\<endogenic>** i'd suggest consulting with a lawyer about assignment of IP, non disclosure, requirements to execute things for them, etc
**\<sarang>** Yeah, they specifically don't take ownership of any research product
**\<ArticMine>** Assignment of IP?
**\<endogenic>** as mentioned when a contract is couched in consulting language they can say they had expectations of certain things
**\<moneromooo>** One fairly easy way to prevent most of that is to say "sarang can stop this contract at any time, and the pro rata is due".
**\<sarang>** but do state that if they share confidential info with researchers, it can't be discussed
**\<sarang>** So if they knew about some kind of bug, they could disclose under the contract's NDA clause
**\<moneromooo>** That is a massive no.
**\<moneromooo>** It allows them to control what you can do open source.
**\<sarang>** that's my fear
**\<sarang>** If they'll alter or remove that, it takes away most of my concern
**\<sarang>** I'll discuss with them and get the contract posted publicly
**\<moneromooo>** If they know of a bug, htey can use H1.
**\<sarang>** exactly
**\<sarang>** I wonder if it's for a bug in \_their\_ software
**\<sarang>** but anyway
**\<sarang>** This week, I'll be finishing up additional output selection tests, doing some lit review backlog, bulletproofs MPC, etc.
**\<sarang>** How about suraeNoether ?
**\<suraeNoether>** Sarang and I have a deadline of March 1 for this paper we are writing; it was previously Feb 18 but it has moved. I'm finishin g up three proofs of security for that paper, and I believe we will be making the details public soon.
**\<suraeNoether>** sarang: have we talked with our co-authors about when we can talk about this?
**\<sarang>** Ah yes, I forgot to mention that
**\<sarang>** Once it's submitted I'm sure they'll post to IACR
**\<suraeNoether>** this paper we think is rather competitive, it's proposing something novel with immediate applicability, so it should be a shoe-in for publication.
**\<koracain>** loki... wait jeff's project? oh lol that's a safe bet
**\<sarang>** Yep! Relates to the DLSAG construction but with much more on applications
**\<suraeNoether>** in addition to that, i'm simulating blockchain stuff for the matching paper to try to get that out the door
**\<suraeNoether>** i actually have a quiet week of writing for once, which is nice
**\<suraeNoether>** konferenco stuff will have some more announcmeents later this week
**\<suraeNoether>** if anyone wishes to submit an abstract to come speak, please drop one on us at https://konferenco.xyz
**\<suraeNoether>** we are working to accommodate speaker travel costs, too
**\<suraeNoether>** oh, and before I forget: the scholarship applications at MAGIC are now live, so anyone in the US, EU, or ZA who want a small scholarship to mitigate the costs of their books or whatever, swing on by https://magicgrants.org
**\<suraeNoether>** and i think that's it!
**\<endogenic>** thanks as always guys
**\<sarang>** koracain: you personally believe accepting Loki funding is a good bet? Or sarcasm?
**\<endogenic>** you're both rockstars..
**\<sarang>** Also: any other work for anyone to report?
**\<koracain>** i know one of their devs
**\<sarang>** cool
**\<suraeNoether>** oh yeah, the most interesting part of these research meetings, to me, is the folks who aren't sarang and i
**\<sarang>** Their foundation is a legally-established foundation in Australia
**\<moneromooo>** From experience, knowing a dev at one company does not mean you know what the boss will do when possible.
**\<suraeNoether>** i'm interested in how wallet dev is coming from endogenic, i'm interested in what hyc has been working on with moneroR, i want to hear from isthmus but he's usually in meetings around now
**\<koracain>** he's legit i havn't looked very hard at the project but yah lol he'd probably blow them up if they broke monero
**\<sarang>** FWIW foundation funding wouldn't change our research goals or agenda in any way
**\<sarang>** They require monthly reports, but we already do that
**\<sarang>** I'm optimistic that they just want to support Monero research since it would also benefit their project
**\<endogenic>** also when Samsung Noether
**\<sarang>** heh
**\<sarang>** that falls under 5. Questions
**\<endogenic>** :P
**\<koracain>** look hard at it but jeff is in the i2p channels on here via a relay bot
**\<sarang>** My question for moneromooo et al: when do non-consensus decisions like output selection need to be in place for an upcoming release?
**\<moneromooo>** If it's the output lining thing, I can have it done pretty quick given it's very similar to what we already have.
**\<sarang>** What is the expected timeline for a point release after the network upgrade?
**\<sarang>** A month? Two?
**\<moneromooo>** I don't think anything was even really talked about yet.
**\<sarang>** ok, wasn't sure
**\<moneromooo>** But that sounds plausible.
**\<sarang>** Well, at least the algorithm is coded up in Python already (link in agenda writeup)
**\<sarang>** so anyone can play around or test them
**\<sarang>** Real chain data is included (thanks to moneromooo for pulling that)
**\<sarang>** Other questions before we wrap up and return to informal discussion?
**\<sarang>** Righto!
**\<sarang>** 6. Action items
**\<sarang>** I will complete additional output selection testing and consider the possibilities for coinbase more thoroughly
**\<sarang>** as well as get the Loki contract squared away and the other items I listed above
**\<sarang>** suraeNoether?
**\<sarang>** Ah, and an urgent call for translations was just made: https://www.reddit.com/r/Monero/comments/auo078/urgentcall\_for\_translators\_we\_have\_two\_days\_to/
**\<sarang>** Quiet times... well, thanks to everyone for joining. We'll formally adjourn now, but feel free to continue any discussions about previous topics. I'll post logs on the GitHub issue later today
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment