< achow101> under what circumstances would some script be in mapScripts that we would consider ISMINE_NO?
< achow101> I think the only case where that happens is addmultisigaddress
< achow101> oh, apparently I had enable-debug on my hashtable branch and that's what caused the slowdown
< sipa> achow101: that explains
< phantomcircuit> achow101, the debug stuff makes a few seemingly innocuous things comically slow
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a47e5964861d...dffefda21de0
< bitcoin-git> bitcoin/master 36f8e0c Jon Atack: doc: update PyZMQ installation instructions, ZeroMQ link
< bitcoin-git> bitcoin/master 062e669 Jon Atack: script: fix zmq_sub.py file permissions
< bitcoin-git> bitcoin/master dffefda fanquake: Merge #19870: doc: update PyZMQ install instructions, fix zmq_sub.py file ...
< bitcoin-git> [bitcoin] fanquake merged pull request #19870: doc: update PyZMQ install instructions, fix zmq_sub.py file permissions (master...zmq-doc-fix) https://github.com/bitcoin/bitcoin/pull/19870
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/dffefda21de0...9366a73d6951
< bitcoin-git> bitcoin/master a9f2014 eugene: build: use DIR_FUZZ_SEED_CORPUS if specified for cov_fuzz target
< bitcoin-git> bitcoin/master fb3bacc eugene: .gitignore: ignore qa-assets/ folder
< bitcoin-git> bitcoin/master 9366a73 fanquake: Merge #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fu...
< bitcoin-git> [bitcoin] fanquake merged pull request #19916: build: allow user to specify DIR_FUZZ_SEED_CORPUS for cov_fuzz (master...cov_fuzz_cleanup_0908) https://github.com/bitcoin/bitcoin/pull/19916
< fanquake> Looking for Qs / concerns / concept ACKs in #18605.
< gribble> https://github.com/bitcoin/bitcoin/issues/18605 | build: Link time garbage collection by fanquake · Pull Request #18605 · bitcoin/bitcoin · GitHub
< 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.
< jonasschnelli> going to address this
< bitcoin-git> [bitcoin] hebasto closed pull request #19193: qt: Deduplicate NumConnections enum (master...200606-numconn) https://github.com/bitcoin/bitcoin/pull/19193
< 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
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/9366a73d6951...f2d9934381bf
< bitcoin-git> bitcoin/master fa65a11 MarcoFalke: test: bugfix: Actually pick largest utxo
< bitcoin-git> bitcoin/master faba790 MarcoFalke: test: MiniWallet: Default fee_rate in send_self_transfer, Pass in utxo_to_...
< bitcoin-git> bitcoin/master fa56e86 MarcoFalke: test: Run rpc_txoutproof.py even with wallet disabled
< bitcoin-git> [bitcoin] laanwj merged pull request #19922: test: Run rpc_txoutproof.py even with wallet disabled (master...2009-testMoreMiniWallet) https://github.com/bitcoin/bitcoin/pull/19922
< yanmaani> If multiprocess gets merged, would it make sense to have bitcoin-gui deal with all (closely related) altcoins too?
< wumpus> out of scope of this project
< wumpus> jonasschnelli: thanks!
< luke-jr> yanmaani: no
< TallTim> Please don't cater to altcoins. Seriously.
< TallTim> There's enough shillers out there without the bitcoin wallet going all-in on crapconis.
< TallTim> crapcoins even.
< pinheadmz> https://github.com/bitcoin/bitcoin/pull/11413 merged into master but doesn't seem to be included in latest release v0.20.1?
< 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 ?
< jonatack> one sec
< bitcoin-git> [bitcoin] hebasto closed pull request #19891: depends: Fix `make --just-print` command (master...200906-dry) https://github.com/bitcoin/bitcoin/pull/19891
< jonatack> harding had a script but i misremember where it is... he'll know
< sipa> fanquake: a very old bug report about gc-sections in MinGW https://sourceware.org/bugzilla/show_bug.cgi?id=11539
< sipa> there is a patch too
< harding> jonatack, yanmaani, pinheadmz: longest open (but ultimately merged) PR I found was #9381
< gribble> https://github.com/bitcoin/bitcoin/issues/9381 | Remove CWalletTx merging logic from AddToWallet by ryanofsky · Pull Request #9381 · bitcoin/bitcoin · GitHub
< jonatack> harding: thanks!
< 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/19845 | net: CNetAddr: add support to (un)serialize as ADDRv2 by vasild · Pull Request #19845 · bitcoin/bitcoin · GitHub
< jonatack> sipa: 🚀
< jonatack> "New outbound peer connected: version: 70016, blocks=647799, peer=5, peeraddr=kpgvmscirrdqpekbqjsvw5teanhatztpp2gl6eee4zkowvwfxwenqaid.onion:8333 (full-relay)"
< phantomcircuit> glad the address section is variable length
< sipa> phantomcircuit: lol, yes
< phantomcircuit> when i first saw that pr i was kind of worried it would just be a bump to 256
< phantomcircuit> then someone will go "but i need 384!"
< sipa> BIP155 supports up to 512 bytes addresses, but clients will ignore unknown networks/lengths
< meshcollider> #startmeeting
< lightningbot> Meeting started Fri Sep 11 19:00:09 2020 UTC. The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< meshcollider> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball ariard digi_james amiti fjahr
< meshcollider> jeremyrubin emilengler jonatack hebasto jb55 kvaciral ariard digi_james amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< achow101> hi
< meshcollider> Topics?
< jonatack> hi
< achow101> #19077 is ready for review again
< 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> perhaps it is!
< vasild> Which piece of BIP155 looks like (a)?
< bitcoin-git> [bitcoin] sipa opened pull request #19944: Update secp256k1 subtree (including BIP340 support) (master...202009_secp256k1_schnorr) https://github.com/bitcoin/bitcoin/pull/19944
< 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> sipa: https://2019.www.torproject.org/docs/tor-manual.html.en search for "TransPort [address:]"
< 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
< phantomcircuit> i cant recall what they are tho
< 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