<d​iw_tim:matrix.org> You were completely wrong.

<d​iw_tim:matrix.org> Which is why I, along with many others, were able to make money from Qubic's stupidity, rather than spreading misinformation.

<d​iw_tim:matrix.org> From the profits I earn through shorting Qubic, 10% will be donated towards CCS proposals. Funding Monero's growth from Qubic's decline. What are you doing other than spreading FUD?

<b​arthman132:matrix.org> Your 10 dollars will be a good addition to development budget. I was buying hashrate to slow Qubic down when they were at their peak

<b​arthman132:matrix.org> Your 10 dollars will be a good addition to the development budget. I was buying hashrate to slow Qubic down when they were at their peak

<b​arthman132:matrix.org> But in all seriousness though. was i wrong? Yeah I was, but don’t really want to play dumb gotcha games and I’m actually glad I was wrong

qubic has started selfish mining attempts according to pool data

but seems they fell behind

they don't have more than network currently

<o​ne-horse-wagon:monero.social> What do you mean by "more than network currently"?

51%

so they can still get lucky and get some orphans

<o​ne-horse-wagon:monero.social> Yes, they are far from it. Seems like they have lost some miners and mining power as a result in the last few days.

<s​yntheticbird:monero.social> TOTAL BOT ANNIHILATION

<r​ucknium:monero.social> Does anyone object to me locking & closing this issue? "The true target is consensus to change the PoW." monero-project/research-lab #143

seems they have been able to win and orphan one monero block

<s​yntheticbird:monero.social> Rucknium, no objection, this is reddit tier post

<b​asses:matrix.org> will be faced with reddit tier action

<b​arthman132:matrix.org> They orphaned a block. o well I guess

<b​arthman132:matrix.org> Well solutions like kayabanerve is to add a finality layer to stop big reorgs from occurring. repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604. Other solutions are to change the pow entirely like moving to a hybrid system to replace the current pow or others suggest moving to POS entirely.

<b​arthman132:matrix.org> The question on how to get more miners to mine monero. Is a tricky one, because the biggest reason why is simply because the price of monero has stayed stagnant for too long and due to rising electricity costs. There is simply a lot less incentive to mine it compared to like 2018 when random X was first introduced

<b​arthman132:matrix.org> The question on how to get more miners to mine monero. Is a tricky one, because the biggest reason why more miners don’t mine is simply because the price of monero has stayed stagnant for too long and due to rising electricity costs. There is simply a lot less incentive to mine it compared to like 2018 when random X was first introduced

they are further ahead now

<l​ordx3nu:matrix.org> looks like they got 9

irc.gammaspectra.live/4b289b6022729287/image.png

yeah they released it early

you can see they still were ahead a bit

<b​arthman132:matrix.org> Good lord our pools are performing terrible

<t​esttank:matrix.org> They’ve mined the last 20 blocks (?)😬

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/lugwCthMqqrDmbQNjIYJgplL

they are ignoring new blocks

they are going backwards in heights to orphan all that exist above theirs

seems like their new orphan chain starts at 25

they are mining at height 30' now

they are +3 to known tip

<l​ordx3nu:matrix.org> hm

no change in hashrate on their pools

+4

either their hashrate is underreported or they are getting some extreme luck

or they have hashrate outside of pools that is not reported

<l​ordx3nu:matrix.org> ok i bought hash, prioritizing pools that aren't reporting any activity today

<o​frnxmr:xmr.mx> How does the activity look?

<o​frnxmr:xmr.mx> Are a lot of the big ones mining already?

<l​ordx3nu:matrix.org> no

<o​frnxmr:xmr.mx> Hm. I wonder why

<l​ordx3nu:matrix.org> what are they at now?

<b​arthman132:matrix.org> They got 47 out of 100 blocks

<b​arthman132:matrix.org> 49 out of 100

<b​arthman132:matrix.org> I’m sure I’m going to be told it’s all fud

<b​arthman132:matrix.org> They must be massively underreporting their actual hashrate

<b​arthman132:matrix.org> They’re likely at 3gh/s instead of 1.8 or whatever they say it is

<b​arthman132:matrix.org> They’re at 51

<o​frnxmr:xmr.mx> how many blocks were orphaned

<b​arthman132:matrix.org> 33

<o​frnxmr:xmr.mx> if 40 orphans, then they got 40/140

<b​arthman132:matrix.org> Gotcha, they’re doing massive disruption to the network

<l​eonarth_:matrix.org> 14 blocks reorg

<o​frnxmr:xmr.mx> Really? If so, i guess its time we fight dirty

<b​arthman132:matrix.org> Yeah they were able to get a massive reorg

<o​frnxmr:xmr.mx> Looks like 26-36 here

<b​arthman132:matrix.org> Ok nannoopool got 3 blocks, so at least that gives us some breathing room

<t​esttank:matrix.org> Wen dns?

<b​arthman132:matrix.org> We should do it now. They’re likely underreporting their own hashrate anyways

<o​frnxmr:xmr.mx> We cant do it now

<b​arthman132:matrix.org> When is it going to be ready?

<o​frnxmr:xmr.mx> Current dns setup will reorg up to 1hour of blocks and cause more damage than qubic

<b​arthman132:matrix.org> Ok gotcha, but they were able to do a massive 14 block reorg in like 50 minutes

<b​arthman132:matrix.org> Nanopool got a 4th block, so our unlucky streak seems to be over at least for now

they are mining on top of it at least

<b​arthman132:matrix.org> At least it’s something I guess. We stopped their reorgs, but it’s still 33 blocks that were reorged

did we stop their reorgs? :D

<t​esttank:matrix.org> Cum_from_behind said on their Discord that 9 block re-org is the max that they can do

<t​esttank:matrix.org> Wonder why is that

<l​ordx3nu:matrix.org> The Monero Defense Fund saves the day ;)

that's cause they set a limit to not let anyone do double spends

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/RHXqPNrtqKVJOTrtzKTYZqxK

not technical limitation, just their decision to not allow it

they are mining 45' now

<o​frnxmr:xmr.mx> Datahoarder, but they reorged 10 or 11 :P

<o​frnxmr:xmr.mx> 26-36

<o​frnxmr:xmr.mx> Idk if 26 is included

not included

<b​arthman132:matrix.org> It’s pretty bad either way you slice it.

<s​yntheticbird:monero.social> OFRNXMR SHAME ON YOU FOR USING A REACTION. DATAHOARDER COULDN'T SEE IT FROM MATRIX

<s​yntheticbird:monero.social> SORRY FOR CAPS

<s​yntheticbird:monero.social> from irc*

well, I could see those caps from irc :)

<s​yntheticbird:monero.social> always a pleasure to ruin someone else' screen

<o​frnxmr:xmr.mx> 😁

they are mining 53 at the moment

<l​ordx3nu:matrix.org> from 45?

lost where they started from, but some long chain

they are at tip now

<b​arthman132:matrix.org> They orphaned 38 blocks

<b​arthman132:matrix.org> When does their marathon end?

24h from 12:00 UTC, so at 12 UTC

<b​arthman132:matrix.org> So in like 3 hours?

<b​arthman132:matrix.org> Oh I’m dumb

<o​frnxmr:xmr.mx> :P haha. Like 16hrs

<b​arthman132:matrix.org> So do orphan blocks count towards their blocks count?

<o​frnxmr:monero.social> which count?

they take numbers from 3 different places without regard, compare apple to oranges

<b​arthman132:matrix.org> Well are orphan blocks counted in the mining pool stats

<b​arthman132:matrix.org> They have 56

does it matter?

<b​arthman132:matrix.org> What do you mean?

hey monero orphaned one of their attempts! irc.gammaspectra.live/f708dcb190d5fb6a/image.png

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/xzRGbFquHNVYIOvOeucQvnlu

<l​eonarth_:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/ONvaXrICMebtVTETTgkcbqgq

<l​eonarth_:matrix.org> how did nanopool mine 3 consecutive blocks, selfish mining too?

they appeared in order fine

<l​eonarth_:matrix.org> how do you see qubic on the blocks, I only see unknown on moneroconsensus.info

I made my own source

I run it myself :)

then feed custom source. I sent ruck info on how to add a custom source

I added this commit to monero-blocks git.gammaspectra.live/WeebDataHoard…9dc4698e328250d9d47740569a068aa4779

<l​eonarth_:matrix.org> you scoundrel :)

then you just need to tag qubic blocks yourself you find on the network

<l​eonarth_:matrix.org> made a new package for every pool

<l​eonarth_:matrix.org> using an interface wouldn't work?

there is an interface

for nodejs-pool and the cryptonote ones

the other packages are for custom reporting on each custom pool

see git.gammaspectra.live/WeebDataHoard…s/src/branch/master/main.go#L35-L89

<l​eonarth_:matrix.org> curious why new packages for every pool, could have just been a new file

there's no new packages for every pool

these can also get reused elsewhere

each has their own paging tokens and other data

<l​eonarth_:matrix.org> package xmr_nanopool_org

<l​eonarth_:matrix.org> package xmr\_nanopool\_org, package monero_hashvault_pro

yes. they have a custom api and way of pagination, and otherwise it'd be NewNanoPool()

<l​eonarth_:matrix.org> it's a package for every pool

<l​eonarth_:matrix.org> must make sense, i just don't get it

irrelevant

<l​eonarth_:matrix.org> yeah, why not NewNanoPool()

then not standardized, every package offers the same API and implements a common call / interface

<l​eonarth_:matrix.org> pool.New... auto-completes which one I want

if you have more questions about the code syntax my personal choices of packages (with already given reason), you know #p2pool-observer or relevant can probably take those conversation better than lounge :)

it's not the first time!

<l​eonarth_:matrix.org> sorry for being a hassle, couldn't wrap my head on the design

<l​eonarth_:matrix.org> cheers

more orphans (it's theirs now) irc.gammaspectra.live/29b63483d0d708cc/image.png

<o​frnxmr:xmr.mx> Rucknium can you turn your checkpoint script back on

<k​asmaristo:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/MMISciWAFNTOwtBVoHQvtQqH

<o​frnxmr:xmr.mx> Thsts 9 blocks

<r​ucknium:monero.social> DataHoarder: something strange happened with xmrconsensus. Your image shows an orphaned Qubic block with hash 4fd... at height ...799 , but moneroconensus.info shows orphaned unknown block with hash 055... at height ...799. The rest of the alt chain have the same block hashes.

<o​frnxmr:xmr.mx> 779 on DH's image

which full height?

<k​asmaristo:matrix.org> Good. I mixed them up. Still though. How did they pull that off with only 33%?

data points they had more, for a short burst

not via pools

4fd is 3485781

so indeed, why is that on mine

<r​ucknium:monero.social> Oops, I meant 779. Yes, 3,485,779

I refreshed, now it's gone

seems it's good on tree view

<v​tnerd:monero.social> They could be renting hashrate in bursts? Make the reorgs as deep as possible when they get ahead

full tree image irc.gammaspectra.live/c24ebeb5950f67d2/image.png

<r​ucknium:monero.social> Kasmaristo: monero-project/research-lab #102#issuecomment-2402750881

<r​ucknium:monero.social> See "Table: Duration of meta attack to achieve attack success probability of 50 percent"

they did say that'd it is something they do

<k​asmaristo:matrix.org> Thank you

<v​tnerd:monero.social> Yeah, it makes sense when you take human psychology into the mix

<r​ucknium:monero.social> Kasmaristo: If you have 30% hashpower and try peristently to always re-org 7 blocks, they you have a 50% probability of re-orging 7 blocks after 3.4 hours of trying.

<k​asmaristo:matrix.org> And the probability of 10?

<r​ucknium:monero.social> According to my analysis, based on theorems by others.

<r​ucknium:monero.social> 8.6 hours. The table is in units of days.

<r​ucknium:monero.social> I wrote that analysis when MRL was discussing changing the 10- block lock. It's useful now!

<k​asmaristo:matrix.org> Yes! Thanks for the write up

<r​ucknium:monero.social> The classic Nakamoto attack is well-known, but in MRL we were discussing what happens when an attacker stops and re-starts the attack, which is not what Nakamoto originally analyzed.

<r​ucknium:monero.social> The Nakamoto attack assume that the attacker starts the attack and continues the attack for an infinite length of time.

<r​ucknium:monero.social> So I analyze a "`z` stopping rule" attack.

<r​ucknium:monero.social> The results cooled enthusiasm for reducing the 10 block lock.

<k​asmaristo:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/seZPEYgaEeEJHyCAXVzhWjLg

<k​asmaristo:matrix.org> So if I'm reading this right it would take roughly one day for 5% of the hash power to perform a 1 block reorg?

<k​asmaristo:matrix.org> Or to have a 38% chance

<k​asmaristo:matrix.org> Or .38 days?

<r​ucknium:monero.social> Less than one day. Remember, that's the attacker's only goal. If they have a different strategy, then the numbers would be different. For example, a true profit-driven selfish miner would cause a re-org if it were profitable, not necessarily at a specific `z` re-org depth.

<r​ucknium:monero.social> Right. 0.38 days. Not guaranteed. You reach 50% probability of doing that.

<k​asmaristo:matrix.org> That's...concerning. So why not INCREASE the lock instead?

<k​asmaristo:matrix.org> 48 days for a 30 block reorg is much better than .36 days at 30% hash rate percent

<k​asmaristo:matrix.org> 48 days for a 30 block reorg is much safer than .36 days at 30% hash rate percent. Of course an hour for funds to unlock would be inconvenient.

<k​asmaristo:matrix.org> But is there a way the network could dynamically adjust the block lock amount based on the % of any given pool? Say 30 blocks if any pool has >30%, 20 for 20%, and 10 blocks for 10%?

<k​asmaristo:matrix.org> We dynamically adjust our block size. Why not the block confirmations?

that can be abused :)

<k​asmaristo:matrix.org> Elaborate for me

<r​ucknium:monero.social> The blockchain doesn't know which pool mined each block.

there is no reliable way to detect ^

they could specifically appear as 1% 80 pools

<k​asmaristo:matrix.org> Ah. I see

when they want to make noise, they all appear as one, then suddenly confirmations go up. it also doesn't work against collusion between pools, even if you had a way to identify them

<k​asmaristo:matrix.org> Can it detect orphaned block % somehow?

<k​asmaristo:matrix.org> I guess it wouldn't matter anyway. The selfish mining wouldn't appear until they broadcasted it. Too late at that point

to detect orphaned blocks they'd need to be added to blocks so it can be verified later

if there is no incentive to include them, these won't get added

that effectively gives you an extra prize for doing selfish mining

so it promotes selfish mining.

an attacker could also stay hidden UNTIL they publish the chain that double spends

you would know nothing until it is too late

not even posting normal blocks to chain, but mining in silence, trying again

you would never know they existed, until, they do, and it's done

<k​asmaristo:matrix.org> What's the best solution/s to our current problem? More hash rate (obviously), but a 9 block reorg at 30% is too much

there's bandaids incoming at some point

probably DNS checkpoints, sort of less decentralized as desired

there's suggestions about how to prevent overt selfish mining. but otherwise, most long term changes are still being discussed

<k​asmaristo:matrix.org> In the meantime I sure hope pubic doesn't get lucky enough to pull off a 10 with 30%. That would be awful for pr. The media would have a hayday

they no longer have the hashrate burst of before

<o​frnxmr:monero.social> I was thinking abt the detective mining. I don't think that works if i am mining in secret?

they had ~4GH/s before from estimates

not reported on pool hashrates

no, detective mining doesn't work if detective doesn't know about the mining

<l​m:matrix.baermail.fr> do they mine in secret or do they actually have a pool open to anyone ?

qubic is in the open. it'd work for current situation, but they can also pull different tricks

<r​ucknium:monero.social> ofrnxmr: I think there was a re-org 1.8 days ago on testnet and my checkpointing node was on the wrong side of it.

<r​ucknium:monero.social> I restarted without enforcing DNS checkpoints and got several messages like this:

<r​ucknium:monero.social> ```

<r​ucknium:monero.social> 2025-08-25 22:18:53.463 W CHECKPOINT FAILED FOR HEIGHT 2818109. EXPECTED HASH: <af96b17bcc2b630708fd16a39312ddd26db728039abd622bd108baaba34932c4>, FETCHED HASH: <a8888f04a94b582658f7893dcfe020b35686d3b97407c6d250eaf5616ebc0ada>

<r​ucknium:monero.social> 2025-08-25 22:18:53.463 E WARNING: local blockchain failed to pass a MoneroPulse checkpoint, and you could be on a fork. You should either sync up from scratch, OR download a fresh blockchain bootstrap, OR enable checkpoint enforcing with the --enforce-dns-checkpointing command-line option

<r​ucknium:monero.social> ```

they have a larger reorg in the work, unless they lose it

<o​frnxmr:monero.social> I think the non-checkpointed chain just overtook

<r​ucknium:monero.social> ofrnxmr: After testnet advances 10 blocks, the DNS checkpoints should be up to date. I will turn on DNS checkpoint enforcing on the _checkpointing_ node at that time.

<o​frnxmr:monero.social> I'll make sure to put some hashrate towards the checkpointed chain this time :P. Sorry

are altchains broadcasted widely across the network now?

<r​ucknium:monero.social> You can see the re-orged alt chain at testnetnode4.moneroconsensus.info , etc.

<r​ucknium:monero.social> DataHoarder: Any idea of what's causing it or a fix? I don't completely understand.

it's reverse order

irc.gammaspectra.live/7304f787b9ea53af/image.png

this should be (top to bottom hashes) 05, 4f, ea, 98

the order is instead 98, ea, 4f, 05

is it maybe fct_alt_chains.R line 48/49?

I'm so unfamiliar with R :)

<r​ucknium:monero.social> Thanks. I will look at it.

here's a recently generated csv privatebin.net/?0633283d458731b9#3c…XxSr871Lp9Zz9hD7yiUQcs5tHk8bE4S3CuU

<r​ucknium:monero.social> I had to do some untidy things to get certain display characteristics. Maybe that is causing it.

your live version also seems to be affected

they are trying to attempt longer reorgs according to discord

they are mining at 21 already

+6 over tip

but the chain is way longer

seems like a 15 reorg so far?

<l​ordx3nu:matrix.org> ourch

<l​ordx3nu:matrix.org> ouch

they are at 24

+10 over monero tip plus everything else before that they have before

or well, +9, plus everything before (-1 as what I see is their "next" height)

<b​arthman132:matrix.org> We’re pretty much helpless against them it seems. Anybody who downplayed qubic is looking pretty stupid

it's here

08 until 23

16 reorg

<b​arthman132:matrix.org> Damn

or it "could" have been

they only reorg'd 9 blocks

but they were at height 23 when they decided to push

<l​ordx3nu:matrix.org> datahoarder -- can I tweet that out?

hashes are reversed here due to above bug irc.gammaspectra.live/44b65c08e1794a29/image.png

24 isn't theirs, they have started another selfish altchain from 23

I can't control what you tweet or not, I just hoard data and recently report on it :)

so is the most realistic theory currently that they used cloud providers to get some extra hashrate for like an 1h to do these large reorgs? because they did the same earlier today for some amount of time before they had a more normal block rate again

selsta: data says yes

based on what gingeropolous said yesterday this is really really expensive and nowhere profitable even if they get all the blocks

i guess it's for marketing

until last 20m they peaked at 4GH/s for 50m when estimating blocks, but their solution rate was exactly consistent with 2GH/s

they did the same earlier, where it also shows same increase and "getting ahead" pattern

that estimates at 4.XGH/s as well

this was done a few marathons ago, but something went wrong and instead CfB blamed "sech1 proxy backdoor" as to why it reported higher hashrate, but data then showed the same

so extra 2GH/s that they can sustain for several hours or so

now that they aren't getting "ahead" they are losing blocks to monero network

irc.gammaspectra.live/2612d08c8ba453ed/image.png

their stated goal is marketing, and growing qubic itself. though the narrative has changed many times

<b​arthman132:matrix.org> So the theory is, they purchased around 1.5 to 2gh/s of hashrate?

many parts of qubic itself have been left to die for the past two weeks, most token platforms, and wallets as well, focus has been on actively harming monero and everything else doesn't matter :)

seems they got more hashrate again or very lucky

we know that you can get 2gh/s on cloud providers like azure because we had these cloud botnets that would last 2-3 days

found 34-37 within 15s

they also have effectively moved their operations to operate more like a pool and less an open network

including breaking all miner rewards several times, but ofc, they will just pay out of pocket, money is no issue for them

<b​arthman132:matrix.org> I’m still surprised how much hashrate they still have though. The price of Qubic has dropped quite a bit and they halved, so their miners aren’t making as much as they used to

one person can push an update across all pools and nodes, within a few hours, or otherwise, the centralized arbitrator can replace these anytime

or they just setup systems to bypass their network entirely :)

originally anyone could verify and connect to their network via github.com/qubic/outsourced-computing/tree/main/monero-poc if solutions were correct and count them

they have changed things since (computors cannot verify solutions, only central authority can) and from data gathered, they even completely removed the ability to see these entirely for a period

<o​frnxmr:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) checkpoints ok?

<o​frnxmr:monero.social> nvm, had to use 8888

it's no decentralized network, it's all in the hands of a few people and indeed. they can rent as much hashrate as they want to pay up to achieve their goals, which are not directly "monetarily attributed" with Monero, in their own words, it's just a toy/tool

<b​arthman132:matrix.org> It does seem like qubic blocks are starting to drop, which is good

that is because they didn't have hashrate help

they have a reorg waiting :)

they are mining 38 at the moment

pushed ahead in a couple of minutes, and just waiting there, maybe getting one extra block

<t​uxsudo:nitro.chat> excuse my ignorance, is it not a part of the protocol that would reject a larger than 10 block re-org?

<o​frnxmr:monero.social> No

if a client reconnects, it doesn't know which one is the legit one. so "highest effort" one is picked, which usually means longest

<o​frnxmr:monero.social> @tux

funnily - they are also merge mining Tari and posting their blocks on Tari :)

<v​tnerd:monero.social> Do they even bother to pivot back to AI? Or this cynically all some big ploy to whack pow chains

their AI was not actually done

the qubic mining is a different pow the AI training hasn't hit the core yet :D

<v​tnerd:monero.social> Yeah that's what I mean, was this cynically a pow whacker coin?

take everything you see from that project with this lens: does it hype up, make the news, bring attention?

if so, do it

<v​tnerd:monero.social> I mean if there is no ai, the coin is speculation on the ability to whack other chains or something

the network is complex enough to discourage most people from looking at it, but in the end it's one single entity having authority on who collaborates or runs nodes in it

it's speculation in how big they will be able to get others to speculate on it my making the news

<v​tnerd:monero.social> Ah yes, it's basically just a vehicle to get liquidity for this token, and to profit off it. Still so twisted

not even aicoin, ai is yet another toy/tool for bringing a "marketing purpose" for it

<v​tnerd:monero.social> Right, you pitch different angles to different audiences so that the ngu

<t​uxsudo:nitro.chat> but existing healthy non-malicious nodes wouldn't allow that to happen? So at some point there would be almost like a chain fork

if hyping up it's a crypto distributed coin is going to bring more people than just a central server db, you hype that up

yes, @tux, but nodes don't know if they are on an attacker or legit chain at this moment

it's blocks after all. and time on computers can be wrong. they also don't just need to verify it "now" but be able to sync from blocks 10 years ago in time

which there are checkpoints for, but you can do without checkpoints as well

<o​frnxmr:monero.social> Tux, that idea is in research stage. Max reorg depth, rolling checkpoints

<o​frnxmr:monero.social> Main issue is bootstrapping nodes, if a new or offline node wakes up and starts syncing the wrong chain

or a node actively gets attacked and split from the network, and fed an attackers chain for a while before merging back

<o​frnxmr:monero.social> like, if cake's node was forked onto qubic chain, cake would start checkpointing qubica chain

<o​frnxmr:monero.social> And then refuse to go back to the real chain

<o​frnxmr:monero.social> that being said, you could protect yourself from this by using a private, node as an intermediary

<o​frnxmr:monero.social> Similar to dns checkpoints. The node which the checkpoints are created from, wont be a publicly known node

approximately 1-3 transactions on each qubic block is now made by them

so not only are they trying to selfish mine and orphan blocks, but they are spamming the network with bogus transactions that can be knowingly attributed to them

they also only include a couple more of other transactions, but several times it's also their own

their blocks are not full

would this cause similar issues with these known outputs becoming "tainted"

given they publish their view keys after the end of the epoch, someone afterwards could come back and eliminate all the decoys

examples of their transactions p2pool.io/explorer/search?value=8d5…b43b59781789784be1cdd661e3de811c1d0

fbfd903e37b77793e9a30db90cedfa01b9325e5117f7af23cde2b33162c0fadd

a1e71de849f11f950f98e15a74dbb673ef42a5fc81c49b7fed3e6f299a993594

etc.

they seem to be 1 in 2 out but they had 2 in 2 out before, looking at their past blocks and which transactions had not been published before their blocks come out

which matches what aj suggested on monero-project/research-lab #140#issuecomment-3213511402

currently they have 227 of these transactions I can reliably find