< midnight>
It appears that one can specify multiple -externalip= -- for example, to specify multiple tor HS addresses, as it's a std::map and the access element [] operator creates a new entry if one does not exist; Is this the case? The logic is splayed out a bit.
< midnight>
(Asking because I think adding torv3 addresses to my nodes would be more palatable if I can retain my (ancient, mined) v2 addresses still.
< sipa>
won't be useful until they can be rumoured using BIP155
< * luke-jr>
assumes midnight means after it's merged :p
< midnight>
sipa: I like these changes. +1 vasild <3
< sipa>
midnight: also, yes, you can set multiple local addresses with -externalip; the one that will be rumoured to peer X is the most compatible one (using some heuristics; if there are multiple ones, the one which we've seen the most incoming connections to)
< midnight>
I saw that logic too. I failed to verify on top of that that rumouring would include a torv3. I'm okay with it in either event. Yeh, I like these changes going in. Neat stuff.
< tryphe>
has anyone taken a look at #19598? i think i kind of understand what he's saying and it looks important
< sipa>
tryphe: i don't think it matters; the cost of the current check is negligable
< sipa>
compared to merkle tree hashing
< sipa>
i do think he's right though about an O(log n) solution being possible
< tryphe>
sipa, gotcha, thanks!
< tryphe>
sipa, i had a slight interpretation that he was saying there was something wrong with the way the boolean is modified during the loop but maybe it was a misunderstanding
< sipa>
tryphe: no, i think he just finds it ugly that the merkle computation and malleability check are in one function
< tryphe>
sipa, ahh, makes sense :)
< tryphe>
it was a bit hard to grok for me, just seemed a bit concerning, thanks for the look!
< tryphe>
sipa, to be fair your fourth bullet point makes a lot more sense than the original post :D
< Kiminuo>
Command to reproduce the "./fs.h:14:10: fatal error: filesystem: No such file or directory" error is: `~/work/bitcoin$ ./autogen.sh && ./configure --enable-zmq --with-gui=qt5 --enable-glibc-back-compat --enable-reduce-exports --enable-c++17 --enable-debug CFLAGS="-g0 -O2 -funsigned-char" CXXFLAGS="-g0 -O2 -funsigned-char" --with-boost-process && make`
< Kiminuo>
The goal is just to verify whether `-lstdc++fs` has an effect or not to document it and thus move the PR an inch forward.
< Kiminuo>
wumpus, ^ friendly ping
< provoostenator>
Not sure if this was brought up, but the GUI repo is lagging by about a week.
< provoostenator>
Which causes PR's to have a whole bunch of old commits in them (at least when they're rebased on the main repo's master, which is what I do)
< vasild>
Wrt the next bip155/torv3 PR, assuming #19845 gets merged - #19031 has two more commits "net: CAddress & CAddrMan: (un)serialize as ADDRv2" (+193/-15) and "net: advertise support for ADDRv2 via new message" (+129/-8). Then we will have done BIP155 - will gossip torv3/i2p/cjdns addresses if we receive them (even though we may not be able to make use of them yet). After that we need one more change
< vasild>
to create torv3 hidden service instead of torv2 one, which is the topmost commit in #19954 (+27/-6). This will conclude TORv3 support. I plan (planned) to open 3 PRs for those to ease reviews (one for each commit). However I noticed that it takes lots of time after a PR is opened for reviewers to start looking at it. Once reviewers are engaged it starts rolling (either big or small). So I wonder
< vasild>
above I am talking about what to do next, after it get merged
< provoostenator>
I know, but I'll have to review some of it in order to develop such opinion :-)
< vasild>
:-)
< gleb>
Developer notes in 0.20 say: "`-whitelistforcerelay` configuration parameter has been removed". I think this is an inaccurate description of what happened in the PR #17985.
< sipa>
#proposedmeetingtopic short topic: endomorphism optimization in libsecp256k1
< fanquake>
sipa: has that patent expired now
< sipa>
sep 25th
< fanquake>
🚀
< phantomcircuit>
sipa, how big of a win is that?
< sipa>
27%
< sipa>
for signature validation, there is additional overhead to full script validation
< luke-jr>
patents are funny
< luke-jr>
they serve no real purpose but as a "date people can begin using it" <.<
< sipa>
i think there are plenty of patents which end up being used by the inventor before becoming publicly available.... not saying that's a good thing, but in that case it does serve a purpose