< wumpus>
I tend to get that wrong too, it's a very difficult rule for non native speakers of English
< jonatack>
I agree it can look strange to read
< wumpus>
for 30 years of so I was blissfully unaware and based a/an on the simple letter-based heuristic, it worked enough for people to never complain
< wumpus>
elichai2: you've added a native ppc build? nice
< elichai2>
yep. it's kinda undocumented, so we might need to allow it to fail (altough it works on my repos), still have some problems with the docker. but it's pretty cool
< wumpus>
so they have actual POWER servers running builds? sounds expensive :)
< elichai2>
wumpus: either that or a bunch of emulation stuff
< wumpus>
for ARM it's not hard to believe it's real native
< luke-jr>
POWER isn't that expensive either, especially for business..
< luke-jr>
I built my Talos II for $3k and there's the cheaper Blackbird now
< luke-jr>
wumpus: Technically you could always use "an" and just defer to the Tonal number system (where "an" is 1)
< wumpus>
I don't get it, ci/lint/06_script.sh runs subtree checks for various trees, but doesn't import their master branches, how is this supposed to work?
< wumpus>
I added a new subtree in #17398 and locally the subtree checks pass, but not on travis, because it doesn't have the commit available
< wumpus>
ooh the native osx travis build has beer keg emojis, yes it's the first time I look at that
< fanquake>
is that in the brew output?
< fanquake>
We can turn that off if required heh
< wumpus>
no, let's leave it
< fanquake>
We can also customize it using HOMEBREW_INSTALL_BADGE
< wumpus>
"checking for F_FULLFSYNC... no" looks like the detection is somehow not working, fullfsync is a MacOS thing right?
< wumpus>
oh, I think I understand the issue
< fanquake>
wumpus let me know when that PR is "stable" enough to test in various places
< wumpus>
fanquake: sure; it should work now on linux/windows/osx, though without crc32c acceleration
< wumpus>
integrating crc32c into the build system is going to be slightly involved, there's various new things (besides sse42 support) that need to be detected
< fanquake>
wumpus ok. Will do some initial testing on macOS / BSDs
< wumpus>
most of the fixes I've pushed in the last hour or so, except for the FULLFSYNC one, were to make linters happy
< wumpus>
that's how it goes right ...
< fanquake>
?
< fanquake>
I've been trying to track down the file descriptor discrepancy for the past day or so. Think it's time to give up and dump the info in an issue..
< wumpus>
that sometimes helps, maybe someone else has ideas
< wumpus>
cleaned up the commits; everything besides "build: Update build system for new leveldb" (and the subtree update for src/leveldb) is related to crc32c and not necessary for build at the moment
< fanquake>
cool
< wumpus>
(but also shouldn't get in the way; HAVE_CRC32C is hardwired to 0 at the moment)
< fanquake>
ok
< fanquake>
are we discussing 0.19.0 release at the meeting this arvo?
< wumpus>
yes, we should
< wumpus>
I think it's ready, nothing else has come up with the last rc
< fanquake>
Yep.
< fanquake>
One final thing we probably want to do is at least add a note to the release notes in regards to macOS Catalina users having to "right click" and open.
< fanquake>
Might avoid some potential confusion.
< wumpus>
yes, definitely
< fanquake>
That's all I'll say in regards to macOS atm.
< fanquake>
Can anyone remember in which PR sdaftuar mined a commit hash to have 6-7 leading 0s ?
< fanquake>
or it might actually have been marco
< aj>
fanquake: "git log 000000" should tell you, #13510
< bitcoin-git>
bitcoin/master fae43a9 MarcoFalke: test: Seed test RNG context for each test case, print seed
< bitcoin-git>
bitcoin/master 772673d MarcoFalke: Merge #16978: test: Seed test RNG context for each test case, print seed
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16978: test: Seed test RNG context for each test case, print seed (master...1909-testSeed) https://github.com/bitcoin/bitcoin/pull/16978
< fanquake>
#proposedmeetingtopic not so much a topic, but a reminder that if everyone wants to air / dump their GitHub grievances into #15847, I'll be discussing with GH next week
< fanquake>
elichai2 a test, or the depends build of OpenSSL ?
< fanquake>
We use 'Configure' to configure OpenSSL in depends, looks like it's suggesting to use ./config instead. I'd assume Configure is bombing out for some reason
< elichai2>
so why will it fail only on here?
< elichai2>
(maybe the tests shouldn't use the depends and add the incompatible db flag?)
< fanquake>
I'd guess no one has tested a depends build with a powerpc64le-unknown-linux-gnu HOST before, and haven't run into the OpenSSL configure failure
< elichai2>
fanquake: what do you think, should I try fighting it (replacing Configure with `./config` or just not use the depends?)
< fanquake>
elichai2 I'm going to spin up a container and take a quick look in a second.
< fanquake>
In any case hopefully OpenSSL will be gone soon
< elichai2>
k. i'll for now try without depends to see if any other erros come up that are more directly related to bitcoin
< elichai2>
if you have a local container with ppc64le feel free to debug a Docker bug i've found that made me replace `library/ubuntu` with `ppc64le/ubuntu:18.04`
< fanquake>
elichai2 I've recreated your issue locally with HOST=powerpc64le-unknown-linux-gnu. OpenSSLs ./Configure fails. ./config detects ppc64le-whatever-linux2 and will configure for linux-generic32
< elichai2>
fanquake: does that mean it's working, `linux-generic32` doesn't sound good hehe
< elichai2>
I guess that's a change to the test framework though?
< MarcoFalke>
Idk. I kept bumping them for years
< elichai2>
or is there a env variable?
< MarcoFalke>
Maybe we should remove the timeout
< MarcoFalke>
They are hardcoded in the individual test files
< elichai2>
k. i'll start by making this work *without* functional. so I can open a PR and document what works and what doesn't, and then look into timeouts
< MarcoFalke>
self.rpc_timeout = 120
< wumpus>
elichai2: you're not basing it on luke-jr's PR? I thought that was the idea
< elichai2>
It's been a year, hmm the only thing there that's related is the glibc_compact. But I assume the CI will increase people's confidence in that PR?
< wumpus>
helping test and review it would increase confidence in the PR, just asking because you care about ppc apparently :)
< wumpus>
and yes I don't think it makes sense to add a travis run for a platform we don't distribute binaries for
< wumpus>
unless it's a big endian platform, would be nice to have a big-endian travis run no matter what
< sipa>
wumpus: (not sure where to comment) your leveldb commit 180296c359ba248ae6f2a6094098a22fd31994d6 drops a few 'override' modifiers for no reason, i think
< wumpus>
sipa: oh that's not intentional, thanks
< sipa>
also in 415ad71a96070dd4989153a800e6fd969269590b's commit message you have a typo in your own name
< sipa>
(i think!)
< elichai2>
wumpus: I don't even have ppc, was just excited that I found this new Travis feature, and always looking for ways to contribute :)
< wumpus>
sipa: thanks, will fix
< sipa>
the patchset for leveldb seems amazingly small now
< sipa>
and entirely upstreamable?
< wumpus>
sipa: yes, I think it's eventually upstreamable
< sipa>
we're using the cmake buildsystem for crc32c?
< wumpus>
no :)
< sipa>
then why does your patch modify CMakeLists.txt?
< fanquake>
Glad we don't have too
< wumpus>
I've integrated crc32c into the build system in the same way as leveldb, this requires being able to pass defined manually instead of having this .h file
< wumpus>
because cmake uses that .h.in file to provide configuration
< sipa>
oh i see, to make sure things don't break for when people build the patched tree using cmake
< wumpus>
I don't, but don't want to break their buid system...
< wumpus>
yes
< sipa>
of course
< wumpus>
I have sse42 already working locally (it's not in the PR yet), now trying to get ARM64 crc32c to work
< wumpus>
it's easy just have to convert the cmake detection to autoconf (it doesn't help I don't really know either very well though :)
< sipa>
nobody does.
< wumpus>
true.
< MarcoFalke>
is the meeting in 9 minutes?
< fanquake>
*8 minutes
< wumpus>
I think so
< wumpus>
date -u shows it's 18:53 so yea
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Nov 7 19:00:29 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
I think that's already a perfect number so let's move on
< BlueMatt>
proposed topic: one last question blocking rust progress
< wumpus>
(anything to add/remove?)
< achow101>
add #17373 pls
< gribble>
https://github.com/bitcoin/bitcoin/issues/17373 | wallet: Various fixes and cleanup to keypool handling in LegacyScriptPubKeyMan and CWallet by achow101 . Pull Request #17373 . bitcoin/bitcoin . GitHub
< wumpus>
achow101: ok, added
< fanquake>
Only PR I'd suggest adding is #17270. I have some new comments to make there, and think it could be split up to aid review, but could use more eyes regardless.
< gleb>
I think there is some valuable discussion is going on here: #17326. Not sure it's a particularly high-prio, but I think it's worth looking at for whoever missed. It's about whether we should keep (some) p2p connections on a node restart or connect to new peers.
< wumpus>
but yea, that would be more like a proposed meeting topic than something for review
< fanquake>
Should we move onto a proposed topic? This might be a quick meeting for once.
< fanquake>
is nickler or instagibbs here?
< gleb>
I don't think at this point we need real-time discussion, as long as the conversation is happening there on github. Just wanted to bring a bit attention of everyone.
< BlueMatt>
seems like an easy solution is proposed there: add a list for secp-securiy@bitcoincore.org and add relevant folks to it?
< nickler>
We're adding a SECURITY.md file to the bitcoin-core/secp256k1 repo and considered secp256k1-security@bitcoincore.org as security email address.Would it be possible to add such an email address? How are we making sure that security contacts will actually get emails forwarded to them? Who can see the content of a vulnerability report if it's sent unencrypted?
< BlueMatt>
I presume wumpus can do that?
< wumpus>
yes, I can make a forward address on bitcoin-core.org
< BlueMatt>
dig +short bitcoincore.org mx
< BlueMatt>
10 spool.mail.gandi.net.
< wumpus>
just tell me who to include
< wumpus>
doesn't have to be in the meeting :p
< nickler>
wumpus: cool, will do in private
< sipa>
we'd need to put it on the bitcoincore.org website as well, i think
< sipa>
together with gpg keys of some/all of the people involved
< achow101>
instagibbs wanted to ask whether we should consider making SRD something that is opt in instead of outright replacing the current knapsacksolver fallback
< wumpus>
could at least initially do that I guess
< gleb>
Is it assumed that everybody knows what does SRD stand for?
< achow101>
so people who care could set some switch to use srd as the fallback so that we aren't breaking things too much
< sipa>
gleb: single random draw
< wumpus>
replacing it is goig to be much more controversial than adding a new method
< achow101>
but I don't think anyone would opt in because what user knows that srd is or really cares about the coin selection algo details?
< achow101>
My current pr for srd is to actually use both knapsack and srd, then choose the one that produces the "better" solution
< wumpus>
it's something that needs to be tested/evaluate over a long period
< achow101>
although defining "better" is non-trivial
< wumpus>
people that want to test it can enable it
< achow101>
i'm not convinced that people are going to test it
< wumpus>
you mean, no one?
< meshcollider>
Probably lol
< wumpus>
that's a dangerous statement, if you think no one cares, why work on it?
< sipa>
a possibility could be to run both, and add a debug log that tells you what SRD would have done instead
< achow101>
I would guess that the people who would test it are not the same people who make enough transactions for it to matter
< wumpus>
that doesn't matter
< sipa>
there's a big difference between people in general being interested in a feature ("better coin selection" i think certainly qualified) and people with both the technical means and in a situation where they can provide good feedback
< jonatack>
perhaps it needs awareness raised about it? via bitcoin optech, forums, etc.
< achow101>
then there's no meaningful results or feedback
< wumpus>
though it might mean you need to convince people that make enough transactions to test it, maybe
< wumpus>
that's easier if it's an option
< wumpus>
I don't think we can have this discussion without anyone arguing to add it
< wumpus>
let's move to next topic
< wumpus>
#topic Subtree organization and linters (wumpus)
< fanquake>
linters ?
< wumpus>
so while trying to add crc32c to the tree (because the new leveldb uses that), I've noticed that the exceptions to linting are spread all over the place
< wumpus>
I think it'd be useful to move subtrees to one place in the tree
< sipa>
yes!
< MarcoFalke>
Linters shouldn't be a reason to move source code around
< BlueMatt>
ack
< wumpus>
so that doxygen knows to avoid it, linters know to avoid it, etc
< gleb>
broke: minting; woke: linting
< MarcoFalke>
But I agree it makes sense even absent of linters
< BlueMatt>
mostly cause putting them in one place is clean from a "this isnt our code, you should know that" human pov
< BlueMatt>
but, yea, my preference for anything where linters come up is to remove them :)
< wumpus>
do you think it would not only be clutter?
< wumpus>
in any case that leaves the linters and everything
< wumpus>
I think a mess now
< wumpus>
it took me an hour or so to find them all
< MarcoFalke>
#action Move subtrees to one place
< sipa>
it seems ctaes and secp256k1 are included in doxygen, though
< wumpus>
that's probably accidental
< jnewbery>
an alternative would be to have an exclude.txt file in the linter directory and have all linters read from there
< wumpus>
it's also easy to forget one
< jnewbery>
(not saying we shouldn't change code organization structure, just agree with Marco that it shouldn't be driven by satisfying the linters)
< wumpus>
yes, that's also possible
< wumpus>
oh I agree
< sipa>
or have a directory subtrees with all the subtrees? :)
< fanquake>
another alternative would be to just remove all the linters, as they seem to take up a disproportionate amount of everyones time ?
< MarcoFalke>
fanquake: Not having them also takes up time, unfortunately (as we recently saw)
< jnewbery>
Concept ACK directory subtrees with subtrees
< jamesob>
something something baby bathwater
< wumpus>
FWIW doxygen input is already generated using automake so it'd be trivial to generate it from a central list
< wumpus>
the linters are shell scripts all over the place
< BlueMatt>
ignoring linters, I think its a good idea to put them all in one place, and it looks like no one materially disagreed?
< wumpus>
using different ways to scan the tree
< wumpus>
so that's more work...
< BlueMatt>
so...next topic?
< fanquake>
I have a real quick topic if there aren't any others left
< BlueMatt>
i haz topic
< MarcoFalke>
It is going to change all includes. Incoming merge conflicts
< wumpus>
#topic rust in bitcoin core (BlueMatt)
< wumpus>
MarcoFalke: yes, it's a mess to clean up a mess
< MarcoFalke>
lol
< BlueMatt>
one question about the rust stuff that wasn't answered in the last meeting (#16834)...in the last meeting the conclusion was "why merge if not shipped by default", so I set it as default, and this added a new question...if you dont have rustc installed, should configure fail, or just warn and not build rust.
< BlueMatt>
cfields made the point that this results in silently building binaries with significantly different feature sets than release ones, which feels super strange, but I figure folks will complain if suddenly master stops building for them cause rustc is required unless you say --disable-rust. thoughts?
< BlueMatt>
other than this it seems that pr is Ready to Go (tm)
< jamesob>
seems pretty aggressive to me to require rustc by default
< wumpus>
but if someone wants to fix the linters to use a central exclude list that's fine with me too ,anyhow, I really don't know what's the best solution here, but I think something needs to change
< fanquake>
I don't think rustc should be a requirement to build master, I also agree that silently failing to build new feature sets feels like the wrong behaviour.
< wumpus>
also I didn't really like including crc32c in our main src directory, it's kind of indirect
< wumpus>
something like /src/external would be better
< sipa>
why not just leave the rust stuff off by default?
< wumpus>
yes, leave the rust stuff off by default, at least initially
< BlueMatt>
sipa: you're three meetings late on that one :p
< sipa>
yeah, haven't paid much attention to that
< sipa>
but i don't see why that isn
< sipa>
't the obvious solution
< jnewbery>
Sorry, I also missed the 'on by default' decision
< BlueMatt>
well I mean we could also leave it off by default, but there was strong agreement to have it on by default in 0.20
< BlueMatt>
I dont think there were any voices that disagreed with that
< promag>
hi
< jnewbery>
BlueMatt: do you have a link? Struggling to find it in my scrollback
< wumpus>
I haven't seen that
< wumpus>
I like to merge *some* rust code by 0.20
< BlueMatt>
(built by default, not, like, making new network calls by default at runtime, that is)
< wumpus>
I think it's best to have it disabled by default initally
< meshcollider>
Maybe the "strong agreement" was just everyone missing the discussion :p
< jamesob>
and just to clarify, there's no way that a failure in any of the rust subsystems can cascade over to the other processes, right?
< BlueMatt>
(in case that was the confusion)
< wumpus>
it's always possible to change a default
< wumpus>
but you're going to have a merge harder time getting it merged it you want to require it
< BlueMatt>
yes, jamesob, that is (to my knowledge) true.
< fanquake>
#17090 some default discussion in here
< BlueMatt>
wumpus: I personally dont want to require it, my preference was just "on if you have rustc available"
< BlueMatt>
but cfields pointed out this felt....strange
< BlueMatt>
cause you would just silently get things that had different feature sets from release
< wumpus>
I like explicit configuration flags, but anyhow
< promag>
BlueMatt: isnt that the same as with qt?
< jamesob>
I think in general whenever we release major new features they should be opt-in (if possible) for a few releases to iron out kinks
< BlueMatt>
you mean ./configure flags, anything written so far has to be opt-ed in at runtime
< sipa>
promag: but Qt is actually built and enabled by default in release builds
< BlueMatt>
promag: maybe zmq is a better example, at least with qt you just totally miss the bitcoin-qt binary
< meshcollider>
why not off unless you have --enable-rust then?
< BlueMatt>
jamesob: you mean opt-in, or not built-in, cause those are different
< wumpus>
I'm not sure why this is such a big issue, just leave it experimental for the first release and only activated with a flag
< jamesob>
BlueMatt: I mean available but disabled by default
< wumpus>
this can always be chagned later
< fanquake>
I feel like an explicit opt into rust stuff for 0.20.0 is ok. That would be the same as all this new android stuff. None of that is going to be anything other than explicitly opt in for a while
< promag>
+1 fanquake
< wumpus>
fanquake: exactly
< BlueMatt>
wumpus: I'm confused, you mean on by default at runtime or built by default
< sipa>
by default don't compile it in
< wumpus>
it's much *easier* to merge things if they're introduced that way
< BlueMatt>
same goes for fanquake...
< wumpus>
disabled in the compile by default
< jnewbery>
wumpus: +1
< jamesob>
+1
< fanquake>
BlueMatt I mean if you want to do rust things, do ./configure --enable-rust, and that's the only time it's used
< BlueMatt>
lol wumpus i distinctly recall the opposite thought last meeting
< BlueMatt>
but, ok, I can undo all those changes...
< BlueMatt>
fanquake: lol you too...
< jnewbery>
BlueMatt: no-one else remembers. I can't see any agreement in the Oct 10 meeting
< promag>
BlueMatt: just to be clear, you suggest to enable if rustc is available?
< wumpus>
I'm not sure having rustc in your path should change anything automatically to bitcoin configuration
< BlueMatt>
yea, that was cfields' objection, which seems strange
< wumpus>
but than again, I like explicit configuration options, I hate 'intelligent' software trying to second-guess me in general, so :)
< wumpus>
any other topics?
< promag>
I think it's fair to expect a first-time thing to be opt-in
< fanquake>
Basically just for everyone to dump any more thoughts they have into that thread, as the (in person) discussions with GitHub are happening early next week.
< wumpus>
BlueMatt: let' sjust aim to get some rust code in, the default discussion is really something that can be left for later and only confuses the intial merge I think
< fanquake>
There have already been some discussions in repos in GitHub in which I've started bringing up some of our suggestions.
< BlueMatt>
right, ok, I'll just turn it off by default and we can have this conversation again post-merge.
< wumpus>
yes, maybe in a major release or two
< promag>
wumpus: I have one topic: cmd notify queue
< fanquake>
Seems that some of the maintainers from other projects, which include some people from Rust core, agree with some of our concerns/issues.
< fanquake>
That was all though. If you have any thoughts you don't wont to post in the issue, feel free to get in touch with me directly.
< sipa>
fanquake: come say hi when you're in the bay area
< fanquake>
sipa: will do
< wumpus>
#topic cmd notify queue (promag)
< promag>
so -walletnottify and -blocknotify spawn a thread which in turn call system()
< promag>
and sometimes that can lead to some load - but that's not the issue now
< wumpus>
you want an unbounded queue instead of a fork bomb :)
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #17404: Remove redundant class file include from test_bitcoin msvc project (master...msvc_test) https://github.com/bitcoin/bitcoin/pull/17404
< wumpus>
launching processes for notifications was always a bad idea
< promag>
well, that can't be changed I guess
< wumpus>
definitely if they happen often enough to consider things like that
< wumpus>
well if it's just every 10 minutes no one complains
< promag>
while replacing with boost::process I've noticed that the pace of process spawning is shorter
< wumpus>
if it's a high frequency noticication you should use another mechanism
< promag>
so I wonder wdyt about adding some queue
< promag>
which has de bonus of guaranteeing order
< promag>
also, the advantage is to avoid command line placeholders
< wumpus>
that adds latency, also people expect the thread to run free (so keeping a command running doesn't block bitcoind), so you can't guarantee much
< promag>
and pass vars via env
< promag>
wumpus: I think that if a command does that now I will have problems anyway
< promag>
*it will
< wumpus>
right now, it creates a new thread an starts the command in that
< promag>
right, but if the command doesn't quit you end up with lots of threads?
< wumpus>
if you want to create say, a single-threaded worker queue for notifications, that does change how it works
< wumpus>
I'm sure it needs to quit some time
< promag>
would you nack that?
< wumpus>
I think it's a unnecessary change
< wumpus>
how it is now works for the people that use the current mechanism
< wumpus>
if you want more, use zmq
< wumpus>
you're not going to make a system that supports high frequency notifications with process spawning
< promag>
my problem is that in #13339 if I use boost::process notifications are slowly handled
< meshcollider>
jnewbery: sweet I'll take a look today
< jnewbery>
thanks!
< wumpus>
promag: sorry to be so cynical but the way you way that, the more I hear people talking about boost::process the more I start thinking that it's a bad idea to start using it
< wumpus>
things like thread safe calls for process spawning have been solved in the 90's, it's not some magic new technology
< promag>
The execvpe() function is a GNU extension.
< wumpus>
so do you need to override the environemtn?
< wumpus>
we've always passed things as arguments
< promag>
wumpus: escaping issues
< wumpus>
wait
< promag>
and honestly do you prefer that over env vars?
< wumpus>
you're talking about low-level process spawning right?
< wumpus>
escaping issues are a shell thing
< jeremyrubin>
Oh
< jeremyrubin>
Meeting....
< wumpus>
if you don't invovle the shell, so spawn a process directly, you're not going to have escaping issues
< wumpus>
this is similar to python subprocess.Popen with shell=True versus shell=False
< wumpus>
yes, I prefer arguments to environment variables
< ryanofsky>
wumpus, on windows you have escaping issues without a shell because processes are starting with a single string, not an array of strings, and the c runtime library parses that into an argv array
< wumpus>
environment variables are for global state
< wumpus>
if you need to pass arguments to a process, the preferred way to do that is to use arguments
< promag>
wumpus: what I usually see is if something has to launch a process with a custom configuration then env vars is the choice - honestly I don't recall seeing placeholders
< promag>
like %s
< promag>
anyway, I'll try to see what is slowing boost::process:spawn
< wumpus>
ryanofsky: I have no idea about windows
< promag>
I really dislike %w, and there's the windows "'issue'", that's why I'm trying with boost::process
< wumpus>
POSIX already confuses me enough,thanks
< wumpus>
let's look it up though
< promag>
yup, I don't think this stuff too.. but walletnotify lacks support for multiwallet
< wumpus>
which brings me back to, please use another notification mechanism
< promag>
wumpus: we don't support zmq in the wallet
< wumpus>
spawning processes is OS specific madness
< promag>
right
< wumpus>
in a sandboxed env you might not even be allowed to do that
< wumpus>
promag: maybe we should!
< promag>
I think that good solutions is a) some PR for longpoll by jonasschnelli b) push to some amqp
< promag>
problem with a) you need a long poll for each wallet
< wumpus>
so to be clear I'm not arguing to remove walletnotify etc, if the load is low enough that spawning processes is good enoguh, then it's good enough, but I don't think it's worth spending a lot of work to improve/change it, especially incompatibly or movingthings to environment variables etc
< promag>
wumpus: right, I'm ok with last decision - just support %w in linux/mac
< wumpus>
so why is wallet zmq not a thing?
< wumpus>
why notwork on that instead?
< promag>
?\_(?)_/?
< promag>
I think that was discussed before
< wumpus>
okay
< promag>
if the subscriber is down then you miss notifications?
< promag>
I don't remember
< sipa>
zmq is only useful as a "you need to poll right now" mechanism
< wumpus>
I don't think spawning processes is 100% guaranteed either
< sipa>
you need to poll at startup/intermittently anyway; zmq helps reduce your latency
< wumpus>
it's extremely hard, maybe impossible to make a notification mechanism that is 100% loss proof
< promag>
so the zmq message is (new stuff in wallet x, bye)
< wumpus>
sipa: right
< wumpus>
and it includes sequence numbers so you know if you missed something
< wumpus>
(maybe use a block chain for your notifications *ducks)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #17407: Add MempoolInstance() to get the current mempool (master...1911-txPoolOptional) https://github.com/bitcoin/bitcoin/pull/17407