02:54:05 how is qubic orphaning twice :D https://irc.gammaspectra.live/2b71619b66c89b0a/image.png 02:57:14 -4 qubic https://irc.gammaspectra.live/d7dc823709f4f044/image.png 03:43:22 all of qubic's added transactions in their recent block attempts are solely composed of their own internal transactions, and none others 03:43:43 effectively back to 0 transactions mined, but with extra tx pollution 07:59:32 3 days ago while qubic was mining my tx was struggling to get 10 confs for 40+ minutes and got resubmitted to mempool, loosing recipient address from wallet data... it was like I sent it, closed wallet, then opened again and there is delayed tx with unknown recipient 07:59:33 https://mrelay.p2pool.observer/m/xmr.se/YJEEOYNgpTGVGlpVgbDSQLbR.png (image.png) 08:00:00 I guess it was because of qubic :( 08:00:42 damn qubic 08:24:01 <17lifers:matrix.org> you got qubed 08:32:26 DataHoarder: Yeah this happened to me. Had to wait an hour for two transactions to go through because they got reorged and then delayed by the empty blocks. 10:13:38 @anotherone:xmr.se: Thx for reproducing 11:33:37 hey guys i just found out how to kill monero for good as a state actor without spending too much 11:33:49 > hoard a bunch of coins 11:34:27 > start mining secret chain via datacenters (not that expensive) 11:34:36 > sell hoarded coins 11:35:02 > get them all back after publishing the MOAR (mother of all reorgs) 11:35:44 community in shambles, more people start agreeing that PoW is dead and PoS implementation kicks into high gear 11:36:02 > take over PoS system with hoarded coins from way back 11:36:52 thats it, chain is done for, no path to recovery from that. 11:41:08 The only real mitigation is unironically to go PoS before the MOAR 11:41:37 The MOAR would crash the price so hard that you could probably take over a later PoS system without even needing the double spend the previous coins. 11:42:35 PoW assumes majority hash is honest 11:42:47 past few hours of mining https://irc.gammaspectra.live/24ec0087e43ec426/orphan_list.png 11:42:56 Majority compute is undeniably with Mega-Corps, not the people 11:43:40 The MOAR would cost a couple of millions at most 11:44:12 Attacking a PoS system the size of Monero would cost billions 11:44:44 Even for state actors thats a though sell 11:46:06 I fully believe that Monero will get destroyed if it remains RandomX only. 11:47:43 There might be some other schemes to make this less likely but PoS seems the most robust to me. 11:53:57 MsM Money securing Money 12:23:51 @monerobull:matrix.org: billions to invest, 0 cost if successful. 12:24:56 it still costs billions? 12:25:11 you cant censor transactions on monero 12:25:22 so an attack can only disrupt 12:25:46 permanent disruption would make your billions in stake worthless 12:26:20 at worst a POS takeover is protocol-wide buy-out 12:29:27 What happened to pos is bad mkay thing? 12:29:55 Once you get a huge stake, you don't need to spend much resources to maintain it 12:30:11 Once you get 51% stake, you keep it forever 12:35:37 should have better nicks if users are identified and matches their connection 12:46:22 lol @ CfB https://x.com/c___f___b/status/1961409578442117519 12:46:28 Just use https://docs.getmonero.org/rpc-library/monerod-rpc/#send_raw_transaction via RPC! 12:46:55 can fetch tx pools from healthy nodes, or recent blocks, send back 12:48:06 But that's not the worst part, all their self-sent txs spam the decoy pool for users transacting normally 12:50:26 here's 1109 of their recent transactions doing so https://irc.gammaspectra.live/b6aae1a1eec6ec72/qubic-tx.txt 12:51:15 any decoy picked from these effectively can be discarded after a couple of days 12:52:55 FWIW, it should be fairly easy to discard outs from any set of blocks from considratoin when creating a fake out set for a new tx, if the daemon can maintain a list of known bad blocks. 12:53:22 Though the resulting time distribution might end up skewed. 12:54:15 This, of course, requires a new db table (or carving out a new bit in the block_info table). 12:54:26 it's not specifically bad blocks, some of these transactions end up on not their blocks due to how they are produced 12:54:48 but yeah, lately when they do selfish their blocks are solely composed of these 12:56:18 Could also be done in the wallet in fact. 12:57:00 if it has an extrinsic ground truth (which does not have to be perfect) for the list. 12:58:52 so effectively one of their blocks is 1 coinbase output + 3-7 of these txs, which are 2 out, so +6-14 outputs 12:58:59 plus any others that end up elsewhere 13:00:53 it's not in the levels of mordinals or when p2pool created all the outputs for main, yet 13:09:33 There's also the blackball system but I think it might have got removed. 13:20:08 rucknium right now the "% block(s) orphaned in last 720 blocks" changes when you move the slider on "Number of blocks to display after each orphan/altchain:" 13:21:05 moving it from 1 to 2 changes it as well as from 2 to 3, that is as far as I went 13:23:07 ^ noticed it as well 13:24:53 Thanks. That's expected, given the architecture. The process to compute the number of orphaned blocks is inside the process to produce the plot, which is called when you change the sliders: https://github.com/Rucknium/xmrconsensus/blob/main/R/fct_alt_chains.R#L119 13:25:14 load-bearing plot 13:27:19 Shiny's reactivity architecture re-compute things when an input changes. This can be "delayed" by setting an input to only pass to the reactive function when a button is pressed. But for now, it reacts instantly as soon as an input changes. 13:30:57 which setting yeilds the correct % 13:31:36 The percentage is different depending on the input setting? That would be a bug. 13:32:02 I thought you meant it just refreshes 13:32:10 to the same value 13:32:53 choosing 1, 2 or 3 each gives a different value 13:33:30 That sounds like a bug. I will investigate. Thanks. 13:48:54 I think it's fixed. It was cutting off at 150 displayed main chain blocks. When there are a lot of orphans in the most recent 24 hours, it woudn't compute correctly. Thanks nioc and DataHoarder. Maybe I will count up known and unknown orphaned blocks 13:49:33 Because Qubic is losing a lot of the races and increasing the orphaned blocks count by being losers. 13:49:36 also fyi, I added an argument to monero-blocks to include external node-pool compatible apis 13:49:55 I sent you one of these urls over DM if you want to display qubic as qubic :) 13:50:13 and for testnet, the ability to query/add checkpoints 13:50:31 If you think the API/system is stable enough, I would add it. I just don't want to be chasing a moving target. 13:51:00 the external api system is stable and allows people to add their own sources without editing the code 13:51:27 the URL I gave for qubic is also stable, I have been using it on my own instance 13:52:59 for the checkpoints, maybe wait, I want to add an option to remove all other pool fetching (for testnet all the pools are irrelevant) 13:54:12 relevant option is -nodejs-pools "qubic=http://1.2.3.4/api" 13:54:20 but multiple can be added separated by comma 13:56:16 rucknium it no longer changes but it currently display this: "150 (20.83%) block(s) orphaned in last 720 blocks" 0_o 13:57:09 which is an increase to what is was b4 13:57:30 quickly scrolling thru it may be correct 13:58:07 .shrug 14:02:49 maybe a % of orphan ownership could be something to add later 14:04:34 Aha. Got it working already. 14:06:11 > 71 (9.86%) block(s) produced by known pools have been orphaned in last 720 blocks (about 24 hours). 14:06:11 > 79 (10.97%) block(s) produced by unknown pools or solo miners have been orphaned in last 720 blocks. 14:16:26 If all those unknown blocks are mined by Qubic, does that mean that they are losing XMR by trying to selfish mine? (Yet, if you take difficulty adjustment into account, that may not be completely correct.) 14:16:41 they were losing quite a lot a few weeks ago 14:17:29 I don't have the exact numbers, that'd be report part 2 (selfish mining strategy data or so) 14:17:47 but yeah ... many races lost 14:18:08 if the default lock time was increased for mining rewards, would that affect qubic's ability to operate? 14:18:15 this last marathon was how it usually was for their normal reported hashrate 14:18:25 it'd affect nothing, unless we bump it to years :D 14:18:47 they already run with a week+ delay in handing out rewards on each pool 14:23:59 so their cashflow doesn't rely on constant reward payouts for operation? How long of a payout delay would be needed to start causing significant disruption to their operations? 14:24:37 users are paid in qubic. not XMR. pools pay qubic from their own rewards 14:24:54 xmr earned is used to buy qubic on exchanges, then burn it 14:25:56 but qubic needs revenue from the monero they're mining themselves, presumably? 14:26:53 no. qubic again doesn't pay that monero directly. they pay in self-generated qubic 14:27:18 the expectation is that buying qubic by core via XMR rewards and burning it effectively brings the price up for everyone 14:27:34 there's also a % threshold for 50% or 100% rewards 14:29:49 what would happen if they didn't have xmr rewards to spend on qubic for a week? 14:29:57 for example 14:29:58 price of qubic would fall 14:30:07 it's more complex than that 14:30:43 it'd delay the burn, or however they want to do that 14:31:00 but people in epoch 174 are being paid with future rewards of epoch 175 already 14:31:22 it'd just offset their burn time 14:32:02 > > moneromooo (static.82.87.47.78.clients.your-server.de) changed their display name to moneromooo 14:32:03 :D 14:33:01 see this weird flowchart they have https://raw.githubusercontent.com/qubic/outsourced-computing/refs/heads/main/monero-poc/images/QubicOutsourcedComputing_MoneroPOC_v2.png 14:33:26 they just sell offhand the XMR on USDT pairs, then buy qubic with USDT 14:33:31 which then is burned 14:33:42 miners are always paid with qubic. 14:40:33 each pool can pay users in different ways btw, but most do the same 14:42:49 weird nick changes D: 14:47:02 based on that flowchart, if they can't process/swap/payout from their xmr rewards in x amount of time, looks like they'd be dead in the water. Unless they have a surplus of funds they can pull from. But that would last only x amount of time. If the rewards payout delay is > x, then what? 14:47:17 what do you mean? miners are still paid in qubic 14:47:40 if people sell qubic, price goes down yes. something else could change it 14:47:52 XMR rewards are the same now but qubic ones are halved 14:47:53 this is just mining rewards I'm talking about, other txs on the network would not need a delay 14:48:03 it wouldn't do much 14:48:16 they know how much xmr they have, they could do out of pocket :) 14:48:44 and that's only against qubic. someone doing something for themselves (not paying people) would not be affected 14:54:49 if they were paying people directly, it'd do some, but only against specifically qubic, not any other kinds of attacks. but it's already disconnected and mostly doing price pressure 14:55:01 I don't know how many others rely on xmr mining rewards, considering it is usually only to secure the network and results in no profit 14:55:15 p2pool :) 14:56:01 it's the "out of pocket" part I'm wondering about: how much runway do they have? If you can make them run out their runway, it doesn't matter if they will have the rewards later, because it will put pressure on qubic miners to switch to mining another coin in the meantime 14:56:02 it'd require a hardfork and consensus, for no noticeable change against qubic and no change against hidden attackers that don't care about the incoming XMR 14:56:10 there is no runway agai 14:56:22 price of qubic would go down if people sell and there isn't pressure 14:56:28 but ... it could also not 14:56:52 the xmr there is just doing some buy pressure, not being given directly 14:57:08 it'd take long to do the hardfork than it'd get them to get bored 14:57:12 longer* 14:57:29 or reach the next halving they have, maybe :D 14:58:57 it's not just "qubic qubic" but measures taken should be relevant for different classes of attackers if they are to be permanent 15:01:09 I mine monero like most people probably do on the network, p2pool, so I don't need the little payouts in a timely way. You could hold them for 6 months and I doubt it would affect most xmr miners 15:01:24 it'd affect all other pools, too :) 15:01:50 but again, what effect would it have about someone trying to do what qubic is doing, but literally just burning money away in secret 15:01:57 they don't care about the block reward 15:02:56 yeah if the xmr reward isn't something they're relying on for operation, it wouldn't matter 15:03:18 as well: qubic isn't relying on XMR reward for operation 15:03:25 the qubic gets generated regardless 15:03:52 it just hints price pressure via burns, which probably does more than just handing it out directly 15:04:15 the halving of rewards in qubic did more against than any delay would 15:04:31 it's hard to believe that's the case, though, considering the hashrate they're achieving, they must be getting a lot of xmr rewards worth a lot of $ to their operation 15:04:56 last epoch, 175, from their numbers XMR: 737 | XTM 6M 15:05:22 a bit below $200k 15:05:25 in a week 15:05:48 in the past they were giving people 2x-3x this amount when measured in qubic 15:06:20 there's already a disconnect there, even now when it's vastly lower past their halving, what they get in XMR and what they pay is disconnected 15:06:35 hype on their coin > what they get in XMR 15:18:28 I'm guessing there's no proof they're actually buying/burning qubic with their monero. Supposing that generating qubic is essentially free for qubic creator, could he not just be stealing all the monero rewards? 15:18:42 they do release some of their proofs/transactions later on 15:19:09 it's a bit more spotty as they had issues recently with exchanges they used no longer accepting XMR deposits 😆 15:24:58 To clarify, if I'm the creator of qubic: 15:24:58 1. I mint tokens for myself for free (qubic) 15:24:58 2. I tell people to mine monero and in exchange I will give them my shitcoin (qubic) I just created 15:24:58 3. I'm rewarded with an actually valuable untraceable cryptocurrency (monero)[... more lines follow, see https://mrelay.p2pool.observer/e/obq3_68KaHI3TlZZ ] 15:25:18 1. they don't have minting as such, but they have some pools 15:25:49 4. could be. but they do publish some spend proofs when they transfer to exchange 15:26:05 and then publish the burned amount matches what value they transferred out 15:26:27 note this is not a classical token either as in ethereum or solana 15:26:41 it's their C++ code which changes every week :) 15:26:43 I'm wondering how much is actually proven to be traded/burned out of 100% 15:27:27 they publish these on pinned messages on Discord :) 15:27:59 I read a rumor that Qubic is funded by VC money. Any truth to this? If so, the VC money subsidizes everything. 15:28:10 or their own people pockets :) 15:29:03 really if you want to check their data, go to their discord pinned messages and search for the specific announced transactions 15:29:39 that's their consensus method for when things go wrong or "documentation". it's all pinned messages or search on discord. 15:30:27 I'd check with my account I made to also join the monero discord, but it's in 5d timeout jail for joining, not even talking ofc 15:31:10 for epoch 173 their XMR wallet private keys are also available, not just view keys 15:31:18 so you can verify further there 15:31:49 bridge is so funny, someone is named "wallet" elsewhere and it auto-matches their nick on matrix side :D 15:33:39 smartest move would be to show proof of some trade/burn and then steal everything else 15:33:55 but they show burn of an equivalent amount 15:34:04 they could do that, they don't need to do so 15:34:23 their own qubic holdings probably cover anything they care to get 15:35:02 but for price discussion or what they could do to steal funds probably should move away from #monero-research-lounge 15:35:43 What is the status of DNS checkpoint testing? Might be needed soon. https://xcancel.com/c___f___b/status/1961356882028687738#m 15:37:10 regardless of depth being 9 or 10 or 15 or 29 whatever they decide, dns checkpoints as a bandaid to reorgs that could exploit double-spend even unintended is needed 15:37:32 Question: In the background I’ve been working on an upgrade proposal (post FCMP), and I’m currently divided between trying to finish it in its entirety before publicizing it or releasing it as is somewhere so it can be worked on. Any thoughts? 15:39:28 It depends on their real hashrate, which is unclear. 1-3 block reorgs are unlikely to result in double spends. 15:39:48 indeed, and that's the target of DNS checkpoints, prevent 10+ ones 15:40:02 tevador: real hashrate is able to do it, on demand 15:40:14 tevador: I think we're iterating toward a good protocol. I think we should enumerate all of the possible attack & network response scenarios and then run them several times each to make sure that the network responds as hoped and expected. 15:41:19 And we need to keep DNS delays in mind. 15:45:44 Right now the "protocol" is for the checkpointing node to record the block hash that is 2 blocks deep (i.e. if chaintip is zero, then the -2 block hash) in two different DNS records. The checkpointing node will not update the DNS record if its new chaintip rolls back, which can happen if the longest seen chain does not agree w [... too long, see https://mrelay.p2pool.observer/e/sMKDgLAKb2liRk1L ] 15:47:56 i'm available for any release that includes DNS checkpoint improvements 15:48:20 Thanks, selsta 15:50:54 the other part of such a release from what I remember is coordinating this being followed on exchanges and major pools if they'd like so 15:51:11 and that they have a proper DNS resolver that handles DNSSEC :) 15:52:44 Now I have two domains that are blacklisted by some strict DNS providers (moneroconsensus.info and moneronet.info) and two that seem to not be (townforger.net and townforgepool.net). I read somewhere that the big 3 TLDs (.com, .org, .net) are less likely to be blacklisted. I don't have any more of the big 3 TLDs, but I have a [... too long, see https://mrelay.p2pool.observer/e/5p2dgLAKdEVWUHFi ] 15:53:05 One of the strict DNS providers that is blacklisting those two domains: https://quad9.net 15:53:13 some ISPs/DNS providers straight up block tags 15:53:16 like monero 15:53:42 have you tried their "no malware blocking" ones? https://quad9.net/service/service-addresses-and-features/ 15:53:59 my moneroresearch.info isn't blocked, but it has been established for years. 15:54:53 I emailed Quad9 about a month ago to remove moneronet.info from their blacklist, but not response. 15:55:08 moneroconsensus.info works on quad9 without blocking 15:55:19 on their domains with blocking, it's blocked 15:55:43 tbh pools or exchanges should be running their own DNS Resolver 15:55:56 not give this to another entity 15:56:22 a recursive resolver, not a forwarder 15:57:04 shilling opportunity detected 15:57:07 Engagement initiated 15:57:10 https://github.com/hickory-dns/hickory-dns 15:58:00 as for DNS server latency, a custom dns server for explicitly just serving checkpoints would be interesting, hmm 15:58:29 how do the checkpointing servers agree on what entries to set? 15:58:56 are checkpoints placed in heights % (minus some delay for propagation)? 15:59:12 I see moneroconsensus.info blocked on quad9 15:59:12 Just by using the most used of there DNS resolver, 9.9.9.9 15:59:14 https://mrelay.p2pool.observer/m/xmr.mx/zHKuclHKmFkhZZEnsIxtGJaT.png (clipboard.png) 15:59:36 I tried their 9.9.9.10 15:59:52 yes, most used is blocked, just confirming it's their blocklist and not other unrelated DNS issues 16:00:35 You can input a domain here and it will tell you why it's blocked: https://quad9.net 16:01:07 > Blocked 16:01:07 > Threat Intelligence Providers who have listed this domain 16:01:07 > DOMAINTOOLS Hotlist 16:01:07 > False Positive? 16:01:07 > Please contact us 16:01:32 https://www.domaintools.com/products/threat-intelligence-feeds/predictive-risk-scoring/domain-risk-feed-hotlist/ 16:01:34 Are you talking about my code? > how do the checkpointing servers agree on what entries to set? 16:02:08 I assume so. I can run similar code within "mainnet" to see what reorgs could have been avoided or state 16:02:56 That's a good point. Some scenarios can be tested directly on mainnet. 16:03:03 Did you take a look at who told Quad9 it's bad? 16:03:11 "About the DomainTools risk score 16:03:11 DomainTools Risk Score predicts how likely a domain is to be malicious, often before it is weaponized. The score comes from two distinct machine learning algorithms: 16:03:11 Proximity — how closely a domain is connected to other known-bad domains" 16:03:14 PROXIMITY 16:03:29 https://mrelay.p2pool.observer/m/monero.social/htXjNPnakRVIqheIfPMEPUsf.png (image.png) 16:03:30 AI again 16:03:31 unrelated: the matrix bridge resolved that "reply" and converted it to a quote on IRC side 16:03:41 always AI syntheticbird :D 16:03:49 : I saw that and I was confused. It's pointing to the same server as other "good" domains. 16:04:18 But it also point to the same as moneronet.info, I was wondering 16:05:42 I run the snooper https://qubic-snooper.p2pool.observer/tips.txt and it tracks how far ahead they are and attempts, so could have history of when checkpoints would be done and which side their reorgs land at 16:05:55 Probably the "monero" name plus recency of its registration are big factors. 16:05:57 ofc, last night they didn't try many long ones 16:18:24 DataHoarder: Here is the checkpointing code. It only works for Njalla's API and is messy because it used to update 10 TXT records instead of 1: https://gist.github.com/Rucknium/b298325e3beaf84f1d884d6fe4e84fc6 16:18:44 ah, I'll make a standalone dns server that does that then 16:18:51 Maybe you can see the logic. 16:19:02 R :) 16:19:22 If you can see past the R, you'll see the logic :P 16:19:50 I'll take a look later, thanks 16:21:11 The domains are "synced" to the same checkpoints because they are just iterated through in the loop. 16:39:08 I wonder, should ZMQ pub get a new channel for notifying of alt blocks? 16:39:16 Otherwise that method is RPC only 16:40:26 I have some scripts that use ZMQ for incoming new block headers but I need to poll manually /get_alt_blocks_hashes 16:40:37 then have my own logic to fetch new ones 16:41:43 the existing interface was designed specifically to allow this extension 16:43:52 yeah, lemme see if I can get a quick patch 16:51:57 my monerod already has a couple of patches to effectively be able to handle old altchains via RPC so what's one more :) 17:06:56 totally untested https://irc.gammaspectra.live/524116ac52fe6f16/0001-WIP-added-json-full-chain_alt-and-json-minimal-chain.patch 17:07:40 same structure as current block notify, doesn't notify of txs in it explicitly 17:07:56 so full + minimal are supported 17:08:36 I'll run this with a couple of logging on a client 17:14:36 What are the real cons of merge mining with BTC or LTC&DOGE? What does "becoming a vassal" mean? Compared to other solutions, it looks like merge mining will greatly raise the security budget while preventing Monero from being singled out thanks to the plausible deniability of mining it. Here's an argument for it: 17:14:36 https://boards.4chan.org/biz/thread/60863030#p60866023 17:14:36 https://boards.4chan.org/biz/thread/60863030#p60866069 17:14:36 https://boards.4chan.org/biz/thread/60863030#p60866128 17:14:36 https://boards.4chan.org/biz/thread/60863030#p60866383[... more lines follow, see https://mrelay.p2pool.observer/e/nPfIgrAKSUFiLUpn ] 17:19:28 good q, I guess it would 1) dilute the brand a bit, and 2) kill the romantic notion of everyman securing the network with their smart tv and toaster 17:19:44 it seems like pretty straightforward and low risk approach tho 17:30:49 Could the first bitcoin pool to add monero mm instantly 51% monero ? 17:43:31 yes 17:44:14 : I believe merge mining requires a hardfork, which we cannot do fast enough to respond to the present attack. If we have to hardfork anyway we might as well also research other solutions that don't rely on other cryptocurrencies. 17:44:27 Merge mining doesnt stop any of this 17:46:42 I think was actually referring to checkpointing via another chain, not merge mining. I should have clarified what I meant. 17:46:56 That still requires a hardfork, right? 17:47:39 where are all of these cucked (literally) ideas coming from 17:47:54 Why would monero become a sub-chain to litecoin? 17:48:25 If we wanted to be scrypt, we would have bowed to bitmain years ago 17:50:03 monero is the premier hash on randomx. Dogecoin is just litecoin's(the pimp's) prostitute 17:50:33