does monero trace all payments all the way down to genesi, similar to bitcoin?

This question is very unclear, but I think this is what you want:

every monero output is ultimately derived from one or more coinbase output.

i mean, in order for me to verify a monero payment, do i have to download the entire transactions like bitcoin?

Yes.

<d​ark:pub.solar> github.com/monero-project/monero/bl…2f072b/src/cryptonote_config.h#L162

<d​ark:pub.solar> this should clarify the details for you, h-erectus

<d​ark:pub.solar> you don't have to download the whole chain if you're using simple mode

thanks

moneromoooo: i'm thinking if it's possible to shift the genesis block every now and then, in order to optimise the efficiency.

from my understanding, the longer the dependency chain gets (i.e. the older the genesis block is), the more difficult it becomes for someone to inject a false genesis block. but i wonder if it's currently "too secure" and that it should be a bit less secure in return of making it a lot more efficient.

it would result in people's money expiring so def a no-go

any idea to make the algorithm space-efficient? because currently it's space complexity is O(n), where n is number of transactions ever made—doesn't scale space-wise.

I don't think anyone's really worried about it considering the blockchain has only become easier to store so far

how easier?

or, why easier?

storage has become faster and cheaper at a much greater rate than the blockchain has grown

1 TB SSD is like $50

what's the total chain size?

ummm I'd have to check but I think around 300 GB plus or minus

165 GiB unpruned

thanks I thought I mightve been over estimating by a good bit

Lyza: is that bitcoin's? i think they're about 500 now.

We're talking about Monero here, no?

storage is so cheap I literally don't pay attention to the size, my hard drives will die before they fill up

165 GiB after almost 10 years of operation. But it's growing ~40 GiB/year now

yes, but, logically, this won't scale in the future. or even for new nodes. you'd have to download the entirety of it every time you install a new full node.

<d​ark:pub.solar> I second what Lyza said, it's premature optimization

<d​ark:pub.solar> on mobile devices, simple mode works well

I mean yes, in the abstract there is probably a physical upper limit to storage density

<d​ark:pub.solar> maybe it'll scale even better. you don't know if there's gonna be more or fewer transactions in the future

As long as internet bandwidth and an average storage device capacity grow faster than the blockchain, it's considered fine

O(n) is a timed bomb. imo we must have a plan for the future when it will be a problem.

i don't think that anyone has any plan, not even bitcoin or ethereal.

<d​ark:pub.solar> why are you using big O for this? it makes little sense

what should i use?

<d​ark:pub.solar> ethereum has a plan, sharding

big O(n) always makes sense when you have "n" that makes sense

n = total number of transactions

<d​ark:pub.solar> use what Lyza was using GBs in the chain, GBs that get added to the chain a year

<d​ark:pub.solar> practical units are helpful

sech1: yes. imo, a cryptocurrecy must eventually have O(log n) or O(1)

<d​ark:pub.solar> bitcoin also has a plan, the lightning network, second layer

<d​ark:pub.solar> I can make a crypto that is O(1), and always requires 1,000,000 TB

Lightning network is not a solution, it has fundamental problems which are still not solved yet

BTC maxis will of course say "this vid is 5 years old bla bla bla"

but it's disussing the fundamental design of Lightning

nothing changed in 5 years

<d​ark:pub.solar> well, it's a solution, just not a good one

Wow wow, "you don't have to download the whole chain if you're using simple mode" is completely wrong if you want to verify the chain.

<d​ark:pub.solar> sorry, I meant you don't have to store the chain in simple mode

<t​rasherdk:monero.social> Syncing from zero took 24+ hours, downloading 245 GB data.

<t​rasherdk:monero.social> What was the extra ~80 GB?

It's theoretically possible to "restart" but it would make the "new" genesis block include a lot of state (ie, all spent key images, all outputs generated so far, possibly other ancillary stuff).

<d​ark:pub.solar> anyone has stats about the usage of crypto after the crash?

<d​ark:pub.solar> why talk about scaling if the number of transactions and users is going down

going down? bitinfocharts.com/comparison/monero-transactions.html#alltime

It's been pretty stable the last 2 years

<d​ark:pub.solar> 60K a day was the record? VISA processes that many transactions per second

t​rasherdk: possibly duplicate downloads, extra stuff like list of hashes (the "skeleton" from which a node selects blocks to download), and random extraneous stuff like peer lists and other p2p overhead.

Then again, the chain stores some stuff duplicated for speed, so it does seem high.

m-relay/dark:pub.solar: are transactions now going down for cryptocurrencies?

<d​ark:pub.solar> etherscan.io/chart/tx

<d​ark:pub.solar> you can see a mild downward trend for Eth

<d​ark:pub.solar> probably cause NFTs are now worthless

<p​olar9669:matrix.org> Compare it with previous market cycle

monero's value is 1-to-1 with USD. so i guess monero is inflating since 2021.

the btc is doing good against the usd. at least since 2022.

any reason? e.g. any government harassments against monero?

<d​ark:pub.solar> well, there is a bounty by the IRS

<p​olar9669:matrix.org> Maybe discuss it in Monero Markets

<d​ark:pub.solar> 1.2M USD

does sharding space the disk space? or does it only increase the speed?

s/space the/save the/

<d​ark:pub.solar> the term comes from relational databases, search for sharding in postgresql or mysql for more details

Pruning saves disk space, and only increases speed if your internet connection is a bottleneck and you use --synced-pruned-blocks.

.merges

it's over 9000!

0.18.3.0 tagged, can we start reproducible builds?

let's wait for selsta to confirm

sech1: yes

my hashes: paste.debian.net/hidden/049626f2

woh thanks sech1

I'm running v0.18.3.0 on my nodes now

<r​ecanman:agoradesk.com> I will create a pr in a couple of hours for my pgp key to the gitian.sigs repository and add my hashes. I was planning to a while ago but completely forgot

setting up gitian android seems to fail, did anyone else run into this? github.com/monero-project/monero/ac…ons/runs/6364928412/job/17283036566

tobtoht any idea?

i thought it's some network thing but we already tried to restart it, same error

I did the gitian build locally and it built Android binaries without issues

sech1: clean build?

or did you have it setup from previous build?

No, it had leftovers from v0.18.2.2 build

or whatever release we had last time

yes, it fails during gitian setup which you already have from last time

The problem is "500 Bad redirection (path) [IP: 172.17.0.1 3142]" when running apt-get

It's something with ubuntu update servers

they redirect to a local network IP range (172.16.x.x - 172.31.x.x)

Maybe it's some Github's "optimization"

archive.ubuntu.com resolves to 172.17.0.1 for some reason

<r​ecanman:agoradesk.com> Not for me

<r​ecanman:agoradesk.com> matrix.monero.social/_matrix/media/…radesk.com/QREeOLvukVFvJcIDufvnmACk

I mean DNS servers that Github VMs use

<r​ecanman:agoradesk.com> Oh, ok

resolve it to 172.17.0.1

<r​ecanman:agoradesk.com> Odd

on the other hand, RUN echo 'Acquire::http { Proxy "172.17.0.1:3142"; };' > /etc/apt/apt.conf.d/50cacher works just fine a few lines up

maybe it will work again tomorrow, seems networking related

so there is some server at that IP

all other gitian build jobs worked fine with the exact same settings

I see only 4 gitian jobs here github.com/monero-project/monero/actions/workflows/gitian.yml

and the last successful 6 months ago

has 5 jobs (android, macos, windows, linux, freebsd)

only android failed

the others show the build hashes

So there is a server at 172.17.0.1, but it's giving error 500 right now. M$ should fix it eventually

but it's weird that other builds succeeded

single point of failure xD

btw if it's github-only issue, then clean build should work for everyone else