13:18:58 <monerobull[m]> Do we have any  research on what might happen to the chain if Russia completely cuts itself off of the internet? 
13:30:15 <wernervasquez[m]> 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?
13:30:46 <andytoshi> wernervasquez[m]: nonetheless it is an actual possibility
13:31:02 <andytoshi> monerobull[m]: i'd imagine the experience with china has resulted in some lessons/info
13:31:41 <andytoshi> 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
13:33:17 <moneromooo> 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 ?
13:36:28 <moneromooo> 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. 
13:37:02 <andytoshi> i don't think "people can just wait til the war is over to use their monero again" is a reasonable solution
13:37:04 <moneromooo> But pretty quickly no Russian txes will be valid, just the ones picking only old fake outs by chance.
13:38:08 <moneromooo> Solution to what ?
13:38:38 <andytoshi> ah, sorry, i am conflating things -- i meant "solution to the chain being split by a russian internet cutoff"
13:38:44 <andytoshi> but i guess monerobull[m] was not asking for a solution necessarily
13:38:46 <andytoshi> just "what would happen"
13:41:00 <moneromooo> 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.
13:41:27 <moneromooo> Thankfully, I'm sure this is interesting problem #849743832 for them.
13:46:40 <andytoshi> 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.
13:46:53 <andytoshi> so disruptive and messy, but not liek, a catastrophic years-long reorg
14:08:17 <UkoeHB> wasn't there a project trying to use radio/short-distance signals to propagate blocks/txs in case of a network outage?
14:23:25 <gingeropolous> locha mesh
14:55:10 <UkoeHB> meeting ~2hr (looks like we are missing an agenda
14:55:14 <UkoeHB> )
15:31:35 <gingeropolous> this crawler has seen 10k monero nodes: https://monero.fail/map
15:33:01 <gingeropolous> https://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. 
15:40:21 <wernervasquez[m]> 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.
16:04:15 <spackle_xmr[m]> Starlink is not currently offering service to Russia. From https://www.cnet.com/home/internet/starlink-satellite-internet-explained/ 
16:04:15 <spackle_xmr[m]>  "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."
16:04:15 <spackle_xmr[m]> That matches with the coverage map shown here: https://satellitemap.space/
16:04:15 <spackle_xmr[m]> There are other satellite internet service providers, but I don't believe any of them would currently service Russia.
16:32:50 <nioc> is that 2.5k nodes is only those with incoming connections open?
16:46:42 <w[m]> nioc: https://eprint.iacr.org/2019/411.pdf
16:46:48 * w[m] uploaded an image: (108KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/OuYVVAMocnZXShZFnwQCGNGN/Screenshot_20220309_114518.jpg >
16:51:17 <Rucknium[m]> <UkoeHB> "meeting ~2hr (looks like we..." <- Agenda (same as last week's agenda) :
16:51:17 <Rucknium[m]> https://github.com/monero-project/meta/issues/672
16:52:19 <UkoeHB> thanks
17:00:15 <UkoeHB> meeting time: https://github.com/monero-project/meta/issues/672
17:00:22 <UkoeHB> 1. greetings
17:00:22 <UkoeHB> hello
17:00:47 <rbrunner> Hi
17:00:52 <Rucknium[m]> Hi
17:02:15 <xmr-ack[m]> Hey
17:02:50 <jberman[m]> howdy
17:04:43 <UkoeHB> 2. not sure if there are any active topics to discuss; we can at least do updates, what has everyone been working on?
17:06:18 <UkoeHB> me: I rebased seraphis_lib onto master and started working on multisig seraphis txs, which will use the new multisig_account interface
17:07:05 <jberman[m]> noice
17:07:58 <jberman[m]> me: been working on background sync mode mostly
17:09:29 <Rucknium[m]> 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?
17:10:03 <UkoeHB> to what end?
17:10:08 <Rucknium[m]> I could use some time series statistics. Could be a fun and illuminating project.
17:10:44 <Rucknium[m]> To figure out how much of an effect the fee raise has, in terms of pool share of hashpower.
17:11:02 <rbrunner> You mean in advance, some sort of prediction?
17:11:07 <UkoeHB> Oh you mean an empirical estimate, not prediction?
17:11:29 <Rucknium[m]> Since people have been trying to come up with a way to reduce hashpower concentration, and increasing the fee is one possibility.
17:11:41 <Rucknium[m]> Yes, empirical. Ex-post.
17:12:15 <UkoeHB> I suppose it would be interesting
17:12:44 <rbrunner> I am a bit confused - is this more than compare hashrate before / after?
17:13:28 <Rucknium[m]> rbrunner: Right. Determine what effect, if any, the fee increase has on minexmr's share of the hashrate.
17:14:02 <Rucknium[m]> Since in general we may expect that increasing the fee would cause some miners to shift to lower-fee pools.
17:14:08 <rbrunner> Well, yes, I just fail to see where interesting statistics and math come into play
17:14:24 <rbrunner> Hasharate after minus hashrate before...?
17:14:38 <rbrunner> I am sure I don't yet fully understand your proposal :)
17:15:23 <w[m]> Watching minexmr HR, it changes pretty wildly regardless of the fee.
17:15:23 <w[m]> 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.
17:15:23 <w[m]> 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 
17:15:34 <w[m]> 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 /
17:16:10 <w[m]> 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 /
17:16:14 <Rucknium[m]> It's not so easy as before-after. You need to take into account other trends occurring at the same time, stationarity, etc.
17:16:24 <rbrunner> Yeah, it was 51%, now it's what, 35%?
17:16:51 <w[m]> And the "unknown" will change by 3-700k in and out of minexmr
17:17:25 <Rucknium[m]> w: Right. So it is unknown whether there will be a detectable effect at all.
17:22:53 * w[m] uploaded an image: (390KiB) < https://libera.ems.host/_matrix/media/r0/download/monero.social/KTCVhJqDqLbqDsOgYdQPJEPl/Image_55.jpg >
17:24:41 <atomfried[m]> Has anyone read up one this thing?
17:24:41 <atomfried[m]> https://www.youtube.com/watch?v=2glB7Cr6Jhw
17:24:41 <atomfried[m]> https://iacr.org/cryptodb/data/paper.php?pubkey=31723
17:24:41 <atomfried[m]> maybe it can be used for squashing ring sigs or make multisig more easy
17:25:19 <UkoeHB> I glanced at it, afaict it depends on size-linear constructions
17:26:46 <atomfried[m]> ok thats exactly what monero tries to avoid i guess
17:26:46 <Rucknium[m]> 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:
17:26:57 <Rucknium[m]> https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=47
17:27:48 <Rucknium[m]> 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.
17:27:59 <rbrunner> Where could Monero use something like "Extendablity" (just picked from the title)?
17:28:47 <rbrunner> (and that looks like a typo, doesn't it?)
17:34:58 <atomfried[m]> i dont realy know thats why i was asking if someone more knowledgable has seen it.
17:35:36 <atomfried[m]> same about that https://iacr.org/cryptodb/data/paper.php?pubkey=31719
17:35:36 <atomfried[m]> 😅
17:35:36 <atomfried[m]> for me it sounds like this could maybe be usefull for the monero ecosystem but i dont know for sure
17:35:51 <plowsof[m]> <rbrunner> "(and that looks like a typo..." <- should it be Extensibility? 😄
17:36:53 <rbrunner> or else "Extendability", with one "i" more :) Finding something like this is probably being quite mean to those authors ...
17:37:11 <UkoeHB> hmm should we end the meeting here?
17:38:37 <w[m]> Any updates on POC wallet?
17:38:58 <UkoeHB> I have a ccs: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/290
17:39:50 <UkoeHB> My progress: added tx extra, added fee plumbing, started working on multisig tx builder
17:41:23 <UkoeHB> ok I'll call it; thanks for attending everyone
17:42:20 <wernervasquez[m]> 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.
17:42:47 <wernervasquez[m]> Would anyone be interested in critiquing what I have so far?
17:43:03 <UkoeHB> I can take a look
17:43:39 <UkoeHB> is your goal to have a to-spec implementation?
17:44:47 <wernervasquez[m]> 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.
17:44:54 <UkoeHB> sure
17:47:00 <spackle_xmr[m]> <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"
17:48:31 <UkoeHB> the privacy benefits are unclear, because anyone who tracks the mempool will know the original ring boundaries
17:50:35 <spackle_xmr[m]> 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.
17:50:38 <gingeropolous> well, it would require active surveillance to achieve that
17:50:59 <gingeropolous> but the passive surveillance of the blockchain could be sig harder mebbe
17:55:03 <gingeropolous> 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
20:35:33 <atomfried[m]> <gingeropolous> "well, it would require active..." <- thats an awesome idea,
20:36:13 <atomfried[m]> is this maybe also a step towards the mergability of transactions into one? would this have any space benefits?
20:53:13 <UkoeHB> 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).
20:54:19 <UkoeHB> (this is for aggregation-style signing in multisig)
20:56:55 <moneromooo> 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.
20:57:29 <moneromooo> Then you can recover the corresponding bitfields if you saved the indices of the set bits when collapsing.
20:58:04 <moneromooo> s/ < / M /
20:58:59 <moneromooo> 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".
20:59:41 <moneromooo> Otherwise, I think intel might have a "nmber of bits in this" insn.
20:59:53 <moneromooo> (if <= 32 or 64 bits)
21:00:27 <atomfried[m]> moneromooo: popcnt is the instruction you are looking for here
21:00:38 <moneromooo> Thanks.
21:04:09 <UkoeHB> hmm thanks that helps
21:38:10 <UkoeHB> 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
21:38:36 <UkoeHB> sadly std::popcount is c++20...
21:41:25 <atomfried[m]> 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
21:41:36 <atomfried[m]> s/bytes/bits/
21:45:29 <UkoeHB> atomfried[m]: it will convert this?
21:45:29 <UkoeHB> ```
21:45:29 <UkoeHB> std::uint32_t flags_count{0};
21:45:29 <UkoeHB>     for (std::uint32_t signer_index{0}; signer_index < num_signers; ++signer_index)
21:45:29 <UkoeHB>       flags_count += (filter >> signer_index) & 1;
21:45:29 <UkoeHB> ```
21:47:12 <atomfried[m]> UkoeHB: let me check.
21:47:12 <atomfried[m]> is monero compiled with any `march=...` flags?
21:47:55 <UkoeHB> uh don't know
21:48:24 <atomfried[m]> let me check in the compiler explorer if gcc will do such a thing without archflags
21:55:50 <atomfried[m]> 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 https://libera.ems.host/_matrix/media/r0/download/libera.chat/be5e0b93bec5e550c51315ca83092a3dbb40efe9)
21:56:08 <atomfried[m]> https://godbolt.org/z/6WY84ss57
21:58:25 <UkoeHB> what about a branchless version?
21:59:38 <atomfried[m]> let me check
21:59:38 <atomfried[m]> like:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6c25188b5a0628022e1ac997e563adc50d26e89a)
22:00:12 <UkoeHB> oh that one worked
22:01:09 <atomfried[m]> yes it works, but only with an `march=...` flag or the `-mpopcnt`flag
22:02:13 <atomfried[m]> -mpopcnt might be implicitly activated by any sse flags if monero uses some of those
22:03:34 <UkoeHB> well we have this so maybe it works out of the box: https://github.com/monero-project/monero/blob/d562deaaa950979b7a31a441a8f02a00013e26d6/CMakeLists.txt#L729
22:04:20 <atomfried[m]> yeah this should optimize it if popcnt is available on the architecture
22:07:46 <UkoeHB> cool thanks for the help :)
22:08:05 <moneromooo> Well, you can have a tiny 4 kB, and lookup each 16 bit value, add them all up.
22:08:40 <moneromooo> Oh, the clever compiler option's even better :D
22:09:44 <moneromooo> Ugh, 64 kB. Not booleans anymore.
22:11:16 <atomfried[m]> i am actually a bit suprised that clang and gcc cannot optimize the version with the if statement :/
22:14:37 <UkoeHB> It looks like clang wants the -mpopcnt flag
22:15:19 <atomfried[m]> for the if version?
22:16:05 <UkoeHB> for your version
22:16:24 <UkoeHB> branchless*
22:16:56 <atomfried[m]> doesnt an march flag work as well?
22:16:56 <atomfried[m]> the march=native flag might not work on the compiler explorer.
22:17:47 <UkoeHB> oh it does work... I must have used a bad march flag
22:18:12 <UkoeHB> or maybe it depends on the architecture whether you need -mpopcnt
22:22:05 <atomfried[m]> 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
22:23:24 <UkoeHB> 👍