00:00:01 <sech1> I mean something like https://en.wikipedia.org/wiki/Introduction_to_Algorithms
00:00:06 <sech1> in a form of university course
00:00:24 <sech1> and Knuth's TAOCP
00:01:07 <aum> xmrpow the wonderful thing about Java is it feels so good when you move on to a freer, less "choking tie, starch shirt and tight suit" language :)
00:01:46 <aum> for myself, I can't stand Java for actual development; its red tape slows down the thinking terribly
00:01:49 <xmrpow> sech1: I dont know this specific book, but we talked about the efficiency of datastructures and things like standard sorting algos.
00:02:43 <sech1> We used Pascal and later Assembler for as languages for learning. Pascal was nice learning language for its strict grammar and type checking, Assembler was good for learning low level
00:02:54 <sech1> and data structures/algorithms to learn programming in general
00:02:57 <sech1> good combo
00:03:09 <xmrpow> so you studied computer science right?
00:03:33 <sech1> yes, in university
00:06:10 <ocb> hmmm something is wrong
00:07:48 <xmrpow> sech1:  When I started with computer science we had to learn haskell :-D
00:08:26 <ocb> something is really wrong. starting monerod with 0.17.1.5 docker image 18081 is open to local, however when started with 0.17.1.7 image same config .. 18081 does not open ...
00:09:52 <selsta> ocb: rpc?
00:10:28 <selsta> look into --rpc-restricted-bind-ip
00:10:41 <ocb> yep rpc
00:10:48 <selsta> by default restricted rpc binds on 127.0.0.1 now
00:11:34 <xmrpow> sech1: Could you recommend some  other good computer science books, which are worth to read?
00:12:08 <sech1> Start with https://en.wikipedia.org/wiki/Introduction_to_Algorithms
00:12:14 <sech1> that one is a huge fat book
00:12:16 <ocb> yep, rpc-bind-ip=172.x.x.x rpc-bind-port=18089 rpc-restricted-bind-port=18081 confirm-external-bind=1 restricted-rpc=1 .. with 0.17.1.5 i can see the 18081 is open, but with 0.17.1.7 same config 18081 is c losed
00:14:10 <xmrpow> sech1: Ok thanks, I gonna give it a try. Im sure it is not that complicated like these german study books. Germans normally make things more complicate than they are in reality;)
00:16:52 <selsta> ocb: yes, add --rpc-restricted-bind-ip 172.x.x.x
00:18:11 <ocb> selsta: when was this introduced, between 0.17.1.5 and 0.17.1.7 ?
00:20:17 <ocb> selsta: thank you. back on the road.
00:20:34 <selsta> https://github.com/monero-project/monero/releases/tag/v0.17.1.6
00:20:45 <selsta> we did not intentionally break backwards compatibility
00:20:57 <selsta> but new behavior makes more sense
00:21:17 <selsta> now you can bind unrestricted to e.g. local and don't have to worry about firewall
00:21:22 <ocb> selsta: it does, i wondered earlier why there isn't such an option and was confused with rpc-bind-restricted
00:22:10 <ocb> i planned to make building auto, but now.. think i'll just leave it on manual or it will require manual checks.
00:22:16 <ocb> thanks for the help!!
00:22:44 <ocb> s/manual/multiple/
00:39:04 <ocb> selsta: i wondered for a moment, could the same people be behind attacks on electrumx servers (mainly btc) and on monero. whoever it is, they keep hitting but in the case of electrumx they are using client vulnerability to scam coins
00:39:44 <selsta> unlikely the same people
00:40:03 <selsta> our attacker is monero focused and mostly cares about annoying users
00:41:03 <ocb> i see you are probably right. i didn't even know until now about ongoing monero attacks. maybe my ip was low in their list :)
00:41:11 <ocb> have a good day /away
02:00:04 <viperperidot[m]> What is the correct current block height?
02:00:28 <viperperidot[m]> Not sure if my node is under attack right now or not
02:00:39 <selsta> 2260297
02:00:43 <nioc> 2260297
02:01:58 <selsta> w0w
02:02:25 <nioc> u faster than a bot :)
02:11:51 <ocb> lol
02:12:59 <viperperidot[m]> Ok thanks looks like im good
02:13:13 <viperperidot[m]> Is there a way to know that your block height is correct?
02:13:20 <selsta> xmrchain.net
05:49:01 <cryptorchist> Wishing you guys the best in fighting against the attack. Happy holidays!
07:57:53 <nodlr> phew. finally updated monerod and applied banlist
07:58:06 <nodlr> Was reading the /r/monero and looked like my monerod got killed
07:58:18 <nodlr> bastards >:O
10:19:15 <moneroist> No remote node will get my view key until I set up node as trusted right?
10:29:44 <hyc> node never gets your key
10:30:39 <moneroist> I was guessing about it, but then what is trusted daemon option?
10:32:31 <hyc> the daemon will see transactions you create
10:35:35 <moneroist> what benefits then are?
10:37:11 <hyc> on an untrusted node, the wallet will ask for blocks around the height it wants
10:37:18 <hyc> to obscure which one is the block of interest
10:37:27 <hyc> on trusted node, it will ask for exactly the block it wants
10:37:38 <hyc> so trusted node will be more efficient
10:38:14 <hyc> on a trusted node, the wallet can turn mining on and off. untrusted node can't.
10:38:20 <hyc> various other stuff
10:39:09 <moneroist> ok thanks for explain :)
10:41:34 <ask6155> hello
10:43:03 <ask6155> I'm in the process of syncing pruned monero blockchain. The syncing was going pretty fast till 50% after which it has slowed down to a crawl.
10:43:03 <ask6155> Why is that?
10:43:33 <hyc> the early blockchain was mostly empty blocks
10:43:52 <ask6155> huh?
10:44:07 <hyc> not many transactions were happening early in monero's life
10:44:28 <hyc> the latter half of the blockchain has a lot more activity, more volume
10:44:34 <ask6155> how long is it supossed to take to sync a pruned blockchain?
10:44:45 <hyc> and also heavier crypto algorithms, so more CPU-intensive to verify
10:45:33 <ask6155> how can I increase the syncing speed?
10:46:01 <hyc> hard to say. dunno what's bottlenecking for you - network, CPU, or disk
10:46:31 <ask6155> I have 20mbps, 2 cores and a rotating disk.
10:47:29 <hyc> probably disk is too slow
10:47:42 <hyc> but you should check a performance monitor to see what's busy
10:48:34 <moneroist> rotating disk is a biggest bottleneck
10:49:32 <moneroist> with SSD sync is finished something about 12h as I remember, with HDD it is something about couple days maybe week
10:50:54 <ask6155> cpu is at 60%, internet usage is not capping at all (at about 200KBps) I think it is the hardrive. ;(
10:51:14 <hyc> how much RAM have you got? running windows or linux?
10:51:28 <ask6155> linux. I have 4GB
10:52:06 <hyc> you can tweak the OS a little to use RAM more aggressively
10:52:13 <hyc> in /proc/sys/vm
10:52:44 <hyc> echo 90 > dirty_ratio
10:52:50 <hyc> echo 60 > dirty_background_ratio
10:53:00 <hyc> echo 60000 > dirty_expire_centisecs
10:53:14 <hyc> then run monerod with --db-sync-mode fast:async
10:53:23 <hyc> or fast:async:10000
10:54:06 <hyc> oh, and also echo 0 > swappinessappiness
10:54:23 <hyc>  ... echo 0 > /proc/sys/vm/swappiness
10:55:26 <hyc> that will leave data cached in RAM for up to 10 minutes, default is only 30 seconds
10:55:39 <hyc> greater caching will lighten load on the HDD
10:56:34 <hyc> if you have a system crash, you may lose more data, so don't do this if you have unstable power or other shaky environment
11:04:01 <moneroist> hyc maybe do you know hot to read mdb files on linux?
11:04:20 <moneroist> I was try using mdb-tools
11:04:33 <moneroist> but with mdb-parsecsv there is core dumped :?
11:10:03 <hyc> there's no csv data in the blockchain db
11:10:57 <hyc> mdb-tools is for M$ Access db files. monero uses LMDB
11:13:26 <moneroist> uhh you are right I forgot about it
11:15:03 <moneroist> ok so even when it is lmdb how to open/read this on linux?
11:15:24 <kloinka> Is there a bug/attack on latest monerod? The service seems to be using excessive memory.
11:16:42 <moneroist> I see there is lmdb in linux apt but can not install it
11:17:48 <moneroist> I will only open/read lmdb database with python?
11:20:43 <Mochi101> kloinka, yes
11:23:52 <kloinka> Thought so , thanks...I tried  --limit-rate and --in-peers paramus but didnt help.
11:24:44 <moneroist> on reddit you have post with recipe how to prevent but it is hotfix
11:24:51 <kic0> use --ban-list
11:26:13 <ask6155> I think there's still some problem. After doing all what you said. I still at 50% and it says estimated time to finish is 1 month!
11:36:56 <asok> a node with 64 GB ram crashed, but another one with 256 GB survived
11:37:47 <asok> does anyone know how many nodes were taken down?
11:37:58 <asok> (approx.)
11:41:03 <Jaska_> by whom and when?
11:41:47 <asok> ref: topic
11:43:09 <kic0> is this on v017 release or master only? https://github.com/monero-project/monero/pull/7138
12:12:19 <moneroist> how to prepare transfer for submit by rpc wallet? there are methods transfer, submit_transfer, sign_transfer what is the flow? I would like to get preinformation before send tx like fee and so on
12:13:37 <binaryFate> moneroist: see https://www.getmonero.org/resources/developer-guides/wallet-rpc.html#relay_tx
12:14:19 <binaryFate> first you create it with 'do_not_relay' set to true, and store the hex result. You can then relay the hex transaction after doing your checks
12:22:59 <moneroist> @binaryF
12:23:08 <moneroist> binaryFate oohh I see it, thanks!
12:31:25 <kloinka> Thanks Mochi101, --ban- list worked a charm! 😁
12:46:57 <kloinka> Spoke too early...service fails after a short time.
12:50:11 <vekin> I've had it up for over 24 hours with the new banlist but its using 17.7G of ram D:
12:51:07 <vekin> 23h cpu time too which seems a bit high
12:54:02 <sech1> 8G ram used after 3 hours on my node, tor ban list helps but not entirely
13:09:53 <kico> https://downloadmoreram.com/
13:09:56 <kico> :P
13:10:27 <LyzaL> selsta new candidates for the block list https://paste.debian.net/1178369/
13:11:34 <kico> https://github.com/kic0/Monero-nodejs-pool-daemon-monitor/blob/master/checkheight.py
13:11:49 <kico> if anyone wants a script to see if node is synced
13:11:51 <LyzaL> vekin, kloinka, have you tried https://gui.xmr.pm/files/block_tor_new.txt ?
13:11:56 <kico> not optimal but it works
13:12:38 <LyzaL> that file should include some tor exit nodes that aren't in block_tor.txt
13:15:32 <LyzaL> kloinka not sure if you caught my last message before disconnecting but have you tried this list? https://gui.xmr.pm/files/block_tor_new.txt
13:16:00 <LyzaL> contains additional tor exit nodes, may help with the memory issues
13:25:24 <vekin> LyzaL: yeah i've been using it and it lets me keep my node up longer but I'll have to wait for the real fix, I saw some patches on github but they aren't commited yet
13:25:57 <LyzaL> guess I'm lucky so far
13:26:33 <LyzaL> I have a little script that bans node displaying the +2 issue but I think the nodes causing oom crashes aren't doing the +2 thing
13:26:40 <vekin> I have an increased number of allowed incomming connections and good bandwidth so the problem is probably made worse by that
13:26:52 <vekin> i don't get the +2 issue any longer with the block list
13:27:08 <LyzaL> cool, I wasn't either but I just found some that aren't on the list yet
13:29:26 <vekin> i do get the synchronized ok messages extremely frequently though, probably around 1 per second
13:36:02 <d3cker> hello, @vekin unfortunately I have the +2 issue with ban list. It occured after few hours. OOM not showing on build from last night (so far). Has anyone tried PR with --enable-dns-blocklist feature?
13:37:02 <kico> i tried but seems to be only included in master ?
13:37:17 <vekin> I don't think any of the oom/cpu/bad peer handling is merged yet, the last commit was 7 days ago
13:37:41 <d3cker> so it's placebo effect then
13:37:45 <kico> ye
13:37:47 <kico> lol
13:38:30 <vekin> it hasn't been very long though they are moving really fast already
13:40:41 <kico> .git push
13:43:13 <kico> if one updates block.txt the node is using do the changes get picked up by it ?
13:44:26 <vekin> i think you have to restart monerod and reload the blocklist
13:44:44 <kico> yeah that's what I thought thanks for confirming
13:46:32 <LyzaL> kico I made a little script to update the ban list without restarting https://paste.debian.net/1178373/
13:46:53 <LyzaL> also here is one that does some rough detection of nodes causing the +2 issue https://paste.debian.net/1178372/
13:47:18 <kico> naisu! thanks!
13:47:32 <LyzaL> for the second one you'll have to change the monerod path if you use it
13:47:49 <kico> sure I can see /path/to/monerod
13:48:00 <kico> thanks! this helps :)
13:48:05 <LyzaL> you bet
14:22:46 <selsta> LyzaL: do you run my block list?
14:23:14 <LyzaL> selsta I do
14:23:21 <LyzaL> were some of those IPs already on it?
14:23:24 <selsta> yes
14:23:28 <LyzaL> hmmmm
14:24:54 <selsta> 159.65.173.58 is a new one
14:25:27 <selsta> can you double check?
14:26:10 <LyzaL> double check what, that I'm using the list?
14:26:28 <selsta> 14:10 <LyzaL> selsta new candidates for the block list https://paste.debian.net/1178369/
14:26:29 <LyzaL> 159.65.173.58 is on block_tor.txt
14:26:36 <selsta> yes I added it 1 sec ago :D
14:26:39 <LyzaL> haha ok
14:27:03 <LyzaL> I've been banning them manually, so Ig let me restart monerod and see what happens
14:54:29 <h2017> my node died at least once in the night. i noticed that the ban list has been updated again with 6 new entries. I have applied the new ban list. I hope that helps
14:55:40 <selsta> the problem is my list does not include tor relays with exit policy for 18080
14:55:50 <selsta> https://gui.xmr.pm/files/block_tor_new.txt is a more complete list but might also contain false positives
14:56:12 <h2017> ok i'll keep it in mind
14:58:39 <h2017> i don't know anything about the release schedule, so forgive this question. Does anyone have any kind of back of the envelope estimate of when fixes might arrive in a production release?
14:59:29 <selsta> everything is on Github now https://github.com/monero-project/monero/pulls
14:59:45 <h2017> would it be worth it for me to compile from git?
15:00:07 <h2017> as someone who's willing to do it but it goes outside my comfort zone a bit
15:00:33 <selsta> we hopefully have a release out in 24-48h
15:03:11 <agentpatience> Can we just hve one banlist, no there are 3?
15:03:16 <agentpatience> now
15:04:59 <Jaska_> just keep banning them manually
15:05:04 <Jaska_> list will be old after few hours
15:23:00 <anchor[m]> Damn, are we banning tor nodes now
15:23:21 <selsta> only exit nodes, and also only temporary
15:23:34 <selsta> you can still use monero with tor using --tx-proxy
15:28:09 <kico> .onions should not be affected by the ban list?
15:28:15 <selsta> yep
15:28:19 <kico> makes sense
18:15:19 <sugaring[m]> What stops the sender from spending the receivers output. I don't see a signature on the transaction. Only one is the RingCT signatures.
18:35:35 <mfoolb> I've just read a reddit post on r/monero asking to start a public node.. while I really agree on supporting monero, I think that some kind of disclaimer from a security perspectvice should be needed (most of the comments I read are from guys trying to use their home pc)
18:38:30 <selsta> mfoolb: we have this here https://github.com/monero-project/monero#socket-based
18:40:12 <sugaring[m]> When do I prove ownership of an output I own? Would this happen in the ring signature?
18:41:06 <mfoolb> selsta: I was referring specifically to the reddit post..  considering the levels of the comment I highly doubt that they are all aware of the security concern.. I thought that some of the moderator could add something about it.. even this link you gave (maybe with the 'this is a must' in bold too)
18:42:02 <sech1> sugaring you can spend an output only if you have a private spend key for this output, it's not related to ring signatures
18:43:20 <sugaring[m]> Whoever has the address’s key owns the output. But what stops the sender from referencing my output as the one to be spent. Where does the ownership happen?
18:44:58 <moneromooo> The sender does not know the output's secret key. It needs the receiver's secret spend key to derive.
18:45:47 <moneromooo> But the sender can reference that output in another tx, 10/11 are outputs not necessarily owned by the sender,
18:47:47 <sugaring[m]> I understand that part. The sender knows the value and the blind to the Pedersen commitment. Can't he just rebuild it his side and spend the output?
18:48:43 <h2017> how does more public nodes strengthen the network. fluffypony said to just run a node open for p2p (which I'm doing)
18:49:05 <h2017> this is about the r/monero thread asking for more public nodes
18:49:07 <dEBRUYNE> mfoolb: I suppose I can write a comment and sticky it
18:49:10 <dEBRUYNE> What do you expect to be there?
18:50:38 <mfoolb> dEBRUYNE: Well, first of all thanks. I thought it could be useful to explain that it is better to use a dedicated machine and one you surely don't use to browse the web, send e-mail, daily routine..
18:50:56 <sugaring[m]> moneromooo: What stops this from happening?
18:51:21 <mfoolb> ofc if I'm not the only one seeing this as a potential problem for supporting users
18:53:16 <dEBRUYNE> Especially for an RPC node, yes
18:54:27 <h2017> can a mod on reddit just remove that post and replace it with a better one? It should say more p2p-facing nodes
18:54:44 <h2017> open to p2p traffic (i don't know what the best terminology is)
18:54:57 <selsta> both are useful for the network
18:54:59 <h2017> asking people to run public nodes right now will just cause mass confusion
18:58:34 <h2017> selsta why are the rpc-facing nodes beneficial to the network?
18:59:04 <selsta> because the reality is that not everyone runs their own node, even if in an ideal world this would be the case
19:00:51 <selsta> but yes p2p nodes help way more than public rpc nodes, but every rpc node is also a p2p node
19:00:54 <h2017> i add what fluffypony said to me (he said to just run an rpc-facing node) to the comments will people get angry?
19:08:01 <sugaring[m]> <sech1 "sugaring you can spend an output"> Does that mean I need to sign the transaction?
19:10:09 <h2017> would other like it if i ran another node from my same IP address?
19:13:57 <h2017> or is there a way that i can make my existing node do more than it's doing?
19:17:38 <Frenn_> weird my monerod was "Unable to send transaction(s), no available connections" and i needed to kill -9 to reboot cause no command worked really weird
19:18:23 <dEBRUYNE> Frenn_: Are you running with the --ban-list flag?
19:21:25 <Frenn_> dEBRUYNE: yes
19:21:54 <selsta> what do you mean with no command worked?
19:23:34 <h2017> if I increase the number of outgoing connections (say from 12 to 24) will that help the network?
19:23:35 <selsta> Frenn_: let’s see if it happens again
19:31:36 <LyzaL> having more outgoing increases your connectedness to the network so you get blocks faster, but allowing more incoming connections is the bigger thing. I think incoming is unlimited by default though
19:34:33 <h2017> yes o
19:34:57 <h2017> i;ve got unlimmited incoming, so i think i'm helping the network as much as i can (without running a fully public node)
19:35:23 <h2017> i actually don't want to run a public node ever. i think it disincentivises people to run their own nodes
19:37:13 <selsta> keeping the node updated helps the network
19:37:46 <h2017> my nodes on 24/7 now. it's always updated
19:53:22 <p0nziph0ne> Frenn_: i had the same message starting monerod with ban list
19:54:00 <p0nziph0ne> but monerod works normal for me
19:56:27 <selsta> yea the message can happen on startup
19:57:41 <Frenn_> p0nziph0ne: my node was stuck :(
20:08:05 <p0nziph0ne> selsta: what is the cause for this message?
20:08:34 <selsta> I can imagine that it is a check running too early
20:09:28 <selsta> no available connections is probably correct directly on startup
20:09:33 <selsta> it just should not print yet
20:10:11 <selsta> afaik this happens since https://github.com/monero-project/monero/pull/7021
20:10:23 <p0nziph0ne> but unable to send transaction sounds not very confident
20:12:50 <p0nziph0ne> when this is not an error in regard to the network attack, thats good
20:16:26 <selsta> p0nziph0ne: yea it is not related to the attack and should get fixed
20:21:41 <p0nziph0ne> thanks
21:15:23 <sugaring[m]> I'm confused and need some help. When Bob spends his output. At what point does he prove ownership?
21:15:55 <sugaring[m]> Does Bob use the private key/ public key generated from the one-time address to sign the ring signature?
21:20:25 <sugaring[m]> Does the ring signature's public key relate to the outPk (output public key)?
21:23:06 <sugaring[m]> What stops Alice from using Bob's commitment when she know the value and the blind?
21:24:01 <needmoney90> The key image
21:24:13 <needmoney90> the key image is kind of like a one-way fingerprint of the true spend of the ring
21:24:37 <needmoney90> cant fake it
21:55:52 <sugaring[m]> needmoney90: I'm reading zero to Monero second addition and there they explain it as follows.
21:55:53 * sugaring[m] sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/IlUUneDxJdLElneFXMzbzjDs/message.txt >
21:56:34 <sugaring[m]>  * To spend his ‘0’ amount output [sic] in a new transaction, all Bob needs to do is prove ownership
21:56:34 <sugaring[m]> by signing a message with the one-time key K . The private key kB is the ‘spend key’ since it
21:56:34 <sugaring[m]> is required for proving output ownership, while kBv is the ‘view key’ since it can be used to find outputs spendable by Bob
21:57:21 <sugaring[m]> But I don't see any signatures in the transaction structure. Only one is the MLSAG.
21:58:22 <sugaring[m]> So at what point does the above happen? That's confusing me.
22:19:10 <aum> monerod doesn't like the format of my mining receive address
22:20:23 <selsta> mining to subaddresses is not supported
22:20:30 <aum> oh ok
22:26:45 <aum> thanks selsta, now working, and compliments to the devs for the configuration options; nice to have mining stealing only non-essential CPU cycles
22:42:21 <aum> what's the general drill for raising pull requests for contributed code?
23:05:52 <selsta> aum: can you rephrase?
23:08:10 <aum> selsta if I want to add code, eg API verbs for showing node mining stats, then what is the procedure for submitting code for inspection, with a view to possible acceptance into the core codebase?
23:08:40 <selsta> just submit a pull request
23:08:46 <selsta> no special procedure