kriik- has quit [Remote host closed the connection]
chip_x has joined #bitcoin-core-dev
kriik- has joined #bitcoin-core-dev
kriik- has quit [Remote host closed the connection]
zeropoint has joined #bitcoin-core-dev
zeropoint has quit [Client Quit]
salvatoshi has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
PaperSword has joined #bitcoin-core-dev
chip_x has quit [Ping timeout: 268 seconds]
dviola has joined #bitcoin-core-dev
chipxxx has joined #bitcoin-core-dev
flexid has joined #bitcoin-core-dev
flexid has quit [Client Quit]
Victorsueca has joined #bitcoin-core-dev
chipxxx has quit [Ping timeout: 248 seconds]
chipxxx has joined #bitcoin-core-dev
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #bitcoin-core-dev
yanis_fourel has joined #bitcoin-core-dev
yanis_fourel has quit [Quit: Client closed]
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
Talkless has joined #bitcoin-core-dev
jonatack2 has joined #bitcoin-core-dev
jonatack1 has quit [Ping timeout: 246 seconds]
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] martinus opened pull request #27331: refactor: extract CCheckQueue's data handling into a separate container "Bag" (master...2023-03-bag) https://github.com/bitcoin/bitcoin/pull/27331
AaronvanW has joined #bitcoin-core-dev
salvatoshi has quit [Ping timeout: 276 seconds]
bugs_ has joined #bitcoin-core-dev
Evel-Knievel has quit [Ping timeout: 250 seconds]
Evel-Knievel has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
bugs_ has joined #bitcoin-core-dev
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #bitcoin-core-dev
chip_x has joined #bitcoin-core-dev
chipxxx has quit [Read error: Connection reset by peer]
nanotube has quit [Quit: *poof*]
AaronvanW has quit [Quit: Leaving...]
yanmaani1 has quit [Ping timeout: 255 seconds]
ezero has quit [Quit: Connection closed]
yanmaani1 has joined #bitcoin-core-dev
yanmaani1 has quit [Ping timeout: 255 seconds]
yanmaani1 has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Guest9 has joined #bitcoin-core-dev
Guest9 has quit [Client Quit]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
<andytoshi>
does bitcoin core do the "Master key generation" described in BIP 32 anywhere?
<andytoshi>
oh, i found it
<andytoshi>
i was searching for 'Bitcoin seed' but the code uses {'B','i','t','c','o','i','n',' ','s','e','e','d'}
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<sipa>
I think because once upon a time, I didn't want to use a C string that'd use another byte of memory to store the zero terminator...
<andytoshi>
i suspect it's a bit more subtle ... if you do `unsigned char s[8s = "bitcoin";` it'll include the terminator. if you do `unsigned char s[7] = "bitcoin"` it'll silently chop it off .. if you do `unsigned char s[] = "bitcoin"` it'll include it, same as [8]
<andytoshi>
and i think, if you want to avoid the terminating 0, it's much clearer to do what you did
<andytoshi>
than to rely on this insane "lol your string is not actually null-terminated" behavior that you need to count characters manually to verify
<andytoshi>
and if you just included it, then sizeof(s) will be 1 off from what you want. so it's an extra bug opportunity, not just a wasted byte
<_aj_>
andytoshi: char s[7] = "bitcoin"; errors with "initializer-string for char array is too long" in c++ apparently
<andytoshi>
oh, phew :) then it's only C that's ridiculous
<_aj_>
constexpr std::string_view might be the modern way to do it?
salvatoshi has joined #bitcoin-core-dev
anhi has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<andytoshi>
achow101: is it true that with descriptor wallets, there is no way to provide your own bip32 seed?
<achow101>
andytoshi: currently, yes
<andytoshi>
ok. do you have an idea of what it would look like if this ability were provided?
<andytoshi>
i can maybe work on it
<achow101>
it would have to be some addition to descriptors that allows keys to be specified as seeds
<achow101>
e.g. wpkh(seed(blah)) ?
<andytoshi>
or just make all keys specifiable as <seed>/1/2/3
<andytoshi>
extkeys*
<sipa>
it'd need to be converted to an xpub, i think?
<andytoshi>
right, the software would do the xpub conversion when parsing
<andytoshi>
there's a deterministic way to go from a seed to an xpub
<andytoshi>
this maybe should be in ##miniscript now?
<sipa>
perhaps
<andytoshi>
i see, i think i'd misunderstood bip32 ... we always specify paths as <xpub>/1/2/3 or m/1/2/3 where the m is literally 'm' and the seed is off to the side somewhere
salvatoshi has quit [Ping timeout: 265 seconds]
<andytoshi>
achow101: so, after talking to sipa in the ##miniscript channel, i think my plan of action here is to provide a codex32(...) thing which you can put into descriptors, which will be parsed into an xpriv. here the ... is a codex32 (bip 93) encoded seed, or a list of codex32 shares (from which a seed will be recovered)
<andytoshi>
i have a branch that can do all the codex32 stuff, i just need to write a bit of parser glue around it