< fanquake>
We haven't made it to LTO yet, but this should be a (less risky) step in that sort of direction.
< sipa>
fanquake: seema like a no brainer if it reduces binary sizes
< sipa>
you mention that gc sections increases the binary size... by much?
< fanquake>
sipa: yea for Windows. I can't remember exactly, but will rebuild and expand the note in the PR description.
< fanquake>
sipa: bitcoind.exe is 12.69mb building master + link time gc (minimal depends), vs 11.50mb building master
< sipa>
interesting
< sipa>
that's pretty significant
< sipa>
but only on windows?
< fanquake>
Yea. Rebuilding Linux to now to double check the reductions.
< fanquake>
That was also done with binutils 2.34, so quite a new version.
< fanquake>
Linux: master (minimal depends) + link time gc is 6.85mb vs 7.25mb
< jonasschnelli>
it looks like StartWallets (bitcoin-qt`StartWallets(scheduler=0x00007fc10b28df90, args=0x000000010fda5780) at load.cpp:96:18 [opt]) does delay the opening of the main window in the GUI
< jonasschnelli>
I though we had this fixed
< jonasschnelli>
if there would just be sort of automated test to prevent those regressions (if it is one)
< jonasschnelli>
catching up 15k blocks on mainnet via the master GUI is pain in the ass. It freezes constantly.
< wumpus>
yea gc-sections can increase binary size if pretty much all sections are used anyway: putting things in separate sections can reduce packing efficiency, especially for data structures
< wumpus>
then again, it's surprising to see it happen in practice
< wumpus>
clearly the windows linker is worse at packing structures tightly into memory than gcc
< sipsorcery>
isn't the gcc linker still used to cross compile for Windows?
< wumpus>
oh correct (the binutils linker)
< bitcoin-git>
[bitcoin] prayank23 opened pull request #19939: Remove connect_nodes global and replace connect_nodes(self.nodes[a], b) with self.connect_nodes(a, b) (master...master) https://github.com/bitcoin/bitcoin/pull/19939
< wumpus>
jonasschnelli: i'm trying to compile your mempool graph branch but get an error about missing #include <qt/forms/ui_mempoolstats.h>
< jonasschnelli>
Yeah. The makefile commit was missing.
< jonasschnelli>
wumpus: I pushed a new version
< jonasschnelli>
It’s heavy WIP
< bitcoin-git>
[bitcoin] gzhao408 opened pull request #19940: rpc: Return fee and vsize from testmempoolaccept (master...rpc-testmempoolaccept-fee) https://github.com/bitcoin/bitcoin/pull/19940
< sipa>
pinheadmz: 0.x.y releases are for bugfixes
< sipa>
master is the development branch for 0.21.0 currently
< pinheadmz>
I see, and 0.20 cutoff was before this was merged
< sipa>
select bugfixes get backported to the 0.20 (and possibly 0.19) release branches
< pinheadmz>
i was wondering about backports: will users really re-install an old version to get a bugfix instead of just upgrading to latest?
< luke-jr>
pinheadmz: Knots backports features
< luke-jr>
and yes, especially when the latest is the backport :P
< sipa>
pinheadmz: i think they're pretty rare overall, but it certain has happened that someome upgrades, notices that some change breaks things for them, and they temporarily(?) revert to an older major release
< luke-jr>
there's a total of 24 nodes using 0.17.2 today (the last non-latest backport release)
< jonatack>
pinheadmz: some trivia, per harding, 11413 was the second longest-open PR in bitcoin core history
< luke-jr>
not very meaningful IMO considering how long it's been
< yanmaani>
jonatack: what's the oldest?
< pinheadmz>
jonatack lol thank you. and the first ?
< bitcoin-git>
[bitcoin] prayank23 closed pull request #19939: Remove connect_nodes global and replace connect_nodes(self.nodes[a], b) with self.connect_nodes(a, b) (master...master) https://github.com/bitcoin/bitcoin/pull/19939
< * sipa>
has a TORv3 bitcoind service: kpgvmscirrdqpekbqjsvw5teanhatztpp2gl6eee4zkowvwfxwenqaid.onion
< sipa>
you can connect with -addnode/-connect on #19845
< gribble>
https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
< meshcollider>
great \o/
< achow101>
Anyone want to bikeshed over what to use as the application_id?
< luke-jr>
UnitedStatesDollar.com ? /s
< sipa>
achow101: application_id is a byte array?
< sipa>
or a number?
< phantomcircuit>
hola
< achow101>
sipa: it's a big endian int32
< phantomcircuit>
547796124
< achow101>
right now I have it set to the network magic forced into an int
< sipa>
network magic seems great
< achow101>
so that also means that other network wallets can't be opened
< achow101>
which is probably a good thing
< meshcollider>
Yeah network magic sounds good
< sipa>
yeah
< phantomcircuit>
ack
< achow101>
great
< luke-jr>
application id prevents opening? O.o
< luke-jr>
CLI sqlite tool should still work, right?
< achow101>
luke-jr: no, but we can check that it matches what we expect and then error if we don't like it
< luke-jr>
k
< achow101>
general sqlite tools should still work
< meshcollider>
Alright no other topics?
< meshcollider>
Enjoy the weekend everyone :)
< meshcollider>
#endmeeting
< lightningbot>
Meeting ended Fri Sep 11 19:08:49 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< vasild>
sipa: jonatack: so you have started manual gossiping over irc ang github ;-)
< vasild>
of torv3 addresses
< jonatack>
3 of last 4 blocks received from that tor v3 service too, seems well connected
< jonatack>
more than any other i'm connected to
< phantomcircuit>
jonatack, that's uh
< phantomcircuit>
the fuck
< phantomcircuit>
should not happen
< sipa>
jonatack: it is
< jonatack>
phantomcircuit: i just turned it on and it's an onlynet=onion, so only 20 peers. the one other block of the last four was from a wumpus node
< sipa>
vasild: the way i see it, the P2P is just lagging behind a bit due to no BIP155, but we can easily circumvent that now ;)
< sipa>
vasild: my comment about TORv2 and IPv4 is this... if someone sends us an IPv6 address in an ADDRv2, but it contains an address from the OnionCat range or the embedded IPv4 range... should we (a) ignore it (b) treat it as TORv2/IPv4 (c) treat it as just an IPv6 address in a weird range
< sipa>
i don't know what the answer is to that question, but i suspect that the current PR doesn't actually does things consistently
< vasild>
I think (c)
< sipa>
BIP155 makes it sound like (a), at least for TORv2
< vasild>
in order of preference: (c) (a) (b)
< vasild>
"doesn't actually does things consistently" -- where?
< sipa>
hmm, i forgot that all the class checks now use the network type too
< sipa>
Clients SHOULD ignore OnionCat (fd87:d87e:eb43::/48) addresses on receive if they come with the IPV6 network ID.
< vasild>
ah! that is pretty explicit
< vasild>
I have missed it
< vasild>
Should we ignore only torv2, or also embedded ipv4?
< wumpus>
embedded ipv4 in ipv6 should also be ignored
< wumpus>
if there's a seperate address type for something that must be used
< wumpus>
anything else is wasteful and confusing
< jonatack>
+1
< vasild>
ok, I can detect that during unserialize and overwrite it with 16 zeroes, which is later !IsValid()
< vasild>
or throw?
< sipa>
i'd say !IsValid
< vasild>
should we parse subsequent addresses from a msg_addr that contains such embedded?
< vasild>
does not look too hostile, maybe keep parsing subsequent addresses
< sipa>
agree
< luke-jr>
does OnionCat exist for Torv3?
< sipa>
luke-jr: pretty hard to pack 32 bytes in an IPv6 range :)
< sipa>
(that was the motivation for BIP155 in the first place)
< luke-jr>
so I guess no longer possible to just have a router route over Tor :x
< wumpus>
luke-jr: well, Tor actually does this if you enable TransPort and route through it using iptables, but intead of embedding the address, it uses some NAT-like trickery where the DNS for an .onion address returns a temporary address
< wumpus>
in any case that scenario is, and was never, supported by bitcoind
< luke-jr>
ah
< sipa>
wumpus: "TransPort tor" is reallyhard to search for
< wumpus>
if you want to sandbox bitcoind to only be able to connect to TOr it's better to put it in a network namespace that only forwards the SOCKS5 port and doesn't allow direct connections to the internet
< wumpus>
-onlynet=onion works, of course, but I mean if you'd want to be 100% sure
< wumpus>
(yes, using that approach is kind of discouraged)
< wumpus>
it can be useful for selective tor-ificiation of applications but never use it for the entire system
< bitcoin-git>
[bitcoin] prayank23 opened pull request #19945: Remove connect_nodes global and Replace connect_nodes(self.nodes[a], b) with self.connect_nodes(a, b) (master...master) https://github.com/bitcoin/bitcoin/pull/19945
< luke-jr>
wumpus: I was thinking entire network :P
< phantomcircuit>
sipa, is there a standard in addrv2 for the nonv3 onion addresses?
< phantomcircuit>
wumpus, there's some dns things that always return ipv4 as the ipv4inipv6 thing
< wumpus>
phantomcircuit: that's not relevant here, we don't do DNS lookups for bitcoin nodes, and in any case, how a DNS returns is separate from how they're gossiped (which is all that BIP155 is about)
< phantomcircuit>
i'd drop them then, treating them as weird ipv6 might cause issues if someone sets up an ipv6<->onion thing
< wumpus>
yes, I think that's what vasild is doing, just ignoring them
< wumpus>
phantomcircuit: oh maybe the DNS seeds do? sorry, yes that would be somewhat relevant, though, I think the implementation of CAddr was already changed that everything that looks like IPv4-in-IPv6 received in a legacy way is stored as a IPv4 address
< sipa>
wumpus: indeed
< wumpus>
DNS seeds can never handle the longer addresses anyway
< phantomcircuit>
wumpus, yeah i was thinking things might get messed up by a dns server responding to a host request with ipv4 in ipv6 things and them being ignored
< sipa>
when constructing a CNetAddr from socket-layer data structures, they get converted correctly
< phantomcircuit>
i think that's easily resolved by making sure they're stored as ipv4 though
< phantomcircuit>
ok
< wumpus>
right
< sipa>
i wonder how much of a bandwidth savings BIP155 will be
< sipa>
at IPv4 addresses will now be sent as 6 bytes instead of 16, and TORv2 addresses as 12 instead of 16
< vasild>
how much % are IPv4 vs IPv6?
< sipa>
IPv6 goes from 16 to 18 though
< sipa>
vasild: i don't know; most are IPv4 i think
< jonatack>
ipv4 dominates my outbounds. inbounds they all look like ipv6 so can't say.
< wumpus>
i guess we could have saved a byte by not sending the length for fixed-size address types, though, i didn't do that because it makes it ambigious how to handle unknown address types
< vasild>
netstat shows about 20ish ipv4 connections here and 0 ipv6
< phantomcircuit>
sipa, i mean the entire network protocol could probably be runlength encoded and actually get something
< vasild>
the ignorance tweak (of embedded ipv4 and torv2 in ipv6) compiled here and some basic tests pass, pushed
< wumpus>
let's try to get to P2P encryption first … seems already difficult enough process, let alone compression, compression opens quite some vulnerability vectors if done carelessly
< wumpus>
fwiw incoming connections: ipv4 80 ipv6 12 tor 14 on my only node that has ipv6
< sipa>
wumpus: indeed
< jonatack>
wumpus: incoming or outbound? (how do you distinguish between inbound ipv4 and ipv6?)
< vasild>
80*16 + 12*16 + 14*16
< vasild>
1696
< vasild>
80*6 + 12*18 + 14*12
< vasild>
864
< vasild>
it's double
< vasild>
assuming that's the same percentage of gossiped addresses
< vasild>
is there a way to dump all addrman database in a human readable form?
< vasild>
s/all/the entire/
< yanmaani>
luke-jr: It does, but it has a separate lookup table