kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
Guest28 has quit [Ping timeout: 256 seconds]
<bitcoin-git>
[bitcoincore.org] azuchi opened pull request #1075: Add japanese translations for security advisories fixed in v25.0 (master...ja-translate-security-advisories-25.0) https://github.com/bitcoin-core/bitcoincore.org/pull/1075
dermoth_ has joined #bitcoin-core-dev
dermoth has quit [Remote host closed the connection]
dermoth_ is now known as dermoth
<vasild_>
Chris_Stewart_5: jonatack: lightlike: sipa: Using port=11222 rpcport=22333 listenonion=0 bitcoind would still try to bind on 127.0.0.1:18445 (for regtest) and listen there for incoming onion connections.
cmirror has quit [Remote host closed the connection]
<vasild_>
thus the conflicting port 18445 when you start more than one bitcoind on the same machine
kevkevin has quit [Read error: Connection reset by peer]
cmirror has joined #bitcoin-core-dev
<vasild_>
this was the case before 28.0 as well, but there the bind error from the second bitcoind did not cause startup failure and most likely remained unnoticed
<vasild_>
the functional tests all had that bind errors but they did not matter because no test is using or needs that 127.0.0.1:18445, now the functional testing framework was tweaked a bit to avoid trying to bind on conflicting ports.
<vasild_>
to avoid the bind on 127.0.0.1:18445 use bind=127.0.0.1:11222 instead of port=11222 (listenonion is irrelevant, can be 0 or 1)
<vasild_>
or bind=0.0.0.0:11222 if you want to listen on all interfaces, but I guess this is not the case with regtest
<vasild_>
What listenonion=1 does is to automatically create the hidden service with the tor daemon, so that users don't have to manually add HiddenServiceDir and HiddenServicePort in their torrc. But it does not control where bitcoind listens, I think a name like -autotorservice would be more appropriate than -listenonion.
achow101 has quit [Ping timeout: 260 seconds]
achow101 has joined #bitcoin-core-dev
<vasild_>
A real problem with <28.0 that could happen is this: if two bitcoinds are started on the same machine with "port=10833 rpcport=10832 listenonion=1" and "port=20833 rpcport=20832 listenonion=1", then only the first would manage to bind on 127.0.0.1:8334. The second would "think" it did because the bind error was ignored. Due to listenonion=1 both will create a tor service, telling the tor daemon
<vasild_>
to redirect incoming connections to that service to 127.0.0.1:8334. For example first.onion:8333 -> 127.0.0.1:8334 and second.onion:8333 -> 127.0.0.1:8334.
<vasild_>
So all incoming tor connections for the second bitcoind would be redirected to the first bitcoind :/
<darosior>
Others: i initially wanted to report it here but since it had a release note and a simple fix, i figured the breakage was known and intentional.
hashfunc has quit [Remote host closed the connection]
<Chris_Stewart_5>
vasild: Definitely agree this was the behavior pre-28 and likely was silently failing.
<Chris_Stewart_5>
vasild: Kind of unexpected behavior imo that if -listenonion=0 we are still attempting to allocate resources for tor. I'm not an expert on the topic though so i'll defer i guess.
<Chris_Stewart_5>
vasild: Is there any way to keep 18445 from being bound besides using the 'bind' configuration setting?
<Chris_Stewart_5>
your point is taken though with the silent binding failure then redirecting tor traffic to the 1st bitcoind. Thats not good.
<achow101_>
I guess nothing to talk about this week
<achow101_>
no meeting next week
<achow101_>
#endmeeting
<instagibbs>
saving it up for next week
<emzy>
hi
<jonatack>
hi
<jonatack>
vasild: thank for looking into it. ping me if you open an improvement (agree with you offline that -listenonion is confusingly named. maybe a better named alias?)
<instagibbs>
sdaftuar1 I think the 3 ACKs really pushed it over the line, thanks ^
aleggg has joined #bitcoin-core-dev
<sipa>
and double approval
___nick___ has joined #bitcoin-core-dev
___nick___ has quit [Client Quit]
<instagibbs>
yes, very powerful
___nick___ has joined #bitcoin-core-dev
sdaftuar1 is now known as sdaftuar
<sdaftuar>
ack ack ack
<vasild>
< Chris_Stewart_5> vasild: Is there any way to keep 18445 from being bound besides using the 'bind' configuration setting? -- you mean to avoid the bind on 18445? Before 28.0 it was not possible. With 28.0 it is possible if you explicitly specify bind=
<vasild>
< Chris_Stewart_5> vasild: Kind of unexpected behavior imo that if -listenonion=0 we are still attempting to allocate resources for tor. -- If the hidden service is configured in the torrc then you need listenonion=0 to avoid auto creating another one
<vasild>
see "## 3. Manually create a Bitcoin Core onion service" in doc/tor.md
<Chris_Stewart_5>
vasild: cool, thanks!
<lightlike>
@vasild but why is it necessary for simple clearnet nodes that are not interested in Tor at all to stop startup if that port is not available? Wouldn't it be possible to detect if an onion service is running and only bind to the port if that is the case?
ion- has quit [Remote host closed the connection]
ion- has joined #bitcoin-core-dev
Guest82 has joined #bitcoin-core-dev
Guest82 has quit [Client Quit]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
jonatack has quit [Ping timeout: 265 seconds]
preimage has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #31067: test: Print CompletedProcess object on error (master...2410-test-print-err) https://github.com/bitcoin/bitcoin/pull/31067
<vasild>
lightlike: by default bitcoind binds on 0.0.0.0:8333 and 127.0.0.1:8334
jonatack has quit [Ping timeout: 264 seconds]
<vasild>
maybe your question should be rather "why is it necessary for simple clearnet nodes that are not interested in Tor at all to bind by default on 127.0.0.1:8334"?
ion- has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
<vasild>
"Wouldn't it be possible to detect if an onion service is running..." - that would probably involve finding the torrc, parsing it and seeing if some hidden service is redirected to 127.0.0.1:8334; and then the tor daemon and its torrc may be on a different computer
___nick___ has quit [Ping timeout: 252 seconds]
yuvic has joined #bitcoin-core-dev
yuvic has joined #bitcoin-core-dev
yuvic has quit [Remote host closed the connection]
___nick___ has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Talkless has joined #bitcoin-core-dev
ion- has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 248 seconds]
ion- has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
<lightlike>
Yes, that seems non-trivial. I'm just not convinced that the mere possibility of an onion service, that might be running or not, is reason enough to make long-established -port=x -port=y two-node setups impossible.
<lightlike>
Another option could be to disable the stricter bind failure for a DefaultOnionServiceTarget() derived address that was not provided by the user explicitly, and just display a warning in this case.
kevkevin has joined #bitcoin-core-dev
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
kevkevin_ has quit [Ping timeout: 252 seconds]
bugs_ has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
SpellChecker_ is now known as SpellChecker
ion-_ has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 252 seconds]
vstoyanov has quit [Ping timeout: 264 seconds]
darosior has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
<achow101_>
how do i use a secp (or other subtree) header in a header file? autotools had no issue with this.. not sure what to do in cmake.
achow101_ is now known as achow101
<sipa>
just #include <secp256k1.h> doesn't work?
<achow101>
doesn't seem to
<sipa>
it works in key.cpp, i'd be surprised it doesn't work in a .h file
<achow101>
/home/ava/bitcoin/bitcoin/musig2/src/pubkey.h:12:10: fatal error: secp256k1_musig.h: No such file or directory
<sipa>
you will need to confer with the Build People
<achow101>
fanquake: hebasto: ^
<achow101>
(and this branch has an updated secp256k1 subtree with the musig header)
<TheCharlatan>
wfm when I include <secp256k1.h> in pubkey.h
<achow101>
try any other secp header
<achow101>
`#include <secp256k1/include/secp256k1_musig.h>` works, but that seems wrong
Talkless has quit [Read error: Connection reset by peer]
ion-_ has quit [Remote host closed the connection]
ion- has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
ion- has quit [Ping timeout: 252 seconds]
jonatack has joined #bitcoin-core-dev
ion- has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 252 seconds]
ion- has joined #bitcoin-core-dev
ion- has quit [Ping timeout: 276 seconds]
bugs_ has quit [Quit: Leaving]
ion- has joined #bitcoin-core-dev
<hebasto>
achow101: mind sharing a branch?
<achow101>
hebasto: still working on it
<achow101>
it'll be the musig2 pr #29675
<gribble`>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<hebasto>
usage requirements of a library, say libsecp256k1, are propagated to a consumers via `target_link_library` command. So try to link `secp256k1` to the failed target
kevkevin has quit [Remote host closed the connection]
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
<achow101>
it should already be linked? pubkey.cpp already includes secp256k1 headers without issue
<achow101>
you can replicate by adding `#include <secp256k1_ecdh.h>` to pubkey.h
<achow101>
for some reason, adding `#include <secp256k1.h>` to pubkey.h works fine though
<achow101>
it seems a bit wrong to me to have to add secp256k1 to every target when adding it to the header. shouldn't all of those targets already link with secp?
<hebasto>
why to link if no symbols are referred directly?
kevkevin has quit [Ping timeout: 246 seconds]
<achow101>
they don't?
<hebasto>
for example, for the `bitcoind` target, non of its sources, `bitcoind.cpp` and `init/bitcoind.cpp` refers to symbols from libsecp256k1
<hebasto>
... directly
<achow101>
hmm ok
<achow101>
perhaps pubkey.h is not the right place to put this stuff since it seems that it would add secp to a bunch of libraries that otherwise don't directly use secp
ion- has joined #bitcoin-core-dev
ion- has quit [Remote host closed the connection]
ion- has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
gribble` has quit [Remote host closed the connection]