Do we have any research on what might happen to the chain if Russia completely cuts itself off of the internet?

monerobull: Is that an actual possibility? Wouldnt it only take one node to be synced with the rest of the world and connected to the russian internet to keep things straight?

wernervasquez[m]: nonetheless it is an actual possibility

monerobull[m]: i'd imagine the experience with china has resulted in some lessons/info

but idk the situation for monero. for bitcoin a lot of work has gone into this, but bitcoin has a lot more nodes and is somewhat able to rely on "only takes one node" and a small set of volunteers punching holes in the firewall

Russian monero owners will be able to sell their monero, and down the line when they get a massive reorg, they'll get their monero back. Somewhat less security against attacks by others, depending on how much hash is coming from there. Is it not already illegal atm ?

So close to nobody will buy there. Only people who don't realize that. Price going to crash. Some txes made in russia might still be valid when reconnection happens, which would be... fun.

i don't think "people can just wait til the war is over to use their monero again" is a reasonable solution

But pretty quickly no Russian txes will be valid, just the ones picking only old fake outs by chance.

Solution to what ?

ah, sorry, i am conflating things -- i meant "solution to the chain being split by a russian internet cutoff"

but i guess monerobull[m] was not asking for a solution necessarily

just "what would happen"

What could be even more interesting is if an entity were to continue mining at a loss there, with more hash than the rest of the world, which is predicated on not mining at a loss, and not caring much about preventing a reorg to the russian side.

Thankfully, I'm sure this is interesting problem #849743832 for them.

i think in practice there wouldn't be such extremely long reorgs. presumably somebody would be able to sync the chains at least every day or so.

so disruptive and messy, but not liek, a catastrophic years-long reorg

wasn't there a project trying to use radio/short-distance signals to propagate blocks/txs in case of a network outage?

locha mesh

meeting ~2hr (looks like we are missing an agenda

)

this crawler has seen 10k monero nodes: monero.fail/map

monerohash.com/nodes-distribution.html though this one has seen 2.5k. I think this one is a live shot, whereas the monero.fail is a cumulative tally.

Regarding Internet outages, is starlink available in potentially affected areas? I thought I saw a tweet by Musk saying he was a free speech absolutist and would not cut communications unless forced to.

Starlink is not currently offering service to Russia. From cnet.com/home/internet/starlink-satellite-internet-explained

"Per Musk, the list of countries currently serviced by the growing network of low-earth orbit satellites includes the US, Canada, the UK, France, Germany, Austria, the Netherlands, Ireland, Belgium, Switzerland, Denmark, Portugal, Australia and New Zealand. Starlink's preorder agreement includes options for requesting service in other countries, too, including Italy, Poland, Spain and Chile."

That matches with the coverage map shown here: satellitemap.space

There are other satellite internet service providers, but I don't believe any of them would currently service Russia.

is that 2.5k nodes is only those with incoming connections open?

nioc: eprint.iacr.org/2019/411.pdf

<UkoeHB> "meeting ~2hr (looks like we..." <- Agenda (same as last week's agenda) :

thanks

meeting time: monero-project/meta #672

1. greetings

hello

Hi

Hi

Hey

howdy

2. not sure if there are any active topics to discuss; we can at least do updates, what has everyone been working on?

me: I rebased seraphis_lib onto master and started working on multisig seraphis txs, which will use the new multisig_account interface

noice

me: been working on background sync mode mostly

I was thinking: do people think it would be a good idea to try to estimate the effect of minexmr's upcoming change of fee from 1% to 1.1%? The price elasticity of supply, if you will?

to what end?

I could use some time series statistics. Could be a fun and illuminating project.

To figure out how much of an effect the fee raise has, in terms of pool share of hashpower.

You mean in advance, some sort of prediction?

Oh you mean an empirical estimate, not prediction?

Since people have been trying to come up with a way to reduce hashpower concentration, and increasing the fee is one possibility.

Yes, empirical. Ex-post.

I suppose it would be interesting

I am a bit confused - is this more than compare hashrate before / after?

rbrunner: Right. Determine what effect, if any, the fee increase has on minexmr's share of the hashrate.

Since in general we may expect that increasing the fee would cause some miners to shift to lower-fee pools.

Well, yes, I just fail to see where interesting statistics and math come into play

Hasharate after minus hashrate before...?

I am sure I don't yet fully understand your proposal :)

Watching minexmr HR, it changes pretty wildly regardless of the fee.

Would be nice to see if there was a net loss of hr etc? But I think 0.1% isnt enough to discourage bot runners, that are already selling below cost.

If minexmr was the most expensive pool, I think we may see a difference. But 0.1% isnt much, considering a lot of people from xmrig binary and pay 1% ontology already

s/If minexmr was the most expensive pool, I think we may see a difference. But 0.1% isnt much, considering a lot of people from xmrig binary and pay 1% ontology already/If minexmr was the most expensive pool, I think we may see a difference. But 0.1% isnt much, considering a lot of people from xmrig binary and pay 1% on top of the pool fee already /

s/If minexmr was the most expensive pool, I think we may see a difference. But 0.1% isnt much, considering a lot of people from xmrig binary and pay 1% ontology already/If minexmr was the most expensive pool, I think we may see a difference. But 0.1% isnt much, considering a lot of people use the xmrig binary and pay 1% on top of the pool fee already /

It's not so easy as before-after. You need to take into account other trends occurring at the same time, stationarity, etc.

Yeah, it was 51%, now it's what, 35%?

And the "unknown" will change by 3-700k in and out of minexmr

w: Right. So it is unknown whether there will be a detectable effect at all.

Has anyone read up one this thing?

maybe it can be used for squashing ring sigs or make multisig more easy

I glanced at it, afaict it depends on size-linear constructions

ok thats exactly what monero tries to avoid i guess

atomfried: I would like to encourage people to add thoughts about the paper to MoneroResearch.info . That way, comments are more easily organized than in the ephemeral IRC/Matrix:

If anyone doesn't have an account on MoneroResearch.info and wants one , you can PM me or plowsof and we can set you up with an account.

Where could Monero use something like "Extendablity" (just picked from the title)?

(and that looks like a typo, doesn't it?)

i dont realy know thats why i was asking if someone more knowledgable has seen it.

same about that iacr.org/cryptodb/data/paper.php?pubkey=31719

😅

for me it sounds like this could maybe be usefull for the monero ecosystem but i dont know for sure

<rbrunner> "(and that looks like a typo..." <- should it be Extensibility? 😄

or else "Extendability", with one "i" more :) Finding something like this is probably being quite mean to those authors ...

hmm should we end the meeting here?

Any updates on POC wallet?

I have a ccs: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290

My progress: added tx extra, added fee plumbing, started working on multisig tx builder

ok I'll call it; thanks for attending everyone

I have written a golang library for jamtis, I'd like to add the rest of the seraphis stuff as well. However, I have stalled in progress due to real life business.

Would anyone be interested in critiquing what I have so far?

I can take a look

is your goal to have a to-spec implementation?

UkoeHB: yes. My big goal is to have a full monero implememtation in golang. I think jamtis/seraphis is a good place for me to start. I will ping you when I upload it.

sure

<rbrunner> "Where could Monero use something..." <- The paper was originally mentioned in MRL by jeffro256, who stated "IIUC, if this could be applied to Monero, then all the rings signatures in a block could be combined non-interactively for much better anonymity sets"

the privacy benefits are unclear, because anyone who tracks the mempool will know the original ring boundaries

I'm just parroting other's ideas, but another thing mentioned would be tx combining in dandelion as well as once they hit the mempool.

well, it would require active surveillance to achieve that

but the passive surveillance of the blockchain could be sig harder mebbe

i mean, it seems to be beneficial to me. it makes it more difficult for someone to try and trace things on the blockchain if they decide to do so n years from now

<gingeropolous> "well, it would require active..." <- thats an awesome idea,

is this maybe also a step towards the mergability of transactions into one? would this have any space benefits?

any algorithm wizards? I have a set of bit flags (e.g. N total flags, with M + e of them set, with M + e <= N), and want to find all the permutations of the set bit flags where M of them are set. Basically the original is an 'aggregate' filter, and I want to efficiently extract all the embedded filters (each filter has M flags set).

(this is for aggregation-style signing in multisig)

A first step to reducing the problem complexity is to "collapse" the unset N-M-e bits. You're then left with enumerating all the numbers between 0 and 2 ** (M+e) - 1 that have < bits set.

Then you can recover the corresponding bitfields if you saved the indices of the set bits when collapsing.

s/ < / M /

If M+e is not too large, you can have a precalculated table for 2**(M+e) size that says y/n to "does this number have M bits set".

Otherwise, I think intel might have a "nmber of bits in this" insn.

(if <= 32 or 64 bits)

moneromooo: popcnt is the instruction you are looking for here

Thanks.

hmm thanks that helps

the use-case is kind of a one-off per session, so I'm not sure if a table would be performant; I think I will just increment an integer and count the number of bits set to find matches; right now the max number of bits is 16 so it should be fine

sadly std::popcount is c++20...

UkoeHB: when using a for loop to iterate over the bytes of an int, clang is able to detect this and use the popcnt asm instruction. I have tested this for various versions of clang and my guess is that gcc can do this as well

s/bytes/bits/

atomfried[m]: it will convert this?

```

std::uint32_t flags_count{0};

for (std::uint32_t signer_index{0}; signer_index < num_signers; ++signer_index)

flags_count += (filter >> signer_index) & 1;

```

UkoeHB: let me check.

is monero compiled with any `march=...` flags?

uh don't know

let me check in the compiler explorer if gcc will do such a thing without archflags

there is __buildin_popcount if that helps. GCC does not seem to optimize a simple loop into the popcnt instruction. have tested this simple popcnt loop:... (full message at libera.ems.host/_matrix/media/r0/do…b93bec5e550c51315ca83092a3dbb40efe9)

what about a branchless version?

let me check

like:... (full message at libera.ems.host/_matrix/media/r0/do…88b5a0628022e1ac997e563adc50d26e89a)

oh that one worked

yes it works, but only with an `march=...` flag or the `-mpopcnt`flag

-mpopcnt might be implicitly activated by any sse flags if monero uses some of those

well we have this so maybe it works out of the box: github.com/monero-project/monero/bl…8f02a00013e26d6/CMakeLists.txt#L729

yeah this should optimize it if popcnt is available on the architecture

cool thanks for the help :)

Well, you can have a tiny 4 kB, and lookup each 16 bit value, add them all up.

Oh, the clever compiler option's even better :D

Ugh, 64 kB. Not booleans anymore.

i am actually a bit suprised that clang and gcc cannot optimize the version with the if statement :/

It looks like clang wants the -mpopcnt flag

for the if version?

for your version

branchless*

doesnt an march flag work as well?

the march=native flag might not work on the compiler explorer.

oh it does work... I must have used a bad march flag

or maybe it depends on the architecture whether you need -mpopcnt

i guess if the architecture supports popcnt and it is actually faster than the loop, the compiler will use it. at least thats my hope :D

👍