00:15:59 <Adamas[m]> <selsta "Adamas: what is the output of "s"> literally days stuck at 200 blocks behind and suddenly synced up.
00:35:43 <refactor_ring[m]> Can anybody tell me why syncing through a remote node can be a slow process, i.e. what are the bandwidth/latency requirements and bottlenecks ?
00:35:43 <refactor_ring[m]> Spent time in remote places with limited bandwidth and high latency and it was basically impossible to sync my wallet at times (was using cakewallet,monerujo and monero gui)
00:37:20 <sethsimmons> You have to download a portion of each block to check for transactions you control locally, which requires a good bit of bandwidth depending on how many blocks behind your wallet is.
00:38:11 <sethsimmons> AFAIK this can be worked around with Monero-wallet-RPC but not sure if mobile wallets support it/how to use it personally.
00:39:03 <mnt_grrrl> and also io
00:39:16 <refactor_ring[m]> Thanks, that makes sense I guess, I will look into Monero-wallet-RPC
00:40:34 <mnt_grrrl> ssd or raid/zfs wil be faster
00:40:41 <refactor_ring[m]> It's something which was a big hurdle for adoption in that particular situation because when I would show people Monero it would always be a bit problematic
00:41:00 <sethsimmons> Yeah mobile light wallets against your own full node is the easy solution
00:41:02 <refactor_ring[m]> @mnt_grrl I don't think io was the issue, tried monero gui locally with gui
00:41:16 <sethsimmons> Right now mobile wallets are full wallet clients and have to check every block individually
00:41:25 <refactor_ring[m]> I do run my own node
00:41:32 <sethsimmons> Monero-wallet-rpc enables light wallets when run as a server against a full node IIRC
00:41:44 <sethsimmons> I think hyc has done that before?
00:41:52 <sethsimmons> Not sure if anyone else has input on the subject
00:42:17 <mnt_grrrl> for a full node io is an issue
00:42:21 <refactor_ring[m]> I meant I tried gui with a ssd earlier
00:44:55 <refactor_ring[m]> So Monero-wallet-rpc is used when you use a remote node in monero gui for instance ?
00:48:54 <mnt_grrrl> what host are you using?
00:49:57 <refactor_ring[m]> I run a couple nodes on different hosts, hardware for the nodes themselves shouldn't be the issue
00:50:13 <mnt_grrrl> clear,i2p or tor
00:50:20 <refactor_ring[m]> Ah clear
00:50:47 <refactor_ring[m]> But with password for rpc
00:51:36 <mnt_grrrl> what port
00:54:08 <refactor_ring[m]> 18080 and 18081
00:56:09 <refactor_ring[m]> But it really seems like latency is the problem, with a good connection it is fine, however at the remote places with high latency (ranging intermittently from ~200-2000ms) it just doesn't work
00:57:15 <refactor_ring[m]> While other wallets like electrum will cope much better
00:58:03 <mnt_grrrl> I might be missing something but why are you having latancy above 500ms
00:58:26 <refactor_ring[m]> There are still places in the world with really bad connections haha
00:58:59 <refactor_ring[m]> Islands without cables for instance
00:59:42 <refactor_ring[m]> However bandwidth is not that bad
00:59:49 <midipoet> what's half  a second between friends anyway?
01:00:31 <kankles> trying to sign a a transaction from a cold wallet. keep getting "Error: Failed to sign transaction"
01:01:01 <kankles> hotwallet and cold wallet running same version. computers are different arch. hot -> x64  cold -> arm
01:01:34 <kankles> 0.17.1.9-release
01:01:39 <mnt_grrrl> refactor_ring[m], are you seeing packet loss with ping?
01:04:41 <refactor_ring[m]> mnt_grrrl: Yes for sure, I'm just wondering why it's so slow because my experience with other cryptos has been better
01:04:41 <Quotes> CRYPTO IS NOT CRYPTOCURRENCY ಠ_ಠ ~ IT REFERS TO CRYPTOGRAPHY, refactor_ring[m]
01:05:44 <kankles> in the logs i see "Filed to parse data from unsigned tx"
01:06:42 <kankles> the unsigned_tx data file is formatted with ---BEGIN MoneroAsciiDataV1---
01:07:22 <moneromooo> There's a bug ferrying cold data between different archs. It'll be fixed in next couple days. If you want to help, it might be fixed earlier. You need to run a logging patch on both archs and paste the resulting log.
01:07:57 <kankles> logging patch?
01:10:07 <moneromooo> https://paste.debian.net/hidden/e4e7fa2b/
01:11:40 <kankles> is this a recent bug? what if i just downgrade the hot wallet version instead to generate the unsinged tx?
01:12:04 <kankles> but publish the signed tx with a 0.17 version?
01:12:31 <moneromooo> Fairly recent, yes. I believe 0.17.0.0 would work.
01:12:57 <kankles> can i generate and sign with 0.15 versions?
01:13:10 <moneromooo> Probably not.
01:13:20 <donkeydonkey[m]> hey y'all wondering how current is the zero to monero for the tech details and all that? thanks
01:13:24 <kankles> really?
01:21:15 <kankles> ya, i se, downgrading to 0.15 probably requires more effort.
01:35:28 <zed19[m]> <Quotes "CRYPTO IS NOT CRYPTOCURRENCY ಠ_ಠ"> agreed, xmr is crypto 90% of the rest is digital currency
01:35:43 <orly_owl> topkek
01:36:04 <zed19[m]> <Quotes "CRYPTO IS NOT CRYPTOCURRENCY ಠ_ಠ"> agreed. xmr is crypto, 90% of the rest is digital currency
01:37:15 <kankles> is there a reason i cant create the full transaction from the cold wallet?
01:37:31 <kankles> it has all of the outputs imported and the keyimages
01:38:00 <kankles> what is the hot wallet accessing that the coldwallet cant?
01:38:08 <moneromooo> There's a bug ferrying cold data between different archs. It'll be fixed in next couple days. If you want to help, it might be fixed earlier. You need to run a logging patch on both archs and paste the resulting log.
01:39:22 <moneromooo> When I say "in a couple days", it's because I have someone who can repro it easily who's running these patches to get me the logs, but offline atm.
01:39:51 <moneromooo> So it'll probably take a couple days to debug.
01:45:38 <moneromooo> kankles: oooh, I have an idea
01:45:46 <moneromooo> in monero-wallet-cli, enter:
01:46:10 <moneromooo> set export-format binary
01:46:15 <moneromooo> Then try again.
01:46:34 <mnt_grrrl> what is the difference between runing monero-gui and monero-rpc against a localserver?
01:46:40 <moneromooo> I'd been assuming it was all binary, I'd forgot someone added an ASCII version.
01:52:00 <kankles> oh ya i forgot about the binary version
01:52:01 <kankles> let me try
01:52:25 <kankles> i thought i remembered it was in binary the last time i did cold transfer
01:56:52 <moneromooo> And if you can build with the patch I linked and get me the level 0 logs (both from export and import), I should be able to copare and spot where it goes out of sync.
01:59:15 <kankles> nope. still failed.
02:02:00 <xmready> Are the attacks still ongoing?
02:09:27 * moneromooo bumped logs up a bit to check, I'll look again in an hour or so
03:06:18 <moneromooo> No attack packet so far. Probably over.
03:11:12 <xmready> moneromoo: point upgrade solved it or attacker gave up?
03:17:19 <h2017> bitcoin is going to test 35000 again
03:19:03 <h2017> sorry wrong chan
03:19:10 <h2017> that was meant for #-markets
04:14:11 <u29601mg6ba93j[m> https://mobile.twitter.com/naval/status/1348427330570489856
04:14:26 <u29601mg6ba93j[m> https://mobile.twitter.com/naval/status/1348427330570489856
04:15:16 <u29601mg6ba93j[m> https://mobile.twitter.com/naval/status/1348427330570489856
09:01:49 <dyskotekowy_ding> Hello everyone
09:08:51 <mawk> is 6GiB too few ram for a full node?
09:09:13 <mawk> I see my node was out of memory killed a month ago, I hadn't noticed it
09:10:06 <Inge-> there has been an OOM attack running against nodes
09:11:19 <mawk> ah
09:11:59 <Inge-> running a publicly available node on a 4GB VPS, seems fine.
09:12:06 <sech1> on that note, it's recommended to update your node to the latest v0.17.1.9
09:12:08 <orly_owl> how does this benefit the attackers
09:12:51 <mawk> some people just like chaos
09:12:57 <mawk> that's where the benefit is
09:13:41 <orly_owl> hmm
09:13:42 <Inge-> There could be many motives. There is the somewhat delusional guy with a thorn in his side wanting to get "monero" to concede something, then there are govts that probably want Monero to fail (or at least to be trackable), then there could be those looking to make a buck by shorting and/or buying low by attacking and making it out to be a coin in trouble
09:13:44 <mawk> also testing a theory at large scale that's cool too
09:15:17 <sech1> anything popular enough will attract haters and attackers, Monero is not an exception
09:15:40 <mawk> I found a first bug in v0.17.1.9, it doesn't like my empty password
09:15:53 <mawk> but trying one more time does it
09:16:20 <mawk> or maybe I just typed a few letters by accident just the first time, becasue trying again and it works sounds suspicious
09:28:54 <mawk> the "mark as trusted daemon" checkbox keeps unchecking itself
09:31:15 <selsta> mawk: I have a lot of test wallets with empty passwords and they work fine
09:31:19 <selsta> which OS are you using?
09:31:30 <mawk> linux, with debian
09:31:42 <mawk> but I guess I may have typed something by mistake in the box if it works fine by your side as well
09:31:52 <selsta> 10:28 <mawk> the "mark as trusted daemon" checkbox keeps unchecking itself <-- yea that is kinda bugged, the idea is that it unchecks itself if the value is changed but it annoys me too
09:32:57 <mawk> well the value is changed but kinda not
09:33:02 <mawk> the value changes to the old value
09:33:21 <mawk> I guess if the ssl certificate didn't change, and the uri is the same, it shouldn't say it's changed
10:06:58 <amuro> Is monero is still worth mining?
10:07:39 <orly_owl> yes
10:12:10 <amuro> Is there any public node I can connect to for my cli-wallet?
10:15:32 <Inge-> a bunch: https://moneroworld.com/#nodes
10:29:55 <amuro> Inge-: thanks.
10:30:59 <Inge-> yw
12:14:03 <urza> Hello I have a question. By accident I started monerod with --prune-blockchain command. I shut it down by CTLR+C quiclky after that when I noticed it started prunning. Is there something I can do to check that I still have full blockchain locally and if not, can I force to re-download missing blocks? Thanks.
12:51:47 <dyskotekowy_ding> Do you know when Triptych will be implemented?
12:54:11 <moneromooo> No.
14:21:21 <Adamas[m]> <orly_owl "how does this benefit the attack"> word down the grape vine is that the attacker is moneromoo and Selsta. They purposely made sure to never fully take down the network. They did this in an attempt to rile up the community to start up more full nodes to make the network stronger while simultaneously keeping the price low so XMR could stay out of the radar a little longer as to not fully kick the hornets nest just
14:21:21 <Adamas[m]> yet.
14:21:26 <Adamas[m]> jk tho
14:41:26 <selsta> Adamas[m]: did you resolve your syncing issue?
14:42:24 <Adamas[m]> <selsta "Adamas: did you resolve your syn"> yeah, somehow it decided to work after a week+ of being constantly behind by 200 blocks.
14:46:33 <Lusya_BriTvA> Howard, you know why all the 'Titanic intelligence Saviour of NASA' posts stopped last year? They know you are an embarrassment. Your arse didn't learn anything new in 25 years, and that includes C++. They just can't say it to your face.
14:48:26 <urza> Hello I have a question. By accident I started monerod with --prune-blockchain command. I shut it down by CTLR+C quiclky after that when I noticed it started prunning. Is there something I can do to check that I still have full blockchain locally and if not, can I force to re-download missing blocks? Thanks.
14:49:10 <moneromooo> check_pruning IIRC. Or check_blockchain_pruning.
14:49:30 <moneromooo> To force re-download: rm ~/.bitmonero/lmdb/data.mdb while monerod is down.
15:03:16 <kinghat[m]> anyone running the xrmto node container? i got it to the point where it wants to write the db but i get a permission denied even though the ENV is set to 1000.
15:47:51 <urza> @moneromooo thanks
15:48:32 <testericle_> hello, which wallet is most recommended?
15:49:03 <testericle_> non web, non store the entire blockchain type preferably?
15:51:23 <fachpersonal[m]> Just use the standard cli or gui wallet and a remote node
15:52:52 <cacamonerr> hey guys
16:04:01 <sethsimmons> <cacamonerr "hey guys"> hey there
16:46:26 <miliw[m]> howdy
16:52:19 <raecarruth> ohai fibonacci :)
16:53:22 <miliw[m]> hope we are all doing well
17:07:30 <Dyrim[m]> oaky so everyone is dead /shrug
17:08:12 <r00tobo> hello if I may ask does running a full monero node without mining takes up cpu usage all times (for validation/verification) ? is it ok to run it on a small vps ?
17:08:18 <mmxxx[m]> hello Dyrim
17:08:25 <jebba> hello hoomans
17:08:30 <u29601mg6ba93j[m> >>> update check
17:08:30 <u29601mg6ba93j[m> [1/11/21 11:07 AM] 2021-01-11 17:07:48.397 I Monero 'Oxygen Orion' (v0.17.1.8-release)
17:08:30 <u29601mg6ba93j[m> Error: Problem fetching info-- rpc_request: Error checking for updates
17:08:43 <azy> r00tobo low cpu usage if synced
17:08:51 <jebba> r00tobo: after it syncs, low cpu
17:09:03 <u29601mg6ba93j[m> any ideas why the update check fails?
17:09:12 <jebba> r00tobo: you can do it with 1 gig ram, 1 cpu, but more "comfortable" with 2 gig ram, 2 cpu.
17:09:25 <jebba> u29601mg6ba93j[m: do you have --public-node or restricted RPC going?
17:09:25 <r00tobo> so it's better to load up the monero blockchain ahead of running the daemon ? so shared low end vps won't be affected ?
17:09:40 * u29601mg6ba93j[m sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/VnvWLzGTPPCtRmdwjCCjxEEI/message.txt >
17:09:44 <jebba> r00tobo: i dont do that, but ya, that could be a way perhaps.
17:09:51 <u29601mg6ba93j[m> restricted RPC on
17:09:59 <u29601mg6ba93j[m>  * restricted RPC on that device
17:11:12 <jebba> u29601mg6ba93j[m: ya, that restricted/public-node thing will stop you from running `status` etc.
17:11:20 <r00tobo> cause according to ramnode AUP they strictly prohibited "Crypto verification (SmartNodes, etc.) (*Allowed on VDS*)" I don't know if this applies to running a full node tho and what do they mean by smartnodes
17:11:40 <jebba> u29601mg6ba93j[m: I also see you are running .8, you probably want to update to latest/greatest.
17:11:57 <u29601mg6ba93j[m> <jebba "u29601mg6ba93j: ya, that restric"> thanks!
17:12:04 <jebba> :)
17:12:32 <jebba> r00tobo: I think they dont want blockchain miners (since it crushes the vps), but you may want to just confirm with them.
17:12:42 <jebba> I haven't seen any that dont allow nodes, fwiw.
17:13:23 <u29601mg6ba93j[m> <jebba "u29601mg6ba93j: I also see you a"> thanks. I can do it manually and verify the hashes myself. just testing the auto updater feature
17:13:26 <r00tobo> they say "Virtual currency / cryptocurrency (*coin) mining"
17:13:36 <r00tobo> so it's also prohibited
17:13:53 <r00tobo> but I don't get the crypto verification part
17:14:54 <jebba> maybe find another host? there's millions of them.
17:15:19 <jebba> best bet is to contact them
17:16:37 <monerouser1144> LOL, my monerod is "syncing" with IP 116.203.42.1 from ZZ (reserved / unknown country) according to whois :-)
17:17:16 <r00tobo> monerouser1144, that's a hetzner ip
17:18:10 <r00tobo> your whois is outdated x3
17:18:34 <jebba> ya, looks like german hetzner
17:18:52 <jebba> Fine provider, btw. :)
17:19:24 <r00tobo> I might go with them then instead of RN
17:21:04 <jebba> r00tobo: are you just setting up a node for kicks? Maybe track down a country that is serverless at present. Just humble suggestion, idk what your plans/needs are.
17:21:26 <monerouser1144> Well, even the 2 web-whois sites I just checked say this: http://paste.debian.net/1180675/
17:21:46 <r00tobo> terms of service saying  Operating applications that are used to mine crypto currencies
17:22:04 <jebba> monerouser1144: ya, the `whois` record is old for that IP.  By tracing it and looking at current DNS, shows it is probably at hetzner germany.
17:22:13 <r00tobo> jebba, just a node to connect to
17:22:23 <r00tobo> always run your own node
17:22:29 <jebba> then you probably want it close to you
17:22:32 <jebba> maybe
17:23:14 <r00tobo> or just run it at home why not
17:23:24 <jebba> Anyhoo, i havent used hetzner for monero, but i've used them in the past and they are good, in my experience.
17:23:50 <jebba> if your home will allow incoming 18080-1 and you have the bandwidth....
17:24:11 <r00tobo> I can limit it with monerod
17:24:18 <jebba> ya
17:24:21 <r00tobo> how much bw do I need ?
17:25:38 <jebba> Uh, initially you have to download 30 gigs (pruned) or 98 gigs (full).  Then you could probably throttle down to a couple mbit/sec  (?).
17:28:47 <r00tobo> that's easy I have 100 mbps down
17:29:54 <ndorf> after the initial sync you can throttle as low as 100k/s and it will work fine.
17:30:37 <r00tobo> perfect
17:40:48 <Inge-> doesn't a pruned node download the full 98GB (but only need 30-ish gigabytes storage)?
17:44:02 <sethsimmons> Roughly, but less than that IIRC
17:44:45 <marmulak> such data
17:48:48 <miliw[m]> is anybody running with the rpc_payments? I can't figure it out
18:13:11 <Adamas[m]> tried to set up through tor on arch but gave up :(
18:18:35 <moneromooo> Did you try contrib/tor/monero-over-tor.sh ?
18:30:49 <monerouser1144> Catching up on earlier discussions, I think that using dedicated ("root") servers instead of VPS for monerod, you get a lot more "bang for the buck". Because a VPS (running on KVM) typically offer better uptime and redundancy etc, which you don't need for "disposable" / "ephemeral" monerod nodes.
18:32:21 <monerouser1144> I have no final opinion on using Docker to deploy, but I currently think doesn't offer any advantages over a dedi (with auto-deployment).
18:45:05 <micah> hi, i'm trying to send some xmr... it waits for confirmation for a while, and then it just says "Failed"
18:45:37 <micah> i see in the log: 2021-01-11 18:32:20.504 E res.txs.size() != 1. THROW EXCEPTION: error::wallet_internal_error
18:45:54 <micah> this is with 0.17.1.9
18:46:27 <selsta> micah: CLI or GUI?
18:46:48 <micah> selsta: Gui
18:47:04 <selsta> which wallet mode?
18:47:38 <selsta> can check on Settings -> Info
18:57:14 <micah> selsta: Simple
18:57:41 <micah> i'm also using a hardware wallet (trezor)
18:57:57 <selsta> Ok, go to Settings -> Info, click on (Change) next to wallet restore height and then on ok twice
18:58:03 <selsta> wait for a full rescan and try again
19:12:28 <viperperidot[m]> Any update on the tor attack?
19:13:34 <micah> selsta: ok, i did that, there was no wait for a rescan though, it was just...immediate
19:13:38 <Adamas[m]> <moneromooo "Did you try contrib/tor/monero-o"> yeah, ran into some issues. will try again later. probably doesnt help that i fell for the anti systemd meme and am running artix. will prob switch that system to ubuntu to make my life easier.
19:14:06 <selsta> micah: look at the left status bar
19:14:07 <micah> selsta: although I don't see a value there now, and if I click Change again, its 0
19:14:26 <micah> selsta: yeah, the left says wallet synchronized, daemon is synchronized
19:17:39 <selsta> micah: ok, let’s try this then
19:17:55 <selsta> click on Change and enter a date that was before you first received a transaction into this wallet
19:17:58 <micah> i could try and quit/restart after the 'change'
19:18:11 <selsta> e.g. 2020-02-01 if you first received a tx in Feb 2020
19:18:22 <jebba> Inge-: If you start with `--prune-blockchain`  it wont download the full 98G, it will just start pruned. I have some KVM with just 50G, for example.
19:18:23 <selsta> then click on ok twice and see if the wallet scan bar restarts
19:18:50 <jebba> micah: IMC? :)
19:19:31 <micah> selsta: it does not
19:19:38 <micah> jebba: ahimsa ;D
19:19:41 <jebba> lol
19:20:12 <selsta> micah: what value does "Wallet restore height" display now?
19:20:31 <micah> selsta: if I click change it shows '0'
19:21:44 <selsta> micah: do you know how to restore from seed?
19:22:05 <micah> selsta: i do
19:24:47 <selsta> yea, that will work too
19:25:03 <selsta> afterwards you should be able to send again
20:03:10 <Inge-> jebba: did you check how much data it downloaded? not talking about disk space used.
20:03:32 <jebba> Inge-: good question, i didnt check that.
20:15:50 * assratatouille[m sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/MHldabdMoAmMbTpgUQHpbbzK/message.txt >
20:29:00 <assratatouille[m> also, im using btrfs. should i disable CoW for my lmdb directory
20:45:25 <urza> Full blockchain sync in 6 hours and 12 minutes on Ryzen 5900x. Not too bad. I noticed that mostly only one core was fully utilized. Is it not possible to paralelize the verification?
20:46:57 <moneromooo> Try --fast-block-sync 0
20:47:32 <moneromooo> This should be more parallel, and also much slower.
20:49:21 <urza> slower?
20:50:32 <moneromooo> Taking more time.
20:54:53 <urza> so what is the bottleneck if not parallelization?
20:57:03 <urza> At least with Bitcoin, what takes most time during IBD (initial blockchain download) is CPU time verifying all those signatures. So in theory the more parallelizable the verification the faster it should be. Is it different with Monero?
20:57:36 <urza> Assuming fast internet connection and fast nvme drive.
20:58:25 <endor00[m]> The hash function is much heavier for Monero, so the verification of block headers takes longer too
21:09:50 <micah> selsta: ok, i'm trying to recover the wallet from my trezor, but when I create a new wallet from device I get: 2021-01-11 21:08:32.937 E Open exception: Failed to acquire device
21:17:40 <micah> selsta: i'm seeing: !hwdev.connect(). THROW EXCEPTION: error::wallet_internal_error
21:30:56 <Guest_53> Hello, I have some security questions about running a full node. I'm planning to run automated build and redeploy when master is updated so I can hopefully update before any 0 days can affect me, but I'm wondering if this is potentially a security concern in case something nasty slips into master. Am I being paranoid? or maybe there is a better way
21:30:57 <Guest_53> to keep the node up to date?
21:31:44 <sech1> Master branch is not guaranteed to be compatible with current release, use the latest release branch
21:36:59 <Guest_53> sech1 ok, would automatic builds on updates to the release branch be ok?
21:37:33 <sech1> mostly ok, but intermediate updates can be unstable
21:37:41 <sech1> only release tags are safe
21:41:42 <xmready> If i connect the latest CLI wallet to a remote .onion node will it get blocked or is the network allowing .onion nodes?
21:41:48 <Guest_53> Thanks!
22:08:25 <rbd> hi guys, anyone had issues getting --restore-height to be honored with monero-wallet-cli? I am trying a command like "./monero-wallet-cli --generate-from-device myledger --restore-height 0" and the wallet still prompts with "No restore height is specified." -- this is newest release, on OS X Big Sur
22:09:08 <rbd> tried changing the order of the options around. Also tried --restore-height=0
22:11:32 <moneromooo> Probably a bug.
22:14:32 <moneromooo> https://paste.debian.net/hidden/938e4dd5/ should fix it.
22:15:53 <rbd> ah great, thanks @moneromooo ...assuming this fix will be in the next release too?
22:18:45 <moneromooo> Probably. Assuming it builds.
22:18:54 <moneromooo> and works :)
22:52:28 <moneroist> I am reading now on getmonero.org FAQ that lightwallet is not able to know how Monero you received, it is that correct?
22:55:09 <moneroist> We are talking about light wallet like MyMonero where viewkey is given directly to them , or light wallet like Monero wallet connected to remote node where wallet only download blocks and locally scans transactions to discover own outputs?
22:55:30 <endogenic> it must be talking about the lightwallet API that scans for you in front of a node
22:56:13 <endogenic> it can tell which transactions contain outputs decodable by your view key.. but it doesnt have your spend key so cant generate the key images to check if you were the true spender in certain transactions.. aiui
22:56:35 <endogenic> or dont as the case may be
22:57:24 <moneroist> ok thanks
23:42:17 <xmready> If i connect the latest CLI wallet to a remote .onion node will it get blocked or is the network allowing .onion nodes?
23:45:45 <ndorf> i might be mistaken, but i think blocking tor exits refers only to P2P connections, not RPC
23:45:51 <ndorf> so node-to-node, not wallet-to-node
23:47:32 <monerofanboy> Any reddit mods on here? This post looks prime to turn into a "shit show" quickly. https://www.reddit.com/r/Monero/comments/kvf75w/how_to_censor_monero/
23:47:37 <moneromooo> The network doesn't block anything. Individual node operators may block some nodes.