As mentioned several times in this channel, > 21:48:43 <m-relay> <p​rivacyx:monero.social> Why is Qubic jumping in and out in short bursts in its mining of monero? It makes no sense

Qubic when not in marathon, they mine Monero only during half their time, based in ticks

<t​allhatdoug:matrix.org> testnetnode4 has deeper reorgs than testnetnode3? how did the network heal?

<t​allhatdoug:matrix.org> all I can tell is that testnetnode4 has less orphaned blocks

<o​frnxmr:xmr.mx> By the checkpointed network overtaking the attacking network

<t​allhatdoug:matrix.org> is that after block ...286?

<o​frnxmr:xmr.mx> Testnetnode4 is using dns checkpoints

<o​frnxmr:xmr.mx> There were a few reorgs

<o​frnxmr:xmr.mx> The small 2 block reorg was common for both networks

<t​allhatdoug:matrix.org> 103 -> 120

<t​allhatdoug:matrix.org> massive reorg :(

<o​frnxmr:xmr.mx> The larger reorgs were rejected due to checkpointing

<o​frnxmr:xmr.mx> This was all testing

<t​allhatdoug:matrix.org> I think I see it now so 298 -> 317 from testnode3 is not in testnode4

<o​frnxmr:xmr.mx> The reorgs are on purpose

<t​allhatdoug:matrix.org> for example

<t​allhatdoug:matrix.org> bravo ofrn!

<t​allhatdoug:matrix.org> if qubic becomes a slient pool, will dns checkpoints still work?

<o​frnxmr:xmr.mx> All nodes have same history

<o​frnxmr:xmr.mx> Testnetnode3 was send a large reorg

<o​frnxmr:xmr.mx> Testnetnode3 then dropped the "honest" blocks, and replaced with the attackers blocks

<o​frnxmr:xmr.mx> testnetnode4 uses checkpoints. When encountering the attackers large reorg, it ignores is entirely.

<o​frnxmr:xmr.mx> Testnetnode4 carries on as usual.

<o​frnxmr:xmr.mx> testnetnode4's blockheight surpasses testnetnode3/theattackers, and testnetnode3 and the rest of the non-checkpointed nodes are reorged again, dropping the attacking chain

<o​frnxmr:xmr.mx> Yes

<o​frnxmr:xmr.mx> dns checkpoints dont care who the attacker is, only care about depth if the attack and if >50% of honest hash is using the checkpoints

<t​allhatdoug:matrix.org> wow this is impressively effective

<o​frnxmr:xmr.mx> Sorry

<t​allhatdoug:matrix.org> hopefully nodes don't choose to opt out in the meantime...

<o​frnxmr:xmr.mx> Yeah. We have the checkpoints tweaked to allow 2 block reorgs, which are pretty normal

<t​allhatdoug:matrix.org> I don't think dns checkpoints adds any overhead for node operators?

<o​frnxmr:xmr.mx> Nodes dont reallt matter

<o​frnxmr:xmr.mx> Only miners do

<t​allhatdoug:matrix.org> so pools need to implement this?

<o​frnxmr:xmr.mx> yea

<t​allhatdoug:matrix.org> I need to figure it out then 😆

<o​frnxmr:xmr.mx> Without pools, its useless

<o​frnxmr:xmr.mx> The node that the pool uses will just need to ass --enforce-dns-checkpointing and run a yet-to-be-released version

<o​frnxmr:xmr.mx> Add*

<t​allhatdoug:matrix.org> what happens if big pools like qubic choose to opt out? what is the number of pools needed to make dns checkpoints work effectively?

<o​frnxmr:xmr.mx> then their blocks get orphaned

<o​frnxmr:xmr.mx> 51% :P

<o​frnxmr:xmr.mx> As long as checkpointed nodes produce more honest hash than attacker, it should work smoothly

<t​allhatdoug:matrix.org> will p2pool reflect this change?

<o​frnxmr:xmr.mx> If qubic actually attempted a 51% attack or had >51% hashpower, then non-checkpointed nodes would get pulled onto their chain.. fracturinf the network into 2 parts

<o​frnxmr:xmr.mx> Thats the dangerous part.

<t​allhatdoug:matrix.org> I don't think there is enough hash rate to sustainably rent for qubic to 51% attack

<t​allhatdoug:matrix.org> otherwise they would have done it already

<o​frnxmr:xmr.mx> You never know what a desperate adversary might do

03:57:47 <m-relay> <o​frnxmr:xmr.mx> Only miners do

and any other user that prefers to stick to this chain

they have done it already tallhatdoug, but in bursts

they can sustain it if needed for several hours and can get very far ahead

<o​frnxmr:xmr.mx> datahoarder, other users get pulled back onto the majority chain regardless of their settings

over time, yes, exchanges might want to stick to ours quicker

<o​frnxmr:xmr.mx> yea

03:58:28 <m-relay> <t​allhatdoug:matrix.org> I need to figure it out then 😆

as said get recent monerod and run with --enforce-dns-checkpointing

<t​allhatdoug:matrix.org> D​ataHoarder -> is it due to qubic's rented hash rate not appearing on their api?

that's all for now

<t​allhatdoug:matrix.org> will do!

yeah, not just the API

I shared some specific charts of the interest periods

just assume that they can get +2GH/s at least in bursts over their normal hashrate

good work testing dns checkpoints :)

I'm adding these to monero-pools so they appear in the CSV if they want to be ingested!

monero-blocks*

<t​allhatdoug:matrix.org> DataHoarder -> is this research report misleading or outdated? it says that qubic did not reach 51% of the total network hash rate:

<t​allhatdoug:matrix.org> shai-deshe.gitbook.io/parallel-thou…f-of-work/the-qubic-minority-report

this is outdated and also only uses data from found blocks

<t​allhatdoug:matrix.org> 👍️

we have data from all their solutions (640M each) including their high difficulty ones that could have found blocks (but not all did for different reasons)

<t​allhatdoug:matrix.org> if qubic can already 51% attack, is there any point in using DNS checkpoints if the chain will inevitably split?

in many cases our data gathering exceeded qubic's view, so we had a better viewpoint than them

<t​allhatdoug:matrix.org> I can't wait for the blog post!

they have to sustain 51%, knowing that their branch will be undone over time

it more or less reduces their selfish mining impact to 1-2 reorgs

<t​allhatdoug:matrix.org> to sustain 51% are the cost estimates by gingeropolous accurate?

monetary costs?

<t​allhatdoug:matrix.org> yes

I sadly can't help much there. I know they don't sustain their burst hashrate (max we seen is 4h continuous) so an assumtion done is that it's vastly more expensive than their "baseline" user hashrate

there are other data samples you can correlate with (MMR rental pricing per region during those times, AWS spot markets, etc)

<o​frnxmr:xmr.mx> Yeah, lol. Mrr rental prices spike during marathons

<t​allhatdoug:matrix.org> when I set --enforce-dns-checkpointing should there be any logs confirming I'm using the flag correctly on monerod?

<o​frnxmr:xmr.mx> No

<o​frnxmr:xmr.mx> if you set --log-level=1 (maybe 2?) it will show that the moneropulse checkpoints were contacted

<o​frnxmr:xmr.mx> But it wont work as mitigation against qubic until we release another version

<o​frnxmr:xmr.mx> current version only checks every hour, which is too long

<t​allhatdoug:matrix.org> how often will the next version check and will it cause any bandwidth issues?

<o​frnxmr:xmr.mx> And unless the majority of hashrate is running checkpoints, youd just end up isolated on a splinter of the network

<o​frnxmr:xmr.mx> 5mins. A few kbs

<t​allhatdoug:matrix.org> ok perfect

<d​atahoarder:monero.social> Rucknium: newest monero-blocks supports MoneroPulse checkpoints for inclusion in csv. Use `-dns-checkpoints mainnet` for default mainnet ones or specify a comma separated list, like `-dns-checkpoints checkpoints.moneroconsensus.info,checkpoints.moneronet.info`

<d​atahoarder:monero.social> you will probably want to remove the rest of the pool listing, however

<d​atahoarder:monero.social> Might be something cool to show in consensus tree with a different highlight

seems dkat on Discord also thinks I'm some Monero core dev as well 😆 irc.gammaspectra.live/8587da946eb86582/dkat_discord.png

I just mostly hoard data (and sometimes provide it to others)

<s​yntheticbird:monero.social> DataHoarder

<s​yntheticbird:monero.social> new bridge when?

it's still syncing up from messages from 2024

it's up to 2025-07-07!

events are drip-fed to it from way in the past...

<s​yntheticbird:monero.social> i see

<g​ingeropolous:monero.social> you have been anointed

2025-07-12, it's slow... I get one HTTP request per event in the past year

note qubic has increased target tick time from 1 second to 3 seconds. it's on/off mining phases are now longer

<b​arthman132:matrix.org> When is kayabanerve starting his research into pos or has he even begun fundraising it yet?

<o​frnxmr:xmr.mx> You ask that as if were going to switch to pos

<b​arthman132:matrix.org> No I’m asking if his proposal was something that he’s actually working on or is just something that he threw out there as a alternative.

Regarding the message last time about Qubic's known transactions. this is the current list of most likely, sorted from high to low paste.debian.net/hidden/c23d4585

460 at the moment, not counting coinbase transactions

some of these might be non-existent given how they were scanned for

20:50:25 <m-relay> <r​ucknium:monero.social> I don't like docker either. Any way to do dockerless docker? :P

podman exists :)

<o​frnxmr:monero.social> Ew

this is a CSV of provable blocks Qubic mined up to Epoch 174 inclusive (not included are broken unspendable blocks due to bugs they had, or orphans) irc.gammaspectra.live/950456ea74ebb26f/qubic-blocks-epoch174.csv

Each line includes block height, id, coinbase id, reward, the address they mined to and generated verifiable InProofV2 for the coinbase output

will be updated with epoch 175 whenever they release view keys or seed words, which they haven't done so yet.

CSV contains 6900 block entries

Each OutProofV2 can be verified without having to load the view keys in wallet, by going to Monero GUI -> Advanced -> Prove/check -> Check Transaction / Reserve, then entering coinbase id, address, and OutProofV2 in signature, leaving message empty

This gets generated within a few seconds scanning all coinbases of heights from current tip to 3413153 inclusive (which is the first block they mined we have view keys for)

InProofV2* instead of OutProofV2, I use OutProofV2 in p2pool code, these are InProof :)

Qubic was waiting for most exchanges to lift confirmation times past 10 to do reorgs past that, so depending how they feel like it they might try for longer reorgs

<j​ack_ma_blabla:matrix.org> Sitting ducks

<r​ottenwheel:unredacted.org> still just an idea, hasn't moved to Funding Required stage yet. maybe he has already started working on it, though.

<j​ack_ma_blabla:matrix.org> is qubic using botnets ? or server farms ?

<m​onerobull:matrix.org> likely both

rotten it was covered in today's MRL meeting

<j​ack_ma_blabla:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/GNsRNZoCtskdLzqYrsZAZMMv

<b​arthman132:matrix.org> Ok thanks for the clarification

<r​ottenwheel:unredacted.org> nioc I'll check logs in an hour or three. thank you sir.

<g​onbat.zano:zano.org> Tevador said that the CCS was merged (matrix.to/#/!toFcRZtpaiwiyapgVO:mat….org&via=monero.social&via=envs.net)

<g​onbat.zano:zano.org> Tho I'm not seeing that reflected on repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604

<g​onbat.zano:zano.org> Oh seems he meant it was probably gonna be merged

<b​arthman132:matrix.org> Yeah I saw that, but that’s just for a book. 200xmr is quite a bit to likely just write a pdf document.

<t​esttank:matrix.org> If it’s just a pdf document you should write it and get the 200 xmr yourself!!

<b​asses:matrix.org> repo.getmonero.org/monero-project/c…als/-/merge_requests/604#note_31419 this is interestingband/anon?

the word "just" should be banned from the english language as it serves no purpose

I have seen spacekiity420 around b4 so I would guess not

<b​asses:matrix.org> SyntheticBird do u guys get paid for the docs? is it included in the CCS? amazing resource btw. Which I feel is how it is done in normal big dev projects docs.

<b​asses:matrix.org> Is the kaya 'book' something that he already did research of and will just document it his findings in a 'book' format?

<b​asses:matrix.org> looking at the linked github issue by kaya in original proposal, there seems already some expected results and research done? also not many people in favor of it (amount of dislikes, idk if from people knowledgable or ogs), also seems liker jbermen is not very interested rn, which was one from the suggested candidates that will be reviewing the work done.

<s​yntheticbird:monero.social> The entirety of the book have been done by boog and hinto. I haven't participated into it (yet). I don't remember it being an explicit CCS milestone on their proposal, but i guess you can see it as part of their paid work.

<b​asses:matrix.org> thanks a lot boog, hinto and future Syn

<b​asses:matrix.org> even if cuprate going to take a while, the book keeps expanding 🤩

<g​onbat.zano:zano.org> > seems liker jbermen is not very interested rn

<g​onbat.zano:zano.org> rando Berman explicitly said "I support this proposal and would review the final product."

<g​onbat.zano:zano.org> repo.getmonero.org/monero-project/c…als/-/merge_requests/604#note_31328

<o​frnxmr:monero.social> No he didnt

<b​oog900:monero.social> the consensus part of the book was part of my first cuprate CCS

<g​onbat.zano:zano.org> ye I misread, clarified below sry

<o​frnxmr:monero.social> Yeah, no, i read from top to bottom and responded before seeing the next msg

<t​orir:matrix.org> We shouldn't use docker or podman. We should just use chroot jails.

<s​yntheticbird:monero.social> me too I love low level pain when a high-level and standardized way exist. This way I don't get the high-level bugs from the high-level implementation. And since the linux kernel devs are so great there aren't any low-level bugs

<t​orir:matrix.org> Actually, no, we should require booting from UEFI executables the same /

<t​orir:matrix.org> way Qubic does /s

<k​ayabanerve:matrix.org> I'd kill for a Redox-based monokernel with Xen device drivers running Cuprate, a la MirageOS

<s​yntheticbird:monero.social> can you stop reading my mind

<s​yntheticbird:monero.social> that's beginning to be very irritating

<s​yntheticbird:monero.social> That was my idea

<k​ayabanerve:matrix.org> Get original thoughts :C