01:21:03 <MajesticBank> https://twitter.com/MajesticBank/status/1663716497380737024
01:55:09 <TrasherDK[m]> <monerobull[m]> "this kills the conversation 💀" <- Yes, please. Kill it already 😴
03:16:35 <DanIsnotthemanBr> Pew pew
03:20:41 <apotheon> Pew pew?
04:54:41 * DanIsnotthemanBr uploaded an image: (99KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/muqBEzELWtsfoXSAOgQTYSZX/ima_e9721cb.jpeg >
10:03:00 <DanIsnotthemanBr> https://www.reddit.com/r/Monero/comments/13viqax/update_the_fucking_flatpak/
10:03:00 <DanIsnotthemanBr> wtf?
10:05:32 <plowsof11> i asked for more info and only got "version incompatibility error acfer ", any ideas BigmenPixel 
10:05:48 <plowsof11> s/acfer/after flatpak run
10:07:56 <BigmenPixel[m]> DanIsnotthemanBr: > <@123bob123:matrix.org> https://www.reddit.com/r/Monero/comments/13viqax/update_the_fucking_flatpak/
10:07:56 <BigmenPixel[m]> > 
10:07:56 <BigmenPixel[m]> > wtf?
10:07:56 <BigmenPixel[m]> Wtf, it would be good if there is a github issue with info
10:10:27 <plowsof11> cannot reproduce, closing for now, good job everyone 
10:18:08 <DanIsnotthemanBr> People are weird
10:54:37 <susman1[m]> <red_cardinal[m]> "There's a long list of natural..." <- > <@red_cardinal:monero.social> There's a long list of natural resources of which the world's biggest consumer is the US military. The primary purpose of the US military is to (indirectly) maintain USD and UST as global reserve currency/asset, thereby allowing the creeps in the shadows to maintain control for their own benefit and at the cost of everyone else.
10:54:37 <susman1[m]> > 
10:54:37 <susman1[m]> > As a general rule, anyone "left leaning" has a child-like understanding of economics, so is a hopeless case. There are always exceptions, of course.
10:54:37 <susman1[m]> don't simply discount leftists like that be the bigger person bc this kinda behaviour leads to possibly wrong assumptions and echo chamber thinking there are some leftists who are adept at economics its just that it is somewhat subjective
10:56:23 <susman1[m]> <ofrnxmr[m]> "My response is "youre on reddit,..." <- that is more of a player not the game type thing tho
10:57:35 <susman1[m]>  * don't simply discount leftists like that be the bigger person bc this kinda behaviour leads to possibly wrong assumptions and echo chamber thinking there are some leftists who are adept at economics its just that it is somewhat subjective, its like when some auth people say libertarians are retarded same with college educated liberals the same about conservatives don't turn an argument into an ego boost
11:29:03 <k4r4b3y[m]1> is cryptogrampy around the matrix?
11:29:21 <k4r4b3y[m]1> I would like to ask him some questions about his android-termux-monero-node project
11:29:30 <k4r4b3y[m]1> if you see him, please tell him to DM me.
11:29:53 <k4r4b3y[m]1> btw, you can join #yolgezer:karapara.net to discuss about running a monero node on your android device
12:19:04 <DanIsnotthemanBr> https://www.reddit.com/r/Monero/comments/13wbsf3/monero_has_been_a_bad_experience_am_i_doing_it/
12:19:04 <DanIsnotthemanBr> 🤦‍♂️
12:22:50 <k4r4b3y[m]1> what is the world record for syncing a full monero node in shortest amount of time?
12:23:54 <DanIsnotthemanBr> Ravfx did hdd/ssd testing
12:24:08 <DanIsnotthemanBr> They might know
12:24:41 <sech1> World record doesn't mean much because a few months later it will take more time anyway
12:25:00 <sech1> Right now it's 4-5 hours to sync a full node with 1 Gbit connection and a fast PC with NVMe SSD
12:25:52 <sech1> Also, it's faster right after new release because new release has fresh checkpoints
12:26:03 <k4r4b3y[m]1> then I should've asked "the world record for having GB/s synced.
12:26:05 <sech1> you can compile a binary with fresh checkpoints to save a few hours of syncing in the end
12:26:45 <k4r4b3y[m]1> k4r4b3y[m]1: > <@k4r4b3y:karapara.net> then I should've asked "the world record for having GB/s synced.
12:26:45 <k4r4b3y[m]1> > 
12:26:45 <k4r4b3y[m]1> can be computed as the full blockchain size / total time it took to sync
12:28:47 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> Also, it's faster right after new release because new release has fresh checkpoints
12:28:47 <k4r4b3y[m]1> what are the functions of "checkpoints"? Am I trusting someone else with the state of the blockchain with them?
12:29:19 <sech1> it's known block hashes (or hashes of each 256 consecutive blocks, I don't remember the details)
12:29:50 <sech1> with these hashes, you're just choosing the "current" blockchain and make your binary ignore deep reorgs (deeper than the last checkpoint)
12:29:50 <k4r4b3y[m]1> why are they needed? can't a node sync to a full blockchain without them?
12:30:06 <sech1> node can sync without them, but it will be much much slower
12:30:27 <k4r4b3y[m]1> also, aren't reorgs discarded by "eventual consistency" among the many numbers of nodes?
12:30:36 <k4r4b3y[m]1> you know, the most proof of work chain is the main one?
12:31:17 <sech1> reorgs happen from one chain with X amount of PoW to another chain with more than X amount of PoW
12:31:42 <sech1> if someone does 51% attack lasting for a long time, then nodes with checkpoints will ignore new chain even if it has more PoW
12:32:04 <k4r4b3y[m]1> hmm..
12:32:11 <k4r4b3y[m]1> does btc also make use of such checkpoints?
12:33:41 <sech1> no idea
12:35:44 <selsta> yes bitcoin also has checkpoints
12:36:20 <selsta> though based on googling it it seems they removed them at some point
12:36:29 <DanIsnotthemanBr> https://bitcoin.stackexchange.com/questions/75733/why-does-bitcoin-no-longer-have-checkpoints
12:36:40 <DanIsnotthemanBr> Yeah thats what i saw
12:38:26 <selsta> monero checkpoints are usually weeks or months old, if there is a whole month of reorg there is a bigger issue anyway
12:41:25 <k4r4b3y[m]1> DanIsnotthemanBr: > <@123bob123:matrix.org> https://bitcoin.stackexchange.com/questions/75733/why-does-bitcoin-no-longer-have-checkpoints... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/dceeaf724db902808ea0b5353bcc75e11eb671b0>)
12:41:47 <k4r4b3y[m]1> so, in monero, these checkpoints are used for increasing the speed of the sync?
12:41:54 <selsta> no
12:42:12 <selsta> fast-sync and checkpoints are two separate things that sometimes get confused
12:42:48 <k4r4b3y[m]1> so, the checkpoints in monero are used as part of the blockchain's security model?
12:43:10 <selsta> fast-sync is a list of known hashes that reduce verification work during initial sync
12:45:07 <selsta> checkpoints are to make sure you are on the right chain during initial sync and have the right difficulty
12:46:54 <selsta> i don't know if they help with security, like i said there's often weeks or months between the latest checkpoint and current blockchain height, such large reorgs are not realistic unless the whole system is broken
12:47:25 <k4r4b3y[m]1> selsta: > <@selsta:libera.chat> checkpoints are to make sure you are on the right chain during initial sync and have the right difficulty
12:47:25 <k4r4b3y[m]1> I am not understanding why wouldn't a fres-syncing node be lead-astray during the initial sync?
12:47:32 <k4r4b3y[m]1> *why would
12:47:50 <selsta> fres-syncing?
12:47:56 <k4r4b3y[m]1> fresh-syncing
12:48:09 <k4r4b3y[m]1> why would a fresh-syncing node be lead-astray during initial block sync?
12:48:23 <selsta> in case the node gets isolated from the network and only connects to malicious peers for example
12:48:54 <k4r4b3y[m]1> is monero's node network still open to such attacks? still the attackers can outnumber the honest nodes?
12:49:12 <k4r4b3y[m]1> I would expect monero's network to be mature enough to have resilience against that, at this point.
12:49:17 <selsta> every p2p network can be attacked this way
12:49:43 <k4r4b3y[m]1> yeah, true. But having a large number of honest nodes counters this attack, no?
12:49:49 <selsta> it's a theoretical thing
12:50:18 <k4r4b3y[m]1> what's theoretical? the attack or having the resilience by large number of honests?
12:50:36 <selsta> the attack
12:51:22 <k4r4b3y[m]1> isn't such a "checkpoint" mechanism a form of centralization around some human institutions?
12:51:41 <k4r4b3y[m]1> is it being considered for discarding the checkpoints? like btc did apparently?
12:52:40 <selsta> imo it's not centralization, as it only protects against attacks but there's no way it can be abused
12:52:49 <selsta> everyone can run their own client without checkpoints
12:53:10 <k4r4b3y[m]1> does monerod have an option (or, directive) for this to be placed in its config file?
12:54:08 <plowsof11> relevant issue from tevador i think https://github.com/monero-project/monero/issues/8836
12:54:10 <selsta> compile your own daemon
12:54:29 <selsta> plowsof11: this is about fast-sync and not checkpoints
12:54:36 <plowsof11> ah ok ok
12:54:41 <k4r4b3y[m]1> plowsof11: > <@plowsof:matrix.org> relevant issue from tevador i think https://github.com/monero-project/monero/issues/8836
12:54:41 <k4r4b3y[m]1> yes, this gave me a surprise
12:55:26 <k4r4b3y[m]1> yeah, I know the current topic is about fast-sync and checkpoints, but also tevador's issue gives some concerns about actually having Monero network be decentralized when it comes to its blockchain state.
12:56:07 <sech1> I was talking about fast-sync as "checkpoints" this whole time
12:56:19 <sech1> there's a lot of confusion about this
12:56:27 <k4r4b3y[m]1> it sure seems like it
12:56:28 <plowsof11> XD
12:56:35 <sech1> even the file is called "src\blocks\checkpoints.dat" in Monero repo
12:56:42 <sech1> but it's for fast-sync
12:56:47 <selsta> yes, that's where the confusion comes from
12:57:24 <sech1> the "other" checkpoints were created to prevent attacks and have never been used IIRC
12:57:37 <sech1> they're DNS-based
12:57:49 <selsta> the DNS based ones have never been used
12:58:11 <sech1> and by default they only print a warning
12:58:16 <sech1> you need special command line to enforce them
12:59:19 <k4r4b3y[m]1> <selsta> "in case the node gets isolated..." <- > <@selsta:libera.chat> in case the node gets isolated from the network and only connects to malicious peers for example
12:59:19 <k4r4b3y[m]1> is this the only reason we have the checkpoints (the ones that protect against reorgs_?
12:59:50 <k4r4b3y[m]1> if so, can the protection from being isolated from the network be solved with getting people to run monero nodes?
12:59:54 <selsta> they are so infrequently updated that i don't see a scenario where they help against reorgs
13:00:13 <k4r4b3y[m]1> Why not remove them?
13:00:31 <selsta> what harm do they cause?
13:00:55 <k4r4b3y[m]1> they give the impression that a human institution is still being trusted with monero's chain state.
13:00:57 <k4r4b3y[m]1> imho
13:02:16 <ofrnxmr[m]> You can just run with --disabke-dns-checkpoints
13:02:22 <ofrnxmr[m]> Or something like that
13:02:30 <ofrnxmr[m]> And also disabke fast sync, am i wrong?
13:02:42 <k4r4b3y[m]1> ofrnxmr[m]: > <@ofrnxmr:monero.social> Or something like that
13:02:42 <k4r4b3y[m]1> I think the messages prior has shown that what we now talk about is different from dns checkpoints
13:02:43 <ofrnxmr[m]> Can free-wheel it all day if you please
13:03:04 <ofrnxmr[m]> But if you run a wownero node and witness a chainspit, you might want those checkpoints
13:03:04 <selsta> i would like a scenario where hardcoded checkpoints harm decentralization that isn't impression based
13:03:19 <k4r4b3y[m]1> ofrnxmr[m]: > <@ofrnxmr:monero.social> And also disabke fast sync, am i wrong?
13:03:19 <k4r4b3y[m]1> also, we have been talking about the "checkpoints" of the sort that "protect against reorgs", as far as I am understanding the convo
13:03:24 <ofrnxmr[m]> There was even talk of decentraliz*ng the checkpoints sobthey are genersted distributed p2p every x blocks
13:03:36 <ofrnxmr[m]> Im referring to both
13:03:54 <ofrnxmr[m]> There are flags to disable checkpints and alsp fast sync
13:04:06 <selsta> we could also remove prebuilt binaries because they "harm decentralization"
13:04:08 <selsta> remove seed nodes
13:04:25 <ofrnxmr[m]> You can do that too
13:04:35 <ofrnxmr[m]> Free wheel it if you want. Nobody is stopping you
13:04:47 <k4r4b3y[m]1> ofrnxmr[m]: > <@ofrnxmr:monero.social> Free wheel it if you want. Nobody is stopping you
13:04:47 <k4r4b3y[m]1> give me the monerod flags to do that
13:05:11 <ofrnxmr[m]> Monerodocs.org
13:05:23 <ofrnxmr[m]> daemon page 
13:05:39 <ofrnxmr[m]> Ctrf f
13:05:39 <ofrnxmr[m]>  fast-sync
13:05:54 <ofrnxmr[m]> Ctrl-f
13:05:54 <ofrnxmr[m]> dns
13:06:21 <ofrnxmr[m]> 99% sure both are documented there
13:06:27 <k4r4b3y[m]1> How do I locate the flag for disabling the reorg protection checkpoints?
13:06:36 <k4r4b3y[m]1> you are missing that kind of checkpoints still
13:06:48 <ofrnxmr[m]> --disable-dns-checkpoints
13:06:58 <ofrnxmr[m]> Or look at the termux node install script 
13:07:05 <selsta> dns checkpoints are never used anyway
13:07:06 <ofrnxmr[m]> It disables em
13:07:50 <k4r4b3y[m]1> selsta said you have to compile yourself for disabling the reorg checkpoints
13:07:59 <k4r4b3y[m]1> there isn't a flag for that
13:08:01 <selsta> yes
13:08:24 <k4r4b3y[m]1> anyways I don't want to keep playing the devil's advocate here, as I am moving towards concern trolling
13:08:40 <selsta> dns checkpoints are never used without enabling them with a flag, hardcoded checkpoints are added to the source code once per release and have to be removed from the source code
13:08:48 <k4r4b3y[m]1> but I would like to say, I want to see monero rely on no-checkpoints for its chainstate in the near future.
13:09:51 <sech1> dns checkpoints are not enforced by default
13:10:15 <sech1> "./monerod --fast-block-sync 0" to disable fast-sync checkpoints
13:10:17 <ofrnxmr[m]> selsta:  this option doesnt skip them?
13:10:25 <ofrnxmr[m]> --fast-block-sync 	Sync up most of the way by using embedded, "known" block hashes. Pass 1 to turn on and 0 to turn off. This is on (1) by default. Normally, for every block the full node must calculate the block hash to verify miner's proof of work. Because the CryptoNight PoW used in Monero is very expensive (even for verification), monerod offers skipping these calculations for old blocks. In other words, it's a mechanism to trust monerod
13:10:25 <ofrnxmr[m]> binary regarding old blocks' PoW validity, to sync up faster.
13:10:39 <sech1> --disable-dns-checkpoints just turns off the warning in case dns checkpoints and chain state mismatch
13:10:40 <selsta> ofrnxmr[m]: this option disables fast-sync
13:10:52 <sech1> turns off the warning and turns off dns updates
13:12:37 <ofrnxmr[m]> sech1: I thiught it was other way around
13:12:37 <ofrnxmr[m]> ```
13:12:38 <ofrnxmr[m]> --disable-dns-checkpointsThe MoneroPulse checkpoints set by core developers will be discarded. The checkpoints are apparently still fetched though.
13:12:38 <ofrnxmr[m]> ```
13:13:46 <sech1> MoneroPulse checkpoints are not fast sync checkpoints
13:13:50 <selsta> k4r4b3y[m]1: how does monero "rely" on checkpoints?
13:14:46 <ofrnxmr[m]> so to clarify:
13:14:46 <ofrnxmr[m]> fast sync =/= hard coded checkpointsc disabling fast sync doesnt effect them
13:14:46 <ofrnxmr[m]> dns checkpoints = are still used and it just turns off the logging?what?
13:15:07 <ofrnxmr[m]> Disable-dns-checkpoints*
13:15:54 <sech1> all wrong :D
13:16:03 <sech1> fast sync checkpoints are hardcoded
13:16:15 <sech1> dns checkpoints are not used and were never used
13:16:34 <ofrnxmr[m]> My understanding:
13:16:34 <ofrnxmr[m]> - fast sync = hardcoded checkpoints = disable fast sync will skip checkpoints.
13:16:34 <ofrnxmr[m]> - disable dns checkpoints = still fetched but not used or logged
13:16:49 <k4r4b3y[m]1> selsta: > <@selsta:libera.chat> k4r4b3y: how does monero "rely" on checkpoints?
13:16:49 <k4r4b3y[m]1> as far as I could understand, they seem to offer protection against a few weeks' of reorgs for the nodes that are still syncing the blockchain?
13:18:20 <sech1> they're used to speed up sync, nothing more
13:18:31 <selsta> https://github.com/monero-project/monero/pull/8805/files#diff-e6e8140963756b6f6cb97bb2253240db5b0bd63e17fdd99df29cd51941aea637R248
13:18:31 <sech1> "few weeks reorg" is only a theoretical scenario
13:18:40 <selsta> this is what i call hardcoded checkpoints
13:18:42 <sech1> if it happens for real, checkpoints will be the least of problems
13:20:21 <selsta> having two things with the name checkpoint is unfortunate lol
13:20:42 <k4r4b3y[m]1> there seems to be two camps in this chat so far: First camp says that the reorg-checkpoints are used for a few weeks of reorgs for the syncing nodes. The second camp says that they are solely for speeding up the sync. Am I understanding this correctly?
13:21:06 <sech1> "he reorg-checkpoints are used for a few weeks of reorgs for the syncing nodes" whaaaat
13:21:08 <ofrnxmr[m]> <sech1> "all wrong :D" <- I dont know wth i typed, but i dont even understand it. Apologies
13:21:33 <sech1> "few weeks of reorgs" is not even correct description of what you're trying to say
13:21:50 <sech1> "reorg few weeks deep" is probably better
13:21:50 <k4r4b3y[m]1> <sech1> "with these hashes, you're just..." <- > <@sech1:libera.chat> with these hashes, you're just choosing the "current" blockchain and make your binary ignore deep reorgs (deeper than the last checkpoint)
13:21:51 <k4r4b3y[m]1> .
13:22:07 <Rucknium[m]> Will monerod ignore a block that has more proof-of-work at a particular block height than the "checkpoints"? I don't think so (please confirm, selsta). I don't think it offers re-org "protection". Just declare that the transactions contained in those hard-coded block hashes are valid, so monerod does not verify all the cryptography in those transactions (which is expensive!).
13:22:35 <sech1> it will ignore is this block is built on top of chain that forks before the last checkpoint
13:22:40 <sech1> *if this
13:23:19 <sech1> "Just declare that the transactions contained in those hard-coded block hashes are valid" or maybe this, actually
13:23:20 <selsta> Rucknium[m]: what you are saying is correct for fast-sync, it's just a list of known hashes that partly skip verification
13:23:31 <sech1> lol
13:23:37 <sech1> so we were discussing non-issue
13:24:01 <selsta> but there's also a checkpoint system
13:24:06 <sech1> if it's a known "correct block" hash, then it's only for fast sync
13:24:07 <selsta> like i linked previously
13:24:12 <selsta> 2851000, "5bf0e47fc782263191a33f63a67db6c711781dc2a3c442e17ed901ec401be5c9", "0x3b6cd8a8ed610e8
13:24:22 <selsta> means block 20851000 has this hash and this difficulty
13:24:38 <selsta> these get added once per release
13:25:27 <k4r4b3y[m]1> selsta: > <@selsta:libera.chat> these get added once per release
13:25:27 <k4r4b3y[m]1> and their function is ..?
13:26:21 <sech1> ah, so these are actual stoppers
13:26:28 <sech1> so there are 3 kinds of checkpoints now :D
13:26:56 <selsta> k4r4b3y[m]1: they help when you are syncing from scratch and completely isolated from the network / only connected to malicious nodes
13:26:57 <k4r4b3y[m]1> what a shitcoin /s
13:27:04 <sech1> fast sync "src\block\checkpoints.dat" that's used only to speed up sync
13:27:11 <selsta> yes
13:27:28 <sech1> then there is src\checkpoints\checkpoints.cpp" that prevent syncing alternative chains beyond the latest checkpoint
13:27:39 <sech1> and then there are DNS checkpoints which are not used :D
13:27:39 <selsta> yep, and dns checkpoints are unused
13:27:58 <k4r4b3y[m]1> selsta: > <@selsta:libera.chat> k4r4b3y: they help when you are syncing from scratch and completely isolated from the network / only connected to malicious nodes
13:27:58 <k4r4b3y[m]1> so yeah, it seems like this is the point I wrote above: can getting more people to run nodes nullify having these blockhashes being hardcoded?
13:29:49 <selsta> more nodes help but p2p networks will always be vulnerable to attacks like this
13:29:52 <selsta> we also have other mitigations
13:30:32 <k4r4b3y[m]1> am I getting my point across, that, having such hardcoded blockhashes are just aesthetically displeasing when viewed from decentralization of the chain?
13:30:55 <selsta> yes, but i don't like to make decisions based on aesthetics or impressions
13:31:00 <k4r4b3y[m]1> alright
13:32:21 <selsta> i'm not even arguing for keeping them, but at the moment i don't see how they harm while they make it a bit harder for attackers
13:33:22 <selsta> bitcoin is a more mature network with more nodes so it's easier for them to remove them
13:33:53 <k4r4b3y[m]1> mature in the sense of having more nodes and more hashpower behind the chain?
13:34:01 <k4r4b3y[m]1> ah ok, you mentioned the nodes already
13:34:01 <selsta> both
13:34:08 <k4r4b3y[m]1> ye ye
13:34:43 <k4r4b3y[m]1> do we have an estimation of maturity for monero, then? Like, having above X amount of nodes, and X Gh/s of hashpower will get Monero to the big-boys club?
13:35:36 <selsta> i don't, it's probably arbitrary
13:35:48 <k4r4b3y[m]1> but surely you seem to have a sense about it?
13:35:56 <k4r4b3y[m]1> since you are of the "feel" that monero isn't mature enough
13:39:46 <sech1> src\checkpoints\checkpoints.cpp just fix the state of THE chain at the moment, I don't see how developers can centralize something here
13:39:58 <sech1> THE chain = current consensus chain which is run by everyone at the moment
13:40:15 <dMartian> System Information: Model: iMac (Retina 5K, 27-inch, Late 2015) • OS: macOS Monterey (Version 12.6.6, Build 21G646)
13:40:16 <sech1> sure, they prevent new nodes from syncing other chains except for THE chain
13:40:27 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> sure, they prevent new nodes from syncing other chains except for THE chain
13:40:28 <k4r4b3y[m]1> this
13:40:28 <sech1> which also prevents some DoS-attacks
13:40:39 <sech1> like feeding new nodes with fake chains with millions of blocks
13:41:28 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> like feeding new nodes with fake chains with millions of blocks
13:41:28 <k4r4b3y[m]1> in this case, shouldn't the new node be contrasting the next-block data it gets from many different peers, and pick the consensus among them?
13:41:29 <sech1> so if you remove these checkpoints, malicious nodes can cause big mess for new syncing nodes
13:41:50 <sech1> new node can't pick the consensus before it validates everything until the last block
13:42:04 <sech1> before it does, every candidate block is just that - a candidate
13:42:09 <sech1> and it must verify everything before choosing
13:42:14 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> so if you remove these checkpoints, malicious nodes can cause big mess for new syncing nodes
13:42:14 <k4r4b3y[m]1> I am saying, Monero should have at least enough nodes at all times to prevent against such an attack, and nullify the need for a hardcoded hash in its codebase.
13:42:27 <sech1> many honest nodes won't help
13:42:55 <sech1> a few malicious nodes can connect to everyone and feed them fake chains (not really fake, just other chains with millions of blocks and low difficulty)
13:43:43 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> a few malicious nodes can connect to everyone and feed them fake chains (not really fake, just other chains with millions of blocks and low difficulty)
13:43:43 <k4r4b3y[m]1> yeah I get that. But is my node blindly accepting the suggestions from its one or two peers, and not comparing those block suggestions with the ones it gets from the 14, or 15 other peers it has?
13:44:09 <sech1> if you go that way, welcome to Sybil attacks
13:44:17 <sech1> node only respects PoW
13:44:39 <sech1> because it can't trust anything any peer is saying before it's verified
13:44:47 <k4r4b3y[m]1> Yeah, OK. Then isn't the new node comparing the suggested PoW's from all its peers and not blindly trusting the"few malicious nodes'" sugestions?
13:44:49 <sech1> or hash checked with known hash
13:45:13 <sech1> malicious peers can suggest PoW that's higher than the real chain PoW
13:45:24 <k4r4b3y[m]1> I am struggling to say that, btc (seems like) it works without that hardcoded hash stuff
13:45:26 <sech1> and force you to sync 10 million blocks before you find out it's an incorrect chain
13:46:18 <k4r4b3y[m]1> why is my new node blindly trusting the pow suggestion from a "FEW" nodes that it has connected to, and why is it not comparing what the other 'HONEST' nodes that it ihas connected to suggests?
13:47:15 <Rucknium[m]> k4r4b3y: Are you aware that bitcoin had block hash checkpoints in the past? According to Peter Todd, bitcoind still today will only accept a chain that has a block with a certain amount of PoW.
13:47:36 <k4r4b3y[m]1> Rucknium[m]: > <@rucknium:monero.social> k4r4b3y: Are you aware that bitcoin had block hash checkpoints in the past? According to Peter Todd, bitcoind still today will only accept a chain that has a block with a certain amount of PoW.
13:47:36 <k4r4b3y[m]1> yes, I am aware btc had those. But it seems like it doesn't have that anymore.
13:47:44 <Rucknium[m]> k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning
13:48:03 <k4r4b3y[m]1> Rucknium[m]: > <@rucknium:monero.social> k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning
13:48:03 <k4r4b3y[m]1> and that's why we need to get more people running nodes. 
13:48:23 <sech1> something something Sybil attacks
13:48:24 <k4r4b3y[m]1> Rucknium[m]: > <@rucknium:monero.social> k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning
13:48:25 <k4r4b3y[m]1> Also I heard seed nodes are a thing?
13:48:43 <k4r4b3y[m]1> ehhh, we are just circling each other's arguments at this point
13:48:44 <sech1> seed nodes are a thing in any p2p network
13:49:00 <sech1> how would you find the _first_ peer to connect to?
13:49:06 <sech1> if you don't have previously saved peer lists?
13:49:25 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> how would you find the _first_ peer to connect to?
13:49:25 <k4r4b3y[m]1> yes, and thus we have seed nodes. and thus rucknium's suggestion that "how do you know you've connected to any honest nodes" is moot
13:49:37 <sech1> how do you know seed nodes are honest?
13:49:44 <k4r4b3y[m]1> I gotta trust
13:49:46 <Rucknium[m]> You can say "find the seed node" (arguably a central thing) or "find blocks with these hashes" (arguably a central thing). If you have neither, then malicious parties can keep DDoSing infant nodes potentially.
13:49:52 <sech1> monerod doesn't make such assumption?
13:50:25 <sech1> seed nodes are the actual centralized part of the sync process
13:50:41 <sech1> which is why monerod doesn't assume anything about them being honest
13:50:59 <k4r4b3y[m]1> Rucknium[m]: > <@rucknium:monero.social> You can say "find the seed node" (arguably a central thing) or "find blocks with these hashes" (arguably a central thing). If you have neither, then malicious parties can keep DDoSing infant nodes potentially.
13:51:00 <k4r4b3y[m]1> I would take "find blocks with these hashes" anyday, instead of "find the seed node" directive. At least I can verify the hash of the genesis block in a way similar to verifying QubesOS developers' main air-gapped GPG fingerprint.
13:51:23 <Rucknium[m]> It may be good to compare the security budget of Monero today with that of bitcoin when it removed the block hash checkpoints.
13:51:57 <sech1> huh, so if someone cracks SHA256 and recalculates the whole BTC blockchain, they can erase all BTC history now? Funny
13:52:09 <k4r4b3y[m]1> sech1: > <@sech1:libera.chat> huh, so if someone cracks SHA256 and recalculates the whole BTC blockchain, they can erase all BTC history now? Funny
13:52:09 <k4r4b3y[m]1> yes it is over.
13:52:19 <k4r4b3y[m]1> cracking sha256 should kill btc, fair and square.
13:52:24 <Rucknium[m]> as in, number of coins in a day's worth of block rewards times the purchasing power of the coin unit
13:52:45 <sech1> Monero daily emission is is ~$65k
13:52:53 <sech1> Bitcoin is $25M
13:53:01 <sech1> 380 times more
13:55:14 <Rucknium[m]> The checkpoints were still there in 2017: https://github.com/bitcoin/bitcoin/blob/c091b99/src/chainparams.cpp#L150-L162
13:56:20 <Rucknium[m]> The youngest block in those checkpoints was in 2014
13:57:50 <Rucknium[m]> More info: https://bitcoin.stackexchange.com/questions/3114/which-blocks-get-to-be-checkpoints
14:08:34 <ofrnxmr[m]> dMartian:  your client is leaking 
14:42:57 <toralien[m]> <k4r4b3y[m]1> "cracking sha256 should kill btc,..." <- > <@k4r4b3y:karapara.net> cracking sha256 should kill btc, fair and square.
14:42:57 <toralien[m]> > 
14:42:57 <toralien[m]> sarcasm I suppose? because otherwise it's completely ogre
14:43:08 <toralien[m]> <ofrnxmr[m]> "dMartian:  your client is..." <- how does ye know this
16:31:34 <ax[m]> What is the deference between transaction key and transaction hash?
16:33:17 <ax[m]> and how can I find my transaction key
17:20:58 * Alex|LocalMonero uploaded a video: (10092KiB) < https://libera.ems.host/_matrix/media/v3/download/agoradesk.com/DMnKbzZUsFRadMlYLvIiOdIE/IMG_4461.MP4 >
17:46:40 <merope> <Rucknium[m]> "It may be good to compare the..." <- https://moneroj.net/securitybudget/
17:50:21 <merope> <sech1> "a few malicious nodes can..." <- Doesn't the consensus rule require the *highest cumulative pow*, and not just more blocks? So to pull that off, they'd have to pull a 51% over the entire history they're rewriting
17:51:08 <sech1> no, they can put fake high difficulty PoW blocks in the end and many low difficulty PoW blocks in the beginning
17:51:19 <sech1> so by the time your node bans them, it has downloaded many blocks
17:52:17 <merope> Oooh right
17:54:41 <Rucknium[m]> endor00: Thanks. So the last time Bitcoin had the security budget that Monero does now was in 2013 (ignoring inflation of the U.S. dollar). Bitcoin was still actively using checkpoints at that point. Case closed?
18:33:49 <xfedex[m]> Is it true that Monero got delisted from Binance in UE?
20:03:30 <cockliuser[m]> Appears to be so
20:03:35 <cockliuser[m]> https://cointelegraph.com/news/binance-to-delist-privacy-tokens-in-france-italy-spain-and-poland
20:03:43 <cockliuser[m]> XMR included
20:04:04 <cockliuser[m]> https://twitter.com/WasPraxis/status/1663879792431620096
20:05:22 <DanIsnotthemanBr> Binance should de-listed binance at this point 
20:17:41 <hbs[m]> Their notion of "privacy coins" seems kind of wide as SCRT is included in the list
20:25:25 <Alex|LocalMonero> <cockliuser[m]> "https://cointelegraph.com/news/..." <- Can't believe they called XMR a token
20:25:49 <DanIsnotthemanBr> Rude
20:25:56 <cockliuser[m]> Journalists being journalists
20:26:09 <DanIsnotthemanBr> De list them of localmonero
20:26:17 <DanIsnotthemanBr> :)
20:57:53 <DanIsnotthemanBr> https://github.com/getumbrel/umbrel-apps/pull/617
21:33:19 <RavFX[m]> <DanIsnotthemanBr> "De list them of localmonero" <- Go there as a Russian (use a russian VPN) and tell me
22:14:10 <plowsof11> recent, 25 May 2023 
22:15:09 <plowsof11> the blogpost on getmonero is soon to be released and will look something like this https://deploy-preview-2170--barolo-time-757cf9.netlify.app/2023/05/25/10block-old-decoy-selection-bug.html
22:16:45 <toralien[m]> <cockliuser[m]> "https://cointelegraph.com/news/..." <- are they pushing out regs independent of mica?
22:16:51 <toralien[m]> or is this in prep for 2024 enforcement of mica?
22:17:31 <cockliuser[m]> Probably prep
22:17:43 <cockliuser[m]> Can't get into trouble with meddling authorities 
22:18:39 <hfclover[m]> <nix_lord_fomo[m]> "sorry about not using nitter 😂" <- People should be using libredirect or untrackme anyway. Anybody who roasts you for posting a twitter.com link is a noob.
22:18:52 <toralien[m]> hfclover[m]: true
22:19:21 <toralien[m]> cockliuser[m]: would LE be able to retroactively enforce something specifically for this?
22:19:22 <DanIsnotthemanBr> Sounds like an eu thing
22:19:46 <DanIsnotthemanBr> Some new law there trying to bring in too keep everyone say¡
22:19:58 <DanIsnotthemanBr> s/say/safe/
22:21:54 <cockliuser[m]> toralien[m]: Probably not but IANAL
22:36:59 <DanIsnotthemanBr> On ios you can create a shortcut if anyone is using that.
23:26:55 <idkrn[m]> <123bob123> "On ios you can create a shortcut..." <- You know I'm not