01:59:41 <endor00[m]> "dixie__flatline" (https://matrix.to/#/@dixie__flatline:halogen.city) we all had to start somewhere
03:37:58 <doktoro> quit
05:06:32 <jbg> I have a node which can't receive incoming connections due to having an external IP that differs from the IP it makes outgoing connections on. I'm working on a patch for issue 5979 which will resolve this, but is there any workaround in the meantime for maintaining sync?
05:07:10 <jbg> for example, can i manually tell the daemon to make outgoing connections to certain peers, or manually publish its external IP somewhere for other peers to find?
05:07:48 <ndorf> i think there was something on github recently, about the latter (manually specify external IP)
05:07:57 <jbg> yeah, issue 5979?
05:08:11 <jbg> there's no way to do it at the moment but i'm working on a patch
05:08:27 <jbg> just wondering if i can do something to stop my node from having no connections in the meantime
05:08:37 <jbg> for some reason it doesn't make many outgoing connections, even though the limit is high
05:08:46 <jbg> and since it has no inbound connections, it loses sync
05:09:55 <ndorf> that's interesting
05:10:54 <ndorf> have you given it enough time to find enough peers?
05:13:36 <jbg> it's been up for 5 days or so
05:13:41 <jbg> it occasionally gets one connection
05:13:43 <jbg> for a while
05:14:14 <jbg> it vaguely keeps up with the network, as in, at least once a day it is up-to-date
05:14:32 <jbg> but there are long periods where it has 0 peers and falls behind
05:14:51 <ndorf> that seems strange, like maybe you have something else going on that's preventing you from making those connections
05:15:14 <jbg> maybe. i mean, it's deployed in a production kubernetes cluster, no other services in the same cluster have any issues
05:15:55 <jbg> i've shelled into the container and tested connectivity, i can connect out on tcp/18080 without any issues
05:16:53 <jbg> is `--out-peers -1` appropriate for unlimited outbound peers or does it not work the same way as inbound peers?
05:17:04 <jbg> maybe it's being interpreted as `1` somehow?
05:17:21 <ndorf> try something else, like 96
05:17:25 <jbg> yeah will try
05:17:45 <ndorf> i just fired up a new daemon without an incoming port, and it found 8 peers and started syncing at 200Mbit+/sec in less than a minute
05:21:03 <jbg> syncing worked perfectly initially, and was very fast, it's only since it caught up to the network the first time that i've had this issue
05:21:42 <jbg> i changed the -1 to 96, will observe
05:22:05 <ndorf> if that fails maybe trying the default, 8, is worth it too
05:22:56 <jbg> 8 should generally be enough anyway, right?
05:23:33 <ndorf> probably. i always have incoming, so i don't know for sure
05:23:55 <ndorf> but if there is some weird bug related to that setting, it maybe could go undiscovered for a while, since most people probably don't change the default
05:24:17 <jbg> yeah, makes sense
07:43:50 <Adreik> Suppose you have outputs in two different wallets and, for whatever reason (maybe they are almost dust) want to construct a transaction that uses outputs across the wallets. Is there any way to import the output private key (i.e. x = Hs(aR) + b) and it's associated output into another wallet in order to do this?
11:32:37 <moneromooo> jbg: try removing p2pstate.bin, you might have only attack peers in your list (which only tell you about peers in their list).
15:56:05 <fort3hlulz_> testerino
15:56:11 <fort3hlulz_> test
15:56:21 <asymptotically> test failed
15:56:34 <fort3hlulz_> perfect :D
15:56:48 <fort3hlulz> better test
15:57:06 <fort3hlulz> betterer test
15:57:10 <fort3hlulz> .xmr
16:17:40 <Lovejmwi1> can someone donate me crypto?
16:20:30 <xmrmatterbridge> <rbrunner7> Lovejmwi1, I could send you testnet XMR if you want to try out wallets
16:21:42 <Lovejmwi1> is that not real crypto?
16:22:24 <xmrmatterbridge> <rbrunner7> What is real, what is only fantasy? :) Anyway, testnet coins don't have any value
16:42:06 <TrasherDK> I have some stagenet XMR. They are double value of testnet XMR.
16:52:47 <xmrmatterbridge> <rbrunner7> Psssst, TrasherDK, wanna try this scheme together with me: https://rbrunner7.github.io/consensus.html
17:11:58 <TrasherDK> rbrunner7 Yeah. I read that one a long time ago. Good one :)
17:15:28 <xmrmatterbridge> <rbrunner7> Thanks!
17:56:12 <Lovejmwi1> Hi
18:34:57 <lza_menace> is it bad form to expose "get_connections" JSON RPC calls to the public web?
18:40:28 <fort3hlulz> Thats only available via an unrestriced RPC, correct?
18:41:13 <lza_menace> yes
18:41:50 <fort3hlulz> I mean I would say its bad form to expose any unrestricted RPC
18:42:04 <fort3hlulz> Especially since it allows all kinds of things, including mining to someone else's addresses
18:42:19 <fort3hlulz> Should only expose restricted RPC externally
18:43:09 <fort3hlulz> using something like this in your command line: --public-node --rpc-bind-ip 0.0.0.0 --rpc-restricted-bind-port 18089 --confirm-external-bind
18:43:30 <fort3hlulz> and then just port forward to the restricted port, not the unrestricted one
18:44:17 <lza_menace> im guessing recreating something like this would be done within private networks and updating something that is external: https://monerohash.com/nodes-distribution.html
18:44:36 <lza_menace> like they're just scraping an internal, unrestricted daemon and then storing results in a DB
21:02:07 <d4ndo[m]> Posted on reddit: https://www.monerooutreach.org/stories/monero-paper-wallet.html
22:26:27 <rajesh_73[m]1> Hi