<monerobull[m]> "this kills the conversation 💀" <- Yes, please. Kill it already 😴

Pew pew

Pew pew?

wtf?

i asked for more info and only got "version incompatibility error acfer ", any ideas BigmenPixel

s/acfer/after flatpak run

DanIsnotthemanBr: > <@123bob123:matrix.org> reddit.com/r/Monero/comments/13viqax/update_the_fucking_flatpak

>

> wtf?

Wtf, it would be good if there is a github issue with info

cannot reproduce, closing for now, good job everyone

People are weird

<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.

>

> 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.

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

<ofrnxmr[m]> "My response is "youre on reddit,..." <- that is more of a player not the game type thing tho

* 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

is cryptogrampy around the matrix?

I would like to ask him some questions about his android-termux-monero-node project

if you see him, please tell him to DM me.

btw, you can join #yolgezer:karapara.net to discuss about running a monero node on your android device

🤦‍♂️

what is the world record for syncing a full monero node in shortest amount of time?

Ravfx did hdd/ssd testing

They might know

World record doesn't mean much because a few months later it will take more time anyway

Right now it's 4-5 hours to sync a full node with 1 Gbit connection and a fast PC with NVMe SSD

Also, it's faster right after new release because new release has fresh checkpoints

then I should've asked "the world record for having GB/s synced.

you can compile a binary with fresh checkpoints to save a few hours of syncing in the end

k4r4b3y[m]1: > <@k4r4b3y:karapara.net> then I should've asked "the world record for having GB/s synced.

>

can be computed as the full blockchain size / total time it took to sync

sech1: > <@sech1:libera.chat> Also, it's faster right after new release because new release has fresh checkpoints

what are the functions of "checkpoints"? Am I trusting someone else with the state of the blockchain with them?

it's known block hashes (or hashes of each 256 consecutive blocks, I don't remember the details)

with these hashes, you're just choosing the "current" blockchain and make your binary ignore deep reorgs (deeper than the last checkpoint)

why are they needed? can't a node sync to a full blockchain without them?

node can sync without them, but it will be much much slower

also, aren't reorgs discarded by "eventual consistency" among the many numbers of nodes?

you know, the most proof of work chain is the main one?

reorgs happen from one chain with X amount of PoW to another chain with more than X amount of PoW

if someone does 51% attack lasting for a long time, then nodes with checkpoints will ignore new chain even if it has more PoW

hmm..

does btc also make use of such checkpoints?

no idea

yes bitcoin also has checkpoints

though based on googling it it seems they removed them at some point

Yeah thats what i saw

monero checkpoints are usually weeks or months old, if there is a whole month of reorg there is a bigger issue anyway

DanIsnotthemanBr: > <@123bob123:matrix.org> bitcoin.stackexchange.com/questions…-bitcoin-no-longer-have-checkpoints... (full message at <libera.ems.host/_matrix/media/v3/do…f724db902808ea0b5353bcc75e11eb671b0>)

so, in monero, these checkpoints are used for increasing the speed of the sync?

no

fast-sync and checkpoints are two separate things that sometimes get confused

so, the checkpoints in monero are used as part of the blockchain's security model?

fast-sync is a list of known hashes that reduce verification work during initial sync

checkpoints are to make sure you are on the right chain during initial sync and have the right difficulty

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

selsta: > <@selsta:libera.chat> checkpoints are to make sure you are on the right chain during initial sync and have the right difficulty

I am not understanding why wouldn't a fres-syncing node be lead-astray during the initial sync?

*why would

fres-syncing?

fresh-syncing

why would a fresh-syncing node be lead-astray during initial block sync?

in case the node gets isolated from the network and only connects to malicious peers for example

is monero's node network still open to such attacks? still the attackers can outnumber the honest nodes?

I would expect monero's network to be mature enough to have resilience against that, at this point.

every p2p network can be attacked this way

yeah, true. But having a large number of honest nodes counters this attack, no?

it's a theoretical thing

what's theoretical? the attack or having the resilience by large number of honests?

the attack

isn't such a "checkpoint" mechanism a form of centralization around some human institutions?

is it being considered for discarding the checkpoints? like btc did apparently?

imo it's not centralization, as it only protects against attacks but there's no way it can be abused

everyone can run their own client without checkpoints

does monerod have an option (or, directive) for this to be placed in its config file?

relevant issue from tevador i think monero-project/monero #8836

compile your own daemon

plowsof11: this is about fast-sync and not checkpoints

ah ok ok

plowsof11: > <@plowsof:matrix.org> relevant issue from tevador i think monero-project/monero #8836

yes, this gave me a surprise

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.

I was talking about fast-sync as "checkpoints" this whole time

there's a lot of confusion about this

it sure seems like it

XD

even the file is called "src\blocks\checkpoints.dat" in Monero repo

but it's for fast-sync

yes, that's where the confusion comes from

the "other" checkpoints were created to prevent attacks and have never been used IIRC

they're DNS-based

the DNS based ones have never been used

and by default they only print a warning

you need special command line to enforce them

<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

is this the only reason we have the checkpoints (the ones that protect against reorgs_?

if so, can the protection from being isolated from the network be solved with getting people to run monero nodes?

they are so infrequently updated that i don't see a scenario where they help against reorgs

Why not remove them?

what harm do they cause?

they give the impression that a human institution is still being trusted with monero's chain state.

imho

You can just run with --disabke-dns-checkpoints

Or something like that

And also disabke fast sync, am i wrong?

ofrnxmr[m]: > <@ofrnxmr:monero.social> Or something like that

I think the messages prior has shown that what we now talk about is different from dns checkpoints

Can free-wheel it all day if you please

But if you run a wownero node and witness a chainspit, you might want those checkpoints

i would like a scenario where hardcoded checkpoints harm decentralization that isn't impression based

ofrnxmr[m]: > <@ofrnxmr:monero.social> And also disabke fast sync, am i wrong?

also, we have been talking about the "checkpoints" of the sort that "protect against reorgs", as far as I am understanding the convo

There was even talk of decentraliz*ng the checkpoints sobthey are genersted distributed p2p every x blocks

Im referring to both

There are flags to disable checkpints and alsp fast sync

we could also remove prebuilt binaries because they "harm decentralization"

remove seed nodes

You can do that too

Free wheel it if you want. Nobody is stopping you

ofrnxmr[m]: > <@ofrnxmr:monero.social> Free wheel it if you want. Nobody is stopping you

give me the monerod flags to do that

Monerodocs.org

daemon page

Ctrf f

fast-sync

Ctrl-f

dns

99% sure both are documented there

How do I locate the flag for disabling the reorg protection checkpoints?

you are missing that kind of checkpoints still

--disable-dns-checkpoints

Or look at the termux node install script

dns checkpoints are never used anyway

It disables em

selsta said you have to compile yourself for disabling the reorg checkpoints

there isn't a flag for that

yes

anyways I don't want to keep playing the devil's advocate here, as I am moving towards concern trolling

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

but I would like to say, I want to see monero rely on no-checkpoints for its chainstate in the near future.

dns checkpoints are not enforced by default

"./monerod --fast-block-sync 0" to disable fast-sync checkpoints

selsta: this option doesnt skip them?

--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

binary regarding old blocks' PoW validity, to sync up faster.

--disable-dns-checkpoints just turns off the warning in case dns checkpoints and chain state mismatch

ofrnxmr[m]: this option disables fast-sync

turns off the warning and turns off dns updates

sech1: I thiught it was other way around

```

--disable-dns-checkpointsThe MoneroPulse checkpoints set by core developers will be discarded. The checkpoints are apparently still fetched though.

```

MoneroPulse checkpoints are not fast sync checkpoints

k4r4b3y[m]1: how does monero "rely" on checkpoints?

so to clarify:

fast sync =/= hard coded checkpointsc disabling fast sync doesnt effect them

dns checkpoints = are still used and it just turns off the logging?what?

Disable-dns-checkpoints*

all wrong :D

fast sync checkpoints are hardcoded

dns checkpoints are not used and were never used

My understanding:

- fast sync = hardcoded checkpoints = disable fast sync will skip checkpoints.

- disable dns checkpoints = still fetched but not used or logged

selsta: > <@selsta:libera.chat> k4r4b3y: how does monero "rely" on checkpoints?

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?

they're used to speed up sync, nothing more

"few weeks reorg" is only a theoretical scenario

this is what i call hardcoded checkpoints

if it happens for real, checkpoints will be the least of problems

having two things with the name checkpoint is unfortunate lol

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?

"he reorg-checkpoints are used for a few weeks of reorgs for the syncing nodes" whaaaat

<sech1> "all wrong :D" <- I dont know wth i typed, but i dont even understand it. Apologies

"few weeks of reorgs" is not even correct description of what you're trying to say

"reorg few weeks deep" is probably better

<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)

.

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!).

it will ignore is this block is built on top of chain that forks before the last checkpoint

*if this

"Just declare that the transactions contained in those hard-coded block hashes are valid" or maybe this, actually

Rucknium[m]: what you are saying is correct for fast-sync, it's just a list of known hashes that partly skip verification

lol

so we were discussing non-issue

but there's also a checkpoint system

if it's a known "correct block" hash, then it's only for fast sync

like i linked previously

2851000, "5bf0e47fc782263191a33f63a67db6c711781dc2a3c442e17ed901ec401be5c9", "0x3b6cd8a8ed610e8

means block 20851000 has this hash and this difficulty

these get added once per release

selsta: > <@selsta:libera.chat> these get added once per release

and their function is ..?

ah, so these are actual stoppers

so there are 3 kinds of checkpoints now :D

k4r4b3y[m]1: they help when you are syncing from scratch and completely isolated from the network / only connected to malicious nodes

what a shitcoin /s

fast sync "src\block\checkpoints.dat" that's used only to speed up sync

yes

then there is src\checkpoints\checkpoints.cpp" that prevent syncing alternative chains beyond the latest checkpoint

and then there are DNS checkpoints which are not used :D

yep, and dns checkpoints are unused

selsta: > <@selsta:libera.chat> k4r4b3y: they help when you are syncing from scratch and completely isolated from the network / only connected to malicious nodes

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?

more nodes help but p2p networks will always be vulnerable to attacks like this

we also have other mitigations

am I getting my point across, that, having such hardcoded blockhashes are just aesthetically displeasing when viewed from decentralization of the chain?

yes, but i don't like to make decisions based on aesthetics or impressions

alright

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

bitcoin is a more mature network with more nodes so it's easier for them to remove them

mature in the sense of having more nodes and more hashpower behind the chain?

ah ok, you mentioned the nodes already

both

ye ye

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?

i don't, it's probably arbitrary

but surely you seem to have a sense about it?

since you are of the "feel" that monero isn't mature enough

src\checkpoints\checkpoints.cpp just fix the state of THE chain at the moment, I don't see how developers can centralize something here

THE chain = current consensus chain which is run by everyone at the moment

System Information: Model: iMac (Retina 5K, 27-inch, Late 2015) • OS: macOS Monterey (Version 12.6.6, Build 21G646)

sure, they prevent new nodes from syncing other chains except for THE chain

sech1: > <@sech1:libera.chat> sure, they prevent new nodes from syncing other chains except for THE chain

this

which also prevents some DoS-attacks

like feeding new nodes with fake chains with millions of blocks

sech1: > <@sech1:libera.chat> like feeding new nodes with fake chains with millions of blocks

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?

so if you remove these checkpoints, malicious nodes can cause big mess for new syncing nodes

new node can't pick the consensus before it validates everything until the last block

before it does, every candidate block is just that - a candidate

and it must verify everything before choosing

sech1: > <@sech1:libera.chat> so if you remove these checkpoints, malicious nodes can cause big mess for new syncing nodes

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.

many honest nodes won't help

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)

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)

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?

if you go that way, welcome to Sybil attacks

node only respects PoW

because it can't trust anything any peer is saying before it's verified

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?

or hash checked with known hash

malicious peers can suggest PoW that's higher than the real chain PoW

I am struggling to say that, btc (seems like) it works without that hardcoded hash stuff

and force you to sync 10 million blocks before you find out it's an incorrect chain

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?

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.

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.

yes, I am aware btc had those. But it seems like it doesn't have that anymore.

k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning

Rucknium[m]: > <@rucknium:monero.social> k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning

and that's why we need to get more people running nodes.

something something Sybil attacks

Rucknium[m]: > <@rucknium:monero.social> k4r4b3y: You cannot guarantee that you've connected to any honest nodes in the beginning

Also I heard seed nodes are a thing?

ehhh, we are just circling each other's arguments at this point

seed nodes are a thing in any p2p network

how would you find the _first_ peer to connect to?

if you don't have previously saved peer lists?

sech1: > <@sech1:libera.chat> how would you find the _first_ peer to connect to?

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

how do you know seed nodes are honest?

I gotta trust

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.

monerod doesn't make such assumption?

seed nodes are the actual centralized part of the sync process

which is why monerod doesn't assume anything about them being honest

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.

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.

It may be good to compare the security budget of Monero today with that of bitcoin when it removed the block hash checkpoints.

huh, so if someone cracks SHA256 and recalculates the whole BTC blockchain, they can erase all BTC history now? Funny

sech1: > <@sech1:libera.chat> huh, so if someone cracks SHA256 and recalculates the whole BTC blockchain, they can erase all BTC history now? Funny

yes it is over.

cracking sha256 should kill btc, fair and square.

as in, number of coins in a day's worth of block rewards times the purchasing power of the coin unit

Monero daily emission is is ~$65k

Bitcoin is $25M

380 times more

The checkpoints were still there in 2017: github.com/bitcoin/bitcoin/blob/c091b99/src/chainparams.cpp#L150-L162

The youngest block in those checkpoints was in 2014

More info: bitcoin.stackexchange.com/questions…/which-blocks-get-to-be-checkpoints

dMartian: your client is leaking

<k4r4b3y[m]1> "cracking sha256 should kill btc,..." <- > <@k4r4b3y:karapara.net> cracking sha256 should kill btc, fair and square.

>

sarcasm I suppose? because otherwise it's completely ogre

<ofrnxmr[m]> "dMartian: your client is..." <- how does ye know this

What is the deference between transaction key and transaction hash?

and how can I find my transaction key

<Rucknium[m]> "It may be good to compare the..." <- moneroj.net/securitybudget

<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

no, they can put fake high difficulty PoW blocks in the end and many low difficulty PoW blocks in the beginning

so by the time your node bans them, it has downloaded many blocks

Oooh right

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?

Is it true that Monero got delisted from Binance in UE?

Appears to be so

XMR included

Binance should de-listed binance at this point 

Their notion of "privacy coins" seems kind of wide as SCRT is included in the list

<cockliuser[m]> "cointelegraph.com/news..." <- Can't believe they called XMR a token

Rude

Journalists being journalists

De list them of localmonero

:)

<DanIsnotthemanBr> "De list them of localmonero" <- Go there as a Russian (use a russian VPN) and tell me

recent, 25 May 2023

the blogpost on getmonero is soon to be released and will look something like this deploy-preview-2170--barolo-time-75…0block-old-decoy-selection-bug.html

<cockliuser[m]> "cointelegraph.com/news..." <- are they pushing out regs independent of mica?

or is this in prep for 2024 enforcement of mica?

Probably prep

Can't get into trouble with meddling authorities

<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.

hfclover[m]: true

cockliuser[m]: would LE be able to retroactively enforce something specifically for this?

Sounds like an eu thing

Some new law there trying to bring in too keep everyone say¡

s/say/safe/

toralien[m]: Probably not but IANAL

On ios you can create a shortcut if anyone is using that.

<123bob123> "On ios you can create a shortcut..." <- You know I'm not