00:43:44 interesting note about ext4 there, is btrfs similarly "safe"? 01:00:12 Monero Fluorine Fermi (v0.18.0.0) binaries are online at getmonero.org 01:33:38 ^ ledger users do not upgrade yet, ledger version locks their app and there is mo update yet 01:35:36 no* 01:54:44 Still says: Current Version: 0.17.3.2 - Oxygen Orion on the site, yet downloads v18 01:59:44 Also hashes are still old. 02:09:51 Just want to take a moment to celebrate the first major released in almost two years! 02:12:50 Mochi101: it's a CDN issue, the non CDN version has the correct links https://web.getmonero.org/downloads/ 02:13:09 should be fixed once binaryFate comes online 02:20:37 2 years? 02:20:44 feels like yesterday 02:35:22 ok selsta 02:39:12 2020 was a forgettable year. it should count as 1 year tbh 02:49:29 Also we had ATH daily transactions today. 02:50:18 I've updated the CDN (again), it's quite an unclear and unrelieable UI that they keep changing every few months. 02:50:28 Hopefully good now 02:51:49 Please hard reload (like SHIFT+CTRL+R) and if still old, try with guest/anonymous window which forces fetching anew. Let me know 02:52:09 Mochi101 selsta ^ 02:52:53 Good now, no hard reload required. Thanks binaryFate 02:53:21 TIL web browsers have hard reloads. 02:53:42 :/ 03:02:02 The v0.18 CLI looks amazing! 09:09:31 Hypothetically speaking, If only BlackRock had the permission to add digitally-signed blocks (with BlackRock key) to the monero blockchain, how will they go about discarding transactions from bad actors? AFAIK, this can't be done because monero transactions are already indistinguishable from each other thanks to CLSAG, one-time-addresses, range proofs of pedersen commitments. So BlackRock won't know which transaction they are including or not-including 09:09:31 in the blocks under this hypothetical scenario. BlackRock could be handling transations from Sisters-of-Charity or a drug-cartel, so BlackRock won't know which transaction they are dealing with. So why do we require Monero to be permission-less? 09:12:23 For one thing, this kind of censorship would work by forcing you to disclose your tx details to BlackRock (or whatever censoring middleman). If you don't, they refuse to broadcast and mine your transaction 09:13:15 But the root problem with that line of reasoning is that since the network is open-source, nobody in their right mind would choose to accept to run a version of the software that allowed only BlackRock to mine blocks in the first place 09:13:43 So if they tried to push such a thing, they would just end up excluding themselves 09:14:16 And thanks to p2pool, we are now (potentially) immune to pool censorship too (if they ever got compromised or forced to implement such policies) 09:16:59 merope, what if I start a company called WhiteRock and I do not require anyone to reveal their tx secrets as per how I define the protocol. I alone can add digitally signed blocks with my key. And then I ask people to trust me that I will only mint/burn my Schmonero token, such that 1 SXMR = 1 USD. I think people will use Schmonero because exchange rate is pegged to USD. And if I add more features like Layer 2 channels that anyone can host, and settle 09:16:59 on my Layer 1, and have other features like easy to use atomic swaps, then people will come. 09:18:11 "then people will come" - you can't just assume that 09:18:17 maybefbi: you're welcome to fork Monero and make a centralized USD stablecoin. It won't be Monero lol 09:18:28 In fact, what you've just described is the definition of a bank 09:18:31 What if the company shuts down? We just no longer have a blockchain? 09:18:33 Like literally a traditional bank 09:18:34 kayabaNerve, yeah it will be Schmonero 09:18:51 maybefbi: call it... SWIFT 09:18:55 lol 09:19:14 While there are plenty of dumb crypto "investors", what you have there is a completely centralized system with you as a trusted middleman 09:19:26 agreed 09:19:31 but it will be anonymous 09:19:47 So you'd just join the pile of thousands of such "enterprises" who scammed a few dumb idiots of some money 09:20:41 the on-chain data might be anonymous, but users would almost certainly end up revealing their identity to you (even just accidentally, through ip/fingerprinting) 09:21:01 maybefbi: this is called mobilecoin 09:22:56 merope, ip/fingerprinting. this is a problem with Monero also. 09:23:17 jwinterm, let me look into mobilecoin and other such shitcoins lol 09:23:52 it is basically monero but the company that runs the signal messenger app launched it and they are in charge of verifying txs on the network 09:24:09 so it is like company verified monero 09:24:20 and definitely a low-tier shitcoin 09:24:40 not the same kind of problem, because you can run your own node, and transactions are relayed using Dandelion++ between nodes - so it's extremely hard/almost impossible to figure out which node first submitted a tx 09:28:30 maybefbi: endor00 kayabaNerve See existing research: 09:28:50 Li, Y., Yang, G., Susilo, W., Yu, Y., Au, M. H., & Liu, D. (2021). Traceable monero: Anonymous cryptocurrency with enhanced accountability. 09:28:50 https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=96 09:29:05 there's also so many legal questions/concerns 09:29:16 Zhang, Y., & Xu, H. (2022). Accountable monero system with privacy protection. 09:29:16 https://moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=94 09:29:59 Rucknium[m]: The discussion is full privacy, just without PoW. 09:30:08 Because why PoW when you can shim in a corp 09:30:22 ... shouldn't this be in #monero-offtopic or literally any better channel? 09:30:50 Side note, the above research is interesting, even if I don't endorse it (in its proposed usage) 09:32:08 kayabaNerve: That's not how the discussion started in -dev 09:32:17 Rucknium[m], looking at it. thanks 09:32:19 This started in -dev? D: 09:32:24 Sorry then 09:32:48 I mean, it's a good discussion to be had - knowing why things work the way they do is just as important as knowing how they work, in environments like this 09:33:07 Oh. Yes. Just those more limited messages do suggest that research on how a corp could break privacy 09:33:34 Yet the above messages elaborated as "do not require anyone to reveal" 11:34:35 We have a new record. 2022-07-19 17:44:30.270 [P2P3] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:414 [216.174.105.167:18080 OUT] Sync data returned a new top block candidate: 2670961 -> 2671381 [Your node is 420 blocks (14.0 hours) behind] 11:34:58 This is the closed I have been to getting head in way too long 12:36:07 I just tried to send a transfer whlie 420 blocks behind and eventually got the error: Error: daemon is busy. Please try again later. 12:43:21 Is this just because the node is not fully synced? 12:45:38 It considers itself busy till it finished syncing once. 12:46:01 "Syncing" here is defined loosely, if you lose all peers I think it'll consider itself synced. 12:46:29 So I *think* out_peers 0 + out_peers 12 should basically tell it to start accepting RPC. 12:46:32 +in_peers 12:57:07 so frustrating. So its been over a week now and the node will not sync any closer to head than ~450 blocks. WHY?!?! 13:03:09 maybe it *is* syncd and one of its peers is lying about chain height? 13:15:50 well, I just --enable-dns-blocklist and see if that makes any difference running overnight. night all 14:54:13 At some point we should move to version 1.0 14:54:21 Maybe with Seraphis 15:09:42 duso: what is your current blockheight? 15:09:54 is it the same as on xmrchain.net ? 15:10:00 which version are you using? 16:06:41 Move versioning to 1.0 upon inclusion of Seraphis protocol https://github.com/monero-project/meta/issues/721 16:52:13 duso, one thing to do is add "--add-priority-node " to your monerod startup, with the ip address of some node you kinda trust 16:59:27 gingeropolous: shouldn't be necessary on a normal working node 17:00:08 indeed 19:42:35 https://www.inforisktoday.com/doj-seizes-500000-from-north-korean-attacks-on-healthcare-a-19593 21:56:51 selsta: 2022-07-20 03:27:46.284 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:414 [92.117.219.164:18080 OUT] Sync data returned a new top block candidate: 2671189 -> 2671715 [Your node is 526 blocks (17.5 hours) behind] 21:58:04 duso: what is your current block height (enter status), what version are you running? 22:00:32 selsta: Monero 'Oxygen Orion' (v0.17.3.2-release) and Height: 2671189/2671701 (99.9%) on mainnet 22:01:48 as a first step i would recommend to update to v0.18.0.0 22:02:18 what is your computer hardware and what storage do you use? you said something about VM in the past IIRC 22:09:26 to review as briefly as possible - 6+ years ago built node in freebsd jail on FreeNAS. 9 Months ago upgraded FreeNAS FreeBSD 12.1 to TrueNAS FreeBSD 13 and monerod crashed, stopped syncing. 2 weeks built new jail and installed monerod, copied over old blockchain 9 months behind, worked, quickly synced to ~450 blocks behind but never any further 22:11:10 hardware is Intel xeon E3-1230v6 with 32GB ram backed with raidz1 ZFS array on rust drives. 22:12:28 If I stop the daemon running for a day, it will again quickly sync to about 450 blocks behind head, but can't seem to sync any further. 22:12:52 I will upgrade to monerod v0.18 as soon as its in the pkg repository 22:15:00 does it also start to ban peers? 23:23:37 selsta: ban or block? I see lots of blocked peers in the log 23:23:59 yes it's likely that your db has an issue 23:24:22 it fails to verify a block -> blocks peer thinking they are sending garbage data -> stays stuck 23:24:28 did you copy this from the node that crashed? 23:24:34 yes 23:25:37 use v0.18 plus sync from scratch, it should solve all the issues 23:28:20 selsta: so just delete the old blockchain and resync 130+ GB of data? Isn't there a way to recheck the old existing blockchain? I'm down here in country australia, 130GB is a lot of trips for carrier pidgeon internet here 23:29:59 you can run --prune-blockchain --sync-pruned-blocks which should reduce overall required traffic 23:30:25 but no, there is no "fix database" function 23:30:31 corruption can mean anything 23:33:31 ok, will try that