< bitcoin-git>
[bitcoin] hebasto opened pull request #18581: ci: Print ccache stats, add pip cache, and cleanups (master...20200409-ci-plus) https://github.com/bitcoin/bitcoin/pull/18581
< jonasschnelli>
achow101: thanks for the writeup! Will go through it now...
< sipa>
< gwillen>
uh, assuming there is not something wrong with my IRC client, I see one line from jonasschnelli which is (presumably accidentally) written in black-on-black text, followed by a blank line from sipa
< achow101>
gwillen: it's a space
< achow101>
I see jonasschnelli's line fine, probably becaue I'm highlighted?
< sipa>
oh, i didn't see jonasschnelli's at all, assuming it was an empty line
< sipa>
sneaky.
< gwillen>
yeah I figured that might have been what happened
< vasild>
I see jonasschnelli's message as black-on-black too, had to copy-paste into another terminal so I can read it
< jonasschnelli>
hmm... I used my mobile (iOS) irc client (via a znc bouncer). Now back on my desktop client. Better?
< gwillen>
your text is no longer black
< jonasschnelli>
I also have a empty line from sipa. :}
< jonasschnelli>
maybe someone is messing with my znc
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18584: test: Check that the version message does not leak the local address (master...2003-qaAddrRelay) https://github.com/bitcoin/bitcoin/pull/18584
< bitcoin-git>
bitcoin/master fad691c MarcoFalke: rpc: Make verifychain default values static, not depend on global args
< bitcoin-git>
bitcoin/master a840dab MarcoFalke: Merge #18541: rpc: Make verifychain default values static, not depend on g...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18541: rpc: Make verifychain default values static, not depend on global args (master...2004-rpcStaticDefaults) https://github.com/bitcoin/bitcoin/pull/18541
< instagibbs>
ryanofsky, indeed looking at private keys disabled to change logic was basically a hack, moving forward with descriptor wallets we should try to do better
< instagibbs>
I'm merely describing what will not work(and likely surprise the user) with #16528
< bitcoin-git>
bitcoin/master dcc8332 Andrew Toth: Add generateblock rpc
< bitcoin-git>
bitcoin/master 7524b64 Andrew Toth: Add tests for generateblock
< bitcoin-git>
bitcoin/master 51e2ce4 MarcoFalke: Merge #17693: rpc: Add generateblock to mine a custom set of transactions
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17693: rpc: Add generateblock to mine a custom set of transactions (master...generateblock) https://github.com/bitcoin/bitcoin/pull/17693
< luke-jr>
is the wallet meeting today or next week? :x
< achow101>
luke-jr: today
< luke-jr>
phew
< bitcoin-git>
[bitcoin] laanwj opened pull request #18586: build: Bump gitian descriptors to 0.21 (master...2020_04_bump_descriptors) https://github.com/bitcoin/bitcoin/pull/18586
< achow101>
one point that has come up in discussions is watchonly, in particular handling multisigs
< sipa>
where watchonly just means "you don't have all private keys in your wallet locally" ?
< achow101>
I think so
< sipa>
(i bring that up, because say in a HW wallet situation, just because the key is not in your wallet.dat, doesn't mean you don't have the ability to spend)
< achow101>
ryanofsky suggested having some descriptors be marked as "watchonly" and others as not, independent of private keys
< achow101>
"I wonder if in this kind of wallet, ability to mark individual descriptors watchonly or not, ability to display two balances, and ability to have RPCs that know which descriptors are intended for signing regardless of whether private keys are present might help with UX, and maybe let someone get away with just having have one bitcoin wallet instead of two and having to exporting/import between them."
< sipa>
i'm not sure how i feel about that
< sipa>
there really shouldn't be a descriptor in the first place for the stuff you don't care about (and turning it into a watchonly thing to separate it feels like a hack)
< sipa>
i also don't have a better solution for how you'd go from "create single-key thing first, and then construct a multisig out of it"
< achow101>
instagibbs also points out that if we allow descriptors with some but not all private keys, bumpfee and PSBT GUI break
< sipa>
how so?
< achow101>
so having a bool on the descriptors to indicate signing-ness or something would help with that
< achow101>
but it does feel like we're regressing to legacy wallet territory
< sipa>
i agree
< achow101>
sipa: they switch on disable_private_keys. so if not disable_private_keys, sign, otherwise show/copy psbt
< achow101>
but a multisig with some but not all privkeys is not disable_private_keys but will fail to sign
< sipa>
wouldn't it be better to have separate RPCs for when you expect a fully-signed output vs PSBT output?
< sipa>
and the latter would always work, and the former would just fail if not enough keys are present
< achow101>
the other problem is that coin selection may choose to include a multisig utxo that you can't always sign for so sometimes sending will fail
< achow101>
sipa: I think that's reasonable
< sipa>
achow101: i think that's inherent to the no-mixed-wallet philosophy
< sipa>
if you really want coin selection to choose directly-spendable coins over multisig ones, you should have two separate wallets
< sipa>
the idea that you'd ever want those two mixed in the same wallet was a mistake i think, and it's what we're getting rid of?
< achow101>
right. I don't think it's really a supported use case, but I'm not sure that we can/should block it
< sipa>
i think to the extent possible the behavior of wallets and RPCs should not depend on whether you happen to have a private key locally
< achow101>
right
< achow101>
I think the separate RPCs and buttons idea mostly solves this. we can disable the signing one when explicitly there are no private keys
< achow101>
those functionality may also be useful even when you do have all the private keys
< sipa>
right
< sipa>
maybe you want to get a PSBT out even when you have all private keys, e.g. for a final auditing on a secure machine before broadcasting or so
< sipa>
(as they retain fee information)
< achow101>
and we should stop changing behavior based on disable_private_keys
< sipa>
yeah
< achow101>
any other topics?
< sipa>
at least for descriptor wallets...
< jonatack>
sgtm (and good doc achow101, thanks)
< achow101>
#endmeeting
< lightningbot>
Meeting ended Fri Apr 10 19:39:12 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< instagibbs>
sipa, I'm reading your comments above as supportive of the idea that sometimes it wouldn't work, if the user had imported a private key of some sort?
< instagibbs>
oh, "don't do it" as in user doesn't do it
< instagibbs>
got it
< sipa>
hmm
< sipa>
i guess the relevant property that "no private keys" is conveying is "are sign operations guaranteed to always result in a fully-signed transaction"
< sipa>
for a descriptor wallet you could technically infer this information from the descriptors (generate an sPK from them, try signing for it)
< instagibbs>
i.e., if you can sign for all descriptors in wallet, magic behavior, vs "are there private keys"
< instagibbs>
well, button greyed out at least
< sipa>
which isn't so much "does this wallet have any private keys", but "is this a wallet that needs external stuff for signing"
< luke-jr>
After #18546, avoid-reuse wallets should be working correctly in 0.20, but remain broken in 0.19 which interprets "destdata" as a destination being non-change.
< achow101>
luke-jr: kinda
< luke-jr>
Since avoid-reuse was a new feature in 0.19 and doesn't affect older wallets or wallets that don't opt-in at all, we can probably get away with just saying "it's broken; upgrade or don't use it"… but this issue makes "destdata" unsafe to use for anything else.
< gribble>
https://github.com/bitcoin/bitcoin/issues/18546 | Bugfix: Wallet: Safely deal with change in the address book [part 2] by luke-jr · Pull Request #18546 · bitcoin/bitcoin · GitHub
< luke-jr>
#18550 instead moves/stores change "destdata" in a new key which older wallets will ignore, thereby making it safe to add new "destdata" keys even in old wallets without breaking backward compatibility.
< gribble>
https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
< luke-jr>
However, doing this in 0.21 will mean extra code to support 0.20 avoid-reuse wallets as a special case. Or we can just merge something like #18572 into 0.20 to be forward compatible.