< bitcoin-git> [bitcoin] dongcarl opened pull request #21239: guix: Add codesigning support for osx+win (master...2021-01-guix-win-sign) https://github.com/bitcoin/bitcoin/pull/21239
< Abrax> bitcoin has an official irc server now
< Abrax> its just started
< Abrax> irc.bitcoin.com
< Abrax> it actually exists
< copumpkin> given who owns bitcoin.com, I'm not sure folks in here are terribly interested
< Abrax> what you mean by that
< Abrax> its bitcoin.com
< sipa> this is offtopic, please take it elsewhere
< sipa> this channel is about development of bitcoin core
< MarcoFalke> PSA. I am tracking non-exploitable (and exploitable) issues on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Fuzz-Trophies-(vulnerabilities) both for transparency and for our own benefit to understand the usefulness of fuzzing. This will hopefully help us to deploy new fuzzing resources more educated and with more impact.
< MarcoFalke> I'll mostly need help categorizing issues that are hit on pull requests.
< MarcoFalke> So if you see any pull request that hits a (valid) issue through fuzzing, please let me know (or directly add it to the wiki)
< MarcoFalke> PSA end
< bitcoin-git> [bitcoin] MarcoFalke pushed 21 commits to master: https://github.com/bitcoin/bitcoin/compare/c46fe4d1073c...828bb776d29c
< bitcoin-git> bitcoin/master d1f932b Carl Dong: validation: Pass in coins cache to ::LimitMempoolSize
< bitcoin-git> bitcoin/master 73a6d2b Carl Dong: validation: Pass in chainstate to IsCurrentForFeeEstimation
< bitcoin-git> bitcoin/master 252b489 Carl Dong: validation: Pass in coins tip to CheckInputsFromMempoolAndCache
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20750: [Bundle 2/n] Prune g_chainman usage in mempool-related validation functions (master...2020-09-reduce-validation-mempool-ccsactiveglobal-usage) https://github.com/bitcoin/bitcoin/pull/20750
< jonasschnelli> MarcoFalke: thanks for tracking those issues. Great idea
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21243: ci: Avoid invoking curl on the host (master...2102-ciCurl) https://github.com/bitcoin/bitcoin/pull/21243
< bitcoin-git> [bitcoin] jnewbery closed pull request #20411: test: Fix Version Message Deserialization Discrepancy (master...2020-11-test-framework-version-msg-fix) https://github.com/bitcoin/bitcoin/pull/20411
< jnewbery> I propose that as an experiment, we move next week's p2p irc meeting to 2100 UTC. That'll make it much easier for aj and sipa to attend.
< jnewbery> wumpus: do you mind updating the calendar for next week's p2p meeting?
< bitcoin-git> [bitcoin] kiminuo opened pull request #21244: GetDataDir: Accept ArgsManager as a parameter. (master...feature/2021-02-get-data-dir-args) https://github.com/bitcoin/bitcoin/pull/21244
< bitcoin-git> [bitcoin] fyquah opened pull request #21245: rpc: Add level 3 verbosity to getblock RPC call. (master...verbosity-level-3-getblock) https://github.com/bitcoin/bitcoin/pull/21245
< wumpus> jnewbery: will do
< wumpus> is there any way to get the xpub for a native descriptor wallet through RPC?
< wumpus> jnewbery: done
< wumpus> (to answer my question above, "listdescriptors" does this)
< michaelfolkson> MarcoFalke: Cool. That dev wiki is editable (and hence vandalizable) by anyone and it has no version control. Is that the best place for it?
< michaelfolkson> MarcoFalke: Perhaps also add it as a topic to next week's dev meeting?
< michaelfolkson> I think that dev wiki should just be used for drafting. It shouldn't be used as a final destination for important/useful information
< wumpus> michaelfolkson: the wiki does have version control, it is a git repository in itself
< wumpus> michaelfolkson: also thanks for reminding me to set it to editable to bitcoin-core members only
< wumpus> this is something i intended to do after the 0.21.0 release
< wumpus> achow101: i'm slightly confused by listdescriptors output: it has derivation paths like tpubD6NzVbkrYhZ4XackbNPEp9oCU488FtNtNcoto4vxcugiZd8munhrhmhe9B9YJD7sbogtnt21mD3nHmJPodX68sX5vovp5GW7Pbxep6b39Xx/84'/1'/0'/0/* , but how is it possible to do hardened derivation like 84' from a xpub?
< wumpus> achow101: what i'm really trying to do is get a xpub to use for a multisig scheme
< wumpus> michaelfolkson: though you're right that the dev wiki is noet the place for 'finalized' documentation, we have other places for that: the 'doc' folder in the repository for things directly related to e.g. RPC functionality, and https://github.com/bitcoin-core/docs for less tightly coupled docs
< newdev42> does anyone know where I can find a list of public testnet peer nodes closest to my region? or do you highly recommend me to spin up a local testnet node? (I'm working with services around a the rpc apis)
< wumpus> newdev42: bitcoind will automatically find nodes for you, they likely won't be close to you geograpically but in the current internet topology that shoudn't matter too much; geographically close doesn't equate a fast link
< newdev42> wumpus: thanks for the response; I actually was looking for not using bitcoind and just consume some public available one (not running my own testnet node) is that not possible?
< wumpus> it's unlikely for anyone to make their peer's RPC available to you
< wumpus> i'm sure there are some public block chain APIs you can use but that's very much off topic here #bitcoin for general questions
< newdev42> gotcha, thank you very much!
< wumpus> PSA: the devwiki has been closed to bitcoin-core members only, if you require access to it please ask here to be added to the "wiki editors" or "frequent contributors" group (both give write access to the wiki)
< newdev42> wumpus thank you very much my friend! :)
< aj> newdev42: spin up a local signet node instead perhaps
< wumpus> newdev42: no problem
< wumpus> i think what i need is a way to generate a *derived xpub* for a custom path in the wallet, i can do this with external tooling (e.g. darosior's bip32 python module), but afaik not from bitcoin core itself?
< wumpus> of course to do it with an external tool i still need to get my wallets xprv somehow
< achow101> wumpus: perhaps #19136
< gribble> https://github.com/bitcoin/bitcoin/issues/19136 | wallet: add parent_desc to getaddressinfo by achow101 · Pull Request #19136 · bitcoin/bitcoin · GitHub
< achow101> Since that is merged, listdescriptors should use that same normalized descriptor
< wumpus> but how? i pasted to you above what i get from listdescriptors, which is the same tpub for every descriptor not a specific one, and it uses hardened derivation on a tpub
< wumpus> (and i am using the latest master so that patch should be in)
< wumpus> fwiw: src/bitcoin-cli -regtest listdescriptors | grep desc output : https://0bin.net/paste/97jvm8Rd#xEeTLSVcFbRGQqFCk67duPb85ynsnSkk4fkTl6I+ZyZ
< wumpus> in any case what i need is the xprv of the root i think
< bitcoin-git> [bitcoin] roconnor-blockstream opened pull request #21246: Correction for VerifyTaprootCommitment comments (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21246
< ariard> aj, sdaftuar: replied to few of your points on #21224, marked as draft until further discussions
< gribble> https://github.com/bitcoin/bitcoin/issues/21224 | [p2p] Halt processing of unrequested transactions by ariard · Pull Request #21224 · bitcoin/bitcoin · GitHub
< ariard> I think "A sane/implementatable rate-limiting strategy" would be a good mail thread, but maybe better to scope the problem space during IRC next p2p meeting
< ariard> otherwise we're going to be back to the airy #19820 :p
< gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
< achow101> wumpus: what I meant was that we need to update listdescriptors to use the normalized descriptor. But for now you can use getaddressinfo's parent_desc field to get the importable descriptor
< S3RK> wumpus: listdescriptors was merged before normalized decsriptors by achow101. I agree in current vesion it's not very useful, I plan to add support for normalized descriptors so you would get an importable version (xpub for latest hardend derivation).
< S3RK> I was also thinking about adding an option to show private descriptors, but that a bit risky. What do you think?
< achow101> S3RK: I think showing private descriptors is fine as long as we limit it to just the master privkey or at least only hardened steps
< achow101> we cannot allow child private key export when there is parent pubkey export too as that is dangerous without being obviously so to non-technical users
< S3RK> is it because with the combination of xpub and any private key it's possible to figure out chain code?
< achow101> S3RK: a parent xpub with a child privkey can recover the parent privkey
< achow101> this is not obvious to most people
< achow101> if we only allow root privkey export, that is at least obvious to most people to be potentially dangerous
< S3RK> yes, I see. I'll send a PR for normalized descriptors first and than work on an option for private descriptors.
< achow101> +1
< Talkless> `fgrep -R QStringLiteral src/qt/*` finds nothing. Why..? :/
< phantomcircuit> Talkless, they're there
< Talkless> phantomcircuit: am I grepping wrong?
< phantomcircuit> Talkless, i think something else is wrong like you're not in the directory you think you are or something
< Talkless> :| QString - finds, QStringL - finds QStringList, but QStringLit - nothing
< sipa> "QStringLiteral" does not appear in the source code anywhere
< phantomcircuit> sipa, maybe it's generated code but it's in my source tree
< phantomcircuit> src/qt/forms/ui_sendcoinsentry.h
< sipa> ah, yes
< sipa> i used git grep
< sipa> so it only searches checked in files
< Talkless> phantomcircuit: ui_ are generated files, in my build dir.
< Talkless> $ find -name "ui_sendcoinsentry.h"
< Talkless> ./build/src/qt/forms/ui_sendcoinsentry.h
< Talkless> and that does not use QStringLiteral either
< phantomcircuit> possibly it generates different things with different qt versions
< Talkless> anyhow, so question standas, why QStringLiteral is not used? Nobody cares / considered micro-optimisation?
< Talkless> Personally, seeing setFoo("plain string literla") generates pain :D
< Talkless> settings.value("key") has to allocate new QString, copy-convert utf-8 into utf16...
< sipa> i'm sure that improvements are welcome
< Talkless> sipa: I just thought maybe there's policy against it or whatever
< Talkless> sipa: is there a point to keep nagging about not using QStringLiteral in new code, without some sort of "Agreement of Developers Committee"? :)
< Talkless> to start nagging*
< luke-jr> Talkless: I for one didn't even know it existed
< luke-jr> Talkless: and find it silly that one needs to be explicit about this :x
< Talkless> luke-jr: yeah kinda annoying, "abc"_qsl might be better, I believe Qt Core maintainer was thinking about it, but maybe not possible without some newver C++ revision, idk
< Talkless> newer*,
< bitcoin-git> [bitcoin] prayank23 opened pull request #21249: doc: Add Whitepaper in Docs (master...whitepaper) https://github.com/bitcoin/bitcoin/pull/21249