00:31:37 <m-relay> <i​mprevisto:matrix.org> hell yah crank it
06:16:59 <m-relay> <r​ottenwheel:unredacted.org> **PSA**: if you run a Monero node, please add the rogue node IP ban list from Monero Research Lab. Find out more [here](https://github.com/monero-project/meta/issues/1124).
06:16:59 <m-relay> <r​ottenwheel:unredacted.org> Ban [list](https://github.com/Boog900/monero-ban-list). Seth's docker [image](https://github.com/sethforprivacy/simple-monerod-docker/commit/cea9d8c83738f8164f8d8e09648c916c571c1571) is up-to-date; so is lalanza808's [image](https://github.com/lalanza808/docker-monero-node/pull/28). Less popular one, opened an [issue](https://github.com/rblaine95/docker-monero/issues/42) for it.
06:17:01 <m-relay> <r​ottenwheel:unredacted.org> =====
06:17:03 <m-relay> <r​ottenwheel:unredacted.org> In case any of you has friends running their own public XMR remote node, feel free to copy and paste my own PSA message.
06:20:29 <m-relay> <3​21bob321:monero.social> Hm markdown #
06:20:53 <m-relay> <f​ijxu:nadeko.net> what do you recommend then, every wallet is a fucking app or a extension
06:29:46 <x64S> Hmm... https://www.reddit.com/r/Monero/comments/1hc1ozf/mrl_recommendation_ban_spy_node_ip_addresses_from/
06:45:24 <waywardson> When monero nodes sync, they suffer a similar problem with the BitTorrent protocol where the last few blocks (pieces for a torrent) are the longest to sync (download).
06:49:36 <waywardson> I believe the block-sync-size flag with monerod may fix this, by default near synchronization monerod only requests 20 blocks ahead of the current validate height it has
07:57:53 <BillyZane> i am trying to put together a mining rig for mining monero
07:58:06 <BillyZane> it seems mining monero works best when you can lower latency
07:58:21 <BillyZane> i was looking at a system that would use EEC DDR4 3200Mhz
07:58:48 <BillyZane> the board itself is a dual socket board
07:59:04 <BillyZane> i am expecting a kH/s rate of ~120,000
08:00:06 <BillyZane> i think it would be sufficient to have 64gigs of ram?
08:04:11 <sech1> RandomX requires 2 GB RAM per NUMA node (usually NUMA node = 1 CPU socket)
08:04:32 <BillyZane> sech1, i see. and it wouldn't benefit from more ram?
08:04:34 <sech1> But to achieve max hashrate, you should also fill all memory channels for each CPU. You can use the lowest capacity RAM sticks (8 GB)
08:04:51 <BillyZane> i see
08:04:54 <BillyZane> thank you sech1
08:04:59 <m-relay> <d​aknig:matrix.org> ECC?
08:05:06 <sech1> Error correction
08:05:19 <BillyZane> the motherboard i am looking at has 8 channels ;.;
08:05:32 <sech1> 8 channels per CPU, so 16 memory sticks in total to get max hashrate
08:05:53 <sech1> Usually you can't squeeze more than 10 kh/s from a single memory stick
08:06:03 <BillyZane> i see
08:06:19 <BillyZane> it looks like you're right
08:07:22 <BillyZane> and yes, this board has 16 slots for ram sticks
08:15:11 <BillyZane> sech1, much appreciated
09:42:56 <blockbet> hi
09:43:11 <blockbet> how come monero-pools is closed
10:05:01 <m-relay> <b​asses:matrix.org> anything that doesn't run in browser from here https://www.getmonero.org/downloads/
10:54:31 <m-relay> <p​lowsof:matrix.org> blockbet for repeated violations of Libera.chat policy
11:02:15 <blockbet> thanks
11:22:27 <m-relay> <t​hemisplacedphilosopher:matrix.org> Paper wallet.
11:27:24 <m-relay> <3​21bob321:monero.social> Burn after reading
11:32:27 <m-relay> <d​aknig:matrix.org> how do you use dapps or exchanges then
11:38:03 <m-relay> <t​hemisplacedphilosopher:matrix.org> You can keep some spending money on your phone or desktop in a wallet like Monerujo for XMR or Muun wallet for Bitcoin. Large amounts should not be stored in phone or desktop wallets.
11:38:03 <m-relay> <t​hemisplacedphilosopher:matrix.org> If you want to trade for a living, use a service like BCHBull. Set a paper wallet as the payout address.
11:53:36 <waywardson> hmm
11:54:19 <waywardson> im setting up an interesting public node. Its reverse proxying to three nodes I have setup that only do traffic through tor, but also listening on rpc (though only the reverse proxy sends its traffic)
11:54:34 <waywardson> the reverse proxy will randomly proxy to the backend nodes
11:55:27 <waywardson> this will effectively anonymise any clearnet into tor
11:57:06 <waywardson> I'm wondering if I should disable public-node option on the backend nodes
11:57:52 <waywardson> that way chainanalysis can't find the onion addresses of my backend nodes (or tell that they are backend ones, they'll look like random client nodes)
11:59:43 <waywardson> periodically get new onion addressed on the backend nodes
15:53:08 <waywardson> I hope its worth it but im going to run mkp224o for two weeks on my gaming pc to get the tor vanity address "fucklevin", in honor of the new ceo of chain analysis
16:12:27 <gingeropolous> so what happens if you have enable dns blocklist AND the ban list...
16:16:34 <m-relay> <c​arbon12011:matrix.org> Hi, is Monerujo still the best Android wallet? Any other wallets which sync faster (but still connect to own node) ?
16:17:06 <m-relay> <f​ijxu:nadeko.net> I'm asking for other coints
16:17:07 <m-relay> <f​ijxu:nadeko.net> I'm asking for other coins
16:17:19 <m-relay> <b​asses:matrix.org> use cake wallet or stack wallet
16:17:30 <m-relay> <f​ijxu:nadeko.net> USDT, USDC, etc. Of course I use the desktop program for monero lol!
16:17:39 <m-relay> <f​ijxu:nadeko.net> I see
16:17:42 <m-relay> <f​ijxu:nadeko.net> thanks :p
16:20:04 <m-relay> <o​frnxmr:monero.social> "<g​ingeropolous> so what happens if you have enable dns blocklist AND the ban list..." you cant
16:21:26 <m-relay> <o​frnxmr:monero.social> It will throw an error
16:35:33 <m-relay> <b​asses:matrix.org> https://discuss.privacyguides.net/t/how-to-mine-monero-with-a-focus-on-the-environment/23174
16:52:20 <nioCat> "Such as mining pools working exclusively with renewable energies."
16:52:30 <nioCat> mining, how does it work?
16:54:28 <m-relay> <o​frnxmr:xmr.mx> 😆😆😆😆😆😆😆😆😆😆
16:54:55 <m-relay> <o​frnxmr:xmr.mx> Without reading at all, i assume ai
16:56:21 <m-relay> <o​frnxmr:xmr.mx> Nope. Just a very weird question
19:19:53 <m-relay> <p​reland:monero.social> It’s the “with a focus on” that triggers me
19:22:49 <m-relay> <s​hortwavesurfer2009:monero.social> I ended up asking in the Monero Community Workgroup room and somebody said it would be a better conversation for here. So I will send my question again here.
19:22:57 <m-relay> <s​hortwavesurfer2009:monero.social> Eli5 risk of running pruned node instead of full node? Why couldn't the entire network just be made up of pruned nodes?
19:23:34 <m-relay> <s​hortwavesurfer2009:monero.social> What I did get from there was that apparently blocks are batched into sizes of 20 and so only a full node is able to verify 20 at once like that.
19:24:45 <m-relay> <p​reland:monero.social> Which is an optional number which can be changed if needed (which it would be in this case)
19:25:03 <m-relay> <o​frnxmr:monero.social> I'm not sure i'd call it an annoyance, but also i dont think its been tested
19:25:24 <m-relay> <p​reland:monero.social> Tbh pruning is cool, but I think that we will need something a lot more….encompassing in the future
19:25:38 <m-relay> <p​reland:monero.social> I feel like it could be “easy” to test
19:26:25 <m-relay> <a​mmortel:monero.social> If I have a full node I can check the full blockchain offline. I guess it's not possible with a pruned node?
19:26:27 <m-relay> <p​reland:monero.social> Just make a testnet, get 8 (unique) pruned nodes, and then attempt to sync a new node using only the 8
19:26:36 <m-relay> <o​frnxmr:monero.social> I dont know if it actually works
19:26:37 <m-relay> <o​frnxmr:monero.social> If it  did, then it should probably set block-sync-size to 1 when pulling from any pruned node
19:26:40 <m-relay> <p​reland:monero.social> No you can I think
19:27:19 <m-relay> <p​reland:monero.social> I kinda want to try it myself, although I can already feel my 8 core mobile Ryzen crying at the thought of running + syncing 9 (at minimum) nodes locally
19:27:35 <m-relay> <p​reland:monero.social> My thinking exac
19:27:41 <m-relay> <p​reland:monero.social> tly*
19:28:07 <m-relay> <p​reland:monero.social> Is there a way to identify which of the segments you have?
19:29:34 <m-relay> <o​frnxmr:monero.social> Yeah.. i dont think i have the resources for 8 unique nodes, but i gave noticed that my nodes prefer to pull from full nodes when i'm doing a catch-up sync
19:30:10 <m-relay> <s​hortwavesurfer2009:monero.social> I thought Monero always pulled from full nodes unless you specifically told it not to.
19:30:52 <m-relay> <s​hortwavesurfer2009:monero.social> I thought there was a specific flag you have to set to allow it to pull from pruned nodes.
19:31:11 <m-relay> <o​frnxmr:monero.social> When caught up it will pull from pruned nodes that have the full block
19:31:35 <m-relay> <o​frnxmr:monero.social> --sync-pruned-blocks is in regards to syncing from nodes that are in the same group as you
19:31:42 <moneromooo> If everyone uses pruned nodes, there is a small chance some info will not be kept by anyone. This is a very very small chance with many nodes.
19:32:33 <moneromooo> A syncing node will pull from pruned nodes if they have unpruned version of the blocks it wants, or if --synced-pruned-blocks is used and the blocks are not recent.
19:33:19 <moneromooo> If you have only pruned nodes in your peer list, you can still sync as long as those nodes have, in aggregate, all the info you need.
19:33:28 <moneromooo> That is, stripes 1 through 8.
19:34:10 <moneromooo> There is no need to change --block-sync-size, it's unrelated to pruning.
19:34:39 <moneromooo> Pruning more would make those nodes useless to the network, so it was deemed not a good idea.
19:34:46 <m-relay> <o​frnxmr:monero.social> what if youre doing and initial sync where the block-sync-size is 20? How will it pull 20 blocks if each stripe only has the next block
19:35:37 <moneromooo> IIRC if the peer you're pulling from has fewer than 20 usable blocks at the place you want, it'll just request fewer, then switch to another peer.
19:35:55 <moneromooo> 20 is not a fixed amount, it's the max.
19:36:43 <m-relay> <o​frnxmr:monero.social> So if all nodes were pruned, it would essentially pull 1 by 1?
19:36:54 <moneromooo> No.
19:37:35 <m-relay> <o​frnxmr:monero.social> I'm confused 🙂
19:38:13 <moneromooo> A pruned node keeps 1/8th of the blocks, but not 0 8 16 24 etc. It keeps 0-7999, 64000-55999, etc. Numbers maybe off but you get the idea.
19:38:19 <m-relay> <o​frnxmr:monero.social> Each pruned node only has 1 full block out of 8 (?) So how could it send 2 blocks?
19:38:29 <moneromooo> So you can get a good number of 20 spans from one before you reach blocks it does not have a full version of.
19:38:37 <m-relay> <o​frnxmr:monero.social> Okokok
19:40:25 <m-relay> <p​reland:monero.social> Ok I want to make one thing very clear because I’m going to have nightmares tonight if it isn’t this way: there are actual defined “stripes” for each eighth of the blockchain, right? It isn’t like each node has a completely random eighth, right?
19:40:43 <m-relay> <o​frnxmr:monero.social> for some reason i feel like my memory isnt what it used to be :).
19:41:07 <m-relay> <o​frnxmr:monero.social> Yeah, the striped are 8 groups, and each pruned node belongs to one of the groups
19:41:26 <m-relay> <o​frnxmr:monero.social> Every node in your stripe will have the same blocks as you
19:41:39 <moneromooo> There are 8 possible stripes. A node may only have one of them (or all of them).
19:43:11 <m-relay> <p​reland:monero.social> Ok good
19:45:54 <m-relay> <s​hortwavesurfer2009:monero.social> So you don't lose any security by running a pruned node instead of a full node.
19:46:08 <m-relay> <s​hortwavesurfer2009:monero.social> ?
19:46:18 <moneromooo> Correct.
19:46:32 <m-relay> <s​hortwavesurfer2009:monero.social> Cool
19:48:28 <m-relay> <s​hortwavesurfer2009:monero.social> This post I made is what prompted my question to begin with.
19:48:29 <m-relay> <s​hortwavesurfer2009:monero.social> https://lemmy.zip/post/28013007
19:48:35 <m-relay> <o​frnxmr:monero.social> Do we have any logic for how peers are chosen/evicted to diversify the stripes?
19:49:51 <orbifx> 0​xfffc:monero.social do you know if you can have sub-txns be on a different environment, as a way to commit or abort on multiple envs?
19:53:21 <m-relay> <s​hortwavesurfer2009:monero.social> Also, what happens if an RPC wallet such as Cake Wallet connects to a pruned node and asks it for a block that it does not have? Does it just go and download that set of blocks and send it to Cake Wallet? Or does Cake Wallet go to another peer to get it?
19:56:34 <m-relay> <p​reland:monero.social> Evicted lol
19:57:06 <m-relay> <o​frnxmr:monero.social> Thats the term bitcoin uses for diversifying peers
19:57:19 <m-relay> <p​reland:monero.social> I can’t think of a way that they could really prevent someone from getting a given prune stripe, though I would wonder what the reasoning for taking a given one is
19:57:35 <m-relay> <p​reland:monero.social> My guess is they just give you a random number or smth and you pinky promise not to change it
19:57:48 <m-relay> <o​frnxmr:monero.social> Another peer
19:58:05 <m-relay> <o​frnxmr:monero.social> The stripes are public. Your peers know what stripe youre in
19:58:50 <m-relay> <3​21bob321:monero.social> Been done before please see IRS video
19:59:24 <m-relay> <p​reland:monero.social> This has always been my concern with the current scalability model of Monero, or rather its lack of such a model lol
19:59:25 <m-relay> <p​reland:monero.social> I hope ArtixMine is cooking up something good xD
19:59:50 <m-relay> <p​reland:monero.social> They may know what stripe you are, but they don’t know who *you* are
20:00:43 <m-relay> <o​frnxmr:monero.social> Even syncing a wallet uses a lot of data, not just running a node
20:01:04 <m-relay> <p​reland:monero.social> If I really wanted to get the “purple” stripe (not a thing) I would just modify my client to check which stripe I’m assigned to and then resync the node immediately from scratch if it isn’t what I wanted
20:01:12 <orbifx> anyone know if lmdb can have sub-txns be on a different environment, as a way to commit or abort on multiple envs?
20:01:18 <m-relay> <o​frnxmr:monero.social> A remote node isnt a solution to data caps
20:01:30 <m-relay> <p​reland:monero.social> It isn’t
20:01:42 <m-relay> <o​frnxmr:monero.social> Orbifx, i pined 0xfffc. He'll respond in time
20:02:16 <m-relay> <p​reland:monero.social> IMO in a perfect world everyone should be able to run nodes on any modern device (even a cell phone) and make light wallets a thing of the past
20:02:21 <m-relay> <0​xfffc:monero.social> Yes, trying to make sense of the question. give me sec
20:02:57 <m-relay> <o​frnxmr:monero.social> What is your definition of light wallet?
20:03:02 <m-relay> <o​frnxmr:monero.social> Lws / mymonero?
20:03:08 <m-relay> <p​reland:monero.social> Yeah that message breaks the five finger rule for me so it’s understandable that its confusing
20:03:22 <m-relay> <p​reland:monero.social> A wallet that requires a remote node to operate
20:03:56 <m-relay> <p​reland:monero.social> Probably not the normal definition of light wallet, but 🤷‍♂️
20:03:59 <m-relay> <o​frnxmr:monero.social> Thats not a light wallet,thats every wallet aka a full wallet
20:04:34 <m-relay> <o​frnxmr:monero.social> Cli, rpc, cake, all of these require a connection to a node and function identically
20:04:49 <m-relay> <o​frnxmr:monero.social> Whether the node runs on the same host, lan, wan, or a fan, its the same thing
20:04:53 <m-relay> <p​reland:monero.social> (I wouldn’t count monero-wallet-gui as a light wallet because you can still run a node on-device without having to set it up separately)
20:05:11 <m-relay> <0​xfffc:monero.social> orbifx let's go step by step, as multi env tx. as far as I remember there is no support for multi-env transactions. transactions should aborted or commited on the same env they have been created.
20:05:18 <m-relay> <3​21bob321:monero.social> LW is different
20:05:30 <m-relay> <o​frnxmr:monero.social> monero gui still connects to a node, and monerod is a separate piece of software
20:05:32 <m-relay> <p​reland:monero.social> What does it mean
20:05:42 <m-relay> <o​frnxmr:monero.social> LWS*
20:06:00 <m-relay> <p​reland:monero.social> I am aware, but it doesn’t present the node as  separate
20:06:05 <m-relay> <o​frnxmr:monero.social> Light wallets use a light wallet (LW) server
20:06:23 <m-relay> <o​frnxmr:monero.social> It literally does tho
20:06:43 <m-relay> <o​frnxmr:monero.social> Theres a whole tab for node stuffs, and it even runs a node in simple mode
20:07:00 <m-relay> <o​frnxmr:monero.social> Monerod isnt built into gui. Its a separate binary
20:07:14 <m-relay> <o​frnxmr:monero.social> Its shipped with gui, but its still an entirely separate binary
20:07:36 <m-relay> <p​reland:monero.social> I am aware
20:08:03 <m-relay> <p​reland:monero.social> Basically what I’m trying to get at is this: can I run a full node on-device by downloading Cake Wallet?
20:08:25 <m-relay> <o​frnxmr:monero.social> Monero gui is a tools that ships 1. A wallet gui 2. P2pool 3. Monerod
20:08:34 <m-relay> <0​xfffc:monero.social> In addition to that, lmdb does not provide sub transaction. it provides nested transaction for read transactions.
20:08:37 <m-relay> <o​frnxmr:monero.social> techniclly yes, if cake decided to
20:08:41 <m-relay> <0​xfffc:monero.social> orbifx
20:09:19 <m-relay> <p​reland:monero.social> How does the RPC fit into this?
20:12:16 <m-relay> <o​frnxmr:xmr.mx> Other client glitched
20:12:26 <m-relay> <o​frnxmr:xmr.mx> 1 monent while msg delivers
20:12:33 <m-relay> <o​frnxmr:monero.social> Theres nothing stopping any mobike wallet (or feather) from adding the ability to control a monerod
20:12:34 <m-relay> <o​frnxmr:monero.social> Monero gui connects to monerod over rpc (all wallets do)
20:12:56 <m-relay> <p​reland:monero.social> Ah ok
20:14:19 <m-relay> <p​reland:monero.social> I guess my concern would really just be whether keeping the node separate from the wallet implementation would be desirable if running a node wasn’t in some way a dealbreaker for some users
20:15:01 <m-relay> <p​reland:monero.social> (IE we magically decrease the blockchain size to a constant 1MB and fix any bandwidth constraints through some equally magical sharding method)
20:15:50 <m-relay> <o​frnxmr:xmr.mx> Monero was designed with the node and wallet as separate entities, unlike btc which marries the wallet to the node
20:16:54 <m-relay> <f​ede:xmr.mx> monero has one of the best designs from UX point of view of all the crypto projects
20:18:21 <m-relay> <f​ede:xmr.mx> (try running a wallet with your own self-hosted node on bitcoin or ethereum or kaspa... then report back. With monero it's as simple as doing "doubleclick" on monerod executable)
20:18:25 <m-relay> <s​hortwavesurfer2009:monero.social> How far back does a pruned node keep recent blocks? Say you are in Stripe 1 and Stripe 1 consists of blocks 0 through 8999. We are currently on block like 3.2 million. Just how far back will it go before you have to get your blocks from other peers?
20:19:42 <m-relay> <o​frnxmr:xmr.mx> It will keep block 0-8999
20:19:48 <m-relay> <o​frnxmr:xmr.mx> Forvever
20:20:00 <m-relay> <f​ede:xmr.mx> it always keeps the last 5500 blocks, and 1/3 of the remaining blocks in stripes of 4096 blocks
20:20:41 <m-relay> <o​frnxmr:xmr.mx> ^ i think this is right. All nodes at the tip are "full nodes"
20:21:05 <m-relay> <s​hortwavesurfer2009:monero.social> So like 7 days of recent blocks. Ok
20:21:21 <m-relay> <f​ede:xmr.mx> iirc what stripes to keep is decided based on a seeded pseudorandom number generator and the seed is saved in the database, but i'm not 100% sure (i'm far from being a monero dev lol)
20:21:36 <m-relay> <o​frnxmr:xmr.mx> fede is a wownero dev
20:22:19 <m-relay> <f​ede:xmr.mx> kinda... ive done a few contributions but im not there from launch
20:22:39 <orbifx> 0​xfffc:monero.social thanks. by sub I was referring to nested ones. If they are for read only then they aren't any use anyway
20:22:53 <orbifx> 0​xfffc:monero.social is there a way to dm you over the bridge?
20:23:27 <orbifx> and are you sure (nested) transactions are only for reads?
20:23:55 <m-relay> <o​frnxmr:xmr.mx> I could be wrong, but i think the pruned node keeps all tx data, and doesnt have to download from other nodes to restore a wallet. It only discards ynnecessary data. Which is why its 1/3 the size instead of 1/8th. It still has essential data from the blocks that it prunes
20:24:12 <m-relay> <o​frnxmr:xmr.mx> Orbifx, he's on irc
20:25:02 <m-relay> <o​frnxmr:xmr.mx> @xFFFC0000
20:26:08 <orbifx> ofrnxmr, can't be that address is too high :P
20:26:31 <orbifx> hope he doesn't mind you sharing that
20:29:47 <m-relay> <s​hortwavesurfer2009:monero.social> What does it consider unnecessary then? And also, does it download the entire 200 gigabyte blockchain when synchronizing and then only write 82 gigabytes of that to disk? Or does it only actually download 82 gigabytes of data from the internet?
20:30:35 <m-relay> <o​frnxmr:xmr.mx> "<o​rbifx> hope he doesn't mind you sharing that" its not some private alt account.
20:30:59 <m-relay> <o​frnxmr:xmr.mx> Yes, 200gb
20:31:51 <m-relay> <s​hortwavesurfer2009:monero.social> Ah ok
20:32:04 <m-relay> <o​frnxmr:xmr.mx> downloads the whole 200. If using sync-pruned-blocks can be less
20:39:59 <m-relay> <3​21bob321:monero.social> What would be the limitations for a pruned node compared to full node ?
20:47:01 <m-relay> <o​frnxmr:xmr.mx> Not able to run certain tools
20:47:41 <m-relay> <o​frnxmr:xmr.mx> Like you cant export the raw blockchain for analysis, cant use "the onion blockchain explorer" etc
20:48:13 <m-relay> <o​frnxmr:xmr.mx> For wallet user not much, if anything
21:02:05 <orbifx> ofrnxmr, doesn't seem active/online
21:06:35 <m-relay> <o​frnxmr:monero.social> He'll respond when he's back
21:42:59 <m-relay> <0​xfffc:monero.social> orbifx ping'ed you on irc
21:43:31 <orbifx> thanks
21:49:46 <m-relay> <c​ontrazene:matrix.org> I've been thinking about something: many people consider it uneconomical to mine monero (takes to much power). But when this calculation is done, it generally assumes that you are not doing anything else with that computer. Has anyone done the economics when it comes to running other processes in addition to monero mining on a computer? By how much do the compute-insensitive power<clipped message>
21:49:47 <m-relay> <c​ontrazene:matrix.org>  expenditures in a computer fall below the compute-expensive ones?
21:56:17 <orbifx> contrazene your cost/watt is what is the main factor. In some cases, running on space cores will be profitable whereas it couldn't if running just for mining
21:56:54 <m-relay> <c​ontrazene:matrix.org> when you say space cores, you mean unused ones