19:00:00 <wumpus> #startmeeting
19:00:00 <lightningbot> Meeting started Thu Feb  6 19:00:00 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:00 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:16 <MarcoFalke> ahoy
19:00:27 <wumpus> I don't expect many people to be here today with the London conference, but we can try...
19:00:28 * BlueMatt 
19:00:32 <sipsorcery> hi
19:00:42 <sipa> hi
19:00:46 <jonasschnelli> hi
19:00:46 <emilengler> hi
19:00:49 <amiti> hi
19:01:01 <hebasto> hi
19:01:09 * BlueMatt 
19:01:15 <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
19:01:17 <wumpus> jeremyrubin lightlike emilengler jonatack hebasto jb55
19:01:45 <fjahr> hi
19:01:51 <wumpus> one proposed topic on https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a: Remove i686 Linux download link from bitcoincore website (MarcoFalke)
19:01:56 <aj> hi
19:01:58 <wumpus> any last minute topic proposals?
19:02:03 <jeremyrubin> hi
19:02:23 <jeremyrubin> proposed topic: mempool project update
19:02:30 <jonatack> hi
19:02:39 <wumpus> jeremyrubin: ack
19:02:41 <moneyball> hi
19:02:42 <kanzure> hi
19:02:53 <jkczyz> hi
19:02:54 <kanzure> proposed topic: more topic selection (or actually, how about topics you don't want to hear about for march)
19:02:56 <promag> hi
19:03:02 <emilengler> proposed topic: the library for #17950, even if to use a library?
19:03:05 <gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler · Pull Request #17950 · bitcoin/bitcoin · GitHub
19:03:35 <wumpus> #topic High priority for review
19:04:00 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 -> 6 blockers, 1 bugfix, 6 chasing concept ACK
19:04:09 <wumpus> anything to add / remove or almost ready for merge?
19:04:48 <meshcollider> hi
19:04:59 <wumpus> hi
19:05:18 <MarcoFalke> The cs_main cs_wallet thing needs rebase and has something proposed by ryanofsky as a preparation pull request. Should these be  exchanged?
19:05:48 * luke-jr glances at some chirping crickets
19:05:49 <wumpus> MarcoFalke: I suppose that makes sense, if the other one is a blocker for this one
19:05:58 <wumpus> either that or add it too
19:06:16 <MarcoFalke> #17954 is the prep I think
19:06:18 <gribble> https://github.com/bitcoin/bitcoin/issues/17954 | wallet: Remove calls to Chain::Lock methods by ryanofsky · Pull Request #17954 · bitcoin/bitcoin · GitHub
19:06:34 <jonasschnelli> half of the PR in high-prio do fail CI
19:06:51 <MarcoFalke> jonasschnelli: travis s390x?
19:07:04 <wumpus> ok, added
19:07:10 <luke-jr> maybe we should disable the s390x temporarily?
19:07:12 <ryanofsky> MarcoFalke, yes my preference would be to do 17954 first
19:07:23 <jonasschnelli> MarcoFalke: I don't know but makes people ignore CI (which is a QA issue in the long run
19:07:45 <MarcoFalke> Yes, maybe we should disable it on travis for now
19:07:51 <MarcoFalke> I do run it locally
19:08:02 <hebasto> How valuable is s390x tests?
19:08:03 * jonasschnelli think the CI should be less fragile
19:08:12 <wumpus> hebasto: big-endian testing
19:08:33 <MarcoFalke> jonasschnelli: travis is the only one that offers s390x native
19:08:45 <wumpus> that's basically the only reason s390x testinig is valuable
19:08:52 <luke-jr> too bad Travis doesn't have ppc64be
19:08:54 <jonasschnelli> I think its very valuable
19:08:55 <wumpus> no one runs bitcoind on that platfor mas far as I'm aware
19:09:07 <wumpus> so any other big-endian platform would do as well
19:09:43 <sipa> yeah, even if we expect literally noone ever to use bitcoin core in production on s390x, variety in test platforms can often expose bugs present but undetectable on other platforms
19:09:50 <MarcoFalke> I do run it, but it is through qemu
19:10:05 <MarcoFalke> sipa: It did find a bug in the tests :)
19:10:17 <sipa> MarcoFalke: the best kind of bug
19:10:25 <MarcoFalke> +1
19:10:31 <wumpus> especially for serialization changes it's very useful to test big endian correctness
19:10:31 <jonasschnelli> Maybe its not ready for a per branch update/PR base but as a manual check?
19:10:47 <jonatack> jonasschnelli: btw thank you for https://bitcoinbuilds.org. it is the first place i look for CI results.
19:11:07 <jonasschnelli> jonatack: It's running again smoothly.. but no native s390x supper...
19:11:24 <jonasschnelli> could try to get a qemu be env up. But I guess it will be too slow
19:11:51 <sipa> may be useful to run s390x qemu on master on a regular basis, but not on every PR?
19:12:04 <wumpus> power can can be big-endian as well, though, it's fairly rare (and travis doesn't offer that)
19:12:05 <jonasschnelli> +1
19:12:14 <MarcoFalke> If someone is knowledged in docker, #18016 is the problem we need fixed
19:12:15 <gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small · Issue #18016 · bitcoin/bitcoin · GitHub
19:12:17 <wumpus> agree sipa
19:12:36 <luke-jr> wumpus: not so rare; but can't be a simple chroot :/
19:12:55 <MarcoFalke> So I think #action is to either fix #18016 or remove it and run locally?
19:12:57 <gribble> https://github.com/bitcoin/bitcoin/issues/18016 | travis: s390x ci build fails on travis because disk is too small · Issue #18016 · bitcoin/bitcoin · GitHub
19:13:15 <wumpus> I don't think we can fix "disk too small" so that leaves removing it for now
19:13:55 <MarcoFalke> It can be fixed with some docker settings and restarting docker, but I don't know anything about this "docker" thing
19:14:14 <wumpus> me neither, I've always managed to avoid it
19:14:47 <MarcoFalke> There is a disk large enough in /var/snap/lxd/... on travis
19:14:57 <MarcoFalke> Anyway, next topic?
19:15:07 <wumpus> #topic Remove i686 Linux download link from bitcoincore website (MarcoFalke)
19:15:20 <wumpus> yes, let's do it
19:15:24 <jonasschnelli> ack
19:15:31 <MarcoFalke> So based on a twitter poll, a mailing list post, we only found one confrimed user of i686 #17504
19:15:33 <gribble> https://github.com/bitcoin/bitcoin/issues/17504 | Should we still ship 32-bit x86 Linux binaries? · Issue #17504 · bitcoin/bitcoin · GitHub
19:15:54 <wumpus> https://github.com/bitcoin-core/bitcoincore.org/pull/695
19:15:54 <MarcoFalke> So as a first step it could make sense to remove the i686 download link from the website
19:16:06 <emilengler> Shouldn't we wait until we don't produce any i686 anymore
19:16:29 <MarcoFalke> emilengler: Removing the link first gives everyone another chance to notice it
19:16:32 <luke-jr> ^
19:16:32 <emilengler> I think it's a better approach to add a note on the website and remove the link once the new version got released
19:16:42 <luke-jr> I'd like to be sure this doesn't turn into the Win32 situation
19:16:49 <MarcoFalke> emilengler: The i686 bin will still be uploaded for now
19:16:58 <luke-jr> the plan there afaik was simply to stop making binaries, but now we're removing the ability to even compile it
19:17:14 <MarcoFalke> luke-jr: That is not going to happen
19:17:22 <wumpus> we need to support 32 bit for self-compiles, period
19:17:24 <luke-jr> k
19:17:31 <MarcoFalke> luke-jr: We have a i686 centos build in ci, that is not going to be removed
19:17:43 <wumpus> ARM 32 bit is not dead, and neither is RISC-V 32 bit, and some others
19:18:32 <jonasschnelli> Indeed. There are a lot of Odroid in the field (Cortex A15).
19:18:37 <wumpus> I think I've been very clear everywhere that this is about the shipped binaries
19:18:49 <wumpus> for x86 32 bit
19:18:53 <luke-jr> wumpus: right, but that was true for Win32 too
19:19:23 <wumpus> win32 is really dead anyhow
19:20:11 <emilengler> The topic was to remove it from the website and nothing else. I feel this discussion drives a bit away to a more general topic about x86 in general. Could we come back to the original point?
19:20:18 <hebasto> even not all libs are available for x86
19:20:31 <luke-jr> hebasto: ⁈
19:20:50 <harding> Removing it from the website to see if anyone complains while it's still easy to add it back makes sense to me.
19:20:50 <hebasto> see Centos 32-bit repo
19:21:20 <luke-jr> hebasto: that's too vague to mean anything to me
19:21:52 <wumpus> yes, so let's remove it from the website, but still build x86_32 binaries for 0.19.1
19:22:00 <MarcoFalke> +1
19:22:03 <luke-jr> sgtm
19:22:10 <wumpus> then for 0.20 stop building them
19:22:44 <emilengler> ack
19:22:55 <wumpus> #topic Mempool project update (jeremyrubin)
19:23:02 <jeremyrubin> hola
19:23:15 <jeremyrubin> So the first PR of the epoch mempool series has been merged
19:23:37 <wumpus> congrats!
19:23:42 <jeremyrubin> Thanks!
19:23:44 <jeremyrubin> I've opened up the next step, which gets rid of this big cache we built during reorgs
19:23:56 <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/18063
19:24:35 <jeremyrubin> Amiti's testing framework changes are making progress & seem good to go IMO
19:24:38 <wumpus> good to know
19:25:41 <jeremyrubin> It seems like there's been not too much attention on nanobench stuff, would be good to "just do it IMO" but I don't have many downstream toolchains
19:25:43 <wumpus> which PR is that?
19:25:51 <jeremyrubin> sorry scrambling for links...
19:25:57 <wumpus> (Amiti's changes, I mean)
19:25:59 <jeremyrubin> #18037
19:26:02 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
19:26:12 <jeremyrubin> and #18011
19:26:14 <gribble> https://github.com/bitcoin/bitcoin/issues/18011 | Replace current benchmarking framework with nanobench by martinus · Pull Request #18011 · bitcoin/bitcoin · GitHub
19:26:46 <jeremyrubin> Amiti has also opened up a new PR that carves out a good chunk of functionality for rebroadcasting
19:26:54 <jeremyrubin> is amiti here? I can ping her
19:26:57 <amiti> ya Im here
19:26:58 <jeremyrubin> #18037
19:27:01 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
19:27:23 <wumpus> ok so add #18037 to high priority for review?
19:27:24 <jeremyrubin> amiti: should people be taking a look at 18037 now?
19:27:25 <amiti> #18038 is the rebroadcast subset
19:27:25 <gribble> https://github.com/bitcoin/bitcoin/issues/18037 | Util: Allow scheduler to be mocked by amitiuttarwar · Pull Request #18037 · bitcoin/bitcoin · GitHub
19:27:26 <gribble> https://github.com/bitcoin/bitcoin/issues/18038 | P2P: Mempool tracks locally submitted transactions to improve privacy by amitiuttarwar · Pull Request #18038 · bitcoin/bitcoin · GitHub
19:27:46 <jeremyrubin> Ah right sorry
19:28:07 <amiti> if 18038 builds on 18037, so if 18037 gets merged in current state then 18038 is ready for review
19:28:30 <jeremyrubin> yes so I think 18037 is hi prio and can be merged with another ack or two (it's just testing stuff)
19:28:53 <jeremyrubin> And then we can pull some ears (not yet hi-prio) for 18038
19:29:32 <jonatack> jeremyrubin: perhaps add #18044 to your mempool dashboard? https://github.com/bitcoin/bitcoin/projects/14
19:29:34 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
19:29:37 <wumpus> ok
19:29:38 <jeremyrubin> Same goes for #18063 -- once I get a reviewer or two I'd like to put it high priority so that progress can keep moving
19:29:40 <gribble> https://github.com/bitcoin/bitcoin/issues/18063 | Improve UpdateForDescendants by using Epochs and Removing CacheMap by JeremyRubin · Pull Request #18063 · bitcoin/bitcoin · GitHub
19:30:12 <jeremyrubin> is 18044 needed for package relay?
19:30:49 <jonatack> no, part of it changes the mempool, up to you
19:30:55 <jeremyrubin> is sdaftuar here and can talk more about it?
19:31:22 <jeremyrubin> I'll add it but from what I can tell this one requires a BIP to move forward?
19:31:41 <jonatack> yes, there is a wip bip draft for now
19:31:43 <sipa> i believe sdaftuar is working on one
19:32:27 <jeremyrubin> Ok great. I'll add it to the package relay track since that's mostly sdaftuar right now anyways, but I think logically it seems more on rebroadcasting
19:32:41 <jeremyrubin> amiti do you have any thoughts on that? Can you review 18044?
19:32:58 <jonatack> WIP BIP draft https://github.com/sdaftuar/bips/blob/2020-02-wtxid-relay/bip-wtxid-relay.mediawiki
19:33:02 <amiti> yeah I've started taking a look, its more about initial broadcast than rebroadcast
19:33:36 <jeremyrubin> (and then I think we're good on mempool project unless anyone has any questions -- please see https://github.com/bitcoin/bitcoin/projects/14 to get references for what to review & look at)
19:34:56 <luke-jr> …
19:35:06 <jeremyrubin> ?
19:35:16 <wumpus> #topic the library for #17950 (emilengler)
19:35:18 <gribble> https://github.com/bitcoin/bitcoin/issues/17950 | gui: Check the strength of an encryption password by emilengler · Pull Request #17950 · bitcoin/bitcoin · GitHub
19:35:33 <wumpus> I *really* do not like introducing a dependency for this
19:35:35 <emilengler> thanks
19:35:42 <emilengler> I agree with wumpus
19:36:00 <jonasschnelli> Yes. Please no dependency for a gimmick feature
19:36:05 <wumpus> it's somewhat nice to display a measure of password strength (if people can ever agree on one), but it's not worth large changes to our build process for
19:36:09 <sipa> i feel that anything that self-written is going to be too ad-hoc to be useful
19:36:10 <wumpus> exactly
19:36:10 <jonasschnelli> It is already handholding...
19:36:24 <sipa> so either it's depending on a well-maintained library, or we don't do it at all
19:36:24 <jeremyrubin> I think i'd rather just *suggest* a strong password
19:36:25 <luke-jr> there's conceptual problems in the first place
19:36:47 <wumpus> maybe it's a bad idea in the first place, thinking of it, we don't want to encourage a specific kind of password scheme, this only reduces security
19:36:52 <luke-jr> this shouldn't be a "strong" password, it should be a memorable one
19:36:56 <jeremyrubin> e.g., here are 12 random words
19:37:04 <wumpus> that, too
19:37:13 <luke-jr> encrypted wallets won't stop malware, just little brother
19:37:30 <luke-jr> the risk of losing access outweighs the benefits of a string passphrase here
19:37:32 <jonasschnelli> Can we just have a short text to help people do the right thing? Or a link (less likely)?
19:37:32 <wumpus> it's not a brainwallet, not the entire internet can attack it, the security needed depends on how secure the wallet file is kept
19:37:46 <gwillen> it is very hard to make a password-strength indicator that is not at least sometimes very misleading
19:37:56 <wumpus> making it too strong might cause people to forgt it
19:38:00 <MarcoFalke> I think more people have lost coins due to forgetting too strong passwords than first getting their wallet stolen, but not their password, and then got their password cracked offline
19:38:02 <wumpus> which is much worse
19:38:11 <jonasschnelli> Indeed
19:38:11 <sipa> gwillen: zxcvbn seems pretty sophisticated already
19:38:14 <sipa> *actually
19:38:15 <wumpus> MarcoFalke: agree
19:38:30 <sipa> it's very hard because users probably don't have a good intuition for what the requirements are
19:38:30 <wumpus> what would be nice is a feature that makes people write down their HD seed
19:38:39 <wumpus> aid recovery, not make it worse
19:38:45 <jeremyrubin> (I'm actually recovering a wallet for someone who forgot their password, so I agree)
19:38:45 <MarcoFalke> yeah
19:39:01 <wumpus> a lot of people lose their coins either by losing their wallet or paspphrase
19:39:01 <sipa> if the wallet.dat file leaking is an attack vector you want to protect against, the password needs to be *far* stronger than common recommendations for website login passwords
19:39:03 <jonasschnelli> wumpus: you mean adding BIP39 support?
19:39:06 <jeremyrubin> * attempting that is, let's hope the fragments are good enough
19:39:28 <gwillen> sipa: as such things go, it's pretty sophisticated, but it does not know your dog's name, or your mother's maiden name, or your birthday, or your favorite book you're quoting from, or any of a number of stupid things users do that lower effective entropy
19:39:40 <gwillen> while not lowering apparent entropy relative to the tool's model
19:39:41 <luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
19:39:45 <wumpus> jonasschnelli: yes I suppose
19:39:53 <sipa> gwillen: of course it can only give an upper bound
19:40:00 <gwillen> it's never presented that way, though
19:40:12 <sipa> anyway
19:40:25 <sipa> i'm in favor of just not pursuing that feature
19:40:31 <jeremyrubin> luke-jr: disagree with those priors
19:40:35 <sipa> it's too hard to do right
19:40:35 <luke-jr> jeremyrubin: ?
19:40:48 <jeremyrubin> [11:39] <luke-jr> sipa: but if the wallet.dat file leaks, you probably have a keylogger on your PC anyway, so..
19:40:48 <MarcoFalke> Yeah, we should recommend users use a shorter password, if anything
19:40:51 <sipa> luke-jr: wallet.dat files get backed up
19:40:59 <wumpus> luke-jr: they might copy it to a cloud service or something
19:41:00 <sipa> MarcoFalke: i disagree with that as well
19:41:02 <luke-jr> sipa: hopefully encrypted!
19:41:04 <jeremyrubin> I think it's relatively likely you leak your file but don't get a keylogger
19:41:13 <sipa> luke-jr: right, but in that case, the passphrase needs to be strong
19:41:25 <luke-jr> sipa: no, I mean encrpying the file itself
19:41:26 <jeremyrubin> e.g., keeping backups on thumb drives
19:42:01 <sipa> luke-jr: it's hard to assume that people will use a strong password for an encrypted backup, but then not one inside the file?
19:42:15 <luke-jr> perhaps we should put a suggestion to that effect somewhere
19:42:16 <wumpus> in any case, there's no disagreement about whether the wallet encryption is useful or not, that's not the topic
19:42:17 <sipa> i disagree that in general we should advise weak passwords
19:42:33 <wumpus> no, we shouldn't advise that
19:42:45 <MarcoFalke> ok, we shouldn't advise on weak passwords, but we might want to explain the tradeoffs
19:42:53 <sipa> MarcoFalke: yes
19:42:59 <wumpus> that would make sense, yes
19:43:02 <wumpus> add an explanation
19:43:03 <MarcoFalke> I.e. what the password protects against and what it does not protect against
19:43:07 <sipa> "Losing this password will make your funds irrecoverably lost"
19:43:28 <jeremyrubin> I think also saying "writing down the password in a notebook is probably better than not having one"
19:43:36 <jonatack> https://www.xkcd.com/936/
19:43:37 <jeremyrubin> Or something to that effect
19:43:38 <jonasschnelli> I'm all for informing (text based) rather then applying rules that only works for certain use cases
19:43:48 <luke-jr> jeremyrubin: it really depends on your risk exposure
19:43:53 <jeremyrubin> I think people don't know that the password is not a seed
19:44:14 <jeremyrubin> if you just write down the password but they don't have the wallet.dat it's fine
19:44:44 <wumpus> jeremyrubin: yep, some people are confused by that
19:44:45 <jeremyrubin> luke-jr: if someone remote compromises your computer but you have a sticky note with a long password on your screen you're "fine"
19:45:06 <wumpus> because most wallets work with seeds nowadays
19:45:07 <jeremyrubin> (until you type it in, but let's assume read only compromise)
19:45:09 <jonasschnelli> The wallet encryption should be better explained. I would not wonder if some users encrypt their watch only wallets in the hope to not leak metadata to computer wide text pattern searches, etc.
19:45:21 <wumpus> agree with jonasschnelli on adding explanation text
19:45:38 <luke-jr> you can't encrypt watch-only I thought?
19:45:44 <emilengler> I think it may be a good way to add a way to encrypt the wallet in the intro dialog
19:45:45 <jonasschnelli> Can't you?
19:45:46 <hebasto> explanation is good
19:46:05 <wumpus> only private keys are encrypted, so encrypting watch-only would be a no-op
19:46:07 <luke-jr> jonasschnelli: what would it even do?
19:46:07 <sipa> jonasschnelli: of course not
19:46:10 <jonasschnelli> luke-jr: I guess you can because its mostly a mixed situation
19:46:13 <sipa> what would there be to encrypt?
19:46:25 <jonasschnelli> sipa: thats exactly the problem
19:46:32 <jonasschnelli> people expect things are encrypted
19:46:41 <wumpus> the metadata is never encrypted
19:46:47 <jonasschnelli> while we only encrypt the keys
19:46:52 <jonasschnelli> Yes. But we don't tell that to users
19:47:01 <sipa> jonasschnelli: a no-key wallet can't be encrypted, i think?
19:47:04 <luke-jr> it's obvious?
19:47:12 <jonasschnelli> So,.. IRS grabs wallet.dat file and reads transaction comments
19:47:16 <wumpus> this is why software needs documentation I guess
19:47:22 <sipa> luke-jr: don't assume things are obvious
19:47:22 <jeremyrubin> luke-jr: how is it obvious?
19:47:31 <jeremyrubin> That they can open the wallet and see stuff and only pw to sign?
19:47:35 <jonasschnelli> It's not obvious to most users
19:47:37 <luke-jr> you open Bitcoin Core and see your metadata, without entry of passphrase
19:47:51 <wumpus> jonasschnelli: well it doesn't ask th password at startup, only when you send
19:47:52 <jonasschnelli> encryption means for most users data can't be read by someone no knowing the secret
19:47:53 <jeremyrubin> Actually that sounds like a 2 birds one stone thing
19:48:08 <jonasschnelli> wumpus: sure. But novice users don't understand that either
19:48:15 <jeremyrubin> If people have to put their password in more often maybe they're less likely to forget it ;)
19:48:23 <luke-jr> jeremyrubin: hmm!
19:49:00 <jonasschnelli> I think adding more explanations on how the encryption work would be great in general
19:49:05 <jonasschnelli> works
19:49:21 <MarcoFalke> Opened an issue #18085
19:49:22 <gribble> https://github.com/bitcoin/bitcoin/issues/18085 | doc: Explain what the wallet password does · Issue #18085 · bitcoin/bitcoin · GitHub
19:49:28 <jonasschnelli> Nice
19:49:37 <wumpus> thanks
19:49:46 <jeremyrubin> I think there's also a lot of room for improvements in what users have available, e.g. shamir's secret shares
19:49:52 <jonasschnelli> We don't encrypt the wallet, we encrypt the keys
19:50:29 <jonatack> I sense new options/config args in our future here
19:50:32 <jeremyrubin> Even though we know multisig is better, user's are really struggling to do anything better than a plaintext wallet
19:51:13 <luke-jr> not sure it makes sense to put any effort into pre-Taproot multisig at this point?
19:51:16 <sipa> jeremyrubin: that's not really an option in a model where a wallet is a file and not a seed
19:51:17 <wumpus> we should be careful only to add features that are actually used and useful though, don't want to end up with some GPG-like tool that does a zillion things but with a lot of pitfalls
19:51:30 <jeremyrubin> Maybe organizing some discussion at coredev.tech would be good about conducting some user research to improve things.
19:51:52 <kanzure> i'll add that to the list then.
19:51:57 <kanzure> empirical user testing would be interesting
19:51:59 <sipa> luke-jr: multisig support at this point means improving PSBT integration, i think
19:52:02 <jeremyrubin> Can ask some of the ideo people to come by since they've been doing key managment UXs with a lot of projects
19:52:08 <sipa> luke-jr: which we should definitely work on
19:52:13 <luke-jr> good point
19:52:17 <kanzure> i'd prefer to forego ideo
19:52:20 <jeremyrubin> sipa: you can still do point-in-time non seed backups
19:52:35 <jeremyrubin> kanzure: Any specific reason?
19:53:09 <jonasschnelli> let's not sidetrack this topic. :)
19:53:21 <sipa> yes please
19:53:48 <wumpus> maybe more apprpriate for the wallet meeting, too
19:53:59 <sipa> yeah
19:54:34 <wumpus> not that we have any more topics for today
19:54:45 <sdaftuar> hi - i'm back, if anyone has questions about wtxid-relay i can discus
19:55:03 <jeremyrubin> yay! please do
19:55:04 <MarcoFalke> sdaftuar: There was a question whether it was needed for package relay
19:55:50 <sdaftuar> i think it's a nice-to-have, but non-essential
19:56:12 <sdaftuar> nice-to-have only because any tx-relay protocol change we make in the future (like erlay, or dandelion, etc) should be done on wtxid-based relay
19:56:17 <jeremyrubin> I guess more concretely where it fits into the https://github.com/bitcoin/bitcoin/projects/14 workflow and where you think it belongs timeline wise
19:56:56 <sdaftuar> well, i'm probably personally gated on it, as i don't want to work on more p2p relay things based on txid-relay at this point
19:57:04 <jeremyrubin> Like if new rebroadcasting stuff like what amiti is working on should be done on wtxids then do we try to slot this before it
19:57:08 <sdaftuar> barring some reason that wtxid-relay is a problem
19:57:18 <jeremyrubin> ah ok; so it slots before further package relay work for you
19:57:39 <luke-jr> I never really understood why we didn't do wtxid-relay from the start
19:57:51 <sdaftuar> luke-jr: we shoudl have! the second best time is now
19:57:53 <jeremyrubin> we didn't have wtxids before segwit
19:57:53 <luke-jr> (or if I did, I forgot)
19:58:01 <sdaftuar> it was just more work, and we were busy
19:58:22 <sdaftuar> but i think it's pretty straightforward, and we should do it, ideally before we make a standardness change to segwit transactions
19:58:31 <jonatack> ack
19:58:33 <sipa> i think initially it wasn't that clear that it was needed in the first place
19:58:49 <sipa> and when segwit was further along, it got pushed back to "later"
19:58:52 <sipa> seems later is now
19:58:55 <wumpus> 1 minute left
19:59:01 <sdaftuar> yeah i'm not sure how much anyone thought about it until petertodd pointed out the issues in #8279
19:59:03 <gribble> https://github.com/bitcoin/bitcoin/issues/8279 | Mempool DoS risk in segwit due to malleated transactions · Issue #8279 · bitcoin/bitcoin · GitHub
19:59:29 <jeremyrubin> My only concern looking at the code is that a new index in maptx kinda sucks
19:59:53 <sdaftuar> a bit more memory, but i don't see a way around it, and i think the tradeoff is well worth the benefit
20:00:03 <sipa> DING DONG
20:00:06 <wumpus> #endmeeting