00:00:28 <sethsimmons> Is there a flag/command for getting network usage totals from monerod?
00:01:02 <selsta> print_net_stats
00:01:21 <sethsimmons> Wow thats amazing
00:01:21 <sethsimmons> TY
00:01:58 <sethsimmons> 1.11GB rx, 15.78GB TX in 6h since updating to v0.17.1.8
00:02:42 <sethsimmons> And what’s the correct value to pass to the limit-rate args to make it unlimited? -1?
00:02:48 <sethsimmons> I don’t want to limit mine at all.
00:04:54 <selsta> I guess you can set it to a large number
00:05:14 <mnt_grrrl> limit-rate-up=1048576     # 1048576 kB/s == 1GB/s; a raise from default 2048 kB/
00:05:14 <mnt_grrrl> s; contribute more to p2p network
00:05:14 <mnt_grrrl> limit-rate-down=1048576   # 1048576 kB/s == 1GB/s; a raise from default 8192 kB/
00:05:14 <mnt_grrrl> s; allow for faster initial sync
00:05:41 <mnt_grrrl> Received 18215268 bytes (17.37 MB) in 8963 packets in 21.8 minutes, average 13.61 kB/s = 0.00% of the limit of 1.00 GB/s
00:05:41 <mnt_grrrl> Sent 30734462 bytes (29.31 MB) in 5347 packets in 21.8 minutes, average 22.96 kB/s = 0.00% of the limit of 1.00 GB/s
00:06:08 <selsta> I don’t seem to hit the limit on my node, on the one with the most traffic I get `31.07% of the limit of 2.00 MB/s`
00:06:39 <tevador> my node has already sent 6 GB of data in less than 1 hour after updating to .8, I think the traffic used to be lower
00:06:39 <mnt_grrrl> yea I am not seeing anything close to the limit
00:07:22 <selsta> (12.31 GB) in 584016 packets in 5.6 hours is the most I have
00:07:26 <selsta> sent
00:07:55 <mnt_grrrl> tevador, what modes are you running clear, i2p, and/or tor? Any tips for increasing the traffic
00:08:29 <selsta> but I assume less nodes that allow incoming connections online due to OOM attack -> more traffic
00:08:33 <tevador> Sent 6749917619 bytes (6.29 GB) in 276931 packets in 55.6 minutes
00:08:45 <tevador> I have 128 out peers
00:08:51 <sethsimmons> Exposing RPC greatly increases traffic
00:08:52 <selsta> that explains it, mine is default 12
00:08:52 <binaryFate> <sethsimmons> And what’s the correct value to pass to the limit-rate args to make it unlimited? -1? <--- yes, check monerod --help
00:09:02 <sethsimmons> I did, it wasn’t clear.
00:09:20 <binaryFate> true, it doesn't say -1 is unlimited. Though it can't be anything else :)
00:09:30 <selsta> -1 seems default
00:09:41 <sethsimmons> It’s... oddly written and handled
00:09:51 <sethsimmons> print_net_stats implies the default for up/down limits is enforced
00:10:19 <selsta> settings limit_down -1 inside monerod sets it to default
00:10:19 <sethsimmons> But the —limit-rate arg says its default is -1, which would imply unlimited.
00:11:03 <selsta> --limit-rate might be unset, but --limit-rate-down and --limit-rate-up are set
00:11:12 <selsta> that’s how I understand it
00:11:15 <sethsimmons> I had none of them set explicitly
00:11:26 <sethsimmons> But all three imply they have defaults that conflict in help
00:11:29 <mnt_grrrl> tevador, is 128 out a good idea
00:11:44 <sethsimmons> And print_net_stats implies that monerod is ignoring —limit-rate -1
00:11:45 <selsta> (=2048) means 2048 is set by default
00:12:01 <sethsimmons> Yes
00:12:18 <sethsimmons> But how can it be set to a limit and —limit-rate set to unlimited at the same time by default 🤔
00:13:30 <tevador> mnt_grrrl lower chance of getting eclipsed and I think it helps block/tx propagation; I've been running like this since before the attacks
00:14:06 <sethsimmons> Also increases the chance of connecting to an attacking node and increases your proportional load on the network.
00:14:22 <sethsimmons> Generally it’s recommended to keep out_peers at the default from most people I’ve talked to about it.
00:14:36 <sethsimmons> But I haven’t seen a detailed/in-depth breakdown of the clear risks/benefits.
00:14:44 <selsta> sethsimmons: it uses the lowest set limit
00:14:53 <selsta> --limit-rate 500 will mean up and down are 500
00:15:10 <selsta> ok no
00:15:20 <selsta> just set --limit-rate to a large number
00:16:01 <selsta> ./monerod --limit-rate 100000 works for example, print_net_stats show 100MB/s
00:17:31 <sethsimmons> Cool, I’ll just set that arg moving forward.
00:17:42 <sethsimmons> I just restarted with up/down set to 1GB/s
00:23:09 <agentpatience007> Do we still need to use block_tor.txt?
00:23:47 <selsta> for now, no
00:23:57 <selsta> you can use https://gui.xmr.pm/files/block.txt or no block list
00:28:00 <coffeeroaster> sech1: sysctl -w vm.nr_hugepages=2048 did the trick thanks!
00:29:37 <sethsimmons> You can also use —enable-dns-blocklist if you’d rather use that method/not pass a file.
02:49:37 <hyc> interesting, I actually have a fair numbero f outbound i2p and tor connections now
02:58:51 <mnt_grrrl2> hyc, outgoing tor are client or peers?
03:00:06 <hyc> I'm talking p2p
08:39:19 <M5M400> selsta: will using dns blocklist automatically refresh and reapply regularly, or only on daemon restart?
08:44:08 <p0nziph0ne> M5M400: good q
08:52:56 <sech1> M5M400 dns blocklist updates without restarts
08:54:07 <M5M400> nice
08:54:16 <M5M400> daily? hourly? on change?
08:54:25 <sech1> every 7000 seconds: https://github.com/monero-project/monero/blob/release-v0.17/src/p2p/net_node.h#L478
08:54:32 <M5M400> thx sech1
08:55:18 <sech1> FUK's nodes are stuck at blocks 2263958 and 2263960 :D
08:55:36 <M5M400> poor fuknodes
08:55:43 <sech1> I'm running without the blocklist and they're stuck, lol
08:57:26 <M5M400> updated my pub node and a couple pool nodes... let's see if this any good
08:57:28 <M5M400> :P
09:12:40 <hyc> nice
09:13:11 <hyc> tho, not sure why old nodes would be stuck. just means no real nodes will talk to them any more?
09:27:09 <sech1> I don't think everyone updated already
09:27:28 <sech1> Maybe it's a bug in the fake nodes
09:36:01 <mj-xmr> Thank you all for working on the release.
09:36:15 <rotten> <3
09:37:47 <mj-xmr> I'd hate to brag, but if fighting off attacks becomes a priority, I know a wide range of machine learning and signal processing methods (from advanced down to the simplest, not requiring 3rd party dependencies). This could help in creating a time series signal of the connections and detecting anomalies in an elegant and not hard-coded way.
09:39:08 <mj-xmr> See for instance here: https://scikit-learn.org/stable/modules/outlier_detection.html
09:39:35 <mj-xmr> Nowadays with the ML methods availability, the hard part is actually the data preparation.
09:41:03 <hyc> ML works after you have a good profile of good vs bad
09:41:14 <hyc> we don't really know what bad traffic looks like until we've seen a lot of it
09:41:26 <mj-xmr> The novelity detection takes care of that.
09:41:46 <hyc> it may be novel and legitimate though
09:41:46 <hyc> ?
09:41:59 <mj-xmr> It depends how you define it.
09:42:06 <hyc> yes, and that's the hard part
09:45:07 <mj-xmr> No ML method is 100% free of false positives and false negative detections. But you may damp (not entirely block) the traffic of those nodes who the system detects as novel. The hardcoded algos will on the other hand be 100% effective for the DEFINED rules, but may have  loopholes for the other ones.
09:46:05 <mj-xmr> Also, you can create a simulation of an attack, not only work on the live organism.
09:46:17 <mj-xmr> Think of it as an audit.
09:48:18 <mj-xmr> https://machinelearningmastery.com/confusion-matrix-machine-learning/
09:49:16 <mj-xmr> So much for theory. I still think that the hardest part is data preparation and creating a solid simulation.
09:49:23 <mj-xmr> (fuzzer style)
09:52:35 <mj-xmr> "we don't really know what bad traffic looks like until we've seen a lot of it"  -> apart from having the pre-trained ("off-line") model, the wallet could continously collect new data and update the model ("on-line training").
09:52:40 <mj-xmr> All doable.
10:13:16 <selsta> M5M400: you should wait with enable-dns-blocklist until the next release, seems there is a deadlock
10:13:55 <selsta> no one reported it yet but if you are unlucky your node could freeze
10:14:38 <selsta> but DNS block list does automatically refresh without restarting
10:20:51 <mj-xmr> I'll be back tomorrow. HNY!
10:45:58 <fhvusxzlg> Will you HODL XMR or dump it to buy Tari when it comes out?
10:55:08 <obnnheao> jess: I can tell you why you can't stop the 'spam'. You are thinking in cult doctrine. If it was real spam, and I was selling Viagra for example - you could easily ban keywords and urls. Instead, stop being a sheep, think like a cult leader. Recoginse that this 'spam' is just some bullshit that you tell to the sheep.
10:55:08 <obnnheao> When you do that, solution will present itself. Observe. 'spam' -> 'fireice_uk talks bad things about Monero on our IRC' (Don't say that out loud obviously, that will get you excommunicated) Solution? Get off-the-shelf sentiment analyser, detect anyone who 'talks bad things about Monero' and ban them.
11:07:27 <mfoolb> is it possible to limit max traffic for a public node on a daily/weekly/monthly average?
11:17:34 <dEBRUYNE> You can implicitly do it with the limit-rate / limit-up / limit-down flags I guess
11:21:03 <mfoolb> ok, I'll look into that
11:35:40 <Yonatan[m]1> Anyone has problems with broadcasting transactions?
11:35:58 <Yonatan[m]1> My transactions sometimes get stuck and I have to use relay_tx to get them through.
11:36:46 <dEBRUYNE> Yonatan[m]1: which version are you running?
11:36:53 <Yonatan[m]1> I also get a "unable to send transaction(s) over tor - no suitable outbound connections at height (block height)" often
11:37:16 <Yonatan[m]1> <dEBRUYNE "Yonatan: which version are you r"> Latest 0.17.1.8 - Oxygen Orion
11:38:15 <Yonatan[m]1> CLI
11:39:01 <Yonatan[m]1> > <@freenode_dEBRUYNE:matrix.org> Yonatan: which version are you running?
11:39:01 <Yonatan[m]1>  * Latest: 0.17.1.8 - Oxygen Orion
11:40:31 <Yonatan[m]1> My args are: --enable-dns-blocklist --tx-proxy tor,127.0.0.1:9050 --rpc-bind-ip (IP) --rpc-bind-port 18081 --confirm-external-bind --restricted-rpc
11:41:53 <Yonatan[m]1>  * I also get a "unable to send transaction(s) over tor - no suitable outbound connections at height (block height)" error often
11:42:34 <hyc> that's quite common
11:42:55 <Yonatan[m]1> <hyc "that's quite common"> Any way I could mitigate this?
11:43:00 <Yonatan[m]1> This is getting rather annoying.
11:43:44 <hyc> haven't seen any reliable way yet, no
11:43:55 <hyc> txns are still being broadcast over clearnet tho
11:44:25 <Yonatan[m]1> Should I just disable Tor then?
11:44:39 <Yonatan[m]1> It's not that critical but I prefer it on rather than off
11:44:43 <hyc> why? leave it up, eventually some conns will settle down
11:46:10 <Yonatan[m]1> I haven't had that issue before the attacks started happening.
11:56:53 <binaryFate> Maybe because lot of people were/are still blocking tor nodes (as mitigation to attack). With new version helping against attack, they might unblock them
12:16:27 <Yonatan[m]1> My Monero node just crashed
12:16:37 <Yonatan[m]1> New attack maybe?
12:16:53 <Yonatan[m]1> [batch] DB resize needed and then a crash
12:18:48 <Yonatan[m]1> <binaryFate "Maybe because lot of people were"> So I would have to turn off Tor?
12:50:44 <tevador> FYI, if your node keeps crashing with OOM, ban TOR exit nodes
12:50:51 <tevador> there is a new attack
12:51:33 <dEBRUYNE> tevador: Can you elaborate on the new variant?
12:53:57 <M5M400> sigh
12:58:04 <sethsimmons> Welp...
12:59:44 <sethsimmons> No issues here with OOM attack, but I’m running with DNSBL
12:59:59 <sethsimmons> I’ll get alerts the moment it happens to my node so I’ll report back if I do run into issues.
13:01:52 <Inge-> 5 hours since I had a "Synchronized OK" entry in my log (0.17.1.7 with regular blocklist)
13:31:04 <sethsimmons> New stacktrace: https://paste.debian.net/1179142/
13:31:26 <sethsimmons> Running without issues other than that, this one doesnt seem RandomX related and I’ve bumped my huge pages up to what I’ve seen recommended.
14:02:48 <Lyza> <binaryFate> that doesn't make since, relaying transactions over tor doesn't use exit nodes
14:03:22 <Lyza> <Yonatan[m]1> try adding some tor peers with --add-priority-node which will cause the daemon to attempt to always maintain a conenction to those nodes. hacky but will actually make tor / i2p relays more reliable
14:11:33 <YourFutureMiner> jess: I can tell you why you can't stop the 'spam'. You are thinking in cult doctrine. If it was real spam, and I was selling Viagra for example - you could easily ban keywords and urls. Instead, stop being a sheep, think like a cult leader. Recoginse that this 'spam' is just some bullshit that you tell to the sheep.
14:15:59 <netrik182[m]> I'm running monerod using this https://github.com/monero-project/monero/blob/master/contrib/tor/monero-over-tor.sh#L69 and --enable-dns-blocklist and still got a dozen "Unable to send transaction)s) to tor" in the last ~12 hours
14:16:35 <selsta> enable-dns-blocklist is not related to this
14:20:43 <Lyza> a dozen in 12 hours is pretty normal even using priority nodes
14:25:11 <Lyza> I've got 16 such messages in 12 hours using i2p with like 4 or 5 priority nodes. The good news is it prints those messages any time all the connections drop, even if it's just for a second or two, so at least in my case it's still pretty reliable despite how often that message is printed
14:25:28 <Lyza> <netrik182[m]> ^^
14:26:25 <Lyza> there's also a github issue if u want to follow, #6631
14:27:38 <netrik182[m]> Lyza: good to know, thanks. I thought my setup could be missing some config as I'm not well versed in tor/networking
14:28:27 <Lyza> you could always add a couple more priority nodes to the script, or use both i2p and tor
14:28:51 <netrik182[m]> <Lyza> there's also a github issue if u want to follow, #6631 << will follow
14:35:05 <Yonatan[m]1> My node was crashed again, I have enable-dns-blocklist on
14:36:30 <selsta> --ban-list with https://gui.xmr.pm/files/block_tor.txt
14:36:40 <sethsimmons> OOM or something new Yonatan?
14:36:49 <selsta> not sure if it is a good idea to add tor nodes to DNS block list
14:36:58 <Yonatan[m]1> OOM
14:37:12 <Yonatan[m]1> Something slipped through
14:37:14 <selsta> it’s a different attack than previosuly
14:37:41 <Yonatan[m]1> Not sure about that
14:37:48 <Yonatan[m]1> Something must've slipped through
14:38:27 <selsta> from logs it does not seem like the same attack
14:39:01 <Yonatan[m]1> Shouldn't the latest version fix the OOM bug?
14:40:13 <sethsimmons> It fixed the known attack vector that causes it.
14:40:23 <sethsimmons> This is using a new attack vector apparently, but same end DoS result.
14:41:20 <Yonatan[m]1> I hope the attacks wouldn't last long
14:43:50 <Lyza> cool I just saw one start in my node in real time when I opened htop
14:49:26 <Lyza> lmk if I should collect logs and what log info would be good or if I should just block these chuds. sounds like u might have what u need
14:56:52 <mfoolb> anyone can explain this: 020-12-31 14:56:10.682I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 2264332
14:59:03 <moneromooo> At the time stated, a block was finished processing as the height stated, not on the main chain.
15:01:38 <mfoolb> I have 66% of connected peers in synchronizing state and has been so for a couple of hours, it is ok?
15:02:48 <selsta> yes, you can ignore it
15:17:01 <Yonatan[m]1> How can I make monerod restart automatically after a crash?
15:17:18 <sethsimmons> Are you running it as a service or via Docker?
15:17:27 <sethsimmons> The example systemd script will automatically restart after a crash.
15:17:37 <Yonatan[m]1> I just run it using ./monerod
15:17:38 <selsta> Yonatan[m]1: did you add the Tor ban list again?
15:17:53 <Yonatan[m]1> <selsta "Yonatan: did you add the Tor ban"> Will do.
15:18:12 <selsta> with that it should rarely crash
15:19:40 <Yonatan[m]1> Done
15:19:56 <Yonatan[m]1> but how can I make it restart automatically if it crashes?
15:20:16 <selsta> maybe sethsimmons can explain
15:21:15 <sethsimmons> <Yonatan[m]1 "but how can I make it restart au"> How are you running the node now?
15:21:29 <Yonatan[m]1> <sethsimmons "How are you running the node now"> Just running ./monerod
15:21:38 <Yonatan[m]1> and detaching it
15:21:43 <sethsimmons> On Linux?
15:21:46 <Yonatan[m]1> Yeah
15:21:55 <sethsimmons> Ok let’s go to DMs.
15:30:26 <Mmmmmmmmmm> If I'm running a full node, and I submit the Prune Blockchain command to the Json RPC, and I'm running a full node, it'll start the pruning process, and return when it's done?
15:30:28 <Mmmmmmmmmm> https://github.com/monero-project/monero/blob/master/src/rpc/core_rpc_server_commands_defs.h#L2548
15:30:42 <Mmmmmmmmmm> Also what is the `bool check` variable there?
15:32:00 <Mmmmmmmmmm> Couldn't find that command in the documentation, but found it under the JsonRpc section of https://github.com/monero-project/monero/blob/master/src/rpc/core_rpc_server.h
15:36:24 <selsta> there is a check pruned status command
15:36:33 <selsta> bool check might be related to that
15:37:07 <Mmmmmmmmmm> What does the check do?
15:38:16 <selsta> Check if the blockchain is pruned I assume
15:39:15 <Mmmmmmmmmm> So why is it false by default?
15:42:55 <moneromooo> You really don't want to prune a synced chain. Resyncing will be much faster.
15:43:21 <moneromooo> I suspect pruning a full chain would need doing it in stages, but it's more time I want to spend on it.
15:43:56 <Mmmmmmmmmm> So resynching in pruned-mode is better than pruning a synched chain, is that right?
15:44:03 <Mmmmmmmmmm> Maybe I should just not support this RPC command?
18:45:41 <agentpatience> I have a question for the devs... I started solo mining to my own node and within 2 weeks with only 20k/h I was able to discover a block. I put all my racks  mining to the node to gather round 230 K/h per second in 2 weeks I found nothing. Was it just luck of the draw or am I doing something wrong?
18:46:35 <sech1> <monerobux> At 20000 h/s with network diff of 2.25e+11 your expected time for find a block is 1.12e+07 s or 130.09 days
18:46:52 <moneromooo> You will need.... wait for it..... patience.
18:47:11 <sech1> <monerobux> At 230000 h/s with network diff of 2.25e+11 your expected time for find a block is 9.77e+05 s or 11.31 days.
18:47:11 <moneromooo> Thanks for helping the network, that block might have prevented a 51% attack from succeeding.
18:49:18 <sech1> Your time to find a block can be 1% of expected time or it can be 700-1000% if you're especially unlucky.
18:50:26 <ndorf> agentpatience: we make your first block real easy, just to get you hooked.
18:50:46 <agentpatience> The idea of running my own node to support the project seems like a no brainer to me. Its the only way the system will survive in the future? One must think about the future, when the ROI on mining becomes much lower it will prevent manay people from running thier own nodes? not like now, where there is incentive, but what happens when much of the incentive is gone?
18:51:35 <moneromooo> There's a misunderstanding. Running a node doesn't force to to mine.
18:51:46 <agentpatience> ndorf... i thought there might be some kind of trickery going on with beginners luck
18:52:59 <moneromooo> If you meant "if there's no money in it anymore, who's gonna mine", then noone will (ie, if the exhcange rate goes to zero).
18:53:03 <agentpatience> I realize this Moneromoo... I am not using the built in mining tool for the node... i mine with xmrig instead... is there any problem with that? also - I wanted to ask if there is any good reason to compile wallet from source instead of uning precompiled linux bins?
18:53:15 <moneromooo> No problem with that.
18:53:58 <moneromooo> Building your own is just good habit I guess. Protects against the builder of precompiled ones being an attacker.
18:54:11 <moneromooo> Though reproducible builds have make this harder to pull off.
18:54:17 <ndorf> agentpatience: i'm just kidding, of course. there's no trickery, you just got lucky. hope it keeps up :)
18:54:30 <moneromooo> You do become more vulnerable to your compiler being backdoored, but if that happens, everyhting else probably also is.
18:54:49 <moneromooo> Do check the GPG signatures on the git commit you use though.
18:55:34 <moneromooo> Now, git's still not super great against high end attacks IIRC, but that can also go thorugh a hgonest builder anyway so you don't lose anything there.
19:02:54 <agentpatience> when i look at all my miners it looks like they are all doing the same work on the same or similar block heights, is that normal?
19:05:51 <ndorf> well they should all be on the same block height -- the current one
19:13:24 <agentpatience> I am bringing down all my systems for a update right now my node is in a Dell VRTX a 2695 V4 that mines to itself then I have 3 other 2695 v4's that mine to that on top of this I have a M1000E 16x 2690 v2 mining to that node via xmrig. I have 2 prototype E7 quad processor rigs which are going down for updates as soon as Vertex is updated
19:15:58 <gingeropolous> agentpatience, im curious, do you have a single node as the primary daemon, and on the other machines, your pointing xmrig to that single node?
19:16:58 <agentpatience> How do I post photos here? -- Ginger to answer your question I just have a single node Daemon on my VERTEX slot 1 which is a 2695 v4
19:17:43 <agentpatience> all the other guys run xmrig only and mine to that one node.
19:28:54 <agentpatience> I heard there is another way to monitize my systems using this RPC thing, can anyone explain to me in simple terms if it is feasable or useful for my situation?
19:37:34 <moneromooo> It's a system that allows you to require others to prove they mine to your address.
19:37:49 <moneromooo> You can then require such proof before giving access to a service.
19:38:01 <moneromooo> The builtin service is RPC access to monerod.
19:38:40 <moneromooo> Primo (software) uses this for web server access (ie, mine to an address the  web server gives you, see the pages when you proved doing so).
19:38:56 <moneromooo> It's theoretically usable for anything "paywally".
19:48:29 <agentpatience> lol Paywally, is it related to the monero project?
19:50:14 <netrik182[m]> paywally in the sense that anything that can be put behind a paywall
19:50:34 <netrik182[m]> news, for exemple
19:50:44 <agentpatience> PRIMO is a computer software that simulates clinical linear accelerators (linacs) and estimates absorbed dose distributions in phantoms and computerized tomographies.
19:50:57 <agentpatience> oh ffs
19:51:00 <moneromooo> Right. If paywally is some software, it's just a name collision.
19:51:27 <moneromooo> Primo is https://repo.getmonero.org/selene/primo
19:55:31 <agentpatience> I just don'
19:55:38 <agentpatience> I just don't get it
19:55:54 <agentpatience> what use is this, ven if it is marketed properly?
19:56:12 <agentpatience> hardly anyone in the camps i visit can even explain this stuff
19:57:42 <agentpatience> If someone is maintaining node they are doing more work than just mining maybe RPC should be intergrated in that? It seems we need kickbacks for futures in Monero, where theres inventive to at least if mining goes to shit to run a node?
19:58:44 <agentpatience> incentive and minig won't be the same in 5 years.
19:59:35 <moneromooo> Either I got drunk *fast* or this is hard to understand.
20:00:04 <agentpatience> The AMD 8000X will be out and will do roughly 100 K/h  sec on its own!
20:00:05 <agentpatience> lol
20:00:49 <agentpatience> sorry my new years eve beers may have screwed with my grammer and spelling lol
20:02:33 <agentpatience> I guess I still don't understand the functionality of RPC with monero wallet or with the daemon. If I made your hash and proved your data is correct with the team in the network, that is what it is saying?
20:04:11 <ndorf> the wallet needs to use the daemon, via RPC, to scan for incoming transactions and transmit outgoing ones.
20:05:15 <selsta> .merge+ 7244 7243
20:05:15 <xmr-pr> Added
20:06:35 <ndorf> if you don't have your own daemon, you can use a public one, which has the option of charging you for this service in the form of mining
20:12:30 <agentpatience> ahh, that sounds cool
21:19:10 <selsta> .merge+ 7237 7239
21:19:10 <xmr-pr> Added
21:21:17 <Snipa> .merges
21:21:17 -xmr-pr- 7237 7239 7243 7244