05:13:44 <m-relay> <p​laiwanone:matrix.org> Can I do e-begging here?
05:16:17 <m-relay> <l​ucidlynx:envs.net> What’s e-begging?
05:40:08 <m-relay> <3​21bob321:monero.social> oliver twist
06:00:20 <m-relay> <m​ark:chat.nicecrew.digital> Does ebegging even works? Do people actually send money to random beggars?
06:02:33 <m-relay> <m​ark:chat.nicecrew.digital> Please send me monero, my village needs a well, I'm poor and everyone died but me and I'm sick and a single dad
06:08:17 <m-relay> <t​he.king45:matrix.org> 👇♦FREE 🎁 GIFT FOR THERE♦👇
06:08:18 <m-relay> <t​he.king45:matrix.org> Come to my telegram group 
06:08:20 <m-relay> <t​he.king45:matrix.org> To make some money 💰 
06:08:22 <m-relay> <t​he.king45:matrix.org> Make money essay 
06:08:24 <m-relay> <t​he.king45:matrix.org> I promise you all 👉NO SCAM ❌
06:08:26 <m-relay> <t​he.king45:matrix.org> NO PAYMENT FEES ❌
06:08:28 <m-relay> <t​he.king45:matrix.org> I PROMISE YOU ALL 💟
06:08:30 <m-relay> <t​he.king45:matrix.org> 👇JOIN OUR TELEGRAM GROUP 👇
06:08:32 <m-relay> <t​he.king45:matrix.org> https://t.me/+ioqje81ziAYyYTc0
06:08:34 <m-relay> <t​he.king45:matrix.org> https://t.me/+ioqje81ziAYyYTc0
06:08:36 <m-relay> <t​he.king45:matrix.org> @everyone @everyone
06:10:06 <m-relay> <l​ucidlynx:envs.net> Hold on why I get my tiniest violin 🎻
06:10:37 <m-relay> <l​ucidlynx:envs.net> Hold on whilst I fetch my tiniest violin 🎻
11:04:02 <m-relay> <s​hortcow:yatrix.org> Is it worth to send multiple transfers in one transaction? Will the fee be noticeably less than sending each transfer separately?
11:26:05 <sech1> Yes, the fee will be smaller. 2in/16out transaction is 3.38 KiB, while 1in/2out transaction is 1.5 KiB. So you pay only 2.25x fee for 16 outputs instead of 2
11:51:30 <m-relay> <m​ark:chat.nicecrew.digital> If you send the transaction in low priority (and you should), the transaction costs less than a cent, so most people don't care.
11:55:51 <m-relay> <s​hortcow:yatrix.org> Thanks
12:30:55 <m-relay> <e​amonsms:matrix.org> Is there a business leader here looking to elevate their brand with tailored, efficient SMS marketing routing solutions? Let’s discuss how we can help you connect with your audience seamlessly and drive results through strategic messaging.
13:22:36 <m-relay> <s​hortcow:yatrix.org> Is it ok to see `transaction_created` 3 time in log while creating 1 transaction?
13:22:55 <m-relay> <s​hortcow:yatrix.org> Is it ok to see `transaction_created` 3 times in log while creating 1 transaction?
13:23:49 <m-relay> <s​hortcow:yatrix.org> Im trying to figure out why transaction fails with `(double spend)` error
13:54:59 <m-relay> <o​frnxmr:monero.social> Bcuz the node has already seen the tx(?). Either in txpool or already confirmed
13:56:32 <m-relay> <s​hortcow:yatrix.org> There is no out transactions in `show_transfers` after rescan_bc hard.
13:57:58 <m-relay> <s​hortcow:yatrix.org> Moreover, on one of the wallets I could not fix this error even after restoring from the seed phrase
14:00:49 <m-relay> <s​hortcow:yatrix.org> `rescan_spent` also doesnt help
14:32:16 <m-relay> <s​hortcow:yatrix.org> Same problem with this wallet. I've just restored it from seed and still cant send XMR
14:58:40 <m-relay> <s​hortcow:yatrix.org> ok, fixed it  with `flush_txpool`. But, honestly, it very strange behaviour. One failed transaction makes it impossible to use node at all.
15:06:58 <m-relay> <r​ucknium:monero.social> shortcow: What network are you making these transactions? Mainnet? Public testnet? Private testnet? Is your node connected to the rest of the network? It looks like the tx was waiting to be mined. Of course a double spend will be rejected.
15:07:45 <m-relay> <s​hortcow:yatrix.org> stagenet. yes, connected
15:08:25 <m-relay> <r​ucknium:monero.social> Did you check a stagenet block explorer to see if the tx was broadcast to the rest of the network?
15:08:54 <m-relay> <s​hortcow:yatrix.org> maybe it takes too long to mine block with my transaction...
15:08:55 <m-relay> <r​ucknium:monero.social> https://stagenet.xmrchain.net/
15:09:41 <m-relay> <r​ucknium:monero.social> How long did you wait? Two minutes between blocks on average, but it can take much longer occasionally since mining time is random
15:11:46 <m-relay> <r​ucknium:monero.social> The Monero tx relay rules don't allow fee bumping by the way. BTC allows it by "replace by fee".
15:12:40 <m-relay> <s​hortcow:yatrix.org> I watch it from time to time, but I didn't pay attention this time. I felt like I spent quite a while trying to solve this problem, well over 2 minutes. Next time I'll look at explorer more carefully
15:13:28 <m-relay> <r​ucknium:monero.social> If you still have the ID of the tx that you flushed, you can check if it was eventually confirmed now
15:13:56 <m-relay> <r​ucknium:monero.social> Just put it in the search box ^
15:15:31 <m-relay> <s​hortcow:yatrix.org> It wasnt.
15:15:44 <m-relay> <s​hortcow:yatrix.org> It wasnt
15:16:19 <m-relay> <r​ucknium:monero.social> Probably it wasn't broadcast to the rest of the network from your node.
15:17:34 <m-relay> <s​hortcow:yatrix.org> Maybe bad `tx-proxy` settings. Thanks
15:18:30 <m-relay> <r​ucknium:monero.social> IIRC, there is a command to monerod that displays a summary of txs in the txpool and how many are "failing". You could have used that command to see if your tx was "failing". Failing usually means a double spend, which would mean that a previous tx that you broadcast, spending the same output, was already confirmed
15:19:21 <m-relay> <s​hortcow:yatrix.org> Thank you
15:33:42 <m-relay> <s​hortcow:yatrix.org> E Listed --anonymous-inbound without listing any --tx-proxy. The latter is necessary for sending local txes over anonymity networks
15:33:42 <m-relay> <s​hortcow:yatrix.org> Why? What if i want allow anonymous relaying for others, but not for my own node?
15:35:15 <m-relay> <s​hortcow:yatrix.org> Ok, probably because monerod dont know how to connect to tor/i2p
15:35:28 <m-relay> <s​hortcow:yatrix.org> But what if i want allow anonymous relaying for others, but not for my own node?
15:56:27 <m-relay> <r​ucknium:monero.social> ofrnxmr knows about that topic
15:57:31 <m-relay> <o​frnxmr:xmr.mx> anonymous-inbound requires tx-proxy to relay your onion addr to peers
16:29:22 <m-relay> <p​reland:monero.social> Back in the day, there was discussion to make tx-proxy not required when also using anonymous-inbound, but it was decided against because it allowed certain edge case scenarios to occur
16:33:50 <m-relay> <p​reland:monero.social> Also, before I bite the bullet and have to start editing monerod—is it currently possible to make —bootstrap-daemon-address only auto select public nodes using I2P/Tor?
16:33:50 <m-relay> <p​reland:monero.social> I’m pretty sure I know the answer, but I’m just making sure before I proceed
16:39:50 <texxy> chat
16:39:57 <texxy> how does xmr prevent replay attacks
16:40:21 <m-relay> <e​longated:matrix.org> Replay ?
16:40:49 <m-relay> <j​effro256:monero.social> texxy: do you mean "double spends"?
16:41:43 <m-relay> <r​ucknium:monero.social> When it hard forks? Usually (maybe always), Monero hard forks are also soft forks. Transactions are neither forward- nor backward-compatible.
16:42:58 <texxy> basically the idea is
16:43:14 <texxy> an attack intercepts a packet containing tx data
16:43:21 <texxy> and just replays it to nodes
16:44:05 <texxy> apparently xmr uses unique nonces and checks for uniqueness
16:44:41 <m-relay> <j​effro256:monero.social> Why would that be an attack? That's basically how transaction propogation works: it touchs peer A, peer A tells all of its connections about the transaction, they tell their connections, so on and so forth
16:45:26 <texxy> w8 i was reading this paper wrong
16:45:37 <texxy> its an issue in account models because they use RPC
16:50:09 <m-relay> <j​effro256:monero.social> Are you asking what prevents publishing a transaction once an RPC node has the already-signed transaction stored?
16:50:29 <m-relay> <j​effro256:monero.social> If you wanted to delay it?
16:50:39 <texxy> no i have realised it is not needed
16:51:16 <m-relay> <p​laiwanone:matrix.org> how2
16:51:19 <texxy> what i do need to know is if there is a way to avoid ringct because it bloats the blockchain massively
16:51:33 <m-relay> <o​frnxmr:xmr.mx> No....
16:51:42 <texxy> it does
16:52:03 <m-relay> <o​frnxmr:xmr.mx> Public-node doesnt broadcast onion addresses. Monerod isnt knowledgeable about onion or i2p rpc ....
16:52:16 <m-relay> <o​frnxmr:xmr.mx> Texxy, my response was to preland
16:52:19 <texxy> oh
16:52:23 <texxy> well anyway
16:52:27 <m-relay> <j​effro256:monero.social> texxy: there is no way to avoid RingCT. It is required since fork v6
16:52:38 <texxy> im talking about new crypto i am making
16:52:46 <m-relay> <o​frnxmr:xmr.mx> jeffro, you can use bitcoin
16:53:09 <texxy> big issue with xmr imo is cost to run nodes
16:53:33 <texxy> right now 16x what is necessary means we are wasting disk
16:53:38 <texxy> same with stealth addresses
16:53:41 <m-relay> <o​frnxmr:xmr.mx> how? Its cheaper than btc atm
16:53:52 <m-relay> <j​effro256:monero.social> Run a pruned node
16:54:01 <texxy> how do you prune properly?
16:54:03 <m-relay> <p​laiwanone:matrix.org> the sun set so
16:54:07 <m-relay> <o​frnxmr:xmr.mx> run a pruned btc node*
16:54:10 <texxy> btc can prune every spent output
16:54:13 <texxy> xmr cant
16:54:20 <m-relay> <p​reland:monero.social> *sigh* thanks for the heads up
16:54:22 <texxy> so we need security that minimizes waste
16:55:04 <m-relay> <j​effro256:monero.social> A pruned Monero node is one that stores 1/8 of the chain using a random "stripe"
16:55:21 <texxy> yup
16:55:23 <m-relay> <j​effro256:monero.social> It does full validation but only stores part of the data
16:55:23 <texxy> except
16:55:25 <m-relay> <o​frnxmr:xmr.mx> Now the question is: does bootsteap work AT ALL with tor/i2p. I dont think so. I2p client tunnels yes, but onion and b32, no
16:55:38 <texxy> if everyone runs pruned xmr nodes, it slows network speed
16:55:58 <texxy> and theres also 0 guarantee that everyone doesnt just remove the exact same 1/8
16:56:01 <m-relay> <o​frnxmr:xmr.mx> No it doesnt
16:56:20 <texxy> also compare 1/8 to the compression btc gets by removing all stxo
16:56:28 <m-relay> <j​effro256:monero.social> Not necessarily in the best case, nodes broadcast stripe values so that could be coordinated to work everytime with hopping
16:56:39 <m-relay> <j​effro256:monero.social> *without
16:56:41 <texxy> if xmr is successful, most coins will be spent
16:56:43 <m-relay> <o​frnxmr:xmr.mx> btc pruned nodes are centralization
16:56:58 <m-relay> <o​frnxmr:xmr.mx> They all require full nodes
16:57:09 <m-relay> <o​frnxmr:xmr.mx> Monero pruned nodes do not require full nodes
16:57:21 <texxy> yet we cant efficiently get rid of all the inbetween where an output isnt being useful
16:57:34 <m-relay> <o​frnxmr:xmr.mx> Each pruned node is in a group (stripe) and each group stores a different section of the blockchain
16:57:43 <m-relay> <j​effro256:monero.social> Yeah if all BTC nodes removed stxo,s then your sync time would be infinite because no one would be storing the data lol
16:58:08 <texxy> pruning can avoid centralization by just using super intense compression algorithmns
16:58:25 <texxy> that way you have "hot" queries and "cold" queries in db
16:58:36 <texxy> so any arbitrary node stores entire blockchain
16:58:41 <m-relay> <o​frnxmr:xmr.mx> like bitcoin?
16:58:42 <texxy> but it avoids super centralization
16:58:53 <m-relay> <o​frnxmr:xmr.mx> oh wait, no. Bitcoin doesnt work like that
16:59:22 <m-relay> <o​frnxmr:xmr.mx> texxy, please build this software
16:59:36 <texxy> what software
17:00:02 <m-relay> <o​frnxmr:xmr.mx> the prune juice blockchain
17:01:12 <m-relay> <p​laiwanone:matrix.org> This is Gundam
17:01:54 <m-relay> <p​laiwanone:matrix.org> he just keeps staring there
17:03:49 <m-relay> <p​laiwanone:matrix.org> about Buzz Lightyear
17:04:31 <m-relay> <p​laiwanone:matrix.org> "Scorpion"
17:05:53 <m-relay> <e​yeyush:matrix.org> anyone know someone who sell vps, for crypto?
17:06:20 <texxy> should i make amazon but with crypto?
17:06:44 <m-relay> <p​laiwanone:matrix.org> uh huh
17:07:07 <m-relay> <s​hortcow:yatrix.org> https://github.com/Lissy93/awesome-privacy
17:08:08 <m-relay> <p​laiwanone:matrix.org> Coco
17:08:09 <m-relay> <s​hortcow:yatrix.org> also i heard about incognet, but i dont now anything about it
17:09:02 <m-relay> <c​rispycat:calitabby.net> i'm currently renting a vps from them and it's fine, however i have had a support ticket open for a couple weeks they have not responded to
17:10:12 <m-relay> <s​hortcow:yatrix.org> also i heard about incognet, but i dont know anything about it
17:11:42 <m-relay> <e​yeyush:matrix.org> most are expensive
17:11:46 <m-relay> <s​hortcow:yatrix.org> No
17:13:08 <m-relay> <s​hortcow:yatrix.org> +- common prices
17:15:12 <m-relay> <e​yeyush:matrix.org> The topics are: software, decentralisation, crypto, web3
17:15:14 <m-relay> <e​yeyush:matrix.org> and philosophy, economics and its social, politcial and economical influence.
17:15:16 <m-relay> <e​yeyush:matrix.org> https://drive.google.com/file/d/1qbyWHhHYMvtJCaw9Uipg8apH0ffLq87_/view?usp=sharing
17:15:18 <m-relay> <e​yeyush:matrix.org> the second issue is going to be entirely technical and better
17:15:20 <m-relay> <e​yeyush:matrix.org> 3. this is student run college magazine, so currently no ISSN
17:15:22 <m-relay> <e​yeyush:matrix.org> 4. we are in the process of designing the cypherpunk/privacy event vxcircle.org x.com/vxcircleorg  around the magazine KALPA  (peoplesklub.vxcircle.org)  and the website will be build this week
17:15:29 <m-relay> <e​yeyush:matrix.org> anyone interested in submitting article?
17:38:48 <m-relay> <p​reland:monero.social> I am cautiously optimistic
17:40:37 <m-relay> <o​frnxmr:xmr.mx> Monerod doesnt know how to handle a b32 address without a proxy
17:40:55 <m-relay> <o​frnxmr:xmr.mx> Also, tx-proxy seems to be bypassed when you have bootstrap enabled (probably a bug)
17:57:31 <m-relay> <p​laiwanone:matrix.org> brb
17:57:38 <m-relay> <p​laiwanone:matrix.org> anyone want a ramen?
18:28:52 <m-relay> <p​reland:monero.social> Does this also make it impossible to add b32 addresses as peers manually?
18:29:09 <m-relay> <p​reland:monero.social> That would explain why I was having issues with that on my testnet
18:37:22 <m-relay> <o​frnxmr:xmr.mx> yes
18:37:48 <m-relay> <o​frnxmr:xmr.mx> Monero isnt designed to allow onion or i2p blockchain sync peers
18:38:20 <m-relay> <o​frnxmr:xmr.mx> It assumes all peers to be ipv4, or (if enabled) ipv6
18:38:54 <m-relay> <o​frnxmr:xmr.mx> If you want to trick it.. use client tunnels
19:55:03 <m-relay> <m​mxxx:monero.social> seems like an oversight
19:56:17 <m-relay> <p​reland:monero.social> I wonder why it was attempting to send stuff to the urls via the protocol anyways…..ughhh
20:17:30 <m-relay> <p​laiwanone:matrix.org> set
20:17:31 <m-relay> <p​laiwanone:matrix.org> sail
20:46:46 <texxy1> bruh
20:46:48 <texxy1> who hacked me
20:59:10 <m-relay> <o​frnxmr:xmr.mx> Me
21:22:05 <m-relay> <s​yntheticbird:monero.social> Mii
21:23:00 <m-relay> <c​haser:monero.social> I was able to compress a pruned node's lmdb directory to ~70% of its size, which seems surprisingly low. does anyone know where this redundancy is coming from?
21:23:55 <m-relay> <s​yntheticbird:monero.social> excuse me what
21:24:02 <m-relay> <s​yntheticbird:monero.social> how did you compressed it exactly?
21:36:55 <m-relay> <c​haser:monero.social> tar -cv "./lmdb" | lzip -9 -o "lmdb.tar.lz"
21:41:02 <m-relay> <c​haser:monero.social> I probably could have shaved a few more percentage points if I used xz
22:01:21 <m-relay> <v​ytskalt:matrix.org> hi, i'm trying to run a monero node on my raspberry pi 5 (4gb ram model). I copied the lmdb directory with the blockchain already synced from another pc and when I run the node it just keeps endlessly repeating these logs and not doing anything:
22:01:22 <m-relay> <v​ytskalt:matrix.org> ```
22:01:24 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.929 I Monero 'Fluorine Fermi' (v0.18.3.4-release)
22:01:26 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.930 I Moving from main() into the daemonize now.
22:01:28 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.930 I Initializing cryptonote protocol...
22:01:30 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.930 I Cryptonote protocol initialized OK
22:01:32 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.931 T Blockchain::Blockchain
22:01:34 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.931 I Initializing core...
22:01:36 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.931 T BlockchainLMDB::BlockchainLMDB
22:01:38 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.931 T BlockchainLMDB::get_db_name
22:01:40 <m-relay> <v​ytskalt:matrix.org> 2025-02-17 21:37:03.931 I Loading blockchain from folder /home/monero/.bitmonero/lmdb ...
22:04:05 <m-relay> <v​ytskalt:matrix.org> I'm using docker compose:
22:04:06 <m-relay> <v​ytskalt:matrix.org> ```
22:04:08 <m-relay> <v​ytskalt:matrix.org>  monerod:
22:04:10 <m-relay> <v​ytskalt:matrix.org>     container_name: monerod
22:04:12 <m-relay> <v​ytskalt:matrix.org>     restart: unless-stopped
22:04:14 <m-relay> <v​ytskalt:matrix.org>     ports:
22:04:16 <m-relay> <v​ytskalt:matrix.org>       - "18080:18080"
22:04:18 <m-relay> <v​ytskalt:matrix.org>       - "18089:18089"
22:04:20 <m-relay> <v​ytskalt:matrix.org>     volumes:
22:04:22 <m-relay> <v​ytskalt:matrix.org>       - ./monero:/home/monero
22:04:24 <m-relay> <v​ytskalt:matrix.org>     image: ghcr.io/sethforprivacy/simple-monerod:v0.18.3.4
22:16:24 <m-relay> <p​reland:monero.social> I had wanted to try that, but I didn’t think it would work *that* well….
22:16:43 <m-relay> <p​reland:monero.social> How long did it take to zip that whole thing lol
22:17:31 <m-relay> <c​haser:monero.social> a long time. around 1.5 days.
22:17:50 <m-relay> <p​reland:monero.social> Not surprising
22:18:37 <m-relay> <o​frnxmr:xmr.mx> Do you have proper permissions for the folder?
22:19:56 <m-relay> <o​frnxmr:xmr.mx> Also, log-level=4 is very high. Will usr a lot of storage very quickly
22:42:46 <m-relay> <s​yntheticbird:monero.social> saying that log-level=4 piped into file is io bottle-necking is an understatement
22:44:18 <m-relay> <s​yntheticbird:monero.social> a small VM ran out of RAM in 10 seconds because everything the console output was buffered in RAM
22:44:57 <m-relay> <v​ytskalt:matrix.org> I think so. I created a docker container with a shell and was able to access the mounted lmdb folder fine
22:45:23 <m-relay> <v​ytskalt:matrix.org> I know. I just wanted to see if there was anything else printed that could give me a clue what is going on.
22:46:41 <m-relay> <o​frnxmr:xmr.mx> Did ypu try w/o copying the data-dir
22:47:03 <m-relay> <v​ytskalt:matrix.org> Yes and it started syncing the chain from scratch
22:48:43 <m-relay> <o​frnxmr:xmr.mx> Sounds like a problem with your copied datadir
22:49:06 <m-relay> <v​ytskalt:matrix.org> I may have copied it while the node was still running
22:49:09 <m-relay> <o​frnxmr:xmr.mx> compare permissions on the new dir and the copied one
22:49:28 <m-relay> <o​frnxmr:xmr.mx> Thats probably not a good idea
22:51:41 <m-relay> <v​ytskalt:matrix.org> i'll try copying it again with the node shut down then