copumpkin: Sure, happy to chat, we can also go to #bitcoin-builds, where bitcoin build systems people hang out :-)
Hi copumpkin, the main (by a large margin) reason is because of Guix's commitment towards bootstrappability at the time I was investigating it as a possible build system for Bitcoin. At that time I had used Nix for a couple of years, and would have preferred to use Nix due to familiarity, but unfortunately there was less of an effort to make it
is there a writeup somewhere on guix vs. nix from a bitcoin dev perspective?
bitcoin/master 506e658 Jon Atack: gui: display plain "Inbound" in peer details
bitcoin/master 6c61408 Jonas Schnelli: Merge bitcoin-core/gui#203: Display plain "Inbound" in peer details
you're right of course that using the same key in schnorr and ecdsa should be discouraged (i personally expect it is not less secure than just ecdsa with that key, but i also don't think anyone has formally analyzed this)... but in the context of bitcoin script signing, this advice is sort of preempted by the fact that you shouldn't be reusing keys _at all_ for whatever purpose
it's nice that we can export all the metadata into bitcoin-gh-metadata, but it's only moderately useful until there are other bug trackers/review platforms that can import it and reconstruct all of the cross-references.
"works offline: in a plane or under the sea? Keep reading and writing bugs!" is nice, sure we can do this sort of by cloning bitcoin-gh-metadata but only in one way
cguida: #bitcoin-core-pr-reviews seems like the appropriate channel to comment, as i believe that's where the original discussion would have happened (and that's the irc home of the pr review club)
Between Noon and 5 pm EST on March 30th (Tuesday).. There will be a remote speaking opportunity for a bitcoin core developer at a "Open Source 101" event. The idea would be someone who can explain about how the project is maintained, how people can contribute, why it's important, etc. Less about the bitcoin tech and more about the project and contribution to the project. I imagine history would also be a very interesting piece
[bitcoin] practicalswift opened pull request #21068: Add GitHub Codespaces integration to allow for easy onboarding of future generations of contributors (master...github-codespaces) https://github.com/bitcoin/bitcoin/pull/21068
[bitcoin] practicalswift opened pull request #21041: log: Move "Pre-allocating up to position 0x[…] in […].dat" log message to debug category (master...pre-allocation-up-to-position-0xff-in-foo.dat) https://github.com/bitcoin/bitcoin/pull/21041
sipa: This is also why we can't just use the bitcoin-core package currently in Guix :-)
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?
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