Zero to Monero 2.0 most recent edition?

yes

ty UkoeHB

So I just found this:

I especially enjoy the MRL Molotov. Tossing truth bombs all over the place 😆

Updated pre-print with security proofs is available now for Lelantus Spark: eprint.iacr.org/2021/1173.pdf

Also available on Github, but IACR should be viewed as canonical.

amazing news

@Halver[m] Got it from the monero database that @neptune maintains

<isthmus> "@Halver[m] Got it from the..." <- Thanks isthmus .

I profit for a silly question : how is it possible for a tx to have more than 11 outputs ?

Are such txs done with unofficial wallets ?

The current protocol allows up to 16 outputs (correspondingly, I think the core wallet would let you send to 15 recipients + change)

So the peak at 16 makes sense, people maxing out the allowed number of recipients

The prevalence of 11 outputs is odd. It could be an unofficial wallet, OR it could be a script/wrapper/whatever around the core wallet that simply batches by 10+change and doesn't take advantage of the full 16 allowed by the protocol

outputs |= ring members

nioc: Indeed, I was making this mistake.

If I'm correct the number of ring members is fixed, at 11 atm,

and it is also mandatory to be accepted in the blockchain ?

correct

<isthmus> "The prevalence of 11 outputs..." <- I guess only a mining pool (old) script could generate such a volume ?

if every transaction returned change split into 15 seperate outputs would that have a net positive for privacy?

If the source of the 11 output txns switched to making 16 output txns it would be a very good thing to reduce how much their transactions stand out

(if we can figure out who/what is behind it, I would politely contact them with a note about updating their max outputs value)

The plot above is a log y-scale, so that peak at 11 is way bigger than it looks (essentially an order of magnitude over the surrounding output count values)

There will always be a bunch of transactions with 2 outputs from day-to-day users, and a bunch of transactions that max out the output count of the protocol (currently 16) for things like batched payouts. So if transactions can pick one or the other and blend into there would be best

I've pondered the notion of requiring #outputs to be a power of 2

So if you have a 6 output transaction (including change) you would just add 2 dummy outputs so that you're at 2^3=8

Rucknium: Isn't there a meeting programmed at 17:00 UTC today ?

isthmus: What would be the benefits ?

yes 40mins

It would prevent goofy stuff like some pool generating thousands upon thousands of N=11 outputs that can be traced to each other and ruled out as decoys from other rings :- P

UkoeHB: ah, so my UTC shown time must be wrong

unless I am crazy, it is 16:20 UTC right now

No. You're right, and I was wrong.

<midipoet> "if every transaction returned..." <- Net privacy win, but a block chain bloating problem

Or maybe not

bigger problem is scanning times to find owned outputs

I don't think it's necessarily a net win for privacy if every tx created 16 outputs. I think you'd likely end up having more tx's that have >1 ring with members from the same tx that way (unless all wallets actively prevent this), which makes it easier to identify those outputs as real

jberman: if that's the norm though, wouldn't it make it basically a wash? Why should anyone send more than 1 output to themselves or another person in normal use?

minko comes to mind, but that's the only legitimate example I've seen

I see 16 out as a net privacy win, but at relatively significant cost

there was an idea earlier for allowing either 2 out or 16 out only, but that's probably not flexible enough

If you have 2 rings in your tx, and both rings reference distinct outputs from the same tx, it's pretty clear that those are the outputs being spent, regardless of whatever else is happening

True, though that's a non-issue since dummy outputs would have 0 value and would not be consumed by subsequent transactions from the same wallet

If you're dividing up amounts into 16 outputs always, you also have smaller outputs with which to make tx's, so it seems you would also need to use more inputs to send the amount you'd want

No I'm definitely not proposing that

Would be a privacy disaster

We could change fake out selection to slightly favour using outputs in different rings that come from the same tx. Never did it though.

oh wow nooooooo, no one is proposing using anything other than dummy outputs here :p

splitting into tiny amounts just for the lulz is baaad

<midipoet> "if every transaction returned..." <- was answering this q

ah sorry I missed that

midipoet: no :)

<moneromooo> "We could change fake out..." <- I think this would be effective though, at the cost of fewer decoys from across the chain (it's sorta like the naive binning approach I was planning to propose)

what use case are we better protecting where the use case involves spending several outputs from the same transaction

if anything, a wallet should probably warn if they receive several outputs in a single transaction as a higher risk of receiving poisoned outputs

ya agree I don't see what privacy gains you get from always constructing 16 output tx's. I think the main benefit is likely less time spent waiting to spend cuz of the unlock time (you have more outputs sitting around ready to go)

sgp_[m]: Some wallets are working on features which generate extra change outputs to avoid the 10 block lock

Rucknium[m]: do you want to run the meeting?

I could. Usually people with agenda items shouldn't run meetings, though.

ok I will do it

Want me to run?

let the meeting commence. Logs will be posted on the issue: monero-project/meta #610

1. greetings

hello everyone

Isn't carrington running one of the Monero Community meetings soon? carrington , could you run this one too? I don't know if you are busy though carringtonn

Hi

Hello

hello

Hoi zäme

Hello

Hi.

hello

I'm cool with koe running for now

Hi all

hi

Hello!

sarang and brandon ran most of the previous ones and they always had agenda items

Hello. A researcher should run the MRL meetings, not me

Hi

Hello

2. updates. People working on stuff, a brief summary of what you have been up to.

hi

hello

hi

My main thing is working on a roadmap to improve the mixin selection algorithm. Within 12 hours I will submit the roadmap to the Vulnerability Response Process in part so that moneromooo and luigi1111w can redact any sensitive parts before release. jberman and isthmus have seen a draft of it.

The I sill submit a CCS proposal to execute it

* will submit

Lots of people here :). My summary: The past couple weeks I have been working on PoC for Seraphis. Right now I have working performance mock-ups of RingCT with CLSAG and Triptych on my branch (github.com/UkoeHB/monero/tree/seraphis_perf), and have a good plan for building out the Seraphis PoC. There are a lot of variations to perf test, so it is taking me a while to design things properly.

So Lelantus Spark is out with security proofs. I am working on Seraphis's security proofs. Need verification of security properties I wrote here: UkoeHB/Seraphis #2#issuecomment-918639450

Lelantus Spark: eprint.iacr.org/2021/1173

But since Lelantus Spark is "somewhat" of an instance of Seraphis, I guess I'll just "align" my security analysis...

I will give about 3-5mins more for summaries then we can move to discussion :)

Here's a good casual discussion on Lelantus Spark youtube.com/watch?v=vEZC1fTYRZk

jberman[m]: would you like to update us?

My summary: recommended patching integer truncation in the wallet & reducing the "recent spend window" (monero-project/monero #7798#issuecomment-917495021), did a bit more research into the decoy selection algorithm adding the effect of MyMonero+Monero-LWS & openmonero to the mix in response to some of vtnerd's feedback and

criticisms (monero-project/research-lab #86#issuecomment-915806414), worked on other non-research related tasks, and hoping to talk about binning in today's meeting

Re: binning, my binning proposal was updated a while back (final draft kind of form) monero-project/research-lab #84

Also research related:

- fee updates have been PRd and I have comments: monero-project/monero #7819

- multisig address generation fixes have been PRd: monero-project/monero #7877

Anyone else?

ty for reviewing the fee changes

3. discussion. Ok I think we can move on. The remainder of the meeting is open ended.

are we accepting ArticMine's growth parameters then? am I the only one who is concerned with them?

I don't have a strong opinion

Ping me when you comment on PRs, I seldom check the repo nowadays.

sgp_: I suppose I could look at them.

ah gotcha

sgp_[m], can u briefly summarize ure concerns?

I am an economist after all. Maybe I have something to say about fees.

I responded to the growth parameters in MRL issue 70 and the pr

ok

gingeropolous: it's just a generous growth rate allowed

we don't need to talk about this here among all the other important stuff, but I am worried it is too generous

sgp_[m]: It may be good to circle back to that issue after the fee PR is ready to merge.

ok

i think Rucknium[m]'s input will be valuable, because it is effectively monetary policy

Just a note if you change the grwoth parameters on has to change the whole fee calulation

So I would suggest this not be left to the last minute

so whats all the other important stuff? :)

Triptych vs. alternatives... (full message at libera.ems.host/_matrix/media/r0/do…1e8ad7cef1dddd03a40c2a19fde0eed447c)

It sounds like there isn't anything new to add in this meeting, just a call to action: please take a look if you can (MRL issue 70 and PR 7819).

for those that can't do links

Triptych vs. alternatives

Improvements to the mixin selection algorithm (

Decoy Selection Algorithm - Areas to Improve research-lab#86 ) @j-berman @Rucknium

Removing/fixing/encrypting unlock time (

Removing/Fixing/Encrypting monero's timelocks research-lab#78) (it also affects binning)

Analysis of July-Aug 2021 tx volume anomaly (?) ( isthmus? { @Mitchellpkt } )

Active recruitment of technical talent @Rucknium & others

MRL structure (why aren't things getting done?).

(from Rucknium[m] 's matrix post)

Oh, long Matrix posts don't come through nicely on IRC?

These are the items from monero-project/meta #610

- does anyone have comments/questions about Triptych vs alternatives?

Do we have some concise figures on verification time / tx size for comparison?

I have one question because we haven't really discussed this during a meeting specifically as far as I understand, but it has been discussed elsewhere:

questions: Triptych isn't competitive even with ideal multisig or multisig is the only blocker ?

ArticMine: I am working on perf tests for that.

Has anyone looked at RingCT 3.0 as an alternative to Triptych?

UkoeHB: My continued preference is explore Seraphis/Lelantus Spark and move to a hard-fork with ring-size change in the meantime.

Thanks

Due to improved view keys and multi-sig simplicity, mainly.

Well, I have the comment that I can't comment because I am not able to read Sarang's paper and decide how the UX and UI for multisig would change.

Which of the following is more important: 1) easy transition with compatible address format, or 2) easy multisig

I.e. how much more complicated to transact?

I vote 2

wfaressuissia[m]: Multisig is the main blocker, but there are other advantages to Seraphis/Lelantus Spark.

I have to agree with sethsimmons after speaking with sarang at DefCon after his talk. The Multisig simplicity is very significant in my view

I would prioritise whatever gives us a good and usable multisig.

Quite some unknown how we would fare with an address format change I guess

Sounds quite radical

sgp_[m]: I assume the new sofware would prevent users from using old addresses?

wfaressuissia: Seraphis in general has several other benefits over Triptych.

1. possibly more efficient (TBD)

2. new features: membership proof delegation (allows tx chaining, offloading membership proofs to third parties, reduces timing analysis of slow tx like multisig), collaborative funding (multiple funders for a tx without big crypto design effort), better address schemes (several variations)

s/sofware/software/

BCH more or less did an address format change. Could query them on how to do it right

Interesting

Could address size decrease?

The new format address not be backward compatible?

i imagine with a hardfork, it would be easy to protect users re: address change.

x3nu[m]: there are two sets of address scheme variations, one set is larger

proper view keys that show the whole balance (while also allowing view keys as we know them today) is a large win

ErCiccione: backward compatible?

UkoeHB: "collaborative funding (multiple funders for a tx without big crypto design effort)" Does that mean that a BCH Flipstarter-like crowdfunding system would be easy to put together?

exporting key images is frankly terrible

hypothetically - depends on various design decisions

This new feature list looks so fantastic, somewhat hard to believe for laypeople

sgp_[m], smooth would have disagreed, or at least they expressed pause in the past. for reasons i don't fully remember or understand

ErCiccione: people would get new Lelantus Spark/Seraphis addresses

re: proper view keys that show whole balance.

I mean, if we really get all that for an address change, well then ...

The biggest issue with the address format change is static addresses used in the past would not be valid/usable.

i.e. static donations, saved addresses for friends in address book, etc.

static = widely published?

haha yeah exactly rbrunner , MANY benefits as I see it

As new wallet software after HF would only use the new format, new address generation wouldn't be an issue.

gingeropolous: there is an address scheme variant where view-only identifies owned and spent outputs, but can't read amounts. I like this one personally.

sgp_: my question was if the precedent format will be still accepted, otherwise would impact ux quite a lot

As it's coupled with a HF I don't think it's a huge deal, but it's certainly a bit more headache.

if the base point of comparison is the best non-reviewed and unproven DAP designs, then Triptych isn't competitive even with multisig. If the base point of comparison is current ring signatures with 10 decoys then even Triptych with a bit more complex multisig is an improvement which was expected to deployed soon.

Seth: critically funds sent to those addresses would not be unspendable however

Zcash is trying to merge t- and z-address formats, I believe. Just another example of another coin doing it.

It would not lead to lost funds with a HF, FWIW, just pain for users when merchants/donation acceptance does not update static addresses.

ErCiccione: the existing format would have to be rejected

but I assume LS/S funds couldn't be sent to old addresses

sgp_[m]: No, wallet software should just reject the address as invalid and prompt that it's old format

UkoeHB: Woah, thats cool

wfaressuissia: 'soon' is only 'soon' if you find someone to implement that complex multisig

Rucknium[m]: This is different, they all still exist and are usable they just basically use a new URI format that can choose among multiple options.

If I see something as good-looking as this I unvolentarily start to look for the catch :)

They aren't phasing out any address format or changing it.

i don't think the change in address format is a cause for concern

It's just a wallet SDK change.

Would it be possible to convert an old address to a seraphis address?

Triptych is a year + out even if we were fully on board with running with it, which I think is inadvisable at this point

d3neon[m]: your private keys would stay the same (or at least your base entropy/mnemonic, depending on design choices)

One can allow a transition phase afte which sending funds to legacy addresses would not be allowed 6 months would be reasonable

UkoeHB: 2 people were agree to help with implementation: hyc and vtnerd, but that's for the case when design is ready

d3neon[m]: New wallet software would just provide new addresses, no conversion needed etc.

Regarding fees. These fees are being used as protection against unlimited blockchain growth (problem with cheap storage and network), unlimited number of malicious txs (problem due to small number of decoys for ring signature) and reward for miners (not very important, since ther is fixed tail emission). How is it possible to justify decrease or increase of fees without any knowledege of hardware available to miners ?

If you could convert it, that would solve the static address issue

d3neon[m]: You just post a new one, don't need to convert.

The sender couldn't convert it, FWIW.

alright

Yeah, a fully automatic conversion tool, based only on the info in the address, would be surprising

ArticMine: Yes, that is an option to implement both address formats, but obviously added complexity and code.

rbrunner: "I unvolentarily start to look for the catch" The protocol is still experimental and not implemented anywhere - of course there might be a catch no one has seen yet. The more eyes the better.

<sgp_[m]> Triptych is a year + out >>> how far out will seraphis / lelantus / superdooper be?

Also Year +

or is it 3 +

So a ring decoy increase should be reconsidered then?

As a holdover

imo its theater

ArticMine: I also think a big transition period would be good.

Firo is planning on Q3 2022 for adoption of Lelantus Spark

just to give a rough idea

x3nu[m]: Yes, IMO.

sorry, Q2 2022

I think there is pretty broad consensus for a ring-size + BP+ HF with ring-size of 15-17.

Seth: yup

But the larger improvements to privacy are likely coming via the decoy selection/binning work being done, TBH.

wfaressuissia[m] Fees increase/decrease based on number of transactions being sent. They have nothing to do with mining hardware

But ring size bump does help with those in theory, but that's more jbermanRucknium territory

Hi! I made an attempt to elucidate Seraphis here. Highly incomplete hahaha. UkoeHB please correct mistakes: raw.githubusercontent.com/coinstudent2048/writeups/main/seraphis.pdf

wfaressuissia: "How is it possible to justify decrease or increase of fees without any knowledege of hardware available to miners ?" The fee PR has two parts. 1) improve the algorithm design to avoid problematic edge cases. 2) increase the minimum fee. Parameter choice is very difficult and somewhat arbitrary, so yes 'how is it possible' is kind of engineering voodoo (which is seen in other engineering fields too).

ok, so lelantus spark will be ready Q3 2022 ?

coinstudent2048[: cool! I will take a look :)

We could turn things on the head and ask whether currently anything still speaks *pro* Triptych

Except an existing but non-multisig implementation

gingeropolous: That's their plan, yes, but that's for Firo -- would require implementation for Monero specifically on top of that, but not sure on complexity.

nice coinstudent2048 !

There is also a PoC implementation of Lelantus Spark: github.com/cypherstack/spark

sethsimmons: I'm not sure it worth to make a hard fork now if there are more consensus changes being worked on (assuming they are consensus-related)

so i guess, as mentioned before, a key piece of data is compare and contrast lelantus spark / seraphis / triptych re: size and speed etc

rbrunner: If Seraphis/etc. turn out to be flops, Triptych is the best known protocol.

ErCiccione: Ah, forgot to include fee changes, which should also be included.

Past that there are no other consensus changes near-ready that I know of.

I see, yes

I think we should prepare a list of what consensus changes would be included in the next hard fork and then have a dedicated meeting about it

And as mentioned a new protocol is still 1y+ out.

That being said, Seraphis/etc. don't introduce any crazy new crypto, so it is unlikely.

UkoeHB: I second this.

Agreee with ErCiccione on dedicated meeting about HF

ErCiccione: Agreed.

UkoeHB: but we need it to support multisig in case

meeting again in two weeks then?

yes seems appropriate

there is enough stuff to talk about in any case i would say, beside the hard fork

Does Lelantus Spark support multisig then in a reasonable form? Does Firo aim to support multisig?

HF process falls outside of MRL scope mostly and is more of a -dev thing, but yes very important

rbrunner: Yes, very simple AFAICT.

rbrunner: afaik yes, the Chaum-Pedersen proofs they use can be multisig-d

rbrunner: yes, Lelantus Spark multisig is a dream compared to Triptych

meeting in monero-dev sunday 3th 17:00 UTC?

Nice, one more arrow in the back of Triptych ... ?

Pre-print: eprint.iacr.org/2021/1173.pdf

Github: github.com/firoorg/spark-paper

PoC: github.com/cypherstack/spark

ErCiccione: I'm not aware of any meeting but there should definitely be one imo

sounds good to me ErCiccione

we should move to another topic, this one took a surprising amount of time

- Improvements to the mixin selection algorithm

rbrunner: that's the main reason not to use Triptych

4 areas to improve decoy selection algo:

1. Integer truncation in the wallet (e.g.: `3 / 2 = 1`)

2. Binning

3. Modifying the distribution estimator (@Rucknium spearheading this)

sgp_: yeah, will post in -dev about it if there is consensus here

4. Validating correct algo used at consenus

ErCiccione: yes please do

1. Patching integer truncation

Refresher: the decoy selection algo selects *older* outputs than it otherwise would because it truncates an integer (e.g. 3 / 2 = 1, instead of 1.5)

I recommended patching integer truncation in the official wallet: monero-project/monero #7798#issuecomment-917495021 (and downsizing the "recent spend window" where the wallet re-selects a young output if the algo suggests a locked output).

Summary: patching truncation seems safe on grounds of tx uniformity to me, and I think it's reasonable to assume it would correctly select a decoys that more closely mirror spending patterns.

don't think there is much to talk about on that^

rbrunner: I try to post about Sarang's Triptych multisig paper in MRL/Lounge, but not now.

TIA!

jberman: +1

Will give 30 more seconds then moving on to binning

yeah safe to patch

Lol, bug killed in 30 seconds :)

:]

I think binning is blocked by the decision on what to do with unlock times

Unlock times have privacy issues (they break tx uniformity & can enable unknowing links), and make binning implementations more vulnerable to particular attacks. So bringing the topic of unlock times back up to try and move toward a decision on what to do with them.

Encrypting unlock times is possible at cost of doubling verification time and increasing tx size. Which seems overkill for a feature barely anyone uses today

Thoughts on how to reach consensus? Seems no one really loves the feature, so no one cares much about it to go one way or another. Is there precedence for deprecating a feature like this?

imo, they seem a novelty

tbh I'm happy to simply write off binning right now

yea, I don't think they are much used

maybe a dedicated issue could help? So we can see points in favor and points agains? unless there is already one

I don't know any important use cases for them

wait, I thought atomic swaps relied on lock times?

precedence? perhaps axing of the clear format tx id or whatever it was.

ErCiccione: binning has been suggested countless times over many years

merope: no on the Monero side

ErCiccione dedicated issue for handling the unlock time: monero-project/research-lab #78#issue-726924520

in practice, ringsizes are too small, and it involves many complexities

(or at least, one of the proposed implementations? comit maybe?)

shouldn't a feature like unlock time be treated elsewhere as in the official wallets ?

Would existing locks honored if we decide to ax them e.g. in our next-gen protocol?

jberman: nice. Thanks

paymentID. that was deprecated because it didn't do many useful things, but it was replaced with something better.

well it did useful things, but poorly

perhaps thats something to throw into the lelantus / seraphis thing - can these new protocols do some kind of timelock thinger?

in a better way

@rbrunner interesting question, I would lean towards yes

(should honor previous timelocks)

rbrunner: yes, since old outputs would be spent using CLSAG

so there is no issue

Ok then, good to know

yup no issue with past compatibility there :)

gingeropolous: not that I know of

Will confirm no swap protocol has plans to use the feature

A consideration for the next gen transaction protocol should also be whether payment channels are possible

Are there any proponents of keeping the lock time assuming not?

carrington[m]: I think someone would need to study that specifically.

Well, I'm for keeping the lock time as-is for this hardfork, and I'm cautiously for removing it for the next hardfork (but there's a lot of TBD there)

i would vote to deprecate them due to their privacy breaking nature and lack of utility

I would vote for retiring them with the HF to the next-gen protocol, for a clean cut

gingeropolous: are you suggesting that for this immediate update? way too soon imo

i mean they are really only used for 1 purpose currently - im not gonna spend my monero until 2099 ... right?

hahah

well no we're not talking what goes into the next hf. thats for the dev discussion :)

I figure as soon as someone presents a fleshed out compelling use case that actually needs to use lock times, like payment channels, then there would be no resistance to bringing them back

It seems 1hr was not long enough for this meeting, there are still 3 items on the agenda. How about we schedule another meeting for 1wk from now at the same time (1700 UTC), so all agenda items get proper attention?

okay, just good to attack rough timelines to these discussions I think

Ok I will talk about (3). (Let me know if this doesn't go through to IRC correctly.) I will repost my "update" from above:

My main thing is working on a roadmap to improve the mixin selection algorithm. Within 12 hours I will submit the roadmap to the Vulnerability Response Process in part so that moneromooo and luigi1111w can redact any sensitive parts before release. jberman and isthmus have seen a draft of it.

Then I will submit a CCS proposal to execute it

why not to finish right now ? there are a lot of important things and 1 hr / 2 weeks is too small quota to discuss something

s/finish/continue/

I am gone in 2mins

but the meeting can continue without me if you want

Seems good to me to adjourn. We are not in such a hurry to do everything today, seems to me

It's a two-stage execution plan. First, what I have termed Optimal Static Parametric Estimation of Arbitrary Distributions (OSPEAD). It's a medium-term solution to stop the bleeding.

We can have a meeting in 1 week

I also have to head out

+1 ArticMine

Would be good to reconvene next week

weekly ftw

Older people are also a bit exhousted after one such hour :)

In for meeting next week

I would be OK with weekly.

The Return Of The MRL Meetings.

I am fine with weekly

Can someone change the channel description to have the next weeks meeting agenda? Once one is created

Yeah, at least until the backlog is cleared.

For next week I'll have a postmortem of the transaction volume anomaly from a few weeks ago

Ah, a cliffhanger

Clever

;- )

Tune in next week

Same bat time, same bat channel

Can someone grab logs?

rucknium[m]: Do you have a write up that can be linked here for people to find in the meeting logs?

"libera.monerologs.net/monero-research-lab/20210915/raw" grab or grab&post ?

carrington: Yes I have a write-up. No, I cannot share it until it has been sanitized by the Vulnerability Response Process.

carrington[m]: I can change topic, just ping me once created

Logs posted

carrington: It looks like something is wrong with the logs. Not everyone's username shows up

Gah, IRC usernames seem missing

It's because of the <> formatting

Yeah, saw it, maybe the Libera log would be better

Or did GitHub eat the usernames?

Github did it lol

Quote somehow the whole log? ```` or so?

time to :%s/</&lt;/g

Not sure about MarkDown

I'll have to manually reformat unless someone has another source without the formatting issue

The Libera log that wfaressuissia posted above, have a look

^ just search and replace all the < with &lt;

libera.monerologs.net/monero-research-lab/20210915/raw"

Arg ... without the double quote at the end of course

did u get a good log? i pulled up my logfile

Fixed

Thanks, looks better now :)

Did we know about this paper?

Someone posted in r/Monero about it

"This can be seen as a theoretical con-

firmation of the approach used in Monero, albeit condi-

tioned on the strong assumption that Monero chose a

good ˆS."

^ "S" is the distribution for the mixin selection algorithm. Hmm, yes it is a "strong" assumption that a good S was chosen.

Seth agenda posted

How's that?

"We emphasize that although Theorem 6.2 shows... (full message at libera.ems.host/_matrix/media/r0/do…7bd9997008a41985651c089065f9fe1b7a7)

Can someone help me decode this notation? coinstudent2048 ?... (full message at libera.ems.host/_matrix/media/r0/do…f1ad983a2ab0a4cac3566a86bdbc200208a)

Top of page 4 of the PDF

Oh, wait, "Logarithms are either with base 2,

denoted by lg..."

Who denotes log() as lg()? Whaaaat?

sgp_[m]: what's the privacy loss by forcing 16 outputs for every transaction?

my first impression is that this is yet another paper recommending binning

midipoet: it would be a similar effect described in this fuk piece ironically, lol: medium.com/@crypto_ryo/on-chain-tra…-and-other-cryptonotes-e0afc6752527

UkoeHB: is the scanning/validation increase linear (or worse) if a wallet forced 16 outputs for every transaction? (Or some other number)

having extraneous outputs is significantly worse

Because there is more chance that you have to combine outputs in the subsequent transaction that have come from the same previous transaction?

basically yes, combining outputs where unnecessary is bad in general

it also comes with the cost of additional rings

yeah, I think I get it. Though, I wonder could you compensate with output selection algorithm - which is why I asked about it being a net privacy gain. Having said that, I was just thinking out aloud.

the big privacy gain is the indistinguishability of every transaction having 16 outputs

yes. I definitely get that bit.

but it's far better to use blank outputs rather than splitting the value for the same recipient among several outputs

But the big loss is that subsequent transactions will need to combine outputs, and those combinations can be identified within rings

Which is why the 0 value outputs would be better, as you could (in theory) bin them, so they don't get used in rings

Rucknium: what PDF? Btw, I sometimes see lg() when base is 2... oh it's indicated hahaha

coinstudent2048: petsymposium.org/2021/files/papers/issue3/popets-2021-0047.pdf

UkoeHB: I have a few comments, the rest of the changes is running tests now.

Rucknium: That lg() is very confusing. I saw some websites use lg() to mean base 10.

coinstudent2048: I have about had it up to here with computer scientists! 😜

lg() meaning log2 is pretty standard in computer science

computer science meats statistics

hrm, the all have 16 output idea might be neat

gingeropolous: meats? #monero-beef:monero.social

if the other 15 are 0, they won't get clumped together

lulz

so you get a funnel in and then a fan out

did you forget that 16 output transactions are much heavier?

coinstudent2048: My question is this: which is better: Optimal "mimicking" or "partitioning". I can't figure it out from a quick look.

and we can finally use the term fake output and mean the product of a transaction that is fake

bah, who cares

magnetic fields on tiny bits of metal were meant for storing data, so lets store some data

i feel like this idea of having fake outputs has been kicked around a while

perhaps the reason its often left alone is the weight

BUT if variable number of outputs is breaking privacy / fungibility, then....

forcing all transactions to 16 outputs will slow down wallet scanning, what... 5-8 times?

Really not well-thought idea

i wonder if there's a way to make the important part of a transaction output somehow stored across multiple piece of data ... no...

thats just optimization sech1

moneromooo: Lol. It is easy to write really slow R code. Check out "The R Inferno"

On the other hand, if you keep in mind some key issues, then it is easy to write fairly fast code.

And if you really need speed, there is Rcpp , a package to do in-line (or imported) C++ calculations to feed into R.

well, perhaps there's a magic number of forced outputs that is a middle ground between privacy gains of uniformity and the cost of heavy txs

Rucknium: I don't know... I assume that "mimicking" is like the current monero setup, while "partitioning" is classifying tx's into classes.

Mimicking is what Monero currently tries to do, but it does it poorly. My project is to improve the mimicry.

Hmm... I downloaded the paper. I'll say "I'll read", but most likely this will take too long for me to understand, but at least the notation *seems* understandable.

coinstudent2048: Yeah it's fairly complicated, although at the end of the day it may be saying a whole lot of nothing. Tough to say at this point.

midipoet: worse than linear, because right now 2-out tx can abuse change outputs for 50% speed up on scanning (even if only subaddresses are supported)

* not speed up over current scanning, but relative to 16outputs with subaddresses

* assuming view tags are implemented

forcing 16-output tx's would probably end up shifting a higher degree of tx deformity to the input side of tx's too

instead of mostly 1- and 2-input tx's that we see today, you'd see a wider range, potentially clusters that reveal information

can i read some kind of summary of the meeting?

atomfried: Not a summary. This is the whole log: