< bitcoin-git>
[bitcoin] achow101 opened pull request #21083: wallet: Avoid requesting fee rates multiple times during coin selection (master...createtx-same-feerate) https://github.com/bitcoin/bitcoin/pull/21083
< bitcoin-git>
[bitcoin] brunoerg opened pull request #21084: test: fix timeout decrease in feature_assumevalid (master...fix-timeout-assumevalid) https://github.com/bitcoin/bitcoin/pull/21084
< sipa>
sdaftuar: yw
< dr_orlovsky>
sipa: are there any plans of creating BIP-43 new purpose for XCoordOnly pubkey derivation? I assume this is desirable since it is not recommended to use keys for Schnorr signatures in ECDSA
< sipa>
dr_orlovsky: i have no interest in that
< dr_orlovsky>
ok, but how do you think, is it required at all (as a support for "good practices"?)
< sipa>
yeah, you'll probably want a separate bip32 path for P2TR outputs; but that has nothing to do with ECDSA/Schnorr; you just don't want to reuse the same keys
< sipa>
i don't know if that needs a standard like BIP43 - perhaps it helps
< sipa>
in general i prefer being explicit about usage using descriptors and similar things rather than making them implicitly dependent on the key path
< sipa>
but i haven't thought very hard about this
< dr_orlovsky>
clear, thank you
< sipa>
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
< dr_orlovsky>
wouldn't tagging key with its own hash for P2TR prevent key reuse with ECDSA anyway?
< dr_orlovsky>
*tagging -> tweaking
< sipa>
yes, but not in a meaningful way
< sipa>
they'd still be related keys
< dr_orlovsky>
true
< dr_orlovsky>
you will have a ECDSA->tweaked taproot simple derivation so you can index blockchain
< sipa>
i guess that means this whole point is moot, and we should probably have a deep look at proving security of ECDSA and Schnorr signatures of linearly related keys (as those created by P2C-tweaking or BIP32 derivation result)
< sipa>
i can't imagine that this poses problems, but it'd be good to formally prove it
< sipa>
because say hardware wallets may use one root key for both ecdsa and schnorr signing, even if that happens through separate subtrees
< dr_orlovsky>
wouldn't hardened derivation cancel any potential correlation?
< dr_orlovsky>
so BIP43-type new purpose value for P2TR will be a good solution in this respect as well?
< sipa>
ah, does it use hardened derivation at that step? i'm not familiar with these standards
< sipa>
in that case, yes, indeed
< dr_orlovsky>
it does
< wumpus>
sipa: that's a very good description, i've often wondered if we could increase the default maximum number of connections if we could somehow limit the resources every single one can take, this is a good general improvement
< wumpus>
(the other approach would be the micro-management side, e.g. scoring, but a negotiation phase in which some kinds of more expensive messages are already explicitly disallowed makes a lot of sense)
< wumpus>
jamesob | jonatack: *adds myspace to list of alternatives* <- kidding aside i have wondered at times whether github is close enough to a social network that layering something like it on top of say, fediverse or matrix protocol would make sense
< wumpus>
it would have some advantages compared to e-mail e.g. moderation features, not as much baggage regarding existing clients, easy federation, structured messages
< bitcoin-git>
bitcoin/master e1e6714 Jon Atack: doc: refer to BIPs 339/155 in feature negotiation
< bitcoin-git>
bitcoin/master 3931732 Wladimir J. van der Laan: Merge #20646: doc: refer to BIPs 339/155 in feature negotiation
< bitcoin-git>
[bitcoin] laanwj merged pull request #20646: doc: refer to BIPs 339/155 in feature negotiation (master...signet-keep-post-verack-sendaddrv2-peers) https://github.com/bitcoin/bitcoin/pull/20646
< bitcoin-git>
[bitcoin] Saibato opened pull request #21085: test: enable self.chain = 'main' to work in python bitcoin test framework (master...mainettests) https://github.com/bitcoin/bitcoin/pull/21085
< wumpus>
thanks
< jonatack>
dank
< bitcoin-git>
[bitcoin] WillyTheCat opened pull request #21086: ResetBlockFailureFlags did not remove the invalidity flag in other chain (master...master) https://github.com/bitcoin/bitcoin/pull/21086
< bitcoin-git>
bitcoin/master 6f36242 Andrew Chow: tests: Set descriptors default based on compilation
< bitcoin-git>
bitcoin/master b9b88f5 Andrew Chow: Skip legacy wallet reliant tests if BDB is not compiled
< bitcoin-git>
bitcoin/master 3641597 Andrew Chow: tests: Don't make any wallets unless wallet is required
< bitcoin-git>
[bitcoin] laanwj merged pull request #20267: Disable and fix tests for when BDB is not compiled (master...tests-opt-sqlite-bdb) https://github.com/bitcoin/bitcoin/pull/20267
< copumpkin>
is there a writeup somewhere on guix vs. nix from a bitcoin dev perspective?
< sipa>
copumpkin: there was a discussion about that a few days ago here
< sipa>
copumpkin: my understanding is mostly (a) it's a different language (which we likely don't really care about; neither nix's DSL or scheme are familiar for most developers) and (b) guix aims (or succeeds?) much more for binary reproducibility
< copumpkin>
ah fair enough, thanks! I'll check scrollback/logs for more detail
< sipa>
and you primarily find (a) as a reason for why Guix was created "no custom DSL", but the reason why we care about isn't so much its origins, but the fact that it simplifies our deterministic building setup
< copumpkin>
makes sense, definitely wasn't a pointed question, was just curious :)
< copumpkin>
even as an (ex) Nix developer I'm excited to see this family of build system get more widely adopted
< sipa>
ping dongcarl, roconnor: ^
< dongcarl>
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
< dongcarl>
bootstrappable.
< copumpkin>
referring to the fact that the little bootstrap bundle underpinning the linux/darwin stdenvs doesn't actually get much love most of the time?
< copumpkin>
(it's a normal derivation and last I checked Hydra was building it, but it breaks from time to time and I don't think many people notice, etc.)
< copumpkin>
or you mean the actual provenance chain of that bundle through the ages?
< dongcarl>
copumpkin: I'm mostly referring to the Reduced Binary Seed bootstrap with GNU Mes + stage0
< copumpkin>
ohh, I see, hmm
< copumpkin>
mind if I PM? probably more detail than most people care about
< dongcarl>
copumpkin: Sure, happy to chat, we can also go to #bitcoin-builds, where bitcoin build systems people hang out :-)
< luke-jr>
(and ironically Guix has bootstrapping problems)
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21087: guix: Passthrough BASE_CACHE into container (master...2020-12-guix-base-cache) https://github.com/bitcoin/bitcoin/pull/21087
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21088: guix: Jump forwards in time-machine and adapt (master...2021-02-bump-time-machine) https://github.com/bitcoin/bitcoin/pull/21088
< bitcoin-git>
[bitcoin] dongcarl opened pull request #21089: guix: Add support for powerpc64{,le} (master...2021-02-guix-ppc64-support) https://github.com/bitcoin/bitcoin/pull/21089
< achow101>
anyone want to review PRs with me on my stream on monday?
< bitcoin-git>
[bitcoin] dhruv opened pull request #21090: Default to NODE_WITNESS in nLocalServices (master...default-to-node-witness-2021) https://github.com/bitcoin/bitcoin/pull/21090