< instagibbs_>
elichai2, which sequence number? the actual zmq sequence number for the notification stream?
< instagibbs_>
or the bitcoiny-sequence value for the "sequence" notifier
< laanwj>
fanquake: no such name
< laanwj>
fanquake: is it the one without 73?
< laanwj>
why is #12314 marked 22.0 ? looks like a really old tag, and i'm not actually sure something remains to be done on the issue (people disagree)
< laanwj>
fanquake: ok, good to see github pro-active i guess
< elichai2>
instagibbs_: the actual zmq sequence number
< elichai2>
I'm starting to think that core might be getting a big dump of txs at once sometimes (also correlates with blocks sometimes so it might be blocks with a lot of unknown txs ) and then it "overflows" the 20 txs buffer (by a thousand?) which causes the big sequence number jumps
< promag>
elichai2: have you set high water mark?
< elichai2>
promag: yeah, to 20
< promag>
that sounds too low?
< laanwj>
going to need a much bigger buffer then, but yeah it's probably not useful behavior for it to send a separate notification for every single transaction in a block
< promag>
elichai2: do you use pubhashtx or pubrawtx?
< promag>
and why hwm=20?
< elichai2>
pubhashtx, I took 20 because in the end I'm gathering some stats on transactions(for research purposes) and it's not too useful to me to get transactions in a big delay after the node gets them (I should've probably hacked my data gathering into bitcoin core), so I'd rather miss transactions than get them in delay
< ariard>
for the ones interested, a friendly reminder about the first transaction relay workshop happening tmrw on #l2-onchain-support (libera) at 19:00 UTC :)
< ariard>
Gonna share open questions and resource pointers soon
< promag>
elichai2: maybe you could use zmqpubsequence?
< promag>
not sure but I think it doesn't pub txs from blocks
< elichai2>
promag: hmm that's interesting, I also wonder if the massive pushhashtx comes before or after the pushrawblock, i'll check in the code
< promag>
what do you do when you recv a hashtx?
< elichai2>
I save it and wait to see when is it confirmed
< promag>
how do you do that? rpc?
< elichai2>
wait for the pushrawblock notification and check if it's in the block
< promag>
elichai2: then maybe just use pushrawblock + zmqpubsequence
< elichai2>
and then look at messages that have 'R' in index 32?
< elichai2>
argh *A
< promag>
y
< promag>
keep in mind that pubrawblock can give new txs
< elichai2>
I'll give it a try, Thanks, I didn't use it before because I didn't care about the other kind of notifications it sends, but I didn't realize the problem with receiving txs that came from a block
< elichai2>
FWIW, I'm not a big fan of the fact that it reverses the hashes before sending, I'm used to reversing only when converting to hex, not having it in reverse in bytes form
< laanwj>
agree it would be better not to, but when i first noticed it (which was already years ago) it had been in the code for long so there wasn't really a choice but to stay consistent between notification types
< promag>
"for some reason" I can't find the reason or discussion regarding that
< laanwj>
i don't t hink there was any, there used to be about nil interest in the zmq notification
< promag>
laanwj: in master it always been the same
< laanwj>
i see, 6103 was the first zmq notifications PR that was merged
< laanwj>
too bad we didn't notice it back then
< promag>
note that hashes aren't reversed in contrib/zmq/zmq_sub.py
< promag>
maybe that triggered server side reverse and stuck around
< jamesob>
hm, not sure if I'm tilting at a windmill here but has anyone ever seen ccache overzealously cache?
< elichai2>
jamesob: yes
< elichai2>
but it happened to me with rust, not C/C++
< promag>
jamesob: yes
< laanwj>
yes, i once had a weird compile issue that was solved by removing ccache's cache, don't remember the specifics anymore
< promag>
sometimes ccache -C
< jamesob>
elichai2: okay, good to know. Saw an issue where compilation worked fine on a system with ccache, but then when I moved the same code over to another system compilation revealed an error
< elichai2>
argh that was with sccache, not ccache, sorry
< jamesob>
pretty unnerving. Like, c'mon ccache, you had one job...
< laanwj>
yeah
< bitcoin-git>
[gui] hebasto closed pull request #307: Make row color alternating in the Peers tab optional (master...210501-stripes) https://github.com/bitcoin-core/gui/pull/307
< laanwj>
i remember what my ccache issue was again: i had some warnings that wouldn't go away, there was a change (to a header file) that *should* make it go away but it didn't, after cleaning and rebuilding my tree a few times i thought about cleaning ccache, and that worked; apparently it hadn't picked up the change for some reason, maybe because the file was rewritten while it was compiling, or
< bitcoin-git>
[bitcoin] laanwj opened pull request #22244: devtools: Correctly extract symbol versions in symbol-check (master...2021-06-pixie) https://github.com/bitcoin/bitcoin/pull/22244
< bitcoin-git>
[bitcoin] amitiuttarwar opened pull request #22245: [p2p] Stop sending SENDADDRV2 message to block-relay-only peers (master...2021-06-sendaddrv2) https://github.com/bitcoin/bitcoin/pull/22245
< Alina-malina>
guys do you remember the name of that program/protocol, that was right before bitcoin appeared in 2009? like it was something-brokers or something?
< jamesob>
Alina-malina: that's a question for #bitcoin
< Alina-malina>
ye i already found it, forgot to mention
< Alina-malina>
there was a mindmap for bitcoin core source code
< Alina-malina>
where can i find it?
< Alina-malina>
some guide sort of
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #22247: Switch Appveyor CI to VS2019 stable image (master...appveyor-image-stable) https://github.com/bitcoin/bitcoin/pull/22247
< achow101>
several of the prs in the 22.0 milestone are rtm I think
< bitcoin-git>
[gui] hebasto opened pull request #365: Draw "eye" sign at the beginning of watch-only addresses (master...210614-tx) https://github.com/bitcoin-core/gui/pull/365