< belcher>
when will 0.20.1 be released? (sorry if it was answered earlier i wasnt able to follow)
< harding>
belcher: do you mean 0.21.1? (0.20.1 was released months ago).
< belcher>
derp, yes
< belcher>
the node which has ST
< fanquake>
I haven't heard any issues in regards to the rc1. Likely be discussed in the meeting tomorrow. If we bump to final after that, then a day or two for gitian builds, and 0.21.1 could be released just after that.
< BlueMatt>
big week
< aj>
fanquake: only issues i've seen are code signing ones
< bitcoin-git>
[bitcoin] fanquake opened pull request #21793: build: use `-isysroot` over `--sysroot` on macOS (master...macos_use_isysroot) https://github.com/bitcoin/bitcoin/pull/21793
< fanquake>
Change a couple "-"s to "i"s and magically you've fixed "dark mode" on macOS
< fanquake>
Hopefully this is the end of that debacle
< promag>
when running make on depends I get this:
< promag>
libtool: warning: remember to run 'libtool --finish /Users/joao/Projects/bitcoin/depends/arm-apple-darwin20.3.0/lib'
< bitcoin-git>
[bitcoin] practicalswift opened pull request #21795: fuzz: Terminate immediately if a fuzzing input ever causes a DNS lookup (belts and suspenders) (master...fuzz-terminate-on-dns-lookup) https://github.com/bitcoin/bitcoin/pull/21795
< queip>
can taproot allow new signature types, like ntru sign, lamport and such?
< sipa>
depends on whether you mean taproot in reference to the technology to tweak keys as a commitment scheme, or the BIP341/BIP342 proposal
< sipa>
taproot itself does not, but it's still just an improvement to the script execution system, and script does (and always has) had ways to extend it, including with new signature types
< sipa>
BIP342 specifically contains a (somewhat unrelated) improvement of introducing "key versions", specifically intended for things like that
< sipa>
it is restricted to just script path spending though; key path spending is necessarily fixed (needs a new output type/witness version to change that)
< dongcarl>
roconnor: For the memcmp bug, was GCC miscompiling memcmp in glibc, or was it some weird GCC builtin optimized memcmp that was problematic?
< sipa>
dongcarl: gcc miscompiling a builtin
< sipa>
(which is done automatically for memcmp and a few related functions like std::lexicographic_compare
< dongcarl>
sipa: I see, so this would have happened even if we swapped glibc for some other libc implementation?
< sipa>
yes, it's entirely independent of libc
< dongcarl>
Got it
< sipa>
of course, the bug could be present in a particular compilation of glibc itself
< bitcoin-git>
[bitcoin] mjdietzx closed pull request #20889: test: ensure any failing method in MiniWallet leaves no side-effects (master...test-miniwallet-no-side-effects) https://github.com/bitcoin/bitcoin/pull/20889
< roconnor>
I've been meaning to test whether this bug I encountered is fixed in GCC 10.3, but in any cases, libsecp256k1 now has its own definition of memcmp that it uses.
< roconnor>
sipa: there is some evidence that it isn't present in glibc since glibc isn't amoung the libraries profiled that emitted an warning with real_or_random's bug profiling enabled: http://r6.ca/blog/20200929T023701Z.html
< roconnor>
BTW, I've been left with the impression that it shouldn't be hard to write a Nix expression to produce the same binaries that Guix produces. Someday I'd like to give it a try. It would be cool to have two different build systems producing the same binaries.
< roconnor>
though it would only take a single wrinke to cause a problem.
< yanmaani>
Less vaguely: say you introduce a new function. Where do the unit tests go?
< yanmaani>
roconnor: You can do a 'reflections on trusting trust'. If guix produces a gcc with compile flags X set, all you need is to create a *functioning* gcc, compile another gcc with compile flags X set, and then use that gcc to compile itself. So any eventual errors are self-correcting.
< bitcoin-git>
[bitcoin] glozow opened pull request #21800: [WIP] mempool/validation: mempool ancestor/descendant limits for packages (master...package-mempool-ancestors) https://github.com/bitcoin/bitcoin/pull/21800
< queip>
in case if TR ST would fail to activate, what is the time limit by which TR overall should activate using some other mechanism that would be attempted after the (hopefully avoidable) ST failure?
< sipa>
queip: not here, please
< bitcoin-git>
[gui] hebasto closed pull request #264: Add "Copy address" item to the context menu in the Peers table (master...210330-copy) https://github.com/bitcoin-core/gui/pull/264