19:01:56 <achow101> #startmeeting 19:01:56 <core-meetingbot> Meeting started Fri May 7 19:01:56 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings. 19:01:57 <core-meetingbot> Available commands: action commands idea info link nick 19:02:34 <fjahr> hi 19:02:50 <sipa> hi 19:02:51 <meshcollider> Hi 19:03:03 <achow101> #bitcoin -core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag 19:03:03 <achow101> provoostenator ryanofsky sdaftuar sipa vasild wumpus 19:03:11 <achow101> any topics? 19:03:30 <sipa> none from me 19:03:38 <jonatack> hi 19:03:51 <meshcollider> Any wallet review begs? 19:04:01 <achow101> #17331 pls 19:04:01 <jonatack> yes! 19:04:07 <gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 ÷ Pull Request #17331 ÷ bitcoin/bitcoin ÷ GitHub 19:04:08 <meshcollider> Theres a few things in the GUI repo I need to have a look at 19:04:42 <fjahr> will re-review 17331 this weekend 19:04:51 <jonatack> #21786 is my second proposal to fix #20534 from last year 19:04:53 <gribble> https://github.com/bitcoin/bitcoin/issues/21786 | wallet: ensure sat/vB feerates are in range (mantissa of 3) by jonatack ÷ Pull Request #21786 ÷ bitcoin/bitcoin ÷ GitHub 19:04:53 <gribble> https://github.com/bitcoin/bitcoin/issues/20534 | sat/b values arent validated to be in-range ÷ Issue #20534 ÷ bitcoin/bitcoin ÷ GitHub 19:05:10 <jonatack> it's simpler and more complete 19:06:15 <achow101> cool, I'll add it to my list 19:06:30 <jonatack> 17331 and follow-up are on my list 19:06:53 <jonatack> the review clubs were very good 19:07:59 <fjahr> Looking forward to a rebase on #21365 as well :) 19:08:02 <gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa ÷ Pull Request #21365 ÷ bitcoin/bitcoin ÷ GitHub 19:08:19 <fjahr> jonatack: will check it out 19:08:48 <jonatack> fjahr: thanks. it's only a handful of lines and then tests 19:08:50 <achow101> Is it reasonable to try to get taproot wallets for 22.0? 19:10:48 <achow101> With feature freeze in June, I'm not sure that we can make it 19:10:52 <meshcollider> I think so? 19:10:56 <jonatack> five weeks until June 15 feature freeze 19:11:19 <meshcollider> Nothing is impossible if enough people are willing to make it happen :) 19:11:53 <achow101> oh, it's only #21365, the prereqs were merged 19:11:56 <gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa ÷ Pull Request #21365 ÷ bitcoin/bitcoin ÷ GitHub 19:12:03 <fjahr> I guess if signalling goes well interest will be high enough, if not people will focus on activation discussions :-/ 19:12:46 <fjahr> (by well at least going in the right direction towards lockin within the next 4 weeks) 19:12:57 <fjahr> *by well I mean 19:13:36 <achow101> hmm, there's also the question of how does the wallet behave if that is merged before taproot activates? 19:13:56 <achow101> definitely don't want to be giving out taproot addresses before activation 19:14:24 <achow101> 22.0 will definitely be released before activation 19:14:40 <sipa> we can merge taproot wallet support without by default construction such descriptors 19:15:02 <achow101> but what happens if someone imports a taproot descriptor? 19:15:05 <sipa> perhaps we additionally want a safeguard that prevents the creation of such addresses in general before activation 19:15:29 <sipa> but you can't prevent people from importing crazy descriptors in general 19:16:27 <meshcollider> I mean, it's not like someone can accidentally import a taproot descriptor if they didn't intend to 19:17:37 <achow101> indeed 19:18:04 <jonatack> address safeguard sounds good 19:18:30 <sipa> i'm not sure where such a safeguard should go 19:18:35 <sipa> prevent importing the descriptor? 19:18:42 <sipa> that's possible with some adhoc code i guess 19:18:58 <sipa> or prevent generating addresses with it? 19:19:04 <sipa> or outlaw the descriptor in general? 19:19:05 <achow101> I was thinking we should have a warning if someone imports a taproot descriptor 19:19:09 <luke-jr> maybe tr() shouldn't be valid until activation? 19:19:22 <achow101> and then something that disallows getting bech32m addresses 19:19:28 <jonatack> for mainnet 19:19:47 <sipa> luke-jr: a downside is that a wallet rescanning post activation might consider the descriptor invalid then 19:20:09 <luke-jr> hmm 19:20:09 <sipa> well, or a node reindexing, with a loaded wallet 19:20:23 <sipa> sec, brb 19:20:39 <luke-jr> I guess logically it should simply not be recognised as the sPK matching 19:20:42 <achow101> maybe just a scary warning on import then. just tell people what they're doing is not recommended because taproot isn't active 19:20:57 <luke-jr> since you don't want a wallet rescan to show pre-activation coins either 19:21:36 <sipa> luke-jr: hmm 19:24:54 <achow101> hmm, if we disallow import until after activation, then none of this would be a problem? 19:25:02 <achow101> even pre-activation coins are fine post-activation 19:25:12 <meshcollider> Yeah it seems a catch at import-time would be simplest then 19:25:57 <sipa> achow101: yeah, that seems reasonable 19:27:59 <achow101> anything else to discuss? 19:30:00 <achow101> #endmeeting