07:14:26 <kgsphinx[m]> So are we going to use statistical tests and other more obvious strategies within wallets to better select outputs that are not NFTs/poisoned?   Fungibility doesn't need to be entirely compromised just because people are pooping on the chain.  Looking at the Mordinals on chain, they're pretty easy to filter out, no?  
07:17:46 <moneromooo> You don't want to make it harder to put custom data in, or people will make it harder to spot. You want to try and spot it and blackball it. That way you get more of the bad data, rather than make it harder for you to spot, while an adversary might find better ways to spot it and keep it to themselves.
07:17:56 <moneromooo> (in this particular case anyway)
07:21:50 <hyc> if they keep it to themselves, that's fine. mordinals are only a problem because their outputs are being published.
07:29:01 <kgsphinx[m]> I was just assuming that wallets could avoid choosing those outputs easily enough.  I'll have to check out some of the output selection code to understand why not.
07:53:52 <sech1> I remember we had a blacklist database of known spent outputs, and we could even feed it to the CLI wallet. Will it make sense to update the database with known Mordinals outputs (they have a specific tag in tx_extra)?
08:03:55 <moneromooo> It's being removed. Though if there some newfound use for it, it's its job, yes.
08:04:10 <moneromooo> It does require people to download and update it though.
08:14:25 <hbs[m]> sech1: I think it would be a good idea to add this feature, we could even go further and define an API so anyone could provide an "output validator" service and the wallets could connect to such services, because maybe some people have dedicated blacklists they don't want to share, or some services could gather output intelligence from multiple sources. Whether you trust or not those services would be up to each one to decide
08:14:25 <hbs[m]> though.
08:15:45 <kgsphinx[m]> There we go.
08:16:05 <sech1> wallets connecting to anything centralized for something as sensitive as decoy selection is a no-go
08:16:48 <sech1> this feature already exists, it's a matter of updating the blacklist database
08:17:03 <hbs[m]> I did not imply that such services would be centralized, just that an API would be more flexible than a file
08:17:13 <kgsphinx[m]> Yeah, not centralized, but something you could run yourself.
08:17:40 <kgsphinx[m]> Anyway, repurposing the blacklist database is a useful first step.
15:26:07 <jtgrassie> The UX for a user having to use a tool like the blackball one is horrible.
15:27:27 <jtgrassie> If we keep tx_extra, instead of blackballing we could just ignore txs that have tx_extra in decoy selection.
15:33:48 <UkoeHB> Meeting 1.5hr
15:36:33 <hbs[m]> jtgrassie: you mean which have padding in tx_extra? That will not work if we go with B3.256 though
15:45:48 <Rucknium[m]> kgsphinx: hbs: That idea could be considered, but it's not simple. There's a whack-a-mole problem. You could avoid outputs with the Mordinal tag in tx_extra. Then a change in Mordinals or something new would require a change to the criteria. And then again. And how to keep user wallets updated? Or nodes? You would have several different decoy selection algorithms being used to construct txs on chain.
15:46:20 <Rucknium[m]> The different algorithms could be used to narrow down which software version was used.
15:46:55 <Rucknium[m]> I would start with excluding coinbase outputs, personally: https://github.com/monero-project/research-lab/issues/109
15:47:14 <hbs[m]> Would constraining tags simplify things? i.e. reject transactions which have unknown tags in tx_extra?
15:47:48 <Rucknium[m]> There is no whack-a-mole there since coinbases are special and identifiable at the protocol level. Even with the p2pool upgrade, coinbase outputs are about 8 percent of on-chain outputs now
15:48:08 <hbs[m]> yes, coinbase outputs appear in most of the rings these days, with the amplification of p2pool pre HF
15:48:25 <Rucknium[m]> They would just change the tags. Whack. A. Mole.
15:49:20 <Rucknium[m]> jeffro256 said he would consider writing code to exclude coinbase outputs
16:02:39 <tobtoht[m]> It does not seem very practical to use blackballing to exclude mordinals outputs. Instead, the daemon could mark outputs that meet certain criteria in the get_outs call during tx construction. No need for users to manually keep lists updated then.
16:04:55 <tobtoht[m]> It should be default behavior, otherwise you're just fingerprinting your own transactions by specifically excluding mordinals outputs.
16:12:28 <isthmus> If we have to start building chainanalysis tools into the wallet, I think we've already lost :- P
16:36:29 <rbrunner> Nicely put.
17:00:03 <UkoeHB> meeting time https://github.com/monero-project/meta/issues/818
17:00:04 <UkoeHB> 1. greetings
17:00:04 <UkoeHB> hello
17:00:09 <vtnerd__> hi
17:00:32 <ArticMine[m]> Hi I have to leave early today 
17:00:37 <rbrunner> Hello
17:01:07 <kayabanerve[m]> Hello
17:02:01 <xmrack[m]> Hey
17:02:24 <hinto[m]> hi
17:02:57 <UkoeHB> 2. updates, what's everyone working on?
17:05:56 <xmrack[m]> The authors of the paper “Range Proofs with Constant Size and Trustless Setup" are here leonardo.mostarda emsczkp to discuss their paper and answer any questions we may have
17:06:25 <xmrack[m]> https://link.springer.com/chapter/10.1007/978-3-031-28694-0_28
17:06:45 <leonardomostarda> Hi nice to meet you all 
17:06:53 <emsczkp[m]> Hi
17:07:42 <emsczkp[m]> we are the authors of the range paper proof paper
17:08:11 <Rucknium> I am monitoring Mordinals. The mint rate has seemed to slow down over the past 48 hours. As of about 24 hours ago, total number of Mordinal txs were 24,222. Sum of Mordinal tx sizes was 202 Megabytes. Total fees to mint Mordinals was 4.05 XMR.
17:09:17 <rbrunner> Good to have you on watch :) Interesting numbers.
17:09:35 <xmrack[m]> Thanks for coming emsczkp and leonardo.mostarda! 
17:10:11 <leonardomostarda> xmrack[m]: You are welcome we are happy to clarify any doubts 
17:10:55 <emsczkp[m]> xmrack[m]: is it just chat or some kind of videocall ?
17:11:19 <rbrunner> Old school chat only
17:11:45 <blankpage[m]> It is worth mentioning that the monero community has recently raised approx 130 XMR towards peer review/audit of bulletproofs++
17:11:45 <blankpage[m]> https://ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html
17:12:11 <rbrunner> Oh, that's filled already?
17:12:18 <leonardomostarda> great!!
17:12:24 <ofrnxmr[m]> 1.x xmr away
17:12:32 <blankpage[m]> 128.67 of 130
17:13:09 <ofrnxmr[m]> leonardo.mostarda:  we are not committed to bp++, and is why we have invited you here today. Would like to hear more about your solutions 
17:13:13 <UkoeHB> re: the constant size range proof, is there a comprehensive security analysis in the works?
17:14:35 <xmrack[m]> The paper compares propf sizes with bulletproofs. I’d be curious to see how it compares to BP++
17:18:32 <leonardomostarda> <ofrnxmr[m]> "leonardo.mostarda:  we are not..." <- Our work is at preliminary stage. Our work seems to be sound and correct  the deep analysis is ongoing work in progress. However we were inspired by other works which have been proved
17:19:24 <plowsof11> bp++ author aims to have a new draft ready for April 14th, which is going to be re-looked at by CypherStack. adjusting the scope/price (as it will come with missing security proofs according to the author) 
17:19:59 <AaronFeickert[m]> The paper seems to jump from security properties of the Halo2 design to conclusions about range proof security. Do you intend to extent the security proofs to cover this?
17:20:29 <AaronFeickert[m]> On an initial read of the paper, it was not immediately clear if/why this jump should be valid
17:20:45 <UkoeHB> leonardomostarda: do you have an estimate of the relative performance for proving/verification compared to BP? e.g. as a function of crypto operations
17:20:52 <leonardomostarda> <xmrack[m]> "The paper compares propf sizes..." <- We do not know BP+ but we can compare our approach with it.
17:21:17 <AaronFeickert[m]> That is, if the Halo2 construction is sound and ZK, and if the original BP paper relied on certain IPP properties (like WEE), do these necessarily play nicely together?
17:21:19 <rbrunner> It's already BP double plus :)
17:22:25 <AaronFeickert[m]> s/extent/extend
17:26:13 <emsczkp[m]> <AaronFeickert[m]> "The paper seems to jump from..." <- Yes, exactly. This is our ongoing work, we now have assumed the IPA argument relation of Halo as secure in our design. However, we need to prove the whole range proof when the new IPA relation is integrated.
17:27:39 <xmrack[m]> Context for BP++ https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=83&browserTabID=
17:27:58 <blankpage[m]> Incidentally you might be interested in presenting your work at https://monerokon.com/ in Prague 23rd-25th June
17:30:24 <xmrack[m]> The last sentence of the conclusion states "As future work, we will validate our approach in real case studies involving streams of sensor data" What do you mean by this?
17:32:58 <leonardomostarda> blankpage[m]: Nice we are very interested. We will submit.
17:33:20 <isthmus> Hi, sorry I’m late. Thanks so much emsczkp and leonardomostarda for taking the time to join us. 
17:33:20 <isthmus> I’m on a call that is taking most of my attention, so apologies in advance if I’m not very responsive. Will try to catch up.
17:38:33 <emsczkp[m]> <AaronFeickert[m]> "That is, if the Halo2 constructi..." <- Referring to Halo and BP, they share the same security properties (WEE, HVZK) and hardness assumptions. I think they can play nicely together.
17:41:24 <UkoeHB> hmm are there any other topics to discuss, otherwise we can end it early? I'm not feeling great today
17:41:38 <leonardomostarda> <xmrack[m]> "The last sentence of the..." <- We are trying to develop private multi transfer payments in an IoT scenario. This involves a continuos stream of sensor data. 
17:43:47 <leonardomostarda> <isthmus> "I’m on a call that is taking..." <- Thanks your interest 
17:46:12 <xmrack[m]> <emsczkp[m]> "Yes, exactly. This is our..." <- Do you have any rough timelines for your ongoing work? Or is it too early to say. 
17:48:02 <emsczkp[m]> Yes, this work has high priority since is part of my PhD
17:48:57 <AaronFeickert[m]> You're of course free not to say, but did the reviewers have any particular notes on the security model or analysis?
17:55:03 <ceetee[m]> <leonardomostarda> "Nice we are very interested..." <- if you have event specific questions you're welcome to join us in #monero-events:monero.social 
17:55:32 <leonardomostarda> <AaronFeickert[m]> "You're of course free not to say..." <- The paper was published in a workshop. The number of pages were very very limited. We could not write a lot. A reviewer was asking about validation.
17:56:02 <AaronFeickert[m]> Yeah, page limits can be pretty brutal :/
17:58:22 <leonardomostarda> Anyway, we are very happy to collaborate with anyone interested in completing the work with the needed proofs. 
17:59:47 <AaronFeickert[m]> Can you remind me if the construction supports efficient batch verification? I don't have the paper handy
18:00:12 <AaronFeickert[m]> And unfortunately don't recall if this was the case
18:01:00 <AaronFeickert[m]> BP and BP+ verify linearly-ish, but shared generators mean pretty big savings in batch
18:01:41 <UkoeHB> ah, are there any plans to publish the paper outside springer? the paywall makes things difficult outside academia
18:02:22 <AaronFeickert[m]> Yeah, posting the submission version (if allowed) to ePrint would be great
18:02:35 <AaronFeickert[m]> I'd be very surprised if you weren't allowed
18:03:22 <emsczkp[m]> AaronFeickert[m]: Yes the work support batch verification and aggregation of range values. In fact the evaluation shows a constant proof size when the number of range values increase.
18:03:37 <AaronFeickert[m]> Nice
18:03:54 <AaronFeickert[m]> I'll need to review the details on this later
18:09:01 <emsczkp[m]> <AaronFeickert[m]> "Yeah, posting the submission..." <- yes by extending the work we could publish on a different journal
18:10:11 <AaronFeickert[m]> Oh I just meant posting the original preprint to the archive for open access
18:10:53 <AaronFeickert[m]> Great way to get extra eyes on it
18:12:00 <emsczkp[m]> yes for the preprint is fine, there should't be any problems
18:15:28 <UkoeHB> we are well past the hour, so in case anyone was wondering the meeting is over
18:15:40 <UkoeHB> next week we will return to the tx_extra discussion
18:15:53 <UkoeHB> thanks for attending everyone
18:17:36 <emsczkp[m]> thanks for inviting us to the meeting, should we join next week ?
18:18:33 <xmrack[m]> leonardo.mostarda: emsczkp Thanks again for coming. You're free to come any week you'd like :) but don't feel obligated. This room is open 24/7 to discuss Monero related research.
18:19:36 <leonardomostarda> Thanks, for sure we keep you updated with the progress of our work.