02:43:28 <kayabanerve[m]> <ooo123ooo1234567> "In theory, if p2pool will get..." <- I don't believe such transactions can exist in the mempool. Monero should only allow one.
02:46:26 <kayabanerve[m]> <MeowingCat> "i would like to implement Monero..." <- There is Python code public which demonstrates libringct binding, if you want to go that low level. If you want to do a wallet, then you want to bind wallet2 though.
05:20:19 <sech1> ooo123ooo1234567 monerod checks for duplicate key images every time it adds a tx to mempool, so that check is redundant
05:35:19 <sech1> although insert_key_images allows duplicates if a tx comes from a block (after a reorg)
07:51:53 <willshu[m]> Hello, since calculating subaddress requires the private spend key, how does the view-only wallet knows which subaddresses to scan for with just the private view key?
07:53:19 <moneromooo> By calculating subaddresses, do you mean generating them ?
07:54:25 <moneromooo> If so, why do you think this needs the secret spend key ?
07:54:27 <sech1> the wallet scans 200 (I think) first subaddresses  by default
07:57:10 <sech1> subaddress N is generated from the private view key and N, private spend key is not used
07:57:27 <sech1> only the public spend key is used
07:58:04 <sech1> moneromooo can you review the new commits in 8381?
08:03:28 <moneromooo> done
09:08:40 <willshu[m]> <moneromooo> "By calculating subaddresses..." <- Oh, it needs private view key and the primary address. No need private spend key
11:02:48 <ooo123ooo1234567> <sech1> "ooo123ooo1234567 monerod..." <- then remove the same check from fill_block_template
11:03:28 <ooo123ooo1234567> <sech1> "moneromooo can you review the..." <- why did you add that check if it's redundant ?
11:04:10 <sech1> because it's not redundant
11:04:31 <sech1> "although insert_key_images allows duplicates if a tx comes from a block (after a reorg)"
11:04:58 <sech1> so it's not redundant in a rare case when there is a reorg with conflicting transactions
11:05:38 <ooo123ooo1234567> sech1: have you read code to find it ?
11:05:42 <sech1> yes
11:05:51 <ooo123ooo1234567> sech1: wow
11:06:19 <sech1> https://github.com/monero-project/monero/blob/master/src/cryptonote_core/tx_pool.cpp#L471
11:07:23 <ooo123ooo1234567> sech1: only that comment or everything related to add/remove txs from mempool ?
11:07:49 <ooo123ooo1234567> comments can be not synchronized with actual code
11:08:03 <ooo123ooo1234567> it's unreliable to rely on comments
11:08:11 <sech1> the whole insert_key_images code
11:08:43 <sech1> kei_image_set.insert(id).second || !m_blockchain.txpool_tx_matches_category(id, relay_category::legacy);
11:08:56 <sech1> this line literally means it's possible to have duplicate key images
11:09:06 <sech1> if the second term in or clause is true
11:09:33 <ooo123ooo1234567> sech1: why did you not read relevant code before ?
11:10:17 <sech1> "then remove the same check from fill_block_template" <- why did you?
11:10:26 <sech1> *why didn't you?
11:11:01 <sech1> I saw this "if (have_key_images(k_images, tx))" check before
11:11:15 <sech1> I just disregarded it thinking it was redundant
11:13:52 <ooo123ooo1234567> writing comments about code without reading it in -dev, is it off-topic or not ?
11:14:46 <sech1> your comments ar 99% offtopic
11:14:59 <sech1> the only useful comment so far was about these duplicate key images
11:15:20 <ooo123ooo1234567> sech1: I've not noticed that confirmed failure in the next message and suggested to remove "redundant" check from other function too
11:15:32 <ooo123ooo1234567> * noticed that you confirmed failure
11:28:12 <ooo123ooo1234567> <sech1> "the only useful comment so far..." <- why not to use m_txs_by_fee_and_receive_time ? it's already simplified clone of fill_block_template labeled as get_block_template_backlog
11:31:14 <sech1> I have commented about it in the PR
11:32:21 <sech1> it's not a clone of fill_block_template
11:32:24 <sech1> it's "get (hash, weight, fee) for transactions in the pool - the minimum required information to create a block template"
11:32:45 <sech1> fill_block_template goes to the grocery store _and_ cooks the food
11:32:53 <sech1> get_block_template_backlog just gives you the shopping list
11:33:26 <sech1> hmm, in this analogy it's the miner who cooks the food
11:33:37 <sech1> so fill_block_template just goes to the grocery store
11:57:54 <ooo123ooo1234567> <sech1> "I have commented about it in the..." <- m_txs_by_fee_and_receive_time is up to date, so it can be used
11:58:22 <sech1> it brings even more copy-pasted code with it
11:59:01 <ooo123ooo1234567> https://paste.debian.net/hidden/876a7a02/
11:59:11 <ooo123ooo1234567> indeed, code without m_txs_by_fee_and_receive_time is cleaner
11:59:13 <ooo123ooo1234567> and faster
11:59:28 <ooo123ooo1234567> and doesn't bring a lot of copy-paste
12:03:47 <sech1> then why it isn't used everywhere in tx_pool.cpp instead of "m_blockchain.for_all_txpool_txes"?
12:04:03 <sech1> until I understand this fully, I don't want to change
12:04:33 <sech1> get_block_template_backlog uses m_blockchain.for_all_txpool_txes because it's next to get_transaction_backlog in the code and follows the same code path
12:05:37 <sech1> besides, it's irrelevant for this particular PR. This change can't bring more than 1-2% improvement, 99% of CPU time is spent in transaction blob parsing and is_transaction_ready_to_go()
12:09:08 <ooo123ooo1234567> <sech1> "then why it isn't used everywher..." <- everything else is agnostic to order of txs, only mempool picker needs different for the best reward
12:10:04 <ooo123ooo1234567> <sech1> "get_block_template_backlog..." <- get_transaction_backlog is doing everything in one pass and doesn't depend on order of txs
12:11:21 <sech1> I don't think it really matters here
12:11:40 <ooo123ooo1234567> <sech1> "besides, it's irrelevant for..." <- indeed, it doesn't makes sense to change anything since PR was already approved blindly
12:11:46 <ooo123ooo1234567> sech1: indeed, who cares
12:11:59 <sech1> you care too much about micro-optimizations
12:12:15 <sech1> the main purpose of this PR is to reduce the number of is_transaction_ready_to_go calls
12:12:18 <sech1> which take 99% of time
12:12:27 <sech1> and it wasn't approved blindly
12:12:39 <sech1> once again, you waste others time with your useless comments
12:12:54 <ooo123ooo1234567> sech1: certainly not me, problem with key images isn't about micro optimizations and https://paste.debian.net/hidden/876a7a02/ has smaller code
12:14:15 <sech1> Problem with key images was fixed. Five extra lines of code bother you that much?
12:34:42 <ooo123ooo1234567> <sech1> "the main purpose of this PR is..." <- yes, but it isn't easy task and that PR turned implementation into simplified fill_block_template since it's expected that reader will have more sophisticated solver internally
12:35:28 <ooo123ooo1234567> <sech1> "Problem with key images was..." <- inconsistency between title / pr description / comments and code / actions - yes, any specific change in isolation - no
12:36:06 <ooo123ooo1234567> > <@sech1:libera.chat> the main purpose of this PR is to reduce the number of is_transaction_ready_to_go calls
12:36:07 <ooo123ooo1234567>  * yes, but it isn't easy task and that PR turned implementation into simplified fill\_block\_template since it's expected that zmq reader will have more sophisticated solver internally
12:47:05 <gingeropolous> come on
12:57:38 <ooo123ooo1234567> <sech1> "your comments ar 99% offtopic" <- comments under PR are coming from those who didn't read relevant code. I've spent some time to check all relevant code in p2pool and monero in order to find better way than 8381
13:01:14 <ooo123ooo1234567> <sech1> "once again, you waste others..." <- all 3 comments from that scammer is an example of dumb micro-optimizations which aren't even correct, theoretical comments about architecture are also useless since aren't practical, and the only useful comment about m_txs_by_fee_and_receive_time was ignored by you due to potentially huge copy-paste or lack of synchronization, but i've posted patch that shows how to use it
13:02:01 <sech1> It wasn't ignored, I wrote at least 3 comments about it :D
13:02:21 <sech1> I just don't think it improves things enough to be justified
13:03:00 <ooo123ooo1234567> sech1: https://paste.debian.net/hidden/33dc162d/, rebased for key images update
13:04:00 <sech1> technically, my code sorts transactions better than m_txs_by_fee_and_receive_time
13:04:03 <ooo123ooo1234567> <sech1> "monerod checks every tx before..." <- yes, I checked that notifications with txs contain only uncontroversial txs (double spends aren't allowed there), so only edge case is only in 1st batch received from that function
13:04:04 <sech1> read the code to find out why
13:04:46 <ooo123ooo1234567> s/only//
13:08:38 <ooo123ooo1234567> sech1: division with double vs integer comparison without division ?
13:09:10 <sech1> bingo
13:09:22 <sech1> no rounding errors, more precise fee/byte comparison
13:11:08 <ooo123ooo1234567> <sech1> "technically, my code sorts..." <- can you open separate PR for mempool comparator ?
13:13:51 <sech1> no, it's not a critical issue
13:14:05 <sech1> at worst, fill_block_template will miss out on a few piconeros
13:14:21 <sech1> not worth the time to spend on it
13:15:35 <sech1> I just pointed it as an example why replacing one with another is not 100% improvement
13:15:41 <ooo123ooo1234567> sech1: not critical -> use m_txs_by_fee_and_receive_time, critical -> use m_txs_by_fee_and_receive_time + separate PR to fix mempool comparator, no third option
13:16:10 <sech1> 1) not critical
13:16:17 <sech1> 2) "use m_txs_by_fee_and_receive_time" - I consider it not critical too
13:17:18 <sech1> you can open a PR after my PR is merged, if it's so annoying to you. You can also replace other instances of m_blockchain.for_all_txpool_txes while you're at it (if it makes things faster)
13:21:20 <sech1> and yeah, I'd like to see some numbers, how much faster it is actually
13:21:28 <ooo123ooo1234567> <sech1> "I just pointed it as an example..." <- smaller code + a bit faster vs more precise comparator (how many piconeros would be lost due to greedy cut of mempool instead of global optimizations with all mempool txs)
13:22:11 <sech1> greedy cut if justified because the miner can start mining faster
13:22:25 <sech1> he'll get more transactions when they're added to the mempool later
13:22:30 <sech1> *is justified
13:22:34 <ooo123ooo1234567> sech1: iterating lmdb db vs iterating in-memory set ? at least not worse, at most probably faster
13:22:45 <sech1> lmdb is memory-mapped too
13:23:11 <sech1> The actual pointer traversing done in both cases will be similar
13:23:11 <ooo123ooo1234567> sech1: only new txs will be broadcasted via zmq, txs that are in mempool but were discarded by your function will not even reach zmq readers again
13:23:21 <sech1> I know
13:23:25 <sech1> that's the tradeoff
13:23:53 <ooo123ooo1234567> sech1: the only missing part is target function, without it it's impossible to choose the best
13:24:07 <sech1> discarded tx will be sent next time, when more profitable transactions go away
13:25:08 <ooo123ooo1234567> sech1: yes, but optimized reward  for parts of mempool may be less than optimized reward for whole mempool
13:25:26 <sech1> yes, in extreme cases
13:25:34 <sech1> 112.5% is not just a random number
13:25:47 <sech1> try to find at least one block in Monero blockchain that went above that
13:26:11 <sech1> i.e. a Monero block bigger than 337.5 Kb
13:26:28 <sech1> we're talking about such rare cases that it's irrelevant
13:28:02 <ooo123ooo1234567> sech1: it's short-term performance optimization (as everything in p2pool), which will not work in case of growth of txs rate
13:28:20 <sech1> "not work" is false
13:28:26 <sech1> it will work, just less than perfect
13:30:31 <moneromooo> sech1: I'm sorry, but I'm putting you on /ignore for a while, I'm just sick of seeing half a side of this. If you need something, ask someone else to ping me.
13:30:39 <ooo123ooo1234567> sech1: that PR is needed only in extreme cases (relatively to avg state of things currenly) when mempool is big, it's also extreme case but for some reason it's taken into considerations while others aren't taken
13:33:30 <ooo123ooo1234567> s/considerations/consideration/
13:42:20 <ooo123ooo1234567> <sech1> "that's the tradeoff" <- without common target function there is no way to converge to the same point
13:47:37 <ooo123ooo1234567> <sech1> "you can open a PR after my PR is..." <- It's possible to open PRs in parallel too. Few more questions under your PR and someone can resubmit with title "lost contact with PR author".
13:47:38 <ooo123ooo1234567> hahahaha
13:48:04 <ooo123ooo1234567> * Few more ignored questions under
14:11:27 <ooo123ooo1234567> <sech1> "we're talking about such rare..." <- In theory, someone unbiased could judge what is better, but it needs explicit target function and a judge
14:23:33 <ooo123ooo1234567> <sech1> "I just pointed it as an example..." <- hmm, interesting question: the best comparator for rational numbers
15:18:21 <arnuschky[m]> <moneromooo> "sech1: I'm sorry, but I'm..." <- Ah. Thank you for that hint. So good ☺️
15:31:21 <ooo123ooo1234567> <arnuschky[m]> "Ah. Thank you for that hint..." <- I did it too, but in reality it doesn't help to solve problems, only postpone them.
16:23:09 <ooo123ooo1234567> <sech1> "while we're at it, can someone..." <- Btw, that key image issue was unnoticed here https://github.com/monero-project/monero/pull/7891/files, and the same happened in 8381, but you didn't even added comment in PR why it was important to check for duplicate key images
16:27:30 <aog> I don't understand why you have to bash down someone for adding a contribution to the project in such a negative non-productive way
16:27:46 <aog> we're all humans, we all do mistakes, no one's code is perfect
16:28:50 <aog> would be much more productive and less frustrating for all parties if you could just point out the mistakes amicably so one can solve them, rather than putting blame on people
16:28:51 <ooo123ooo1234567> aog: "in such a negative non-productive way" I didn't comment on that PR before reading all relevant code, how is it non-productive ?
16:29:26 <ooo123ooo1234567> aog: searching for mistakes is a work, writing shallow comments - not so much work; see difference ?
16:30:10 <aog> the way you communicate and express yourself in non-productive and frustrating for all parties involved, you don't have to put people down to prove a point
16:30:23 <ooo123ooo1234567> aog: I would be satisfied with at least 1-2 people that do checks as deeply I do, everyone else may continue to do whatever they did before
16:33:19 <ooo123ooo1234567> aog: Can call at least 1 opportunity to prove the point in objective way so that no one can escape ?
16:33:23 <ooo123ooo1234567> * Can you call at
16:33:24 <aog> I'm sure your deep checks and the attention to detail efforts you put in, are very important for the project and welcomed with open arms; although the way you attack contributors is wrong
16:35:05 <aog> prove your point, that's awesome, just try not to be a bitpull looking for blood when you do it if you can
16:35:28 <ooo123ooo1234567> aog: I'm attack incorrect statements and incorrect code and in the worst case people, when there are no other way
16:35:32 <ooo123ooo1234567> s/'m//
16:36:12 <aog> I understand, all good
16:39:57 <ooo123ooo1234567> aog: others are balancing their poor code with a lot of comments (in code, in github, in this chat, somewhere else) and it directly interfere with my work here; if these comments are not important -> don't balance poor code with it, if these comments must be correct -> be ready to criticism, but don't force me to participate in this discussion where it's impossible to win/converge to the same point objectively
16:40:20 <dukenukem> jesus christ. it's been like 2 days of your nonsense. stop.
16:44:14 <ooo123ooo1234567> dukenukem: point to concrete sentence that you think is nonsense and explain why, i'll reply
16:44:57 <dukenukem> ooo123ooo1234567: already pointed out by a handful of people in the last 48 hrs. no need to turn -dev into your own kindergarten bullying camp.
16:45:54 <ooo123ooo1234567> dukenukem: if it's so easy then point out at least 1, otherwise put me on ignore list
16:46:25 <dukenukem> no and no. get a mirror, helps with self-awareness.
16:48:41 <ooo123ooo1234567> dukenukem: you're discussing concrete human personality instead of pointing out at least 1 nonsense statement
16:51:59 <ooo123ooo1234567> <dukenukem> "ooo123ooo1234567: already..." <- and try to disconnect your emotions during analysis of msgs, criticism can be treated as bullying if target of discussion isn't clear
16:53:48 <ooo123ooo1234567> it's actually circle: no isolated task -> any criticism to work of someone can be treated as bullying where it's more appropriate -> no way to criticize solution for task
18:42:26 <selsta> .merges
18:42:26 -xmr-pr- 8296 8356 8357 8358
20:14:01 <sech1> I tried to make a gitian build of the latest master, and the compiled binary doesn't start on Ubuntu 16.04: https://paste.debian.net/hidden/7ca5dac4/
20:14:12 <sech1> release v0.17 gitian binaries work
20:15:01 <sech1> so probably some new or updated external dependency breaks Ubuntu 16.04 compatibility
23:18:48 <ooo123ooo1234567> <sech1> "and yeah, I'd like to see some..." <- https://paste.debian.net/hidden/f179ff7b/, no difference, even "Don't ask for blob in for_all_txpool_txes" + "Avoid excess copying of txblob" aren't visible behind fluctuations