< bitcoin-git> [bitcoin] luke-jr opened pull request #21028: doc/bips: Add BIPs 44, 49, and 84 (master...bips_44-49-84) https://github.com/bitcoin/bitcoin/pull/21028
< bitcoin-git> [bitcoin] luke-jr opened pull request #21029: bitcoin-cli: Correct docs (no "generatenewaddress" exists) (master...cli_doc_geNnewaddr) https://github.com/bitcoin/bitcoin/pull/21029
< bitcoin-git> [gui] RandyMcMillan opened pull request #202: peers-tab: bug fix right panel toggle (master...peers-tab-sidepanel) https://github.com/bitcoin-core/gui/pull/202
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e21338292015...bc5f26d4eee5
< bitcoin-git> bitcoin/master 5d1f260 Jarol Rodriguez: Improve gui/src/qt README.md
< bitcoin-git> bitcoin/master bc5f26d MarcoFalke: Merge bitcoin-core/gui#139: doc: Improve gui/src/qt README.md
< bitcoin-git> [gui] MarcoFalke merged pull request #139: doc: Improve gui/src/qt README.md (master...improve-qt-readme) https://github.com/bitcoin-core/gui/pull/139
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bc5f26d4eee5...40dd757bf6ce
< bitcoin-git> bitcoin/master faff399 MarcoFalke: ci: Fuzz with integer sanitizer
< bitcoin-git> bitcoin/master 40dd757 MarcoFalke: Merge #21012: ci: Fuzz with integer sanitizer
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21012: ci: Fuzz with integer sanitizer (master...2101-fuzzIntSan) https://github.com/bitcoin/bitcoin/pull/21012
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/40dd757bf6ce...c8b83510f42c
< bitcoin-git> bitcoin/master a410ae8 Anthony Towns: net, net_processing: log disconnect reasons with -debug=net
< bitcoin-git> bitcoin/master f7edea3 Anthony Towns: net: make debug logging conditional on -debug=net
< bitcoin-git> bitcoin/master 1230210 Anthony Towns: net_processing: additional debug logging for ignored messages
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20724: Cleanup of -debug=net log messages (master...202012-net-log-cleanup) https://github.com/bitcoin/bitcoin/pull/20724
< bitcoin-git> [bitcoin] fanquake opened pull request #21030: refactor: move load block thread into ChainstateManager (master...revive_marco_val_loadblock_thread) https://github.com/bitcoin/bitcoin/pull/21030
< bitcoin-git> [bitcoin] RonSherfey opened pull request #21031: Merge #20724: Cleanup of -debug=net log messages (master...crazy) https://github.com/bitcoin/bitcoin/pull/21031
< bitcoin-git> [bitcoin] fanquake closed pull request #21031: Merge #20724: Cleanup of -debug=net log messages (master...crazy) https://github.com/bitcoin/bitcoin/pull/21031
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #20630: Allow providing local signatures in gitian osx signer (master...2020/12/macos_gitian_signer) https://github.com/bitcoin/bitcoin/pull/20630
< vasild> jnewbery: hmm
< vasild> Looks like fuzz input is not a good input to fill addrman with 1000s of different, routable addresses. Quite often the fuzz bytes are zero which result in a which is not routable and also the fuzzing input is exhausted way too quickly.
< vasild> What about getting some 100 or 1000 bytes of fuzz input, seeding that into a deterministic random number generator and from that generator produce 1000s of addresses?
< vasild> This way we will never run out of "random" bytes and also, I guess, there will be not big areas of 0s bytes to generate duplicate or non routable addresses.
< jnewbery> vasild: you're right about !restore_bucketing. Thanks!
< jnewbery> I don't know much about the fuzzers but I assume there's a way to make the fuzzer itself a bit more intelligent in generating routable addresses, or giving it a seed that results in more routable addresses being generated?
< vasild> fuzzed_data_provider.AvoidLongSequenceOfZerosPlease()
< stevenroose> It seems that with my latest libboost (Arch...) I can no longer build bitcoind v0.16.3. I previously had to add the `#include <deque>;` before but now there's some other errors relating to `BOOST_PRAGMA_MESSAGE`.
< aj> stevenroose: add "--enable-suppress-external-warnings" to your configure command?
< stevenroose> one sec yeah I just noticed it's not an error about the torcontrol.cpp code but about the boost code
< stevenroose> aj: Giving me a lot of `error: ‘_2’ was not declared in this scope` errors all over the place. Seems to be some kind of argument templating that is broken
< aj> stevenroose: oh :( --enable-suppress fixed the qt and boost warnings i was seeing
< luke-jr> stevenroose: bitrot is real :P
< stevenroose> hmm. I can retry with the entire autogen but I'm doubtful. Does a depends build fix this?
< aj> oh, sorry, didn't see that it was an old bitcoind as well as a new boost. depends build sounds worth trying; should get you the old boost
< luke-jr> does fuzz normally take a LONG time to build?
< sipa> not as long anymore as before the targets were merged in a separate binary
< phantomcircuit> luke-jr, define LONG
< luke-jr> phantomcircuit: it's still building :P
< luke-jr> sipa: I'm seeing lots of binaries produced - was that something that happened recently on master?
< sipa> luke-jr: yes, on master it's now a single binary
< sipa> which is much faster to build
< luke-jr> i c
< meshcollider> Wallet meeting today?
< jonatack> hi
< emzy> hi
< meshcollider> #startmeeting
< S3RK> hi
< meshcollider> #bitcoin-core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
< meshcollider> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< jonatack> hi
< meshcollider> Hi :)
< achow101> hi
< kanzure> hi
< meshcollider> Any topics?
< jonatack> meshcollider: you're back! i was a bit worried about you
< jonatack> hope it was good
< meshcollider> jonatack: yeah sorry! A few family things came up so I was MIA for a bit, but I'm back now
< meshcollider> Any high priority wallet PRs that you'd like to review-beg for
< achow101> #20040 but you already know that
< gribble> https://github.com/bitcoin/bitcoin/issues/20040 | wallet: Refactor OutputGroups to handle fees and spending eligibility on grouping by achow101 · Pull Request #20040 · bitcoin/bitcoin · GitHub
< jonatack> #20391 here
< gribble> https://github.com/bitcoin/bitcoin/issues/20391 | wallet: introduce setfeerate (an improved settxfee, in sat/vB) by jonatack · Pull Request #20391 · bitcoin/bitcoin · GitHub
< meshcollider> Yep and I know #19136 is nearly ready too
< gribble> https://github.com/bitcoin/bitcoin/issues/19136 | wallet: add parent_desc to getaddressinfo by achow101 · Pull Request #19136 · bitcoin/bitcoin · GitHub
< jonatack> achow101: will get to that one soon
< jonatack> #19145 seems close too
< gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr · Pull Request #19145 · bitcoin/bitcoin · GitHub
< jonatack> maybe not "wallet"
< meshcollider> Sweet
< meshcollider> Obviously things are pretty quiet in the repo at the moment but anything anyone wants to discuss?
< meshcollider> I'd really like to push to finally get #16546 in, in the next few weeks
< gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
< achow101> I've been working on getting HWI back up to date
< achow101> spent the past week fixing CI
< meshcollider> I saw your tweet about some debatable firmware updates yeah
< achow101> the next HWI release is going to be API breaking, but hopefully not too bad
< TallTim> Is there a schedule for Schnorr/Taproot activation?
< TallTim> Just curious.
< meshcollider> TallTim: unfortunately that's not up to us, that is a discuss for the mailing list and wider community
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c8b83510f42c...16b784d95336
< bitcoin-git> bitcoin/master c84838e Sebastian Falbesoner: contrib: binary verification script verify.sh rewritten in python
< bitcoin-git> bitcoin/master c86b9a6 Sebastian Falbesoner: contrib: remove verify.sh
< TallTim> Okay.
< bitcoin-git> bitcoin/master 16b784d Wladimir J. van der Laan: Merge #20689: contrib: replace binary verification script verify.sh with p...
< bitcoin-git> [bitcoin] laanwj merged pull request #20689: contrib: replace binary verification script verify.sh with python rewrite (master...202012-contrib-replace-verify-binaries-script-with-python) https://github.com/bitcoin/bitcoin/pull/20689
< meshcollider> Alright seems noone else is around or has any topics so let's end here
< meshcollider> #endmeeting
< S3RK> Any newbie friendly PRs to review?
< achow101> #19136 and #20205 aren't that bad
< gribble> https://github.com/bitcoin/bitcoin/issues/19136 | wallet: add parent_desc to getaddressinfo by achow101 · Pull Request #19136 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20205 | wallet: Properly support a wallet id by achow101 · Pull Request #20205 · bitcoin/bitcoin · GitHub
< jonatack> S3RK: i think 20391 is pretty accessible
< meshcollider> The wallet id is a bit contentious
< meshcollider> Did the meeting bot end?
< jonatack> achow101: i'll try to review both your high priority ones this weekend
< S3RK> I looked at 19136 previously, not a big fan on expanding toString method. I've tried an alternative approach but it's not better
< achow101> the meeting bot PMs people now
< meshcollider> #endmeeting
< jonasschnelli> achow101: how so?
< jonasschnelli> the startmeeting or what PM do you get?
< achow101> jonasschnelli: the chair gets a pm at the start at least
< meshcollider> jonasschnelli: a list of commands when you start the meeting
< achow101> oh it doesn't do that at the end
< jonasschnelli> ah. yes. That should be the case but might got muted due to channel settings
< meshcollider> But absolutely nothing happened at the end so I think it's glitched, normally it replies with the minutes links
< jonasschnelli> oh.. yes. thats strange
< jonasschnelli> lemmecheck
< achow101> meshcollider: the wallet id is at least a non-dangrous change I think. the contention is whether we should have one
< jonasschnelli> but it looks like the core-meetingbot has no voice right
< jonasschnelli> core-meetingbot: pin
< jonasschnelli> core-meetingbot` ping
< jonasschnelli> whats that ` after the name?
< TallTim> thx jonatack
< meshcollider> achow101: yep exactly, I find myself leaning toward ryanofsky's arguments
< jonatack> (and https://bitcoinops.org/en/topics/taproot/ is a good general resource)
< roconnor> luke-jr: let me know if this is off-topic, but can't you build the guix bootstrap tarball on your own system? Or is it not deterministic yet?
< jonasschnelli> owner ircquote nickserv identify core-meetingbot Meet!303
< jonasschnelli> ignore
< jonasschnelli> *sight*
< jonasschnelli> *sigh*
< jonasschnelli> ping core-meetingbot
< jonasschnelli> #startmeeting
< jonasschnelli> #endmeeting
< jonasschnelli> #startmeeting
< core-meetingbot> Meeting started Fri Jan 29 19:38:36 2021 UTC. The chair is jonasschnelli. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< jonasschnelli> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Fri Jan 29 19:38:38 2021 UTC.
< jonasschnelli> done
< sipa> short meeting is best meeting
< jonasschnelli> exactly
< luke-jr> roconnor: I couldn't figure out a way to
< luke-jr> jonasschnelli: might I suggest a better password scheme for the bot? :P
< jonasschnelli> :P
< dongcarl> testing codesigning right now... Does anyone know if there's a way to generate test-only signatures for win/osx?
< dongcarl> ping achow101 jonasschnelli
< achow101> dongcarl: for mac, you can get a dev signing cert through xcode
< achow101> I don't know for windows
< provoostenator> meshcollider: thanks for the hardware wallet PR shoutout, I'll keep addressing review comment.
< dongcarl> achow101: Do you have a link/doc I can reference?
< dongcarl> thx
< roconnor> luke-jr: https://guix.gnu.org/manual/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html says `guix build boostrap-tarballs` will build the bootstrap tarballs.
< roconnor> Perhaps the build log for that process would let you rederive those tarballs without the use of guix.
< roconnor> I don't know. I'm specualing a little based on what I would do if this were NixOS instead of Guix.
< luke-jr> roconnor: that assuems you have guix already
< luke-jr> roconnor: I did try :P
< roconnor> I mean, in theory you just need someone to give you the build log to figure out how they are built.
< luke-jr> I also need to figure out how to get guix to accept the hash :P
< luke-jr> at least when I was trying this, they didn't have hashes defined for ppc64le
< roconnor> oh were you able to build the tarballs?
< luke-jr> no
< luke-jr> IIRC I was trying to inject raw binaries
< luke-jr> the design of Guix is kinda weird
< luke-jr> they hash the input data rather than the output
< luke-jr> things could be much simpler if they hashed the output
< roconnor> Again speculating based on how Nix works, there are two (techinically three) different kinds of outputs. Fixed-derivation outputs hash the ouput, while say "non-determinisitc" packages hash the inputs.
< luke-jr> Guix is supposed to be deterministic-only IIRC
< roconnor> And if Guix solved the reproducible bootstrap libraries, they they have a fixed derivation (ie hashed output) at some point in their bootstrap process.
< luke-jr> I'm not sure at this point how much (if any) overlap it has with Nix
< * luke-jr> wonders if there is an actual reason behind the weird domain-specific language stuff in Guix
< roconnor> I would be suprised if Guix were determinisitic in general.
< roconnor> *lol* Guix is main difference between Nix was that it was supposed to *not* be using a domain-specific langauge thing, but using scheme instead.
< luke-jr> scheme is a DSL when nothing else uses scheme
< roconnor> Frankly my undertanding of the reasons Guix exists strike me as silly. But maybe I misunderstand them.
< roconnor> I think your observation makes it clear that if learning the Nix langauge is a hurdle for using NixOS, then switching to Scheme isn't helping.
< luke-jr> I suspect if I were to switch to a Nix/Guix-alike for my OS, I would end up writing something from scratch :p
< sipa> roconnor: i think you may be right, but in the end, the reason for why it started existing isn't as interesting for us as the question for why you'd use it; and the (as i understand it) more deterministic/bootstappability of what is built around the package manager is much more relevant than nix language vs. scheme
< roconnor> Right I was about to say, for the purposes of this discussion Guix has (AFAIU) made far more headway on minimising the bootstrap and reproducibility.
< luke-jr> I also find it strange how it wants root.
< luke-jr> dongcarl: yes, it's possible, but the main design/docs seem to want it
< sipa> dongcarl: what is a .org file?
< luke-jr> "If apache depends on an ssl library, the link is fully referenced in the apache binary. There is no way to circumvent the pointer to the library."
< luke-jr> facepalm
< roconnor> Ya nixos wants root in order to access /nix/store and to set various sticky bits to protect it. You can run outside of /nix/store, but then you cannot download prebuilt binaries because the RPATHs will be all wrong. Though for you luke-jr you probably don't want to download prebuilt binaries.
< luke-jr> RPATHs seem like a bad idea anyway :P
< dongcarl> That's mostly because the guix-daemon was modeled to be compatible with the nix-daemon, which wants root. I speculate one of the reasons is because it needs to do the namespace+cgroups container thing which and distros were having a spat over whether or not to enable USER_NS
< roconnor> yes. When I learn about how Unix systems work, I feel sad.
< luke-jr> roconnor: well, most systems just figure out the lib path at runtime
< roconnor> is that true?
< luke-jr> no reason Guix couldn't do that too
< luke-jr> yes..?
< luke-jr> I mean, there's ldconfig, but it's not embedding the path in the binaries
< roconnor> I was under the impression the answer was no, but this is also the sort of thing I wouldn't know.
< luke-jr> RPATHs aren't non-existent, but fairly rare
< roconnor> Otherwise I don't understand why every binary I download needs patchelf.
< luke-jr> roconnor: because your system isn't doing the job of resolving it? :p
< luke-jr> I have never heard of anyone having to patchelf binaries
< roconnor> well you don't download binaries. :D
< luke-jr> I don't, but other people do
< sipa> what is patchelf?
< luke-jr> roconnor: just take our release binaries for example
< luke-jr> roconnor: they just run fine on a normal Linux system
< luke-jr> (while we do static link some libs, it isn't all of them)
< roconnor> right, but AFAIU they all hardcode paths to /usr/lib or /lib
< roconnor> and in normal unix systems this works.
< luke-jr> nope
< dongcarl> roconnor: Right, nix and guix binaries both share this trait of doing the -rpath and setting a weird dynamic linker. Both these behaviours are thoroughly reverted in the Bitcoin Core guix build
< dongcarl> roconnor: specifically: -Wl,--dynamic-linker=
< luke-jr> $ ldd /usr/bin/zip linux-vdso64.so.1 (0x00007fff9cb70000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fff9ca50000) libnatspec.so.0 => /usr/lib64/libnatspec.so.0 (0x00007fff9ca00000) libc.so.6 => /lib64/libc.so.6 (0x00007fff9c800000) /lib64/ld64.so.2 (0x00007fff9cb90000)
< luke-jr> the path stored in the binary is the part before the =>
< harding> sipa: A .org file is a document formatted using Emacs's org-mode syntax.
< sipa> harding: interesting; any advantages it has over markdown e.g.
< sipa> ?
< roconnor> luke-jr: oooh, Mabe this doesn't work on NixOS because there are no canonical versions of linked libraries.
< luke-jr> roconnor: /lib64/ld64.so.2 is stored absolute, but that lib itself does the resolving of everything else
< sipa> dongcarl: so is it fair to say that guix (and the binaries it builds) are all living in their own little world, and are unconventional in that they're all built to live the... but what we want for the bitcoin core release builds isn't so much building something that lives there, but using the guix-world stuff to build a "normal" binary?
< luke-jr> roconnor: if I were making NixOS, I would modify the ld*.so* to understand Nix's structure ;)
< roconnor> I mean, which libraries are you going to link with?
< luke-jr> roconnor: the ones the binary in question's package depends on?
< luke-jr> I'm assuming you have dep info for everything installed..
< harding> sipa: not IMO. Early org mode preceeds markdown and I think markdown is a bit less noisy. However, if you really learn org-mode---which I never did---it makes it very easy to manage even huge .org documents.
< sipa> harding: okay, won't bother then :)
< luke-jr> roconnor: and if you really want to run a foreign binary, you could have Nix make a guess which libs to use, or ask you
< dongcarl> sipa: Correct! Eventually we can introduce a new build system in Guix (https://guix.gnu.org/manual/en/html_node/Build-Systems.html) to build a "normal" binary, but I didn't bother since the current way emulates how we do Gitian builds and I wanted to take things one step at a time.
< dongcarl> sipa: This is also why we can't just use the bitcoin-core package currently in Guix :-)
< roconnor> luke-jr: I mean where would you store that meta-information of which exact version (by hash) that the binary wants to use? How about in the binary? :P
< luke-jr> roconnor: then it's a pain if you want to use that package in a situation it wasn't made for
< luke-jr> eg, if you want to quickly update a security flaw in a lib
< roconnor> well I suppose that is a point of design contention.
< dongcarl> luke-jr: The security flaw case is solved by grafts in Guix: https://guix.gnu.org/en/blog/2020/grafts-continued/
< dongcarl> Not sure if Nix has something similar
< luke-jr> roconnor: being flexibile enough to do it, does not require you to do it
< roconnor> FWIW, using "replace runtime dependency" I can do quick updates in minutes (unfortately slower than seconds)
< luke-jr> I suspect Gentoo may be closer to the ideal than Nix/Guix
< dongcarl> luke-jr: Perhaps you should write the stage0 bootstrap up to Gentoo's bootstrap bins :-)
< roconnor> Maybe. Blindly replacing runtimes dependencies out from under software is both a security flaw and a security solution.
< roconnor> dongcarl: presumably Nix's replace-runtime-dependendy and Guix Grafts are similar (at least in spirit).
< roconnor> replace-runtime-depencency creates a new derviation using the binary of the old derivation as input and does a search and replace on hash values. :P
< roconnor> This sort of has to be done recurively throughtout the entire system's dependencies, which is why it takes minutes instead of seconds.
< roconnor> luke-jr: thanks. I didn't realize that ldd was doing the resolution of names rather than extracting the contents of the executible.
< bitcoin-git> [bitcoin] ryanofsky opened pull request #21035: Remove pointer cast in CRPCTable::dumpArgMap (master...pr/argmap) https://github.com/bitcoin/bitcoin/pull/21035