06:19:50 <h-erectus> does monero trace all payments all the way down to genesi, similar to bitcoin?
06:21:26 <moneromoooo> This question is very unclear, but I think this is what you want:
06:21:51 <moneromoooo> every monero output is ultimately derived from one or more coinbase output.
06:22:08 <h-erectus> i mean, in order for me to verify a monero payment, do i have to download the entire transactions like bitcoin?
06:22:19 <moneromoooo> Yes.
06:22:54 <m-relay> <d​ark:pub.solar> https://github.com/monero-project/monero/blob/3ad4ecd4ff52f011ee94e0e80754b965b82f072b/src/cryptonote_config.h#L162
06:23:08 <m-relay> <d​ark:pub.solar> this should clarify the details for you, h-erectus
06:26:12 <m-relay> <d​ark:pub.solar> you don't have to download the whole chain if you're using simple mode
06:27:11 <h-erectus> thanks
06:36:47 <h-erectus> moneromoooo: i'm thinking if it's possible to shift the genesis block every now and then, in order to optimise the efficiency.
06:39:54 <h-erectus> 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.
06:40:54 <Lyza> it would result in people's money expiring so def a no-go
06:42:07 <h-erectus> 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.
06:42:38 <Lyza> I don't think anyone's really worried about it considering the blockchain has only become easier to store so far
06:42:56 <h-erectus> how easier?
06:43:04 <h-erectus> or, why easier?
06:43:16 <Lyza> storage has become faster and cheaper at a much greater rate than the blockchain has grown
06:43:38 <Lyza> 1 TB SSD is like $50
06:43:46 <h-erectus> what's the total chain size?
06:44:13 <Lyza> ummm I'd have to check but I think around 300 GB plus or minus
06:44:52 <sech1> 165 GiB unpruned
06:45:22 <Lyza> thanks I thought I mightve been over estimating by a good bit
06:45:47 <h-erectus> Lyza: is that bitcoin's?  i think they're about 500 now.
06:46:09 <sech1> We're talking about Monero here, no?
06:46:19 <Lyza> storage is so cheap I literally don't pay attention to the size, my hard drives will die before they fill up
06:46:53 <sech1> 165 GiB after almost 10 years of operation. But it's growing ~40 GiB/year now
06:47:07 <h-erectus> 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.
06:47:08 <m-relay> <d​ark:pub.solar> I second what Lyza said, it's premature optimization
06:47:10 <m-relay> <d​ark:pub.solar> on mobile devices, simple mode works well
06:47:43 <Lyza> I mean yes, in the abstract there is probably a physical upper limit to storage density
06:47:50 <m-relay> <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
06:47:59 <sech1> As long as internet bandwidth and an average storage device capacity grow faster than the blockchain, it's considered fine
06:48:18 <h-erectus> O(n) is a timed bomb.  imo we must have a plan for the future when it will be a problem.
06:48:35 <h-erectus> i don't think that anyone has any plan, not even bitcoin or ethereal.
06:49:07 <m-relay> <d​ark:pub.solar> why are you using big O for this? it makes little sense
06:49:28 <h-erectus> what should i use?
06:49:31 <m-relay> <d​ark:pub.solar> ethereum has a plan, sharding
06:49:40 <sech1> big O(n) always makes sense when you have "n" that makes sense
06:49:46 <sech1> n = total number of transactions
06:49:58 <m-relay> <d​ark:pub.solar> use what Lyza was using GBs in the chain, GBs that get added to the chain a year
06:50:13 <m-relay> <d​ark:pub.solar> practical units are helpful
06:50:41 <h-erectus> sech1: yes.  imo, a cryptocurrecy must eventually have O(log n) or O(1) 
06:50:41 <m-relay> <d​ark:pub.solar> bitcoin also has a plan, the lightning network, second layer
06:52:48 <m-relay> <d​ark:pub.solar> I can make a crypto that is O(1), and always requires 1,000,000 TB
06:53:33 <sech1> Lightning network is not a solution, it has fundamental problems which are still not solved yet
06:53:49 <sech1> https://www.youtube.com/watch?v=yGrUOLsC9cw
06:54:05 <sech1> BTC maxis will of course say "this vid is 5 years old bla bla bla"
06:54:22 <sech1> but it's disussing the fundamental design of Lightning
06:54:27 <sech1> nothing changed in 5 years
06:55:11 <m-relay> <d​ark:pub.solar> well, it's a solution, just not a good one
06:55:28 <moneromoooo> 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.
06:56:08 <m-relay> <d​ark:pub.solar> sorry, I meant you don't have to store the chain in simple mode
06:56:10 <m-relay> <t​rasherdk:monero.social> Syncing from zero took 24+ hours, downloading 245 GB data.
06:56:10 <m-relay> <t​rasherdk:monero.social> What was the extra ~80 GB?
06:56:20 <moneromoooo> 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).
06:57:21 <m-relay> <d​ark:pub.solar> anyone has stats about the usage of crypto after the crash?
06:57:47 <m-relay> <d​ark:pub.solar> why talk about scaling if the number of transactions and users is going down
06:58:05 <sech1> going down? https://bitinfocharts.com/comparison/monero-transactions.html#alltime
06:58:20 <sech1> It's been pretty stable the last 2 years
06:59:34 <m-relay> <d​ark:pub.solar> 60K a day was the record? VISA processes that many transactions per second
07:00:21 <moneromoooo> 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.
07:00:45 <moneromoooo> Then again, the chain stores some stuff duplicated for speed, so it does seem high.
07:06:15 <h-erectus> m-relay/dark:pub.solar: are transactions now going down for cryptocurrencies?
07:07:11 <m-relay> <d​ark:pub.solar> https://etherscan.io/chart/tx
07:07:22 <m-relay> <d​ark:pub.solar> you can see a mild downward trend for Eth
07:07:51 <m-relay> <d​ark:pub.solar> probably cause NFTs are now worthless
07:08:40 <m-relay> <p​olar9669:matrix.org> Compare it with previous market cycle
07:08:43 <h-erectus> monero's value is 1-to-1 with USD.  so i guess monero is inflating since 2021.
07:10:45 <h-erectus> the btc is doing good against the usd.  at least since 2022.
07:11:15 <h-erectus> any reason?  e.g. any government harassments against monero?
07:11:44 <m-relay> <d​ark:pub.solar> well, there is a bounty by the IRS
07:11:53 <m-relay> <p​olar9669:matrix.org> Maybe discuss it in Monero Markets
07:11:54 <m-relay> <d​ark:pub.solar> 1.2M USD
07:12:57 <h-erectus> does sharding space the disk space?  or does it only increase the speed?
07:13:36 <h-erectus> s/space the/save the/
07:13:50 <m-relay> <d​ark:pub.solar> the term comes from relational databases, search for sharding in postgresql or mysql for more details
08:05:24 <moneromoooo> Pruning saves disk space, and only increases speed if your internet connection is a bottleneck and you use --synced-pruned-blocks.
18:42:42 <luigi1111w> .merges
18:42:42 -xmr-pr- 8998 8999 9000 9001
18:45:56 <luigi1111w> it's over 9000!
18:50:47 <sech1> 0.18.3.0 tagged, can we start reproducible builds?
19:28:16 <luigi1111w> let's wait for selsta to confirm
19:30:08 <selsta> sech1: yes
19:31:54 <sech1> my hashes: https://paste.debian.net/hidden/049626f2/
19:33:34 <plowsof> woh thanks sech1
19:35:14 <sech1> https://github.com/monero-project/gitian.sigs/pull/249
19:58:58 <sech1> I'm running v0.18.3.0 on my nodes now
20:01:05 <m-relay> <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
21:42:55 <selsta> setting up gitian android seems to fail, did anyone else run into this? https://github.com/monero-project/monero/actions/runs/6364928412/job/17283036566
21:43:08 <selsta> tobtoht any idea?
21:59:26 <selsta> i thought it's some network thing but we already tried to restart it, same error
22:00:17 <sech1> I did the gitian build locally and it built Android binaries without issues
22:04:32 <selsta> sech1: clean build?
22:04:43 <selsta> or did you have it setup from previous build?
22:05:28 <sech1> No, it had leftovers from v0.18.2.2 build
22:05:33 <sech1> or whatever release we had last time
22:05:51 <selsta> yes, it fails during gitian setup which you already have from last time
22:08:32 <sech1> The problem is "500  Bad redirection (path) [IP: 172.17.0.1 3142]" when running apt-get
22:08:46 <sech1> It's something with ubuntu update servers
22:09:14 <sech1> they redirect to a local network IP range (172.16.x.x - 172.31.x.x)
22:09:40 <sech1> Maybe it's some Github's "optimization"
22:10:44 <sech1> archive.ubuntu.com resolves to 172.17.0.1 for some reason
22:11:06 <m-relay> <r​ecanman:agoradesk.com> Not for me
22:11:57 <m-relay> <r​ecanman:agoradesk.com> https://matrix.monero.social/_matrix/media/v1/download/agoradesk.com/QREeOLvukVFvJcIDufvnmACk
22:12:12 <sech1> I mean DNS servers that Github VMs use
22:12:19 <m-relay> <r​ecanman:agoradesk.com> Oh, ok
22:12:21 <sech1> resolve it to 172.17.0.1
22:12:31 <m-relay> <r​ecanman:agoradesk.com> Odd
22:13:45 <sech1> on the other hand, RUN echo 'Acquire::http { Proxy "http://172.17.0.1:3142"; };' > /etc/apt/apt.conf.d/50cacher works just fine a few lines up
22:13:47 <selsta> maybe it will work again tomorrow, seems networking related
22:13:51 <sech1> so there is some server at that IP
22:14:36 <selsta> all other gitian build jobs worked fine with the exact same settings
22:15:16 <sech1> I see only 4 gitian jobs here https://github.com/monero-project/monero/actions/workflows/gitian.yml
22:15:24 <sech1> and the last successful 6 months ago
22:15:42 <selsta> https://github.com/monero-project/monero/actions/runs/6364928412
22:15:56 <selsta> has 5 jobs (android, macos, windows, linux, freebsd)
22:15:59 <selsta> only android failed
22:16:15 <selsta> the others show the build hashes
22:21:56 <sech1> So there is a server at 172.17.0.1, but it's giving error 500 right now. M$ should fix it eventually
22:22:47 <sech1> but it's weird that other builds succeeded
22:26:30 <plowsof> single point of failure xD
22:28:25 <sech1> btw if it's github-only issue, then clean build should work for everyone else