In many (but not all) of the rigs there's a band at ~80% to the right

Top 4 rows -> no band at 80% and does have newer outputs

Following half dozen rows -> band at 80%, no newer outputs

Almost looks like somebody tried to implement binning, but they only implemented it around the real spend

isthmus: Can you share a link to that transaction?

(from ofrn in -dev)

Quite an unusual decoy selection method, both from an intra- and inter-ring perspective

The real spend appear to be the 3/5 ring sizes from 2017/18 (?)..

When spending a very old output (2017), are decoys selected from 2016/earlier? Or is spending these old outputs a privacy problem in of itself.

Its weird that some go 2018-2021 3yr, 2019-2022 3yr, then 2017-2021 4yr.

Also, those 0 ring membeds/0input are p2pool, correct?

I found a tx with 3 of those, essentially eliminating 30% of the potential spends.

Wouldnt it be a good idea to ignore coinbase tx when selecting decoys?

How realistic is this:

Maybe an exchange preparing for the hardfork by consolidating their bullrun transactions Maybe the "wallet maintenance" from exchanges like binance was actually them just being incompetent and constantly having to resync their wallets from 0

* Maybe an exchange preparing for the hardfork by consolidating their bullrun transactions.

Maybe the "wallet maintenance" from exchanges like binance was actually them just being incompetent and constantly having to resync their wallets from 0

And they want to speed it up with viewtags once they go live

Oh and they want to avoid the increased fees coming with the fork

<monerobull[m]> "Oh and they want to avoid the..." <- Nah. They paid the highest fee possible

(The post-hardfork fee)

Well they obviously want to get home for dinner, still cheaper than doing it after the fork, no?

Nope, same price

5x the current average.

One of first things ooo noticed was the fee was 5x the current (hard fork fee)

Maybe testing their proprietary wallet software ahead of the fork?

Increased fees? Will there be any change to the dynamic block size?

<monerobull[m]> "Maybe testing their proprietary..." <- No change to block size

<ofrnxmr[m]1> "No change to block size..." <- Oh ok, so from where would the increased fees come?

Post hard fork (v0.18) fees are 5x current.

They are using the new fees

I believe what is being done is that the lowest tier of fees is being removed and instead of 4 teirs there will be 3. Is this correct? AIUI what is currently default is low priority and the 5x is normal

no, the fee code changed from "x/5" to "x*0.95" (plus more fee tuning), so it's 4.75x increase but there are still 4 tiers

Thx

And what's the purpose of increasing fees on base layer? Monero Cash incoming ? 😅

Is there somewhere where I can read more about this?

Spam mitigation. The fees go to miners, so I guess they'll get a bit more cash, but it shouldn't be a large increase I think.

The commit that made the change links to a PDF which lays out the changes with formulae. There's also an issue about this with discussion in the monero-project/meta repo.

The rise of the minimum node relay fee is required to allow scaling of the block weight at minimum fee.

The current 0.2x minimum node really fee is a historical artifact from when fees were much greater due to the 13.5 typical transaction weight resulting in much higher fees.

Good point. Right now blocks that are full barely go above 300k, they're usually 300k + 200-500 bytes, so median weight grows very slowly.

If the 100 block median were to remain above the 100000 block median for an extended period of time. The current minimum node relay fee would allow for a spam / DDOS attack against the nodes at little or no cost.

This is because this spam transactions would not get mined

Seems like fees would get to 3 or 5 cents no? Still good for micro-payments 👍

More like to 1 cent

meeting 2hr

<ofrnxmr[m]1> ignoring coinbase TXes when selecting decoys has been discussed before but maybe it's time to revisit now that p2pool is producing a LOT more coinbase outputs than there were before

<sech1> "Good point. Right now blocks..." <- block size (last 720 * 14 blocks): median - 37.6KB, mean - 66.6KB, max - 315.2KB

meeting time monero-project/meta #715

1. greetings

hello

Hi

Hello

hi

hello

hiya

wave

hi

hi

2. updates, what is everyone working on?

Based on mj-xmr's Python implementation of the `wallet2` decoy selection algorithm, I wrote an R implementation. With one million draws, the R implementation passes a K-S test against the `wallet2` implementation when the number of outputs to draw from is large. mj-xmr/monero-mrl-mj #3

monerkon presentation on seraphis/jamtis features went solid I think, finished the ledger integration for the hf, finishing up reviewing 8076, got help from TheCharlatan on lws static building finishing up testing his work, planning to submit a new CCS soon

me: Got some basic unit tests of enote scanning running. At this point there is enough code in my seraphis library to begin writing a wallet. I still have various todos: deeper/more comprehensive unit testing of enote scanning, implement seraphis coinbase txs, implement ringct/seraphis transition txs (need to decide if it's worth the effort to do mixed-input-type txs), and some miscellaneous library improvements (e.g. still need

to look closer at using Curve25519 to speed up scanning). Also, on sunday I did a monerokon presentation about seraphis balance recovery, hopefully the video becomes available at some point.

I did a monerokon presentation of environmental impacts and a the ramifications for 51% and big bang attascks

(tracking progress of auditors via twitter of their supervisor)

I am starting on a comprehensive overview of the whole fee, scaling, and related security and spam issues

More like a reference on how the penalty and related issue work

ArticMine: You may want to talk with endor00 if you haven't already, since they are working on an analysis of the Monero "security budget".

Sure thanks for lettign me know

3. discussion, anything to discuss? there are the persistent many-input txs that have been showing up since last fall...

hardfork

I didn't consider the ring caching possibility, jberman. Thanks for pointing it out. I think when I read about caching rings, I just assumed that users would re-submit a tx soon after the ring was constructed, so there wouldn't be such a time lag between the decoy selection and confirmation of the tx in the blockchain.

The tx in question would be an egregious case of it.

in the best case it was just txs from some wallet with a lot of failed attempts to relay txs, nothing suspicious or interesting except broken tx relay and harmful edge case for ring signature cache

nothing interesting to discuss from research point of view

I'm in to discuss the hard fork too though we're probably missing some people

I'm here, but I would prefer a separate dev meeting for it.

Is it correct to say that our current predicament is the result of the multisig audit taking longer than expected?

Rucknium[m]: I'd say so

The auditors planned to send a draft last Friday, I'm not sure if they gave an update since then.

Since the scope of audit is unknown it isn't clear whether it's expected or unexpected duration of proper audit

it's ok to do asynchronous audit in private, but it isn't ok to do synchronous audit that blocks everything else in private

I haven't heard anything either

If there is nothing else to discuss, we can end the meeting early

Cutting (time) losses is always an option. Sunk cost fallacy, etc.

At this point I think a 2 week HF delay is realistic.

no objection from me

me neither

2 weeks = 10,000 blocks, so we can move fork height from 2668888 to 2678888

I don't think we can settle on a date until we have better clarity on the path forward with multisig, which is tied up by a 3rd party now

I'm waiting to get feedback from someone who works at Trezor, they also need to do a firmware update before we HF.

settle on a delay*

Is the 2 week period realistic?

is there any postponed research that is required for Seraphis integration ?

or implementation is the only missing component ?

ArticMine: we can decide on it during the dev meetin

So we finalize the new HF time at dev?

yes

Sound good to me

is there a date for dev meeting?

I'm not a software developer, so my opinion means little, but I would support keeping the current date and delaying the multisig fix to a post-HF release.

UkoeHB: ooo had a question regarding Seraphis, in case you want to reply libera.monerologs.net/monero-research-lab/20220622

Rucknium[m]: the problem is we want to give everyone enough time to update

Rucknium[m]: +1

I just do not want the HF to keep dragging on. If we can set a time and then sitick to it

stick

HF date should be set after code is ready, not before

agree with ooo

the good news is code seems pretty close to ready though

yes the remaining things are 1) trezor firmware update date 2) ledger finishing integration

jberman[m] "helped" (or has done everything for them) with the ledger integration but they still have to do testing etc

My point is 2-4 weeks would be fine, but if we are looking at months then may wennd to consider 2 HFs

no, it's not months away

ooo123ooo12345[m: there are no new innovations required, although the paper still needs security modeling/proofs. Once I am satisfied with the implementation, then I will take some time to update the paper as much as possible (including coinstudent's contributions), then go looking for help with the missing parts.

What are the heaviest parts that would require 1-2 years for Seraphis deployment ? is it possible to do rough breakdown ?

luigi also said he will be unavailable for a bit so that also means we will have to delay for 2 weeks

<jberman[m]> "the good news is code seems..." <- judging by size of patches for ledger (~100 lines monero/menoro, ~130 lines ledgerhq/app-monero) their firmware is much simpler than trezor

ok I think we can end the meeting here, thanks for attending everyone; the dev planning stuff can continue in -dev if needed

ooo123ooo1234567: I merely started to think about everything that needs changes for seraphis and got dizzy. In case you don't know yet: monero-project/monero #8157

Soon it's half a year I wrote that ...

That issues doesn't focus on list of technical problems to solve on they way to Seraphis integration, unrelated.

s/issues/issue/

* That issue doesn't focus on minimum list of technical problems to solve on they way to Seraphis integration, unrelated.

It was more something towards your "What are the heaviest parts" question, not the research question

ooo123ooo1234567: Trezor implements bulletproofs in their firmware (core/src/apps/monero/xmr/bulletproof.py), Ledger doesn't (it reuses the Monero code)

There is current tx protocol and the next, there will be just 1 migration plan. It doesn't matter how many wallets are there if all of them must follow current monero tx protocol.

jberman: ledger has security problem due to poorly implemented firmware, so it's kind of their trade-off

s/has/had/

Did you test those ledger patches or real device ? or it's more like a draft ?

* Did you test those ledger patches with real/emulated device ? or it's more like a draft ?

maybe I missed something in my patch, ledger dev seems to think so

but yes I tested

"It doesn't matter how many wallets are there if all of them must follow current monero tx protocol" Unrelated :) To the points I wanted to get accross in that issue

bp+ txs are on testnet created with my ledger

<ooo123ooo1234567> "That issues doesn't focus on..." <- Response in your private messages

(I'm just the monkey in the middle. Aka relaying the message)

rbrunner: I mean that kind of issue should be created by someone who is writing Seraphis implementation

Well, I am quite sure that at least so far ooo and I read each other.

rbrunner: Not from you or ooo, from koe

With enough mutes and ignores communicating becomes a routing problem :)

rbrunner: 👍

In the worst case current Seraphis implementation would be just reference implementation and there will be another which will be integrated into monero

In the best case current Seraphis implementation will consider all edge cases and will be integrated into monero as is

Yes, all true, but I was writing from a point of view where most devs, especially wallet devs, had not idea yet at all what will hit them

That issue wasn't written by wallet dev

Don't understand. That's a problem?

it depends on the balance between noise and useful info, currently there is no alternative so it may be useful

Lol

It isn't clear why there is no single entry point for Seraphis

What do you mean with "entry point"?

which would contain high level overview of required steps and current progress

ooo123ooo1234567: Check pm

Er ... such things don't spring up by themselves, fully formed?

If it's possible to implement something and it isn't R&D then there is already clear plan for actions, but it isn't public yet

Almost 90% of msgs here are unrelated to any research

Maybe, but as I see it, much more than 10% of the messages here are useful one way or another, so there

ok, 99%

My last message wasn't research, sadly. Neither is this one. It really gets worse and worse.

ArticMine is there a link to see your presentation somewhere?

<selsta> "no, it's not months away" <- or it's

github.com/MoneroKon/meta/blob/main/slides/2022/talks.md, these slides ?

<selsta> "Rucknium: the problem is we want..." <- there are many problems at once