< bitcoin-git> [bitcoin] luke-jr opened pull request #18572: Wallet: Accept "changedata" db key as an alias to "destdata" (master...changedata_forwardcompat) https://github.com/bitcoin/bitcoin/pull/18572
< bitcoin-git> [bitcoin] fanquake closed pull request #18333: build: Drop deprecated ACLOCAL_AMFLAGS variable (master...20200311-deprecated-amflags) https://github.com/bitcoin/bitcoin/pull/18333
< jonasschnelli> Or tell me how to do it? I logged in but don't have a restart build button
< fanquake> done
< sipa> fanquake beat me to it
< fanquake> how unusual
< sipa> not really
< jonasschnelli> heh... bored in quarantaine?
< fanquake> jonasschnelli: I'm not sure how to get you a restart button. Are you authed via github, or a different method?
< jonasschnelli> I just logged in via github, yes.
< jonasschnelli> I haven't manually added a project,.. which I think i don't have to do?
< jonasschnelli> well,... i won't use it too much. So no urgency.
< fanquake> I don't think so, but can't quite remember.
< fanquake> I've currently lost my Travis restart button, which is much more annoying.
< fanquake> Re-authing didn't seem to help either.
< bitcoin-git> [bitcoin] sipa opened pull request #18573: [RFC] bitcoin-asmap utility (master...202004_asmap_tool) https://github.com/bitcoin/bitcoin/pull/18573
< bitcoin-git> [bitcoin] jonatack opened pull request #18574: getinfo: call getbalances.ismine.trusted instead of getwalletinfo.balance (master...getinfo-call-getbalances-instead-of-getwalletinfo-balances) https://github.com/bitcoin/bitcoin/pull/18574
< bitcoin-git> [bitcoin] brakmic closed pull request #18570: rpc: return block hash in getbalances json (master...return-blockhash-with-wallet-calls) https://github.com/bitcoin/bitcoin/pull/18570
< bitcoin-git> [bitcoin] brakmic reopened pull request #18570: rpc: return block hash in getbalances json (master...return-blockhash-with-wallet-calls) https://github.com/bitcoin/bitcoin/pull/18570
< wumpus> unless anyone disagrees strongly I'm going to merge #18553 and tag rc1 in a bit
< gribble> https://github.com/bitcoin/bitcoin/issues/18553 | Avoid non-trivial global constants in SHA-NI code by sipa · Pull Request #18553 · bitcoin/bitcoin · GitHub
< wumpus> (after branching off 0.20 etc ofc)
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/661bd5dea3d0...dcef5ad6ec10
< bitcoin-git> bitcoin/master fa68a3e MarcoFalke: appveyor: Enable minimal unit test logging to aid debugging
< bitcoin-git> bitcoin/master fa7af33 MarcoFalke: ci: Run unit tests sequential once
< bitcoin-git> bitcoin/master dcef5ad MarcoFalke: Merge #18562: ci: Run unit tests sequential once
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18562: ci: Run unit tests sequential once (master...2004-qaFixTestTeardown) https://github.com/bitcoin/bitcoin/pull/18562
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dcef5ad6ec10...87374d80a71d
< bitcoin-git> bitcoin/master fa5e973 MarcoFalke: test: Set -use_value_profile=1 when merging fuzz inputs
< bitcoin-git> bitcoin/master 87374d8 MarcoFalke: Merge #18566: test: Set -use_value_profile=1 when merging fuzz inputs
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18566: test: Set -use_value_profile=1 when merging fuzz inputs (master...2004-fuzzValueProfile) https://github.com/bitcoin/bitcoin/pull/18566
< fanquake> wumpus: sounds good
< wumpus> the other option would be to skip #18553 for now
< gribble> https://github.com/bitcoin/bitcoin/issues/18553 | Avoid non-trivial global constants in SHA-NI code by sipa · Pull Request #18553 · bitcoin/bitcoin · GitHub
< wumpus> as some people think it invokes strange undefined C++ behavior maybe that's better, though I'm not sure it's strictly worse than calling optional instruction sets in the initializers
< wumpus> but I don't want to block 0.20 for it for days
< wumpus> fanquake: we might want a linter at some point that checks for init.* sections in the object files for optional instruction sets
< fanquake> wumpus: interesting
< wumpus> i mean, .text.startup sections
< wumpus> a quick hack using "find -name \*.o -print0 | xargs -0 grep -l '.text.startup'" doesn't seem to find any others that might be problematic
< fanquake> wumpus: I see these sections in a fairly recent master https://gist.github.com/fanquake/90bfbed7d8e31e2191ec806cb67b78cf
< wumpus> sections such as .text.startup won't be in the final executable (the linker map collapses them)
< wumpus> but it's fine to have them in .o's compiled with the default compiler options
< fanquake> ah I see. I do have a map
< fanquake> I see:
< fanquake> .rela.text.startup
< fanquake> *(.text.startup .text.startup.*)
< fanquake> .text.startup 0x0000000000001090 0x74 /tmp/ccjlo7po.o
< fanquake> Was playing around with this for #17929. We are going to swap to just passing the optimization flags to the linker, and I was examining the differences in the binaries.
< gribble> https://github.com/bitcoin/bitcoin/issues/17929 | build: add --enable-linker-optimizations configure flag by fanquake · Pull Request #17929 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/87374d80a71d...1ae366ecb067
< bitcoin-git> bitcoin/master 97ba77a Hennadii Stepanov: ci: Add native s390x
< bitcoin-git> bitcoin/master 6136a96 Hennadii Stepanov: ci: Rename RUN_CI_ON_HOST to DANGER_RUN_CI_ON_HOST
< bitcoin-git> bitcoin/master 1ae366e MarcoFalke: Merge #18569: ci: Add big endian native s390x build
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18569: ci: Add big endian native s390x build (master...20200326-allow-s390x) https://github.com/bitcoin/bitcoin/pull/18569
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1ae366ecb067...081dcbde6623
< bitcoin-git> bitcoin/master faede1b MarcoFalke: test: Properly raise FailedToStartError when rpc shutdown before warmup fi...
< bitcoin-git> bitcoin/master 081dcbd MarcoFalke: Merge #18561: test: Properly raise FailedToStartError when rpc shutdown be...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18561: test: Properly raise FailedToStartError when rpc shutdown before warmup finished (master...2004-qaFailedToStartConnectionReset) https://github.com/bitcoin/bitcoin/pull/18561
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #18575: bench: Remove requirement that all benches use same testing setup (master...2004-benchNoGlobalReg) https://github.com/bitcoin/bitcoin/pull/18575
< bitcoin-git> [bitcoin] gzhao408 opened pull request #18576: wip [test] use unittest for test_framework unit testing (master...framework-unittests) https://github.com/bitcoin/bitcoin/pull/18576
< bitcoin-git> [bitcoin] yahiheb opened pull request #18577: doc: Correct scripted-diff example link (master...correct-link) https://github.com/bitcoin/bitcoin/pull/18577
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Apr 9 19:00:05 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< sipa> hi
< elichai2> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
< wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
< achow101> hi
< jonasschnelli> hi
< jonatack> hi
< hebasto> hi
< jkczyz> hi
< aj> hola
< MarcoFalke> hi
< sdaftuar> hi!
< MarcoFalke> (sorry, merge bot incoming in a few secs)
< cfields> hi
< amiti> hi
< wumpus> any proposed topics?
< jnewbery> hi
< MarcoFalke> wen release?
< wumpus> looks like there's one by achow101: deprecating signrawtx RPCs
< sipa> low priority topic if there's time: future of asmap?
< wumpus> MarcoFalke:depends on whether #18553 is a blocker
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/081dcbde6623...405713d00fb4
< bitcoin-git> bitcoin/master 5560845 Pieter Wuille: Make a fuzzer-based copy of the prevector randomized test
< bitcoin-git> bitcoin/master eda8309 Pieter Wuille: Assert immediately rather than caching failure
< gribble> https://github.com/bitcoin/bitcoin/issues/18553 | Avoid non-trivial global constants in SHA-NI code by sipa · Pull Request #18553 · bitcoin/bitcoin · GitHub
< bitcoin-git> bitcoin/master 402ad5a Pieter Wuille: Only run sanity check once at the end
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18529: Add fuzzer version of randomized prevector test (master...202004_prevector_fuzz) https://github.com/bitcoin/bitcoin/pull/18529
< achow101> rc1 soon?
< MarcoFalke> I wish rebroad could ACK it, since they reported the issue
< hebasto> why 18553 could be a blocker?
< wumpus> it's the only PR left that is tagged for 0.20
< wumpus> hebasto: because if your system doesn't support the instruction it'll just crash before main()
< MarcoFalke> Does anyone have that CPU to test?
< elichai2> MarcoFalke: I'm surprised this is the first time we're hearing about this issue. I would've thought everyone without SSE* support will get this error
< sipa> i'm not sure the problem will appear in every build (it may be compiler dependent)
< wumpus> no, bitcoind master runs fine even on my oldest pc, but it might depend on compiler too
< sipa> would i understand how our existing code is broken for systems that do not have sse4
< sipa> *but i understand
< wumpus> movaps is SSE2, right?
< promag> hi
< wumpus> if the init code contained *SSE4* oh sure we'd have noticed
< cfields> *sse2
< cfields> wumpus: right
< sipa> i suspect he is executing an sse4 instruction
< wumpus> almost(?) all amd64 processors support SSE2
< sipa> because his system has sse2
< wumpus> oh
< wumpus> okay in that case we don't know if the PR fixes theproblem at all
< sipa> it does
< wumpus> I suggest we just move on with the branch-off and rc1
< cfields> ah, I guess if we're targetting sse4 it's free to ignore the sse2 intrinsic. Annoying that those are only hints.
< sipa> wumpus: the sha256-shani module is compiled with sse4 on, so any code the compiler produces in that module is allowed to have sse4 instructions
< sipa> the fact that it has a global initializer is a bug regardless
< wumpus> sipa: yes, I agree
< wumpus> I'm the person who ACKed that PR, I think it's a good change
< elichai2> anyways the current code is somewhat broken
< elichai2> even if that's not his specific problem
< sipa> we don't know the exact conditions to reproduce it (which is hard, as it's compiler dependent), but i believe my PR is a bugfix independently of that
< elichai2> sipa: exactly
< wumpus> yes
< wumpus> it makes sense no matter what
< wumpus> even reduces code size a bit
< sipa> but if we want to make sure rebroad's issue is fixed in 0.20... we have no choice but to wait for him
< sipa> i think we can do that in rc1
< jarthur> If anyone needs time on a machine w/ hardware SHA-NI for profiling/memory sanitization, send me your SSH pubkey and I'll give you a VM
< sipa> i have one too
< wumpus> I'm not going to hold up rc1 on them testing it
< sipa> a machine without sse4 would be more useful :p
< luke-jr> (proposed topic: change destdata)
< sipa> there are very few x86_64 systems without sse4 i think
< luke-jr> although maybe better for wallet meeting tomorrow
< wumpus> true, even my old dev machine has "sse4a"
< luke-jr> (but does relate to 0.20)
< elichai2> jarthur: I would like to run some UB sanitizer on the patch, just because I'm a bit uncomfortable with C++'s alignment rules
< wumpus> in that case, let's do rc1 without it
< sipa> ack
< cfields> elichai2: if you're that uncomfortable, there's an intrinsic that doesn't require alignment.
< luke-jr> should probably get at least #18572 into 0.20
< gribble> https://github.com/bitcoin/bitcoin/issues/18572 | Wallet: Accept "changedata" db key as an alias to "destdata" by luke-jr · Pull Request #18572 · bitcoin/bitcoin · GitHub
< cfields> compiler might even auto-upgrade it?
< sipa> cfields: i don't think it can
< wumpus> the current solution has 0 overhead at least
< elichai2> cfields: I'm not saying it's UB/ID just that I don't know the rules well enough :) I assume the unaligned load is costlier
< sipa> elichai2: on most systems they have the same cost, but not all
< wumpus> it even generates the same code as before
< elichai2> sipa: I thought SIMD instructions do require aligned pointers. unlike regular loads/stores
< elichai2> (x86/x86_64)
< cfields> yeah, I'm not really understanding the concern. We use alignment tricks in sse4 as well.
< sipa> elichai2: correct
< luke-jr> depends on the CPU in my expereince
< wumpus> yes, alignas(__m128i) should just work
< sipa> elichai2: movdqa requires alignment, movdqu does not
< elichai2> Ok, if other people are confident in this than I'm ACK too
< luke-jr> for a long time at least, Mesa and glibc used ssse3 for memcpy-type stuff, even when unaligned - and it broke on (IIRC) Sandy Bridge
< sipa> but still on most systems they have the same cost; the distinction was made because on early CPUs they differed
< wumpus> we use alignas() in a few other places too
< wumpus> if the compier ignores it, we're screwed with regard to UB in either case
< sipa> yeah, i'm not worried about the alignment thing
< wumpus> (prevector comes to mind)
< elichai2> wasn't there a UB in a version of prevector?
< wumpus> yes, that was solved using the current explicit construction
< sipa> elichai2: the kind of technically-UB-by-the-C++-spec-but-not-on-any-real-platform one only, afaik
< wumpus> it wasn't alignas()'s fault
< elichai2> isn't that the worse kind? :P
< sipa> elichai2: i think bugs that affect production code are just *slightly* more serious
< elichai2> right it's a pragma thing
< elichai2> anyhow, we're talking about this too much :) I'm ACK if people feel confident, my lack of understanding shouldn't stop anything
< jeremyrubin> just noting that there is a pragma free version of prevector that could be written and has no UB; but it's a bigger refactor
< cfields> elichai2: nothing wrong with being paranoid.
< sipa> of course
< wumpus> #topic deprecating signrawtx RPCs (achow101)
< wumpus> jeremyrubin: we're not discussing refactoring prevector again :)
< achow101> so multisig signrawtransaction workflows don't work with descriptor wallets
< achow101> I was thinking that because we have psbt now, we should deprecate the signrawtx RPCs
< MarcoFalke> completely or only for multisig?
< jonasschnelli> can you quickly elaborate why it won't work with desc. wallets?
< wumpus> I'm not generally in favor of depracating signrawtx RPCs, many people use the raw transactions workflow
< achow101> it should be a longer deprecation cycle because it's so widely used
< wumpus> if we do it should be *very* well documented first
< sipa> i'm not so convinced here
< jonasschnelli> agree with wumpus
< sipa> i believe it's good to "nudge" people towards PSBT, but deprecation is probably too hard a hammer for that
< luke-jr> [19:23:38] <jonasschnelli> can you quickly elaborate why it won't work with desc. wallets?
< wumpus> like make a blog post how to *old thing* in *new way*
< achow101> jonasschnelli: because of the separation of watchonly things, currently we can't create a wallet that has both the multisig script and keys to sign for it
< wumpus> yes, I agree
< achow101> so doing a multisig becomes a half assed psbt workflow
< sipa> achow101: i don't understand why we'd want descriptor wallets to not support private keys for multisig
< achow101> sipa: the issue is with exporting the private keys to the multisig
< achow101> IIRC there was contention about exporting keys that used unhardened derivation
< jonasschnelli> are those technical or conceptual limitations?
< sipa> achow101: so use hardened derivation?
< achow101> jonasschnelli: conceptual and current implementation limitations
< sipa> i understand there may be UI issues on how to make this easy
< sipa> but say you have a private key, even generated manually or whatever... you should be able to import a descriptor for a multisig based on it, and have that private key in the same wallet
< achow101> sipa: sure
< sipa> and that would work fine with signraw*, right?
< achow101> (this is also partly in the context of making all of the RPC tests work)
< achow101> sipa: yes
< sipa> ok
< achow101> but conceptually, it feels like psbt should be a directly replacement to raw txs, so we should move to remove those eventually
< jonasschnelli> I could understand why the signraw commands could refuse to work for BIP44-ish descriptor wallets (due to the hardening violation),... though for manual privkey-ckd it should work
< sipa> jonasschnelli: once you have all the right things in a descriptor wallet, it doesn't matter - hardened or not
< sipa> (is my understanding)
< sipa> achow101: i think my preference would be to mark signraw* as in "maintenance mode" or so, where they don't receive new features (e.g. they wouldn't support taproot signing when that gets in)
< instagibbs> +1
< sipa> but i feel like deprecation is kind of ruthless
< achow101> I was thinking of an extra long deprecation cycle
< wumpus> yes
< instagibbs> imo I think the tooling is too widely used and PSBT still has an adoption curve to hit
< wumpus> agree
< achow101> like 2 releases with a note saying it's deprecated, but don't disable yet. then 2 releases with it hidden behind -deprecatedprc. then remove
< instagibbs> the tooling meaning *raw*
< wumpus> maybe in a few years bring this up again :)
< * achow101> adds to 2022 calendar
< jonasschnelli> I can't completely follow why we should remove/deprecate it since in many use cases those commands work fine.
< jonasschnelli> (the accounting system had conceptual flaw in contrast)
< jonasschnelli> *flaws
< luke-jr> jonasschnelli: what flaws?
< wumpus> yes
< sipa> jonasschnelli: i think the reasoning is "it's hard to make it work nicely with descriptors, and there is a better system already... would be easy to just get rid of it"
< luke-jr> the accounting system worked fine AFAIK, just nobody cared to maintain it
< wumpus> accounting system discussion is off topic
< luke-jr> true
< luke-jr> couldn't signrawtx be reimplemented as a wrapper around PSBT?
< jonasschnelli> is the plan to only support descriptor wallets in the future?
< jonasschnelli> with some sort of migration
< sipa> luke-jr: yes (and probably should), but that wouldn't solve the problem
< achow101> my plan is to make descriptor wallets the default wallet type
< achow101> eventually
< jonasschnelli> this would be fine. As long as "legacy" wallets are still supported, signwith* commands shound't go away?
< sipa> the issue (as i understand it) is constructing a descriptor wallet that has all the same pieces of information as a current legacy wallet is unclear (where do the keys come from, how to import without reintroducing mixed wallets or watching the wrong kind of things...)
< achow101> sipa: yes
< sipa> i believe it would be nice to spend some time on actually solving that... because there is no technical reason why a descriptor wallet couldn't have that information
< jonasschnelli> exactly
< sipa> achow101: FWIW, i think your envisioned workflow (having two wallets, one with the multisig, and one with the private keys) is also pretty suboptimal
< jonasschnelli> we shouldn't enforce modes of use due to solvable technical imitations
< MarcoFalke> If the call doesn't work with descriptor wallets, it should be disabled for those wallets, not for legacy wallets as well.
< MarcoFalke> agree with jonasschnelli
< sipa> it isn't a technical limitation
< sipa> it's an unsolved UI question
< sipa> (where UI includes RPC and workflows)
< achow101> i suppose it is
< sipa> i don't think disabling signraw* for descriptor wallets would even solve the root of the issue - users would still need a workaround to do what they could before (having two wallets, and run PSBT RPCs on both)
< jonasschnelli> achow101: maybe you could write a short gist/paper about the issue for help us to understand it better?
< sipa> can i try in 3 lines?
< jonasschnelli> plz
< achow101> jonasschnelli: sure. I should write release notes for descriptor wallets anyways and there should be section on known limitations
< wumpus> +1
< sipa> currently you can construct a legacy wallet which has (1) a private key for one key and (2) watchonly records for multisigs involving that public key - this is crazy (because it means payments to the individual single key will be treated as incoming money, unable to separate it from the multisig funds), but it works great: you have the script information (the the multisig watchonly) and the private
< sipa> key for one of the keys in one wallet,...
< sipa> so it can do everything
< sipa> in descriptor wallets, you'd need to explicitly import a descriptor for the multisig, and then add a private key for one - you can't have started with a wallet that had that private key already as a single-key wallet (because then you reintroduce the mixing of singlekey/multisig funds), and you can't export that private key from another wallet (because we don't want export of non-hardened keys)....
< sipa> so where does it come from?
< sipa> i think the only question is a UX one around construction of such wallets
< sipa> </fin>
< jonasschnelli> I see. So one would need a watch-only-ms desc wallet and a single-key desc wallet for signing the PSBT (or whatever)
< achow101> yes
< achow101> and with both psbt and raw tx, the workflow is the same
< sipa> right, that would work - and the PSBT would carry the script information from the watch-only-ms wallet to the signing-key wallet
< instagibbs> user stories may help cover cases, I tend to only think about MY use case
< jonasschnelli> Which the signraw commands could construct in the background (assume providing all the infos)?
< luke-jr> aren't the multisig funds classified as watchonly?
< sipa> luke-jr: right, fair - that's the reason watchonly exists
< achow101> you go to the watch-only-ms wallet with a psbt or rawtx, it adds the scripts. then you go to the single-key wallet and sign it. it's the same workflow, but psbt is better suited for carrying this data
< sipa> but it's ridiculous that you currently can't do multisig stuff without also having payments to individual keys as balance in your wallet
< jonasschnelli> sipa: though that is rarely used, right?
< sipa> jonasschnelli: "used" ?
< sipa> it's an attack
< sipa> you can send funds to a individual key in a multisig, and the user may think it's paid to the multisig
< luke-jr> so we need a way to have can-sign non-ismine descriptors
< jonasschnelli> Kida. Yes. I see. Agree that it is a flaw/ridiculous
< sipa> luke-jr: descriptor wallets already do that
< achow101> luke-jr: we already do that. it's a question of the scripts
< sipa> we just need a good way to import a multisig descriptor + individual key into a descriptor wallet
< instagibbs> IsMine implementation in descriptor is a relative beauty :P
< sipa> if that works, signraw* and PSBT* will function just as before
< sipa> if that doesn't work, it's going to be shitty to use for both
< jonasschnelli> Now I see why it's a UX issue. We have set our own limitations which IMO could be worked around by creating the right structures on the fly for the signraw* commands when using desc.-wallets
< instagibbs> achow101, if you do this you're also going to have to get rid of the "private keys disabled" hack we've been using
< instagibbs> to detect if we want to do PSBT stuff or try to sign the transaction
< achow101> instagibbs: I don't think so. but I'll experiment
< achow101> jonasschnelli: which "right structures"
< instagibbs> achow101, well, if there exists a private key, it will try to sign and fail unexpectedly, I think, but you can test yes :)
< jeremyrubin> BTW: if you have thoughts on BIP-119 Next Steps please submit them in this survey; want to collect feedback from everyone https://forms.gle/rT3v4JjHbdn3RMnL6
< instagibbs> The wallet should just probably know explicitly that it should try to auto-sign or return a PSBT, but that's yet another UX q.
< wumpus> 3 minutes to go
< jonasschnelli> achow101: maybe I get it wrong. But if someone invokes a signraw, depending on the input, you could create either a watch-only-ms wallet or a single-privkey wallet in the background and use the PSBT workflow
< achow101> but where does the multisig script come from?
< sipa> jonasschnelli: the question is not about signraw* or PSBT*; the question is constructing a wallet that has the right information
< achow101> it's not hard to wrap signrawtx around psbts so it uses psbt internally. but it just doesn't have all of the data there
< luke-jr> descriptor wallets can or can't have multiple descriptors?
< jonasschnelli> provide it manually or provide it via a second wallet
< sipa> luke-jr: can; change and payments in general will come from distinct descriptors
< instagibbs> luke-jr, you can import any number of descriptors, there are 6 "Active" ones, aka keypool, by default
< achow101> luke-jr: can, but having a descriptor wallet contain both multisig and single key descriptors goes back to the mixed watchonly wallet thing
< instagibbs> legacy/p2sh-segwit/bech32 x internal/external
< luke-jr> achow101: not if you flag the single-keys descriptor as non-ismine?
< wumpus> sorry, time to wrap up the meeting
< achow101> jonasschnelli: yes, and that's the shitty ux sipa was talking about
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Apr 9 20:01:06 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< instagibbs> luke-jr, what you need is a way to import a key and say "yeah it's not an address", right
< instagibbs> that's what people were discussing
< sipa> instagibbs: and also how do you then come up with that key
< luke-jr> [19:51:16] <luke-jr> so we need a way to have can-sign non-ismine descriptors [19:51:31] <sipa> luke-jr: descriptor wallets already do that
< luke-jr> :/
< sipa> luke-jr: the internals can do this fine
< sipa> the question is UX
< achow101> luke-jr: given a psbt with the redeemScript, a descriptor wallet without the multisig can sign the psbt
< instagibbs> if you have a privkey, and it can sign something, it does. So single-key desc wallet can sign a multisig
< instagibbs> but that's a 2 wallet solution
< sipa> but it there shouldn't need to be any single-key desc wallet whatsoever
< instagibbs> right
< sipa> there should just be one multisig wallet with one of the keys
< instagibbs> "just a key"
< luke-jr> achow101: descriptor wallet w/ multisig descriptors ismine + singlekey descriptors non-ismine?
< jonasschnelli> I think that -> <sipa> there should just be one multisig wallet with one of the keys
< achow101> luke-jr: can't do that
< luke-jr> why not?
< sipa> luke-jr: my point is that's even a stretch; there shouldn't be a singlekey descriptor at all
< sipa> a descriptor is a way to encode information about scriptPubKeys
< sipa> there is no interesting scriptPubKey here
< jnewbery> sipa: we didn't get to it in the meeting, but is the future of asmap to fork https://github.com/sipa/asmap to https://github.com/bitcoin-core/asmap ?
< sipa> there should just be a key in the wallet, without a descriptor for the single-key version of that key
< luke-jr> sipa: so just multisig descriptor + private seed
< sipa> luke-jr: right, something like that
< instagibbs> "just"
< instagibbs> ;P
< sipa> jnewbery: #18573 would make my asmap repo obsolete
< gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
< sipa> we still need infrastructure for determining the mappings we want, which gleb has been working on
< achow101> jonasschnelli: https://gist.github.com/achow101/94d889715afd49181f8efdca1f9faa25 here's a writeup of some of the issues
< sipa> achow101: i think exporting descriptors (without private keys) should always be fine
< achow101> sipa: yes, but it's only really useful if unhardened derivation is being used
< sipa> agree
< bitcoin-git> [bitcoin] promag opened pull request #18578: gui: Fix itemWalletAddress leak when not tree mode (master...2020-fix-coincontroldialog-leak) https://github.com/bitcoin/bitcoin/pull/18578
< achow101> so one question is how to support the two use cases in the same wallet
< sipa> i *think* that exporting descriptors including private keys is also fine, as it doesn't risk exporting something that leaks the entire wallet while the user thinks it's just a single key (as in: it'll always leak the entire thing)
< sipa> but it shouldn't be possible to export derived private keys (except maybe if they're hardened... unsure)
< achow101> yes
< achow101> but exporting derived keys is necessary for the usual multisig workflow
< achow101> otherwise all you can do are ranged multisigs when maybe you just want a one time thing
< sipa> i feel that in that case you should also have started from just a single key, rather than an xpub
< sipa> i see the complication, but i'm not sure how important it is
< achow101> but how would you have started from just a single key?
< sipa> that's a great question :p
< sipa> it would be great if a ranged multisig setup already just worked
< sipa> say there was an RPC generatexpub which would generate an xprv, and import the private key, but not watch anything, and then return the xpub
< achow101> maybe if used a wallet global SigningProvider? so keys aren't associated with the scripts directly
< sipa> yeah, i think that makes sense
< achow101> ugh, rewriting it all again :(
< achow101> i'm not sure that's necessarily useful though
< sipa> you'd still need to be able to generate derived private keys
< sipa> alternatively, i think it'd be fine if there was just a way to import descriptors with some public and some private keys... without worrying how someone would obtain those for now
< achow101> sipa: yes, but worrying about how someone would obtain those is important
< sipa> oh absolutely
< sipa> but as a first step... that'd be great already
< sipa> fanquake: what is link-time garbage collection?
< fanquake> sipa: basically just the use of --gc-sections.
< fanquake> Curious, was there anything in particular that prompted you to test building like that?
< sipa> fanquake: seeing the size of bitcoin-asmap in #18573
< gribble> https://github.com/bitcoin/bitcoin/issues/18573 | [RFC] bitcoin-asmap utility by sipa · Pull Request #18573 · bitcoin/bitcoin · GitHub
< sipa> it's around 600 kB, nothing too terrible... but with gc sections etc, it's 100 kB
< sipa> i had always assumed we already enabled those options
< sipa> so i went to check if it would benefit our existing binaries as well
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/405713d00fb4...d486991aa59d
< bitcoin-git> bitcoin/master 5ca90f8 fanquake: scripts: add MACHO lazy bindings check to security-check.py
< bitcoin-git> bitcoin/master d486991 fanquake: Merge #18295: scripts: add MACHO lazy bindings check to security-check.py
< bitcoin-git> [bitcoin] fanquake merged pull request #18295: scripts: add MACHO lazy bindings check to security-check.py (master...does_noone_care_about_MH_BINDATLOAD_anymore) https://github.com/bitcoin/bitcoin/pull/18295