19:01:09 <achow101> #startmeeting 
19:01:33 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
19:01:34 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:02:14 <achow101> There is 1 pre-proposed topic. any last minute topics to add?
19:02:20 <S3RK> hi
19:02:46 <S3RK> I'd like to ask a question about descriptors that produce same scriptpubkeys
19:03:42 <sipa> hi
19:03:58 <achow101> #topic expand fundrawtx external input support to allow arbitrary scripts (achow101)
19:04:14 <kanzure> hi
19:04:41 <achow101> Originally I wanted to ask whether we should do this, but I think it's a bit moot now since people have been reviewing #23201
19:04:43 <gribble> https://github.com/bitcoin/bitcoin/issues/23201 | wallet: Allow users to specify input weights when funding a transaction by achow101 · Pull Request #23201 · bitcoin/bitcoin · GitHub
19:06:24 <achow101> the current proposal is to just let users specify the weights. yanmaani has suggested allowing users to provide signed inputs (in the tx for fundrawtx) and use that for weight estimation
19:07:01 <achow101> the only issue I saw with the latter idea is that signature sizes can change, but that can be solved by figuring out how many signatures there are and using their max sizes rather than real sizes
19:07:03 <achow101> thoughts?
19:07:49 <sipa> no opinion, really
19:08:16 <S3RK> shrugs
19:08:42 <achow101> I suspected that would be the case
19:08:54 <achow101> #topic descriptors that produce same scriptpubkeys (S3RK)
19:09:39 <S3RK> I believe it's technically possible right now to import multiples descriptors that would produce same scripts
19:09:55 <S3RK> can you think of any valid use cases for this?
19:10:20 <achow101> upgrading a raw(addr) to full descriptor?
19:10:39 <sipa> or upgrading in general; e.g. adding origin info?
19:10:52 <achow101> but perhaps upgrading should be an actual upgrade and not duplicating
19:10:59 <sipa> right
19:11:11 <S3RK> yes, for upgrading we can replace the existing descriptor
19:11:59 <S3RK> if this is the only case, should we try to prevent users from importing such descriptors?
19:12:15 <achow101> yes, but that may be difficult
19:12:16 <S3RK> I think it could be hard to detect in some casees
19:12:33 <achow101> e.g. something with derived keys at a high index
19:12:44 <S3RK> yes, exactly what I thought
19:12:50 <sipa> remind me, is it possible to import non-ranged descriptors?
19:12:54 <achow101> yes
19:12:55 <S3RK> yes
19:13:09 <achow101> I'm not sure that duplicating is necessarily detrimental though
19:13:16 <achow101> other than wasting space
19:13:43 <S3RK> It makes it a bit harder to reason about code
19:13:50 <S3RK> I made this mistake in my last PR
19:14:35 <S3RK> should we try to prevent at least in cases when we can detect it?
19:14:45 <achow101> iirc signing and fillpsbt go through all of the spkmans so it doesn't matter if one has less info than another, although conflicting info may be a problem
19:15:16 <S3RK> another one is `getaddressinfo`
19:16:23 <achow101> hmm yes
19:16:44 <achow101> I think it's reasonable to prevent it in obvious cases
19:17:46 <achow101> I would say that having multiple descriptors for the same scripts is not a supported use case, so we shouldn't worry too much about it
19:18:00 <achow101> *about writing code that can deal with it
19:18:37 <S3RK> khm... I agree with the sentiment, but than we should make it clear that it's not supported
19:18:45 <S3RK> s/than/then/
19:19:14 <achow101> yes
19:20:16 <S3RK> we can prevent at import time most cases
19:20:28 <S3RK> and if we detect later we can deactivate maybe?
19:20:50 <S3RK> I don't know how far we should go to avoid it
19:21:08 <achow101> if we were to detect it later, there isn't much that can be done to resolve it
19:21:33 <achow101> it would mean that the user would need to be able to delete the descriptor, but I'm really hesitant to add anything that would let people delete data from their wallet
19:21:36 <achow101> especially private keys
19:22:15 <S3RK> and there are probably already wallets like this :)
19:22:52 <S3RK> ok. good to know your thoughts, thanks
19:23:19 <achow101> any other topics?
19:24:24 <achow101> #endmeeting