< bitcoin-git>
[bitcoin] MeshCollider opened pull request #14478: Show error to user when corrupt wallet unlock fails (master...201810_wallet_corruption_error) https://github.com/bitcoin/bitcoin/pull/14478
< meshcollider>
is it ok if I replace #14019 with #14454 on the high priority review list
< sipa>
meshcollider, achow101: i think there is an alternative longer term solution to importmulti generalization, without the special signer that records what is used; instead, if we first implement a (dumb, map to old structures) importmulti that works with descriptors, we can use #14477 to convert any other request into a descriptor
< meshcollider>
sipa: yes, that sounds very sensible
< meshcollider>
sipa: the new importmulti would be a separate RPC to the existing one? Or a large breaking change to that function
< meshcollider>
something like importmultidesc
< sipa>
meshcollider: i was thinking an additional mode for importmulti, where instead of address/script/pubkeys/redeemscript and a bunch of other fields, you give a descriptor, but all other fields remain identical (label, birthdate, ...)
< sipa>
much later, when we can actually store descriptors as native objects in the wallet, a separate importdescriptor could be added, which does not map things back to old structures
< sipa>
adding a new mode to importmulti wouldn't be a breaking change; just a new way to pass in the same information more succintly
< sipa>
*succinctly
< omegaa>
This project is looking for investors, if you have investment ability, please consider it.
< meshcollider>
yeah and code-wise it seems like an easy separation of logic because we can just make a new ProcessImport function for the descriptor type
< omegaa>
Some time ago someone was brushing spam in irc, maybe its purpose was to stop my information.
< sipa>
meshcollider: right, and then next step would be replacing all other logic with conversions to that
< sipa>
but first things first; i'll review 14454 soon
< * sipa>
zZzZ
< meshcollider>
sipa: whether something is watchonly or not is implicit in the descriptor isn't it
< meshcollider>
e.g. whether the priv key or public key was given
< gwillen>
meshcollider: there was some discussion about this at coredev -- having "is_mine" (i.e. !watchonly) as a separate flag is necessary for things like hardware devices, where we can sign but don't have the key in hand
< gwillen>
which I believe are on the roadmap somewhere alongside descriptors
< meshcollider>
sipa: do you still envision private keys passed as an array separate to the descriptor?
< meshcollider>
and if so, how given the descriptor would you check all the private keys were used? Expand() and check the corresponding public keys were used for solvability?
< meshcollider>
gwillen: I see yep
< Dolaned>
Hi
< Dolaned>
Anyone here
< meshcollider>
no
< Dolaned>
Lol
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14479: serialization: Don't invoke undefined behaviour when doing type punning (master...serialization-ub) https://github.com/bitcoin/bitcoin/pull/14479
< fanquake>
I've added #14011 to high-priority, not having make check running properly on macOS is getting annoying. It's a pretty straight-forward review if someone has 5 minutes spare.
< gribble>
https://github.com/bitcoin/bitcoin/issues/14011 | Disable wallet and address book Qt tests on macOS minimal platform by ryanofsky · Pull Request #14011 · bitcoin/bitcoin · GitHub
< Drakon>
Hi. I was used to start Bitcoin Core minimized. Is this with version 0.17.0 still possible?
< Drakon>
Wrong channel, sry.
< sipa>
meshcollider: i don't understand the question
< sipa>
meshcollider: oh; descriptors can have the private keys embedded in the string (by using wip or xprv instead of hex or xpub), but even if not, it has all pubkeys explciitly, so you can judt iterate over them and see if you have all corresponding private keys