< 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)
< 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>
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)
< 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
< 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.
< 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