<vasild>
"< kanzure> for a future topic perhaps consideration of a private login-only issue tracker (but open registration) to downregulate public social media linkbrigading effects" <-- that is not open source ethos
<bitcoin-git>
[bitcoin] l0rinc opened pull request #32457: bench: replace benchmark block with more representative one (413567 → 784588) (master...l0rinc/bench-block-413567-to-784000) https://github.com/bitcoin/bitcoin/pull/32457
<laanwj>
i guess that's one of the few good things about mailing lists, the contents are public, everyone can subscribe but it puts up a technical barrier against hit-and-run brigading
<vasild>
agree
Christoph_ has quit [Quit: Christoph_]
brunoerg has quit [Remote host closed the connection]
<pinheadmz>
the barrier between users and developers is the issue. users switching to knots right now probably feel like they have better access to luke than anyone else. thats why the discussion blew up on the pull request(s) and why i think in the future we should either expect it and pull way back on the moderation, or hold that github free-for-all in a slightly different place that anyone can access with a web browser and a click
bitdex has quit [Quit: = ""]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 244 seconds]
entropyx has quit [Ping timeout: 260 seconds]
entropyx has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #32458: guix: move `*-check.py` scripts under contrib/guix/ (master...move_release_scripts) https://github.com/bitcoin/bitcoin/pull/32458
<kanzure>
vasild: open source applies to source code licensing not issues; anyone can privately submit an 'issue' to anyone- there is no licensing restriction requiring them to publish the issue in a place for everyone to comment about the issue. if you want to maximize issue visibility then i suggest you propose a license that would require that?
<roconnor>
what's the analogus command for sethdseed for descriptor wallets / how do you import a descriptor with a specific hdseed?
Guyver2 has left #bitcoin-core-dev [Closing Window]
Christoph_ has joined #bitcoin-core-dev
<achow101>
roconnor: there isn't really an analogus command. I think the closest is createwalletdescriptor, but you have to convert the seed to xprv
<achow101>
otherwise you have to importdescriptors the descriptor that you want.
Christoph_ has quit [Client Quit]
<bitcoin-git>
[bitcoin] ismaelsadeeq opened pull request #32463: test: fix an incorrect `feature_fee_estimation.py` subtest (master...05-2025-fix-incorrect-fee-estimator-test) https://github.com/bitcoin/bitcoin/pull/32463
saikasyap has quit [Quit: Client closed]
Guest64 has joined #bitcoin-core-dev
Guest64 has quit [Client Quit]
badkat has quit [Ping timeout: 244 seconds]
Cory38 has quit [Quit: Client closed]
Cory38 has joined #bitcoin-core-dev
<roconnor>
achow101: so the gethdkeys on a descriptor wallet can only have 1 hdkey in practice?
<roconnor>
or will createwalletdescriptor will let you create a new entry hdkey if you give it an xpub?
<achow101>
ah, no it doesn't let you add a hdkey
<achow101>
you have to import with importdescriptors
<achow101>
there's #29136 to import a hd key without having to construct a descriptor
<corebot>
https://github.com/bitcoin/bitcoin/issues/29136 | wallet: `addhdkey` RPC to add just keys to wallets via new `unused(KEY)` descriptor by achow101 · Pull Request #29136 · bitcoin/bitcoin · GitHub
<roconnor>
"Add a BIP 32 HD key to the wallet that can be used with 'createwalletdescriptor"
<roconnor>
BTW, is there tooling to convert an xpub into a fingerprint?
<roconnor>
Or maybe you just look at the output of gethdkeys. :)
<roconnor>
so clearly 4e1b376f is the fingerprint.
<roconnor>
(this is just test wallet data, not real)
<achow101>
I usually just use bip32.org
<achow101>
but not for real keys
<achow101>
but generally you shouln't need the fingerprint
<roconnor>
maybe...
<roconnor>
how do fingerprints work with respect to importdescriptors / createwalletdescriptor ?
<achow101>
for the most part, what you are being given by gethdkeys or listdescriptors is a public descriptor that can be imported into a watchonly wallet
<achow101>
the fingerprint + derivation path is there because of hardened derivation
<achow101>
but you can import a descriptor with an xprv with a full derivation path
<achow101>
e.g. if you import wpkh(xprv/84h/0h/0h/0/*), you'll see a public descriptor of wpkh([fingerprint/84h/0h/0h]xpub/0/*)
<achow101>
but the one with the xprv is the one actually stored in the wallet
<roconnor>
Oh I see.
<roconnor>
createwalletdescriptor doesn't actually take a descriptor argument.
<roconnor>
it creates one.
<achow101>
it does not, it makes descriptors that follow the default templates
<roconnor>
got it.
<roconnor>
how do watch only wallets and public descriptors work? The hardened derivation paths seem problematic.
Talkless has joined #bitcoin-core-dev
<achow101>
roconnor: that's why the public descriptors have the fingerprint + dervivation path in front of the xpub
<achow101>
the xpub is derived at that path
<achow101>
we derive to the last hardened child, make that the xpub, put its origin info, and follow with the rest of the derivation path
<roconnor>
oh. ... don't you lose like what HD level you are at?
<achow101>
how so?
<roconnor>
maybe I don't know what "put its origin info" means.
<achow101>
origin info is fingerprint + derivation path
brunoerg has quit [Ping timeout: 276 seconds]
<roconnor>
oh I see now
<roconnor>
I wasn't understanding the descriptor format correctly.
<roconnor>
I thought [4e1b376f/44h/0h/0h] was part of the path, but it is more like a comment.
<roconnor>
achow101: thanks for walking me through all this.