00:29:47 lmao 00:34:54 @frogmindset:matrix.org: You view the profile and the option is there. 00:34:54 This is what Element-X offers: 00:35:04 https://mrelay.p2pool.observer/m/matrix.org/offdrrSZiQqTkqVhBvqrPHMS.png (1000003460.png) 00:36:00 Element-x is garbage (exvept for sliding sync) 03:10:30 Added a mini block explorer to Monero Blocks like https://blocks.p2pool.observer/block/23e4024f7ad91f52b2c7ec52beb615cfee9df42f0459d906da92403a5661246f or https://blocks.p2pool.observer/block/7d8915c920cabff946b5b41e5e357d556a03b9e3708eec33d5e3043a0676b88d 03:11:21 Can display details on orphaned blocks and other information like list of withheld transactions from qubic or merge mined chain count 06:23:11 huge re-org just happened on the monero network 06:24:11 that one was impressive 06:34:01 It’s over 06:34:27 🤖 06:46:16 18 block reorg just happened 👀 06:50:36 17 block 06:52:19 3499659 - 3499676 06:55:15 https://imgur.com/a/K0pXBmN 06:56:44 does this break anything (besides the risk of double spends)? 06:57:45 what if I receive funds and then spend those, then the funding tx is reorged and put into a new block, will the old transaction (that spends the re-orged one) still be valid and included in a block again? 06:59:04 Transfer proofs should still be a valid right? Even if the transaction is re-orged into a new block? 06:59:57 @binarybaron:matrix.org: Yes it should be included in block. The defult time for a transaction in mempool is 72 hrs 07:00:49 @kevino:tchncs.de: If they had decoys from invalid blocks, txs are invalid 07:00:51 Outputs only receive their index once they are included in a block right? 07:01:20 @kevino:tchncs.de: Cc DataHoarder 07:01:39 nssy2: Start and end blocks are inclusive 07:01:54 Some txs will be invalid and need to be resent > <@binarybaron:matrix.org> does this break anything (besides the risk of double spends)? 07:02:30 @elongated:matrix.org: A normal users won't be able to send decoys 07:02:45 What would be the proper way to handle this? Watch for transactions and reconstruct if they got invalidated? 07:02:45 Asking specifically for our BTC<>XMR implementation. We might have to seriously think about adding some more resilience to re-orgs 07:03:00 @kevino:tchncs.de: 😂 your dsa selects those recent outputs as decoys 07:03:26 @binarybaron:matrix.org: Yes 07:03:46 Maybe rework on dsa 07:04:11 wdym? 07:05:56 @binarybaron:matrix.org: Current decoy selection algo uses decoys from very recent mined blocks, if these keeps getting reorg your txs are more prone to getting invalidated 07:06:30 But us modifying the decoy selection algorithm isn’t really viable. 07:06:32 Never liked current dsa, one more reason it needs to be fixed 07:06:38 We need to produce standard transactions too 07:07:00 Even more reasons we need FCMP++ as quickly as possible 07:07:08 Rings are holding us back 07:07:15 Your txs will stand out, but your spending outputs might not > <@binarybaron:matrix.org> But us modifying the decoy selection algorithm isn’t really viable. 07:07:26 The decoys are not published to whole network before the reorg , so i don't think it matters > <@elongated:matrix.org> 😂 your dsa selects those recent outputs as decoys 07:07:52 @binarybaron:matrix.org: Dsa change was needed yesterday, fcmp is needed now 07:07:52 Nothing is coming today 07:08:21 @kevino:tchncs.de: What are you talking about ? 07:08:31 The point is that when decoys get in invalidated you need to reconstruct and re-sign the transaction. 07:08:53 This means you cannot rely on your transaction being included into a new block after being re-orged and popped 07:09:38 Yes and if they keep doing 10+ reorgs ; your txs will keep getting invalidated 07:09:54 @elongated:matrix.org: You can read above what dathoarder said about decoy transactiona 07:10:07 @elongated:matrix.org: Not necessarily 07:10:21 You can stop spreading fud 07:10:51 Id love to be wrong. Not trying to spread FUD. You have a link to anything ? 07:10:56 @kevino:tchncs.de: What? If your tx has invalid decoys the tx is invalid 07:10:57 Blog post or similar 07:11:12 Refer this > well, they release them later as well, but then those get flagged on early alt blocks 07:11:46 my client is missing that message 07:11:52 typical matrix behaviour 07:13:11 @elongated:matrix.org: Are you talking about decoys from cubic? 07:13:20 @kevino:tchncs.de: Now ask him what happens if your tx has a decoy from a Invalid block 07:14:11 @kevino:tchncs.de: No that would be marble attack another topic 07:15:07 @ofrnxmr:xmr.mx: will explain it to you guys when he wakes up 07:15:30 @elongated:matrix.org: The transaction if invalidated just goes back to the mempool and will be included in subsequent blocks with newer decoys 07:16:22 It won't let you double spend easily , if thats what you are implying 07:17:23 @kevino:tchncs.de: If your sent tx is invalid, you can spend your outputs again as you like 07:17:58 Unconfirmed != invalid 07:18:09 Yeah, transaction do go back to the mempool, but they become invalid if the reorg is larger than 10 blocks and they mention some decoys that don't exist anymore. Check any block explorer now and see the transactions that wait to get mined for almost 1 hour now. They will expire in 23 hours. 07:21:06 @elongated:matrix.org: What is invalid ? How does a transaction become one ? 07:22:18 Referencing decoys works through so-called indexes. Those can become invalid and point into nirvana after reorg. Result is invalid transaction. 07:23:39 🤔 07:23:57 Are there any invalid transactions reported yet ? 07:24:01 Oh, I think I was wrong about those 23 hours. It will be 1 week 07:24:16 @rbrunner7: Yeah 72 hrs 07:24:32 "Are there any invalid transactions reported yet ?" Yes, all these transactions in the mempool that "refuse to get mined" 07:24:39 3 days i guess 07:25:39 #define CRYPTONOTE_MEMPOOL_TX_FROM_ALT_BLOCK_LIVETIME 604800 //seconds, one week 07:25:53 Right from the source code 07:26:58 Hmm, there is a second constant: 07:27:00 Ok 07:27:01 #define CRYPTONOTE_MEMPOOL_TX_LIVETIME (86400*3) //seconds, three days 07:27:17 Not sure which one will apply now exactly 07:43:34 One week is if a tx was ever seen in a block, on hte assumption it's more likely to be included again. 07:44:02 Used to be 1 day and 3 days IIRC. 07:48:41 They will never be included if decoy indices are invalid now 07:49:01 Yes, just saw your PR from 2018 :) https://github.com/monero-project/monero/pull/3205 07:49:31 sech1: Yes, but when will they expire? In 3 days, or in 1 week? 07:49:38 1 week 07:49:47 I recommend to do flush_txpool on your nodes 07:50:50 If for some reason somebody can't do that, they have to wait for 1 week until they can re-submit their transaction? 08:04:27 Yes, to that specific node 08:04:54 If they run their own node, it should be easy 08:05:37 ive ran flush_txpool on my nodes just in case 08:07:47 selsta has added the todo list for the next release here https://github.com/monero-project/monero/issues/10080 08:18:13 "Yes, to that specific node" Thanks, sech1, for confirming what I also suspected. 08:18:51 And all nodes who has old transactions in their mempool will also refuse the new transaction. So all pool nodes probably too 08:18:54 That's a problem 08:19:14 So someone has funds effectively locked for 1 week now 08:19:36 I can ask supportxmr admins to run flush_txpool 08:22:01 sent messages to supportxmr and moneroocean admins 08:23:26 Good idea. Things can move if people don't just "worry", but think what they can do, and then act. 08:27:11 I ran flush_txpool on all my nodes, but they're not mining, so it's only a little help in tx propagation. They are connected directly to supportxmr nodes though 08:28:13 whats going on with nodes? 08:28:21 reorganizing keeps happening 08:28:37 got atleast 3 on the node im running 08:29:03 also keep getting this message in the log for the node im running "Transaction not found in pool" 08:29:58 Because Qubic is mining and withholds their transactions all the time, so they are not found in your node's pool and it has to request them from other nodes. 08:30:00 also got a bunch of messages saying " ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT " 08:30:13 and " Transaction spends at least one output which is too young" 08:30:28 its actually making it where i cant even mine 08:30:47 the whole node is just errors 08:31:43 the xmrig difficuly is 382,863 right now 08:34:49 never mind, counted atleast 10. > <@frogmindset:matrix.org> got atleast 3 on the node im running 08:44:49 is there anything i can do to solve this?? 08:46:43 Your node is working. Check the status, check the block height it displays and compare with what block explorer shows 08:49:43 what does "Transaction not found in pool" mean? it keeps appearing in my node's log 08:51:26 I already I answered 08:52:17 sech1: where? i didnt see it 08:52:25 my client may be acting up again 08:52:44 Because Qubic is mining and withholds their transactions all the time, so they are not found in your node's pool and it has to request them from other nodes. 08:53:16 sech1: ahh thank you, that message didnt show up on my side 09:56:45 impressive that, despite this, monero is still at an all-time-high 😅 13:19:32 Could it be possible they played with the network difficultly adjustment of the network ? 13:19:32 If they mined secretly , the rest of network may not adjust difficulty according to this increased hashrate for balancing the 2 minutes per block policy. 13:19:34 Taking advantage of this they mined more blocks within short period ? 13:20:55 @kevino:tchncs.de: Well they already turn off and on their pool when not on marathon. 13:21:30 Yeah turning it off would decrease network difficulty after a period right ? 13:21:58 Yes! That’s why they do that in the first place 13:22:29 Aah i see . Smart if theory is true 13:24:08 There’s no doubt anymore that Qubic has enough hashrate to do a 51% attack. The real question is how long can they maintain it and can they really only do it in short bursts like they usually do. 13:24:34 hmm, so huh, is the dificulty adjustment somehow centralized? if it relies on reporting from miners 🤔 13:28:54 Thankfully the average monero trader seems to not know what happened and are trading normally. The worst thing to do is spread around bad news like the 18 block reorg. Panic is the worst thing that can happen right now. 13:31:09 it's not reporting, the act of mining a block publicly is what changes the difficulty 13:33:18 how much time does it take for difficulty adjustment to change ? 13:34:07 as a counter measure can we change the period of this change in difficulty adjustment . For example in bitcoin it takes 12 days 13:34:30 that requires a hardfork 13:34:47 it also is not relevant as counter measure nor a problem 13:34:56 certainly not 12 days incase of xmr but maybe 1-2 days. 13:35:02 DataHoarder: ohh i see 13:35:39 18-block reorg, daaamn 13:35:41 it takes 24h+ to adjust more or less 13:35:45 @barthman132:matrix.org: Youre wrong lol 13:36:04 Stop spreading unsubstantiated clickbait 13:36:05 DataHoarder: but it could make selfish mining harder right ? 13:36:10 no 13:36:31 it makes it even easier the longer difficulty takes to adjust 13:36:37 @ofrnxmr:xmr.mx: i just asked it in the room ? didn't say it was true ? 13:36:56 Not you 13:37:35 how its wrong , btw ? 13:38:33 Thst they have enough hashrate for a 51% attack? That you need 51% hashrate which would let you own 100% of the blocks 13:38:35 they aren't relying on difficulty adjusment period to find more blocks ? correct ? 13:38:54 @ofrnxmr:xmr.mx: ok unserstood 13:38:56 Not 100% of the blocks for 20 minutes 13:39:42 @kevino:tchncs.de: A longer diff adjustment period means they can let diff fall, then blast out hashrate for long periods of time withiut worrying about the diff increasing 13:40:06 One of the reasons for their marathons, is because the diff climbs too quickly for them to mine for too long 13:41:15 A longer difficulty allows longer periods of attack though - and longer period of slow blocks when they stop. 13:41:15 note that w/o using uncles/orphans in the difficulty calculation, the difficulty window doesnt do anything to hamper selfish mining. 13:41:15 re longer diff adjustment windows: on the contrary, i think a shorter difficulty window would lead to shorter attacks.[... more lines follow, see https://mrelay.p2pool.observer/e/jM3Sj7UKbk9VdlNH ] 13:41:31 This was my take on whether we should increase or decrease the diff adjuatment period 13:42:03 i bet tevador is glad that he doesn't have to deal with dumbasses who ask "uhm acktually do you see deep re-orgs happening?" 14:03:48 > <@ofrnxmr:xmr.mx> Youre wrong lol 14:03:48 If they didn’t achieve the hashrate. Then they were extremely close. If they didn’t get over 51% then they were at like 50%.”The probability of a 19-block streak is ((0.45)^{19}), which is approximately (3.7\times 10^{-7}). a 49% probability. A "once in 400 years" expectation is plausible given the low individual probability, again depending on the rate of trials”. 14:06:23 i'm gonna cry if peopl use AI for dumb shit 14:11:02 The reality is. it’s extremely unlikely they didn’t get at least a 51% hashrate with a 19 block reorg. 14:11:30 >the reality is 14:11:33 you're delusional 14:11:54 or maybe you aren't, you are doing on purpose 14:13:38 @syntheticbird: Who knows maybe I secretly control Qubic behind the scenes of it all 14:15:43 will the DNS checkpoint point to the side chain of the 18-block reorg? 14:16:06 We suspect that they rent 2+ more GH/s in short burst to do big reorgs. Otherwise it's an extremely improbably to do this with 30% of hashrate that they usually have. 14:16:20 *improbable 14:18:05 sech1: This has been known for a long time 14:18:32 sech1: but statistically speaking how much percentage of hashrate one must have to get 18 consecutive blocks 🤔. Its understood they would more than 51%, but to get 18 blocks , looks closer to 80 or even 90% hashrate. 14:18:58 or if my probabilty calculations are wrong 14:19:18 No, they can have around 50% for a while, and stay a few blocks ahead until their chain gets long enough 14:20:57 but that does also involve luck factor too i guess 14:21:28 Just as we talk here, Qubic people over in their discord discuss whether they really "broke" 118 transactions with their large reorg, and if yes why, i.e. why they did not just copy over those transactions to their alternative chain, to include it here. Fascinating. 14:22:17 they need 51% hashrate + 100% effort luck 14:23:29 They can't "copy over" transactions once they're past 10 blocks 14:23:36 Because decoy indices will not match 14:23:38 @kevino:tchncs.de: It could be chance, with 49% we would expect to see a 19 block streak once in 35 months (The previously estimated 30% it would be basically impossible, 45% is once in every 400 years). 14:24:10 Ah, yes, you would have to copy and modify accordingly ... 14:24:26 Which is - impossible? 14:24:35 yes 14:24:45 Cool 14:24:56 @kevino:tchncs.de: Selfish mining they can have 100% of blocks at 51% 14:25:13 it's not selfish mining at this point, it's just 51% attack 14:25:20 @barthman132:matrix.org: Where are you getting your calculations? Does not sound correct to me. 14:25:28 So it's possible those dear people still don't fully undestand indexes :) 14:26:50 i would say most likely AI from the statement they gave before 14:28:27 You can do about ten 18-block re-orgs per day if you have 45% share of hashpower 14:28:49 "Table: Duration of meta attack to achieve attack success probability of 50 percent" https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881 14:28:51 They have around 30-35% 14:29:03 But they can burst mine with additional 2 GH/s when they want 14:29:13 Source: All my calculations, which you can read there ^ 14:29:39 It costs them a lot of money to rent that extra hashrate, which is why it never lasts long 14:29:44 Burning money for PR stunts 14:30:23 IMHO, the question about DNS checkpoints is how long they can hold that extra 2 GH/s 14:30:36 "Burning money for PR stunts" Half the world's companies are doing this, no? 14:30:53 sech1: If they have a state actor funding them its never ending 14:30:56 does the DNS checkpoints point to the other chain? 14:31:19 broken off by the reorg? 14:34:42 elongated: i wouldn't actually be surprised if QUBIC was a front for state actors to destroy monero 14:35:16 i believe state actors have an interest in using monero, so i believe it's just someone trying to make a quick buck here 14:36:53 and who's to say his intent wasn't to defraud some exchange, eh? :p 14:38:33 @helene:unredacted.org: highly unlikely unless someone has some proof to it 14:39:06 monero's marketcap is not that big right now to attract a state actor 14:39:26 enough to attract the attention of the EU? :P 14:39:30 Cindy_: Why would a state actor need Qubic to destroy monero in the first place? If they really wanted to destroy monero, they would just do it and there wouldn’t be anything we could do about it. What are we going to do? Complain online on twitter 14:40:32 barthman132: crypto grifters like to cannibalize each other, so if we give them a shit coin to invest in, in place of monero, it'll work out 14:40:50 @kevino:tchncs.de: it's not a secret that state actors engage in illegal activities and on DNMs, sometimes doing so to identify sellers or admins; it would be inconvenient to them if monero was unusable 14:42:21 The probability of Qubic being a state actor is extremely low. Also if they were a state actor. Why would they move on to eventually mine dogecoin? 14:42:41 i'm not saying Qubic is a state actor 14:42:49 Is dogecoin in the room with us now? 14:42:55 i'm saying there could be state actors hiding behind Qubic 14:43:09 to FUD people from using monero 14:43:27 and perhaps funding, to help destroy monero more 14:43:39 even state actors accumulating xmr by trying to lower the price 14:44:37 you'd have to be a lil bit retarded to be a powerful state and actually ignore monero 14:45:27 ofrnxmr: really? None of my friends even know about monero... 14:45:37 there have been cases of de-anonymising sellers by pushing them to use bitcoin instead of monero, so it isn't impossible; but i find it unlikely most states would care right now in particular 14:45:48 they probably aren't actually involved in the stuff behind Qubic, but most likely they provide funding cuz they're doing a good job of demotivating people from using monero 14:45:52 your friends are in the irs/cia/nsa/dhs? 14:46:18 no, kgb 14:46:32 Mine are in mossad 14:46:40 ofrnxmr: lol no, my point is that it's not very known-about, so I'm asking why a state would care much about it 14:46:48 if Qubic burns money on all of this, where else do you think they get it from :P 14:47:17 Youre wrong about that.. its arguably the most used cryptocurrency on the planet 14:47:27 niq: Facts! TBH if you asked random people on the street to name a cryptocurrency most would just name either ethereum and bitcoin. The fact is monero is not big enough to attract the attention of a state actor. 14:47:34 People why trade ticker symbols on coinbase dont know about monero 14:48:07 (likely) a majority of people who use cryptocurrency as digital cash, use monero 14:48:20 i think monero is big enough to attract the attention of state actors 14:48:41 otherwise you wouldn't see as much bans on private coins as you do now 14:49:18 They delist privacy coins (monero) cuz they dont knowbwhat it is /s 14:49:24 > i'm saying there could be state actors hiding behind Qubic 14:49:24 Just some big investors 14:50:46