01:18:17 As mentioned several times in this channel, > 21:48:43 Why is Qubic jumping in and out in short bursts in its mining of monero? It makes no sense 01:18:36 Qubic when not in marathon, they mine Monero only during half their time, based in ticks 01:50:37 testnetnode4 has deeper reorgs than testnetnode3? how did the network heal? 01:51:05 all I can tell is that testnetnode4 has less orphaned blocks 01:51:09 By the checkpointed network overtaking the attacking network 01:51:30 is that after block ...286? 01:51:35 Testnetnode4 is using dns checkpoints 01:51:54 There were a few reorgs 01:52:07 The small 2 block reorg was common for both networks 01:52:14 103 -> 120 01:52:16 massive reorg :( 01:52:18 The larger reorgs were rejected due to checkpointing 01:52:36 This was all testing 01:52:57 I think I see it now so 298 -> 317 from testnode3 is not in testnode4 01:52:59 The reorgs are on purpose 01:53:01 for example 01:53:12 bravo ofrn! 01:54:41 if qubic becomes a slient pool, will dns checkpoints still work? 01:55:38 All nodes have same history 01:55:39 Testnetnode3 was send a large reorg 01:55:41 Testnetnode3 then dropped the "honest" blocks, and replaced with the attackers blocks 01:55:43 testnetnode4 uses checkpoints. When encountering the attackers large reorg, it ignores is entirely. 01:55:45 Testnetnode4 carries on as usual. 01:55:47 testnetnode4's blockheight surpasses testnetnode3/theattackers, and testnetnode3 and the rest of the non-checkpointed nodes are reorged again, dropping the attacking chain 01:55:49 Yes 01:56:26 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 01:56:34 wow this is impressively effective 01:56:36 Sorry 01:57:12 hopefully nodes don't choose to opt out in the meantime... 01:57:31 Yeah. We have the checkpoints tweaked to allow 2 block reorgs, which are pretty normal 01:57:40 I don't think dns checkpoints adds any overhead for node operators? 01:57:44 Nodes dont reallt matter 01:57:47 Only miners do 01:58:16 so pools need to implement this? 01:58:24 yea 01:58:28 I need to figure it out then 😆 01:58:39 Without pools, its useless 01:59:09 The node that the pool uses will just need to ass --enforce-dns-checkpointing and run a yet-to-be-released version 01:59:19 Add* 01:59:30 what happens if big pools like qubic choose to opt out? what is the number of pools needed to make dns checkpoints work effectively? 02:00:03 then their blocks get orphaned 02:00:22 51% :P 02:00:54 As long as checkpointed nodes produce more honest hash than attacker, it should work smoothly 02:01:15 will p2pool reflect this change? 02:01:36 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 02:01:43 Thats the dangerous part. 02:02:47 I don't think there is enough hash rate to sustainably rent for qubic to 51% attack 02:02:49 otherwise they would have done it already 02:02:58 You never know what a desperate adversary might do 02:03:07 03:57:47 Only miners do 02:03:07 and any other user that prefers to stick to this chain 02:03:29 they have done it already tallhatdoug, but in bursts 02:03:42 they can sustain it if needed for several hours and can get very far ahead 02:03:43 datahoarder, other users get pulled back onto the majority chain regardless of their settings 02:03:59 over time, yes, exchanges might want to stick to ours quicker 02:04:14 yea 02:04:29 03:58:28 I need to figure it out then 😆 02:04:36 as said get recent monerod and run with --enforce-dns-checkpointing 02:04:38 D​ataHoarder -> is it due to qubic's rented hash rate not appearing on their api? 02:04:39 that's all for now 02:04:51 will do! 02:04:52 yeah, not just the API 02:05:06 I shared some specific charts of the interest periods 02:05:51 just assume that they can get +2GH/s at least in bursts over their normal hashrate 02:06:30 good work testing dns checkpoints :) 02:06:54 I'm adding these to monero-pools so they appear in the CSV if they want to be ingested! 02:07:10 monero-blocks* 02:08:39 DataHoarder -> is this research report misleading or outdated? it says that qubic did not reach 51% of the total network hash rate: 02:08:41 https://shai-deshe.gitbook.io/parallel-thoughts/proof-of-work/the-qubic-minority-report 02:08:55 this is outdated and also only uses data from found blocks 02:09:13 👍️ 02:09:23 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) 02:10:20 if qubic can already 51% attack, is there any point in using DNS checkpoints if the chain will inevitably split? 02:10:28 in many cases our data gathering exceeded qubic's view, so we had a better viewpoint than them 02:10:51 I can't wait for the blog post! 02:11:12 they have to sustain 51%, knowing that their branch will be undone over time 02:12:12 it more or less reduces their selfish mining impact to 1-2 reorgs 02:12:22 to sustain 51% are the cost estimates by gingeropolous accurate? 02:13:06 monetary costs? 02:13:14 yes 02:14:59 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 02:15:53 there are other data samples you can correlate with (MMR rental pricing per region during those times, AWS spot markets, etc) 02:16:27 Yeah, lol. Mrr rental prices spike during marathons 02:16:32 when I set --enforce-dns-checkpointing should there be any logs confirming I'm using the flag correctly on monerod? 02:16:45 No 02:17:23 if you set --log-level=1 (maybe 2?) it will show that the moneropulse checkpoints were contacted 02:17:46 But it wont work as mitigation against qubic until we release another version 02:18:03 current version only checks every hour, which is too long 02:18:34 how often will the next version check and will it cause any bandwidth issues? 02:18:36 And unless the majority of hashrate is running checkpoints, youd just end up isolated on a splinter of the network 02:18:49 5mins. A few kbs 02:19:00 ok perfect 02:39:57 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` 02:40:11 you will probably want to remove the rest of the pool listing, however 02:40:31 Might be something cool to show in consensus tree with a different highlight 12:20:04 seems dkat on Discord also thinks I'm some Monero core dev as well 😆 https://irc.gammaspectra.live/8587da946eb86582/dkat_discord.png 12:21:29 I just mostly hoard data (and sometimes provide it to others) 12:23:06 DataHoarder 12:23:11 new bridge when? 12:24:25 it's still syncing up from messages from 2024 12:24:39 it's up to 2025-07-07! 12:25:04 events are drip-fed to it from way in the past... 12:26:29 i see 12:54:07 you have been anointed 13:35:12 2025-07-12, it's slow... I get one HTTP request per event in the past year 15:11:59 note qubic has increased target tick time from 1 second to 3 seconds. it's on/off mining phases are now longer 16:33:30 When is kayabanerve starting his research into pos or has he even begun fundraising it yet? 16:54:36 You ask that as if were going to switch to pos 16:59:27 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. 17:07:25 Regarding the message last time about Qubic's known transactions. this is the current list of most likely, sorted from high to low https://paste.debian.net/hidden/c23d4585/ 17:07:37 460 at the moment, not counting coinbase transactions 17:08:25 some of these might be non-existent given how they were scanned for 19:07:20 20:50:25 I don't like docker either. Any way to do dockerless docker? :P 19:07:22 podman exists :) 19:08:19 Ew 19:59:29 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) https://irc.gammaspectra.live/950456ea74ebb26f/qubic-blocks-epoch174.csv 19:59:29 Each line includes block height, id, coinbase id, reward, the address they mined to and generated verifiable InProofV2 for the coinbase output 19:59:55 will be updated with epoch 175 whenever they release view keys or seed words, which they haven't done so yet. 20:00:34 CSV contains 6900 block entries 20:03:07 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 20:05:09 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) 20:10:13 InProofV2* instead of OutProofV2, I use OutProofV2 in p2pool code, these are InProof :) 20:35:41 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 20:57:03 Sitting ducks 20:58:10 still just an idea, hasn't moved to Funding Required stage yet. maybe he has already started working on it, though. 20:59:05 is qubic using botnets ? or server farms ? 21:00:12 likely both 21:01:21 rotten it was covered in today's MRL meeting 21:02:41 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/GNsRNZoCtskdLzqYrsZAZMMv 21:15:49 Ok thanks for the clarification 21:23:06 nioc I'll check logs in an hour or three. thank you sir. 21:23:53 Tevador said that the CCS was merged (https://matrix.to/#/!toFcRZtpaiwiyapgVO:matrix.org/$1M7Z_I1VeafA0H_l_lMcenhKdVtrA07eeO7G8BsYdYc?via=matrix.org&via=monero.social&via=envs.net) 21:23:53 Tho I'm not seeing that reflected on https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604 21:25:32 Oh seems he meant it was probably gonna be merged 21:29:05 Yeah I saw that, but that’s just for a book. 200xmr is quite a bit to likely just write a pdf document. 21:32:28 If it’s just a pdf document you should write it and get the 200 xmr yourself!! 21:34:18 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604#note_31419 this is interestingband/anon? 21:37:24 the word "just" should be banned from the english language as it serves no purpose 21:38:52 I have seen spacekiity420 around b4 so I would guess not 21:41:53 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. 21:41:55 Is the kaya 'book' something that he already did research of and will just document it his findings in a 'book' format? 21:41:57 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. 21:44:38 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. 21:45:42 thanks a lot boog, hinto and future Syn 21:47:28 even if cuprate going to take a while, the book keeps expanding 🤩 22:00:46 > seems liker jbermen is not very interested rn 22:00:47 rando Berman explicitly said "I support this proposal and would review the final product." 22:00:49 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/604#note_31328 22:24:29 No he didnt 22:27:07 the consensus part of the book was part of my first cuprate CCS 22:29:31 ye I misread, clarified below sry 22:52:57 Yeah, no, i read from top to bottom and responded before seeing the next msg 23:24:40 We shouldn't use docker or podman. We should just use chroot jails. 23:26:44 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 23:26:48 Actually, no, we should require booting from UEFI executables the same / 23:26:56 way Qubic does /s 23:30:09 I'd kill for a Redox-based monokernel with Xen device drivers running Cuprate, a la MirageOS 23:30:30 can you stop reading my mind 23:30:33 that's beginning to be very irritating 23:30:37 That was my idea 23:31:36 Get original thoughts :C