<one-horse-wagon[> "Seraphis meeting today at 18...." <- in which room was this meeting?

#no-wallet-left-behind:monero.social atomfried

Meeting 2.5hr

meeting time monero-project/meta #786

1. greetings

hello

Hi

hello

Hello

hi

hello

Hi

2. updates, what's everyone working on?

Released my analysis of mining pools delaying tx confirmations: reddit.com/r/Monero/comments/10gapp…ed_mining_pools_are_delaying_monero . Already HashVault, MoneroOcean, and SupportXMR have started updating their block templates more frequently, according to the pool operators and sech1.

UkoeHB: I'm currently looking for a task

With P2Pool, which already had a frequent update policy, about 60% of Monero's blocks are now being mined with frequent template updates, decreasing the time to first tx confirmation.

Hello

I'm working on understanding the computational complexity issues of OSPEAD.

shalit[m]: Would you have time for a chat with me on Matrix in about 2 hours time? We could look at it

Fantastic news on the template updates. Very strange that this hadn't been noticed earlier. Any idea how long this has been an issue?

me: finished my cleanup/review pass on the seraphis library (took almost 2 months wow - over 50k lines is a lot)

right now doing some finishing touches related to practical enote store handling

rbrunner: yeap, sounds good, so in 19:00 UTC?

blankpage: I don't know how long it's been an issue. Possibly since the beginning of Monero.

I will probably finish the work on the knowledge proofs this week (at least a first functional version with basically all the functionalities that we have today and a bit more) but it will probably change a bit when we go to testnet as the integration with the wallet and new bugs may appear. I would like to thank Koe also for always taking the time for reviewing it thoroughly.

I have been working on my OSPEAD review. It is now at the point of completing the verite up.

I have provided Rucknium with timelines and preliminary results.

Im still working on bp++ implementation, mainly comparing the paper and the c code (not haskell code), hopefully something more tangible next week (this is definitely dragging too long, sorry)

Someone on Reddit suggested checking these repos and creating GitHub issues to change the default block template update time: github.com/oliverw/miningcore , github.com/zone117x/node-open-mining-portal

thanks vtnerd

Thank you, ArticMine !

3. discussion

any topics anyone had in mind? on my end, these PRs could use more review github.com/monero-project/monero/pulls/UkoeHB

In "Avoid selecting coinbase outputs as decoys" monero-project/research-lab #109 I say that this would be a wallet-level change. Now I am not sure if that's totally correct. Would monerod need to change what it sends to wallet software, i.e. exclude coinbase outputs from get_outs RPC call?

I'm not familiar with exactly how wallet2 does it.. but probably yes

This would require a separate call for coinbase outputs

Same here. But as it's only one software package, I don't think it would matter too much exactly where one changes code

Probably a good question for jberman , too

It could matter because a old-version wallet software could connect with a new-version remote node (or vice versa) and then...? And if I'm an old version wallet that wants to spend my coinbase output (from P2Pool, let's say), and I don't see my owned output in the reply from monerod remote node, what would I do?

This is if the change would happen outside of a hard fork boundary.

The RPC interface is somewhat flexible regarding compatibility, I think you could add something to the RPC answer of `get_outs` that tells the wallet what to expect

and then react accordingly

(the new wallet would find out whether it talks to a new or an old daemon)

Ok. I'm not sure of the next steps with this idea. I guess we can leave it open for a while longer and see if any arguments to the contrary surface. I've described the privacy risks of the status quo.

It would have to be implemented only at the wallet level unless it is done with a hard fork

it increases the complexity of making txs which basically increases dependency on the core wallet implementation

not that there are many txs being made with anything else, but it's still a cot

cost

anything else to bring up? otherwise we can end the meeting early

ok I'll call it here, thanks for attending everyone

Thanks for hosting

There's a bit of work involved at the monerod db level too in addition to changes to the RPC interface. Would need to start storing both the cumulative count of coinbase and count of non-coinbase outputs at each block, separately. Would need a db migration to store those counts for existing outputs

jberman[m]: idk if cumulative counts would quite work; without a hf coinbase and regular enotes would still share an address space

not sure I follow there

you could bucket coinbase and regular enotes separately in the db without a hf today

cumulative count is just a compact representation of the index, if you are bucketing the index then you need a different strategy; one possibility is just recording the number of coinbase enotes per block; if coinbase enotes are always ordered at the beginning or end of a block then you can infer their indices from the existing cumulative count

Ah, ya I see what you're saying. Ya I agree recording num coinbase enotes per block alongside total cumulative count is a better strategy

Welllll... nevermind. I think in theory, it would make more sense to start using different indexes for coinbase enotes + non-coinbase enotes separately when selecting a decoy. I agree that cumulative amounts aren't enough, the daemon would also need to store the coinbase index for each coinbase enote and non-coinbase index for each non-coinbase enote. You wouldn't need a hf this way though, the wallet could still ultimately

reference its chosen outputs by global index in the final ring

Why I think this is the way to go: let's say p2pool creates the last 90k enotes out of 100k in the chain. The way the decoy selection algo works.. a user spending a non-coinbase output is going to be heavily affected by p2pool into selecting those recent 10k non-coinbase enotes, versus older non-coinbase enotes in the chain

Considering the point of the change is to avoid the impact coinbase outs have on decoy selection, it makes sense to separate the 2 types completely when selecting decoys (I think it would probably even make sense to consider using a different distribution with different params for each type since spending patterns on coinbase enotes are going to be way different than normal enotes)

yeah if you don't want to have to 'reattempt' or hack the decoy selection algorithm a bunch then you can lens the index set to get separate views of coinbase vs non-coinbase, then map back into global space after decoy selection