00:35:53 <br-m> <ofrnxmr> Doge, zcash, any other pow coin, they dont actually care about pool dominance
00:36:35 <br-m> <ofrnxmr> isnt like 70% of Btc hashrate all the same pool operator behind the curtain
00:37:42 <br-m> <ofrnxmr> If qubic, or fed.gov became a dominant pool, none of these miners would care. They already mine on compliant pools and censor txs
00:38:50 <br-m> <ofrnxmr> Attacking monero only makes noise, because 1) our txs can be invalidated 2) we care about pool dominance
00:39:26 <br-m> <ofrnxmr> This attack wouldnt work on zcash, because they dont give a shit that 75% of hashrate is on 1 pool
00:40:59 <DataHoarder> 22:50:37 <br-m> <privacyx> It appears the laregest monero pools like supportxmr and nanoppool have teamed up to fight against Qubit selfish mining by selfish mining
00:41:21 <DataHoarder> no, you can see that yourself with logs
00:42:29 <DataHoarder> I found it funny on their self-made FUD so also added stratum tracking for other pools on the tips.txt
00:43:25 <DataHoarder> They also seem to misunderstand timestamps are entirely miner set and within p2pool it wasn't uncommon to see people with clocks more than six hours apart (future/past)
00:43:51 <DataHoarder> I think we now limit this to like 30m or so as it was making effectively invalid blocks at that point 
00:48:30 <DataHoarder> You need to explicitly keep track of when blocks and alt chains arrive on your node(s) and for that you need higher monero verbosity. nioc explanation of it being sluggish in broadcasting is correct
00:49:05 <DataHoarder> Qubic also has a very delayed switch time that causes their blocks to naturally orphan more
01:23:39 <br-m> <kerenken:matrix.org> How is p2pool orphanic qubic?
01:26:13 <DataHoarder> qubic is either not finding enough blocks to be able to make a longer altchain in time or it's hit by their own made severe transmission delay
01:27:36 <DataHoarder> Orphaning is not free - you need longer chains (or well
01:27:40 <DataHoarder> more work)
01:27:48 <DataHoarder> https://irc.gammaspectra.live/447f79a58a62cb47/IMG_6877.jpeg 
01:28:24 <DataHoarder> In this cases qubic was one block ahead, but then Monero found two in a row before qubic could broadcast a longer chain
01:28:43 <DataHoarder> If you follow tips.txt it mentions when either side needs more blocks to orphan the other
01:47:54 <br-m> <barthman132:matrix.org> Aaajww291: It takes months for him to actually make that change. The fact that our pools are orphaning his blocks now probably isn’t helping him, but because the barrier of entry to attack monero is low. It probably won’t matter anyway
08:16:41 <br-m> <privacyx> Not sure if this has been suggested or discussed but would instead of purely “longest chain wins,” nodes could incorporate propagation speed into tie-breaking decisions.
08:34:11 <br-m> <privacyx> Or heaviest chain wins ( eg. total difficulty)
08:36:12 <br-m> <privacyx> I was reading this paper about defense systems to prevent or reduce risk of selfish mining & double spend attacks
08:36:12 <br-m> <privacyx> https://arxiv.org/pdf/2307.00529
08:37:50 <plowsof> That ones "a dud" sadly
08:38:56 <plowsof> tevador and Rucknium left comments about it in the prev meeting 
08:41:20 <br-m> <privacyx> Oh I missed it thanks
11:40:48 <nioc> DataHoarder: site is behind 200+ blocks and not updating 
11:55:29 <DataHoarder> nioc: indeed, lemme see
12:03:17 <DataHoarder> nioc: some upstream monerod had died, switched to local. upstream ZMQ kept running but I couldn't use RPC :D
12:04:05 <DataHoarder> 10:34:11 <br-m> <privacyx> Or heaviest chain wins ( eg. total difficulty)
12:04:14 <DataHoarder> this is effectively already done, not longest
12:04:25 <DataHoarder> within short periods longest = heaviest
12:53:54 <DataHoarder> next qubic marathon, Thursday 12:00 utc
12:54:30 <DataHoarder> I made a $5/m setup on DO :D
12:55:54 <DataHoarder> hopefully that runs some of the reporting, no idea if that can run xmrconsensus @rucknium?
12:57:35 <br-m> <rucknium> You mean you want to run another public-facing xmrconsensus instance?
12:59:46 <DataHoarder> to expose the one that I have with tagged qubic, unless you have time to improving what you are missing to include it on yours
13:00:18 <DataHoarder> maybe I should cache the last generated image instead and just display that on a page :D
13:01:47 <br-m> <rucknium> IIRC, xmrconsensus doesn't consume a lot of RAM. CPU usage is low if number of users is low. You would want to use shiny-server to serve it publicly.
13:04:34 <br-m> <rucknium> Just checked top. The R process of moneroconsensus.info is using 0.8 GB of RAM (with ??? users). shiny-server is using 0.1 GB of RAM.
13:05:15 <DataHoarder> very nice then
13:05:20 <br-m> <rucknium> You need access to an unrestricted RPC port
13:05:50 <br-m> <rucknium> The URL of the unrestricted RPC port is configurable, but you need unrestricted.
13:07:51 <br-m> <rucknium> Config instructions: https://github.com/Rucknium/xmrconsensus?tab=readme-ov-file#run-xmrconsensus
13:08:28 <DataHoarder> yeah, I run one of my instances already but it's on a "bloated" spec wise system
13:08:52 <DataHoarder> I had an R corrupted db a couple of times by having two sessions open...
13:09:32 <br-m> <rucknium> If you want to run it with shiny-server, you would edit line 7 of this file: https://github.com/Rucknium/xmrconsensus/blob/main/app.R#L7
13:10:24 <DataHoarder> I run it manually via $ xmrconsensus::run_app(options = list(launch.browser = FALSE, port = 8474, host = "0.0.0.0"))
13:10:26 <br-m> <rucknium> I mean, if you wanted to change the default URL of the unrestricted RPC and you wanted to run it in shiny-server
13:14:46 <br-m> <rucknium> If you're using Digital Ocean, it looks like there is already a Droplet with shiny-server : https://deanattali.com/2015/05/09/setup-rstudio-shiny-server-digital-ocean/
13:15:28 <DataHoarder> eh, I can install the needed things :D
13:15:49 <DataHoarder> woah that's a long tutorial
13:16:06 <br-m> <rucknium> It's single-threaded, so the worst it can do is lock up a single CPU thread.
13:16:17 <DataHoarder> good! it has a single CPU core :)
13:16:51 <br-m> <rucknium> DataHoarder: Remember, it's written for scientists. Every little thing needs explaining.
13:17:46 <DataHoarder> yeah, I noted that with the RStudio line "Great, R is working, but RStudio has become such an integral part of our lives that we can’t do any R without it!"
13:18:17 <DataHoarder> I opened the R code on jetbrains code IDE :DD 
13:20:46 <DataHoarder> I remember implementing some state-of-the-art paper on complex audio fingerprinting (with amazing performance both in matching and runtime already) in "non-scientist code" and not only did I find bugs on original implementation but made it two orders of magnitude more efficient runtime wise, and the bug fix improved matching!
13:23:06 <DataHoarder> or "yeah I don't have a gamma function available in my toolset" so ended up with clamping to positive integers, using factorials and adjusting the algorithm to only work on Integers instead of complex or real numbers
13:24:07 <DataHoarder> anyhow, thanks rucknium I'll try to get one of these running but then only display online the last cached image
13:26:41 <br-m> <rucknium> Shiny has pretty easy-to-implement cacheing if you want to display the whole app. Then just disable the different display options so everyone sees the same view.
13:29:00 <DataHoarder> all I see as a dev is a websocket call sending 3 MiB of png data to every user :D
13:29:48 <DataHoarder> I'll extract that as a standalone png, and make webp/avif/png versions to serve clients optimally in a page that refreshes
13:30:04 <DataHoarder> and images will get just cached by browsers and/or buttflare
15:01:52 <DataHoarder> rucknium (and for others) https://qubic-snooper.p2pool.observer/tree/ page refreshes every 30s or so automatically
15:05:59 <br-m> <rucknium> Very nice :)
15:05:59 <br-m> <rucknium> You can display the timestamps (if they aren't too verbose for you) by pulling in the latest: git pull.
15:06:20 <DataHoarder> I'm already reaching close to the max length I can encode on webp :D
15:06:30 <DataHoarder> I might split the image in chunks to allow that
15:06:52 <DataHoarder> had to lower desired pixel density from 2x to 1.5x :D
15:07:08 <DataHoarder> originally I displayed 250 entries as well on my instance
15:07:50 <DataHoarder> image data is cached by cloudflare, so it's nice
15:08:16 <DataHoarder> all I'm doing is send websocket jobs to xmrconsensus and handling data, or sending refresh jobs if it doesn't send new ones
16:38:51 <br-m> <ofrnxmr:xmr.mx> Its pretty much a design flaw that reorgs permanently invalidate decoys (aiui, due to using output indexing)
16:38:51 <br-m> <ofrnxmr:xmr.mx> anyway, this is also an issue for fcmp
16:39:43 <br-m> <ofrnxmr:xmr.mx> Arguably worse for fcmp
16:39:43 <br-m> <ofrnxmr:xmr.mx> https://github.com/seraphis-migration/monero/pull/81#issuecomment-3197430438
16:39:43 <br-m> <ofrnxmr:xmr.mx> > if a pool tx's FCMP++ reference height is >= 10 current chain tip [...] the daemon could end up needlessly trying to re-validate a tx that would never re-validate correctly.
17:15:18 <br-m> <chaser> does the Generalized Schnorr Protocol in the FCMP++ SA/L proofs require special support from hardware devices, or is Ed25519 support sufficient?
20:44:17 <br-m> <jeffro256> Hardware devices will have to run SA/L-specific code, like they do for CLSAG signing, but the hardware requirements are not prohibitively expensive; instead they are comparable to 16-member CLSAG signing