00:02:55 <321bob321> Nope 00:03:05 <321bob321> No state secrets here 00:03:17 it exists but not added here 00:03:59 wait, I don't think it exists they way you are saying it 00:04:01 <321bob321> Only assassin and state secrets use discord 00:13:48 Unfortunate. It used to exist on the Monero Discord Server back in the day. https://discord.gg/gXDsemASaR this one 00:14:36 there is no official server 00:14:43 let alone official bridge 00:14:55 our official ways of communication is matrix and IRC 00:14:57 Cindy, didnt you test coinwallet? 00:15:09 coinwallet? 00:15:13 yeah i did 00:15:24 i used it and had a network debugger on 00:15:27 Theyre in #monero-community whining 00:15:50 i will join 00:16:07 Thanks. Lets see if they respond again 08:55:09 Why is monero on Kraken trading at a premium? 09:27:17 @houseandtiger:matrix.org: how is anyone but kraken supposed to know? 10:12:33 GM 10:55:13 What is Monero? 10:55:22 Is this a new buttcoin? 10:57:05 it's not a buttcoin 10:57:29 it's a cryptocurrency with privacy on transactions by default 11:17:43 who is monreo 11:18:00 my long-lost second cousin 11:21:39 did you mean montero? 11:22:03 yes, montero, excuse me 11:22:20 a car 11:22:49 I need one of those 12:12:12 marilyn monero? 16:48:31 I've read that for btc it is a good practice to sweep large number of UTXOs as fee minimization practice as number of UTXOs in a transaction increases the fee. From what I read, monero fees are a lot smaller. However, it seems higher number of inputs in a transaction should still drive the fee up. Average transaction fee chart [... too long, see https://mrelay.p2pool.observer/e/o_mYjLcKTWJvN0dY ] 16:57:20 And another question around that, but from privacy perspective - is there a difference between spending directly from the main address where mining payouts go, and sweeping/consolidating it first by sending to a subaddress of the main address and spending from there, or consolidating to another main address (different wallet). [... too long, see https://mrelay.p2pool.observer/e/kIC5jLcKZEZEMWU2 ] 17:03:25 That second counts as moving it to another wallet, minus some differences 17:03:55 Note that sweeping to the same sub account (part of the main address) opens you to tagging for future sweeps 17:04:15 The last comment from Jerfov2 here: https://www.reddit.com/r/Monero/comments/1bazcoz/utxo/ suggests it is better to not consolidate from privacy perspective. Yet, since regular Joe's payouts from p2pool are typically very small, almost any real spending of the payouts would end up having lots of payout outputs on the input sid [... too long, see https://mrelay.p2pool.observer/e/i9vSjLcKZTkxeVdF ] 17:04:19 So moving to another full sub account in wallet or preferably another wallet entirely is recommended, specially when mining on p2pool 17:04:49 Even spending normally can show as consolidation 17:05:18 My sweep tracker tags more than 4 inputs but using other heuristics it's very easy to detect even two inputs on same miner 17:05:34 Do not spend directly from p2pool outputs 17:06:07 Either sweep to another wallet or assume that they know the spender is you (and probably the amount spent) 17:08:10 So, if privacy comes first, one must sweep as a best practice, hence the fees part becomes irrelevant as it is unavoidable. Thank your for the explanation. 17:09:40 what about the limit on number of inputs? I read that typically wallets are smart and can take care of such technicalities, but is there really a limit? 17:10:46 They do, there is 17:11:02 You can check the recent likely sweeps in p2pool and see the limits they hit :) 17:11:29 There was recently more interest in offering a sweep type for Coinbase outputs, specially post FCMP 17:11:52 There is nothing yet, but hopefully this is mitigated in the future 17:12:09 You can always use the lowest of fees if regularly sweeping 17:25:14 Thanks, and what's the purpose capturing and publishing the likely sweeps data? most of the likely sweeps show close to 100% of self decoys. Is it simply a demonstration that such sweeps are inherently visible or is there a practical reason to make this data easily accessible? 17:27:15 btw, I see FCMP and FCMP++ being used interchangeably sometimes. Is there a difference? 17:27:54 is using non-default fees is still suboptimal for untraceability? 17:28:06 things were added so FCMP became FCMP++ 17:29:43 got it, but it is still in development/testing phase, right? and it could still become something like FCMP+++ :D 17:30:07 no more pluses coming :) 17:30:54 code is mostly done, private testnet is up with public testnet coming soon 17:34:10 When I say FCMP I mean the latest iteration of it 17:34:51 As for the sweeps, it is to show users that those spends can be tracked with minimal effort, to incentivize the sweep out to external wallet or sub account 17:35:23 I don't capture the data as one off, I scan transactions in Monero and do the linkage. If I can with the shit linking I do anyone else can 17:35:51 If you are sweeping and can be identified, might as well use lowest fees ;) 17:36:07 Not identified as in person, but wallet / entity 17:36:11 FCMP+++ will have things to tackle reorgs and invalidated transactions 17:36:50 Sure, completely get it, I didn't mean to suggest that publishing can be somehow harmful to anyone, on the contrary. Just wasn't sure if there was another reason behind it that one should be aware of and use :) 17:37:55 Well it worked as well to make changes to p2pool so it'd generate less outputs (dynamic PPLNS) 17:38:19 Otherwise it was affecting the privacy of others as anyone using the p2pool decoys would not be using useful decoys 17:39:26 can't wait for the FCMP++, as in my understanding it should make the current techniques of tracing back the outputs obsolete 17:40:05 can you explain a bit on the decoys? p2pool, useful. First time hearing about this 17:52:04 Decoys are how Monero obscures the true spend. For each input several others are included to prevent learning which one you spent 17:55:15 and when you say p2pool decoys, you mean real outputs of the p2pool payout or something else? 17:58:43 I mean they used coinbase Tx outputs that happened to be made by p2pool 17:59:00 They are selected at random according to a specific distribution 18:03:50 I think I got it, thx 19:57:03 gm everyone. Here is a little bash script I made to call a hook when selfish mining is detected. The main use-case is to activate miners when the network is under attack. Thanks @DataHoarder for the API and advice. Please PM me bugs and suggestions. 19:57:03 https://gitea.gf4.pw/ki9/karmine/ 19:57:51 DataHoarder 19:58:02 CONTINUE_MINUTES 60 defalut, nice :) 19:58:19 🫡 19:58:51 note from what I can see qubic mined normally (not selfish) during this marathon so far 19:59:30 I think I caught one ALT ROOT about 100 minutes ago. 19:59:52 that can happen due to timing 20:00:15 block is found -> gets faster to some than others 20:00:45 if you check every 60s, maybe trigger only if 2x in a row with different "update" timestamps exist 20:00:54 Was about to ask 20:01:07 Is 2 enough? I'll make it configurable but as a default? 20:01:10 alternatively try fetching the qubic hash that displays at the top from monero 20:01:13 if they got rpc 20:01:29 that checks if the block is in their node, if not, it's an alternate one or selfish 20:01:54 Man, I was excited to mark this little project finished haha. 20:02:07 :D 20:02:10 I'll just wait for 2x because that's easy. 20:02:16 via stratum I can't see if they are mining ahead or I haven't received monero block yet (I check own monero node) 20:02:29 so it can take a few seconds to converge, though usually it's way faster 20:02:43 you will also some pools lag behind sometimes 20:02:51 specially c3pool lol 20:03:31 I thought the mining ahead is what the tips were. > via stratum I can't see if they are mining ahead or I haven't received monero block yet (I check own monero node) 20:03:40 I don't have to understand but my readme should be correct. 20:03:45 tips is "highest known block" 20:03:58 the "tip" of the chain they have 20:04:26 when I say "qubic mining on TIP" is that they are mining at the same height AND block hash than the public known one 20:04:48 maybe you caught this one https://irc.gammaspectra.live/21755f300674a1a5/image.png 20:04:53 or different pool one 20:05:00 where two pools find a block at the same time 20:05:13 they usually keep mining the one they got first (theirs) until longest wins 20:05:54 nvm, they did selfish at 17:50 20:06:19 for a chain of TWO blocks 20:06:23 then no more 20:09:15 Oh, I see. You mean if you only check stratum, that's not enough information, you have to compare it to the tip of a "benign" node. > via stratum I can't see if they are mining ahead or I haven't received monero block yet (I check own monero node) 20:09:20 Right? 20:09:27 yes, I do that 20:09:36 but my node might not have gotten the block yet... 20:09:44 so next refresh catches it 20:09:57 Got it 20:10:49 So is two a good default? Is it reasonable to trigger an hour of mining for just two refreshes of selfishness? 20:11:23 their selfish mining might be there but unlucky 20:11:43 and suddenly they find 8 blocks in 5 minutes :D 20:12:32 Ok. I'll update the script tonight to wait for a second refresh before triggering the hook. 20:13:03 Also, I guess there's nothing stopping qubic from firewalling 3333/tcp to vpn or lan only and then it's game over for my script. 21:03:01 22:13:03 Also, I guess there's nothing stopping qubic from firewalling 3333/tcp to vpn or lan only and then it's game over for my script. 21:03:04 miners have to mine 21:03:13 and they allow MRR rentals for their users 21:03:21 so the stratum must be connectable 21:04:40 is it more profitable to mine when qubic is selfish mining 21:06:37 efficiency says yes 21:06:59 this is relative to all the blocks found in aggregate btw 21:07:13 lol 21:07:17 hooray! 21:07:27 i should hae mined when they were mining ughhhhh 21:10:42 note both sides get orphans but the end result is worse for qubic 21:10:56 they take a share of it, but lose more 21:11:14 they did make changes and recently it's a bit more efficient, still below 100% when selfish