14:18:53 <real_or_random> not sure if people have seen this paper already https://eprint.iacr.org/2022/132
14:34:56 <UkoeHB> have not thanks real_or_random 
14:35:40 <UkoeHB> meeting 2.5hrs: https://github.com/monero-project/meta/issues/662
14:41:23 <Rucknium[m]> No. This looks like groundbreaking work. 
14:42:58 <Rucknium[m]> >Specifically, assuming two conjectures on certain distributions of random directed graphs (digraphs)
14:42:58 <Rucknium[m]> which we support by providing empirical evidence, we show that if the number of decoys _k_ of a partitioning
14:42:58 <Rucknium[m]> sampler is set to
14:43:47 <Rucknium[m]> > k >= ln(2* |U|) + sqrt(2 * ln(2 * |U|))
14:44:30 <Rucknium[m]> > then [some math]. In other words, a graph-analysing attack is at most twice as successful as a trivial attack does.
14:44:49 <Rucknium[m]> And U is defined as...
14:45:24 <Rucknium[m]> > In applications, it is common for a human user to own many pairs of public and secret keys. Nevertheless, to simplify terminologies, we will refer to a public key as a “user” and use the notation U to refer to the set of users (public keys) where signers belong to and where decoys are sampled from.
14:47:38 <Rucknium[m]> If U = 1,000,000, I'm getting ln(2U) + sqrt(2ln(2*U)) = 19.895
14:47:48 <Rucknium[m]> So ring size only 20 (?)
14:49:36 <merope> There's a bit later on where they look at "Black marble attacks" (ie. an active malicious observer creating transactions to partially deanonymize rings)
14:49:37 <merope> 7.2
14:51:28 <merope> Though I wonder how this interacts with "chain reactions"
14:59:45 <moneromooo> I wonder what a partioning ring sampler is. No obvious hits searching for it, though I see https://eprint.iacr.org/2020/1550 pop up, which studies with those (similar authors).
15:00:06 <moneromooo> Anyone knows what they are ?
15:01:56 <UkoeHB> moneromooo: https://petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf
15:03:52 <moneromooo> Its definition is fairly tautological (to me).
15:06:52 <UkoeHB> I think you literally take a contiguous set of outputs and reference all of them
15:07:51 <moneromooo> Thanks. So... binning, with a single bin ?
15:07:54 <UkoeHB> oh nvm, you randomly select from a segment
15:08:01 <UkoeHB> so yes, binning
15:09:25 <UkoeHB> randomly select from within a bin (which is selected from the set of all bins according to some other distribution, which could be non-uniform)
15:10:51 <UkoeHB> My deterministic binning proposal is combination of the 'mixed' and 'partition' strategies (mixed-style multiple-partition selection, uniform within a parition).
17:00:29 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/662
17:00:29 <UkoeHB> 1. greetings
17:00:29 <UkoeHB> hello
17:00:35 <ArticMine> Hi
17:00:38 <mj-xmr[m]> hi
17:00:40 <rbrunner> Hello
17:01:31 <xmr-ack[m]> Hola
17:01:37 <gingeropolous> oh hai
17:02:29 <jberman[m]> howdy
17:03:09 <Rucknium[m]> Hi
17:03:12 <UkoeHB> 2. Today I don't think there are any pressing agenda items. Let's start with updates. What has everyone been busy with?
17:03:51 <mj-xmr[m]> I've done a review for Ruck's paper over the weekend.
17:05:26 <Rucknium[m]> I have a draft of the MAGIC Monero Fund research request for proposals. Suggestions/edits welcome:
17:05:26 <Rucknium[m]> https://cryptpad.sethforprivacy.com/pad/#/2/pad/view/SBQRrOt+Vd6Bbr0nJHA6eNQtnMaTS-kPLWtvtVbAlAA/
17:05:48 <Rucknium[m]> I think we will approve a final draft by early next week and start accepting applications.
17:06:44 <xmr-ack[m]> I’ve been working on the dataset collection part of my research project. Have 5 servers right now running a collective 900 wallets that are transferring testnet xmr back and forth. I’ve also been working on polishing up a script to extract all the transaction metadata using xmr2csv and the native monero-wallet-cli exporter. Hopefully will have a full dataset by the end of the month and then can start neural network design.
17:06:47 <jberman[m]> reviewed the fee change PR, will be re-reviewing changes today, and various monero-lws related stuff (thinking through subaddress support, submitted a first pass general review of the code, getting a docker image set up)
17:07:33 <ArticMine> Very good catch on the fee pr
17:07:40 <UkoeHB> me: After a couple weeks of work I now have unit tests running on the main part of jamtis (along with some refactors of my seraphis library). I am pretty satisfied with the library as it is now (although it is missing multisig stuff, which I won't add until PR 7877 is merged - getting close on that one, I just need to do a little cleanup and get final approvals from h4sh3d and vtnerd). My next steps are implementing 
17:07:40 <UkoeHB> some grootle proof optimizations that the Firo team found, rerun perf tests for that, then start thinking about the larger wallet PoC (I might make a new CCS for this, since I used up all my hours on the previous one).
17:10:47 <Rucknium[m]> UkoeHB: There were some things brought up on Reddit recently regarding how the address format change will affect future improvements. Do you have any insight on whether the Seraphis address change can be compatible with something like Zcash's Halo2 down the road?
17:10:59 <UkoeHB> No idea
17:12:16 <UkoeHB> If there is anyone out there who actually understands Halo2, would be nice to learn/hear from them... I don't recall ever seeing such a person
17:13:22 <rbrunner> Even without knowing any details, strikes me as improbable, with all that specific keys in the public Seraphis addresses, but yeah, who knows
17:13:49 <jberman[m]> I thought one of the critical ideas of Seraphis' tx modularity was to possibly enable an easier swap-in of something like full-chain membership proofs
17:14:14 <UkoeHB> It would be ideal if we could layer their proving stuff on top of Seraphis, to do the membership proof piece without changing anything else.
17:14:50 <rbrunner> At least some people there were worried about changing their public Monero addresses yet again if we switch to something post-Seraphis later
17:14:50 <UkoeHB> But 'Halo2' is a quite opaque word lol, so who knows
17:15:27 <rbrunner> And there I think it's improbable to keep addresses and switch to very different proofs underneath
17:16:13 <UkoeHB> Yep it's certainly possible, though I wouldn't really expect anything like that for another 3-5 years at least.
17:16:46 <rbrunner> May depend in how positive a light one sees Seraphis :)
17:17:05 <rbrunner> "Gras always greener over there"
17:18:35 <rbrunner> In any case we will collect experience with the address change ...
17:19:26 <UkoeHB> yep...
17:19:40 <rbrunner> Just a thought: It is probably possible to write a tool that calculates a Seraphis address for a given private key, maybe quite soon, right?
17:19:41 <UkoeHB> Does anyone have anything they want to discuss? Questions? Concerns?
17:20:08 <UkoeHB> rbrunner: I think tevador was working on test vectors...
17:20:39 <rbrunner> Interesting.
17:20:39 <UkoeHB> Uh if someone wants to take my library and add a PoC for generating public addresses, that might be fine
17:20:54 <rbrunner> Code is there then already?
17:20:58 <UkoeHB> Public addresses are a bit higher on the stack, so I haven't looked at it yet
17:21:17 <UkoeHB> But I have code to generate the address points.
17:21:49 <rbrunner> Was just thinking it may help in the address switch process if people were able to publish their new addresses months before the hardfork already, to seed them wide and far
17:22:34 <UkoeHB> this guy: https://github.com/UkoeHB/monero/blob/da0c5db016a5b25199054284902aca2b0c9588cf/src/seraphis/jamtis_destination.h#L91
17:23:05 <mj-xmr[m]> UkoeHB: Minor and somehow related to @maxwellsdemon 's adaptive mining proposal: I'll be building a small solar battery island as a test bed for the prediction (via tsqsim) of solar irradiation and battery load / drainage. The prediction will serve as an input signal to whatever controls the mining intensity.
17:23:11 <UkoeHB> Well there might be format changes, so I think it's better to wait a while for that rbrunner 
17:23:30 <rbrunner> Yes of course. That's probably next year's stuff. Just thinking ahead :)
17:25:52 <UkoeHB> mj-xmr[m]: I see
17:27:07 <gingeropolous> whats the word on memo fields / tx_extra?
17:27:47 <Rucknium[m]> What I like about the "On Defeating Graph Analysis of Anonymous Transactions" paper posted earlier is that it starts to get at the question of how many ring members is "enough", at least to defeat specific types of attacks. So if Seraphis gets us to "enough", then that would be great. If it doesn't, then we should still be thinking about the next generation + 1
17:28:14 <UkoeHB> gingeropolous: what word?
17:28:14 <rbrunner> A long time since tx_extra came up the last time, as far as I remember
17:30:24 <gingeropolous> well i guess the question is whether jamtis has a useful memo field that can be done in a way that keeps all txs uniform
17:31:20 <UkoeHB> like encrypted or something?
17:31:56 <UkoeHB> I was planning to use the existing tx_extra strategy, with some additional rules about formatting (sorted TLV, like I have been preaching for years).
17:32:01 <Rucknium[m]> Regarding understanding Halo2, I have found Zcash developers are generally willing to explain things, on their Discourse forum or their R&D Discord. Maybe they could tell us what sort of restrictions apply to their address format.
17:32:20 <UkoeHB> Also, moving the tx pubkeys out of the tx_extra into a dedicated vector.
17:33:17 <rbrunner> What means "TLV"?
17:34:20 <UkoeHB> type-length-value
17:34:30 <UkoeHB> tx_extra is already tlv
17:34:43 <UkoeHB> by convention*
17:36:31 <gingeropolous> ok, so as of now, tx_extra will live on as it is and possibly harbor fingerprints if ppl glob it up with stuff
17:36:42 <zkao> we're using TLV in farcaster for the peer messages
17:37:37 <UkoeHB> gingeropolous: yes
17:37:46 <gingeropolous> then thats the word :)
17:37:50 <rbrunner> By the way, just saw that Halo2 isn't even live on mainnet yet: "The new mainnet activation target is April 18, 2022."
17:38:06 <UkoeHB> don't they have it on testnet?
17:38:16 <rbrunner> Yes, that.
17:38:22 <UkoeHB> do they actually have public code for everything?
17:38:48 <rbrunner> Never checked
17:39:23 <gingeropolous> Rucknium[m], can u link that pdf again for "On Defeating Graph Analysis of Anonymous Transactions"
17:39:33 <gingeropolous> please :)
17:39:43 <jberman[m]> this seems a decent resource on halo2: https://zcash.github.io/halo2/ 
17:40:40 <Rucknium[m]> gingeropolous: https://eprint.iacr.org/2022/132
17:42:27 <gingeropolous> danke
17:43:36 <gingeropolous> getting to "enough" would be .... great :) 
17:46:01 <UkoeHB> Btw, there has been some effort by Firo/Mobilecoin toward confidential assets, if anyone is interested: https://github.com/mobilecoinfoundation/mcips/pull/25#issuecomment-1033194827 .
17:47:42 <UkoeHB> Basically, it can be done extremely cheaply but runs into problems with tx fees.
17:48:14 <gingeropolous> is this like creating your own tokens on the monero chain or something?
17:48:20 <UkoeHB> yeah
17:51:03 <gingeropolous> and so the great compromise of 2022 left us with 1.7 ..... ?
17:51:22 <UkoeHB> fee scaling? yes
17:51:26 <Rucknium[m]> FYI, some people are also developing something similar on Zcash called Zcash Shielded Assets (ZSA).
17:51:41 <UkoeHB> oh yeah thanks Rucknium[m] 
17:52:36 <rbrunner> Don't want to miss the DeFi train, maybe. Too much money sloshing around in attempts to find a home ...
17:52:44 <gingeropolous> lulz
17:53:10 <rbrunner> And when can I finally have NFTs on the Monero blockchain. It's about time :)
17:53:11 <UkoeHB> I think fees can be solved by requiring you add some base-asset inputs/outputs to all asset transfers. So a tx would have a 'base asset transfer' section and 'extra asset transfer'  section.
17:53:53 <UkoeHB> Realistically, miners can't be expected to care about random assets people make, so fees should always be in the base asset.
17:54:04 <gingeropolous> yeah
17:55:08 <UkoeHB> rbrunner: It doesn't help with scaling though... imo we should maximize the utility of one asset.
17:55:54 <gingeropolous> oooh, i know a fun one for the last 5 minutes. any new ideas on the 10 block lock thing?
17:56:02 <UkoeHB> no
17:57:33 <UkoeHB> ok lol I think we can call it here
17:57:37 <UkoeHB> Thanks for attending everyone
17:58:04 <gingeropolous> thanks UkoeHB !
17:58:16 <Rucknium[m]> How useful would it be to reduce the lock to 5 blocks? How often have we had a 5 block reorg? Sounds like a research question.
18:01:19 <gingeropolous> i think noncesense may have reorg #s
18:04:33 <gingeropolous> although as blocks get bigger those #s could change
18:23:34 <dEBRUYNE> <UkoeHB> Basically, it can be done extremely cheaply but runs into problems with tx fees. <= What exactly is the issue with tx fees in this approach?
18:26:25 <UkoeHB> I guess the basic problem is you can't hide you are transferring a special asset, because you need to separate base asset transfers (for fees) from special asset transfers, within the same tx. Also, you can't use special assets for fees without revealing the asset ID.
18:27:27 <UkoeHB> I guess ideally you could do a multi-asset balance proof that hides all the assets, while providing a fee in the base asset. Idk if it's possible/practical though.
18:31:15 <UkoeHB> The nice thing is you can hide which outputs in the chains have a special vs base asset, and you can do asset-type-agnostic membership proofs.
18:31:27 <jberman[m]> I'm having a hard time grokking how initial issuance of the different confidential asset types work
18:32:36 <UkoeHB> You'd specify a new output type 'asset issuance', which must make a unique asset id and define the total supply of the new asset. Then add a big fee on top to discourage spamming new asset ids.
18:32:58 <zkao> UkoeHB: sipa had this argument that these assets are parasitic to the mainchain, compete with the mainchain native asset, and add no value to it. btw 3 years ago people were paying bitcoin network fees on their credit cards to unstuck txs. maybe that happened because of the network centralization
18:33:19 <UkoeHB> yeah I agree they compete
18:33:40 <UkoeHB> however it's at least fun to see how it can be done elegantly :)
18:35:18 <jberman[m]> UkoeHB: "you" as in the user? or "you" as in the protocol? who's "you" here
18:35:39 <UkoeHB> the protocol would have a new output type, to make a new asset you construct such an output
18:38:16 <jberman[m]> so in theory, I as a user can use XMR as my input, and construct USD tokens as output (so long as the protocol supports USD output types), and no one would know what the input types and output types are in the tx?
18:39:19 <UkoeHB> Yes, although the XMR wouldn't be burnt. The XMR part would just be for fees.
18:39:49 <UkoeHB> The key is once you generate a certain asset, it can't be generated again (fixed supply).
18:40:33 <UkoeHB> Wait I got confused. There would not be any cross-asset conversions.
18:40:57 <UkoeHB> It's just a parallel asset transfer system hidden within the main asset transfer system (XMR).
18:43:33 <jberman[m]> so I tag an XMR output as being asset Y, and then all outputs that stem from asset Y in the future are henceforth also asset Y? something like that?
18:47:25 <UkoeHB> right
20:29:50 <zkao> i think the argument was: miners are rewarded in the native asset, and this asset must have a utility, which typically is this asset is used as cash in this payment system and for fees. if u add new assets, that are not rewarded to miners (=no added security to the network), then non-native assets txs compete for the native asset txs for block space (reduce the utility of the
20:29:52 <zkao> network that is used to secure the blockchain).
20:31:21 <zkao> * reduce utility of the native asset that is used to secure the blockchain
20:45:34 <dangerousfreedom> > <@rucknium:monero.social> I have a draft of the MAGIC Monero Fund research request for proposals. Suggestions/edits welcome:
20:45:34 <dangerousfreedom> > https://cryptpad.sethforprivacy.com/pad/#/2/pad/view/SBQRrOt+Vd6Bbr0nJHA6eNQtnMaTS-kPLWtvtVbAlAA/
20:45:34 <dangerousfreedom> Awesome! I hope I can help someday when I finish building my tools and this other problem that I am very motivated to work on about inflation (that hopefully will benefit some people also)