19:00:56 <meshcollider> #startmeeting 
19:00:57 <core-meetingbot> Meeting started Fri Jul 16 19:00:56 2021 UTC.  The chair is meshcollider. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:57 <core-meetingbot> Available commands: action commands idea info link nick
19:01:05 <meshcollider> #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:01:05 <meshcollider> provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:13 <meshcollider> Topics?
19:01:30 <jonatack> jnewbery: have you (a) been testing I2P on master, and (b) found cases of addrman corruption?  IIUC the ossfuzzer is naturally turning up cases we didn't know about before. ISTM that is to be expected.
19:01:38 <fjahr> hi
19:01:41 <achow101> hi
19:01:46 <jonatack> hi :)
19:01:49 <michaelfolkson> hi
19:02:19 <michaelfolkson> I have some general Taproot roadmap questions if there's nothing on the agenda
19:02:22 <kvaciral[m]> hi
19:02:32 <meshcollider> No more urgent wallet things found that need to go into 0.22 right?
19:02:36 <meshcollider> 22*
19:02:37 <kanzure> hi
19:02:58 <achow101> #22461 is the only wallet pr marked for 22.0
19:03:00 <gribble> https://github.com/bitcoin/bitcoin/issues/22461 | wallet: Change ScriptPubKeyMan::Upgrade default to True by achow101 · Pull Request #22461 · bitcoin/bitcoin · GitHub
19:03:46 <sipa> hi
19:04:19 <meshcollider> #topic general taproot roadmap questions (michaelfolkson)
19:04:20 <core-meetingbot> topic: general taproot roadmap questions (michaelfolkson)
19:05:10 <michaelfolkson> So perhaps starting with PSBT (and apologies if my understanding of PSBT has holes)
19:06:09 <achow101> There are proposed taproot fields for psbt PR'd to the bips repo: https://github.com/bitcoin/bips/pull/1139
19:06:10 <michaelfolkson> PSBT won't be supporting with MuSig. But to support Taproot multisig (CHECKSIGADD not MuSig) does this get included in PSBT spec?
19:06:59 <achow101> anything script based is supported by psbt
19:07:02 <sipa> PSBT doesn't need support for individual script types; that's up to individual singer implementations
19:07:20 <sipa> taproot support in general needs extensions (already proposed), and MuSig will need its own ones
19:07:27 <sipa> but scripts don't need anything
19:07:38 <sipa> *signer, not singer
19:08:04 <michaelfolkson> I guess I'm trying to unravel what is specs and what is the Core wallet. "Anything script based" but the Core wallet doesn't support Taproot scripts
19:08:29 <achow101> the psbt fields have fields for the leaft scripts
19:08:31 <sipa> as i said, that's up to the individual signer
19:08:33 <achow101> leaf scripts can be anything
19:08:46 <sipa> clearly you can't expect every signer to support every script
19:08:47 <achow101> it's up to the implementations to figure out what those scripts are doing, and what to do with them
19:08:54 <michaelfolkson> Ok I think I understand, thanks
19:09:11 <michaelfolkson> The PSBT part isn't doing much
19:09:18 <sipa> it's just an interchange format
19:09:33 <gene> do PSBT implementations need to validate scripts?
19:09:45 <sipa> and the Bitcoin Core wallet does support taproot scripts by the way, just only very limited ones (effectively just "<pubkey> OP_CHECKSIG")
19:10:11 <achow101> gene: PSBT implementation don't have to do anything with scripts. whether they should or should not depends on their role
19:10:44 <sipa> signers may want to check any number of properties of what they're signing before deciding that signing is right
19:10:48 <sipa> but what that is, is up to them
19:11:04 <sipa> PSBT just makes sure that data can be made available to them
19:11:18 <gene> achow101: so the PSBT impl can just treat scripts as opaque blobs, and then what's on the other side (e.g. a HW wallet) decides what to do with script?
19:11:51 <achow101> gene: yes, although both sides would be PSBT implementations, just different roles
19:12:00 <gene> +1
19:12:10 <sipa> it's a bit ambiguous what you call "PSBT impl"
19:12:20 <sipa> if you're just referring to the serializer/deserializer, yes, definitely
19:12:44 <sipa> but you probably mean "any software that interacts with PSBT", and they may or may not want to implement various checks, depending on their role and what things they support
19:12:45 <gene> yeah, the software/firmware that handles PSBT serialization
19:13:10 <gene> ok, that makes sense
19:13:13 <sipa> most hardware wallets don't actually handle PSBT directly - they have a software driver that converts between PSBT and the HW API calls
19:13:49 <michaelfolkson> Ok I will reread PSBT BIP with that understanding. That helps, thanks
19:13:53 <achow101> in terms of Core supporting more complicated taproot scripts, I think that will depend on miniscript (and more generally, descriptors)
19:14:24 <michaelfolkson> Right, and I read this from sipa which was very informative too https://github.com/sipa/miniscript/issues/56#issuecomment-876603384
19:15:14 <michaelfolkson> I was surprised that he thinks it is likely Miniscript gets merged into Core without supporting Taproot but I (kinda) understand the argument
19:16:03 <sipa> the goal is obviously to extend it at some point to support taproot
19:16:23 <sipa> but i don't think it's worth doing more spec work if the implementation isn't making progress
19:16:27 <michaelfolkson> To summarize the Taproot Miniscript syntax is easy to design but this will likely be supported by rust-miniscript before the C++ implementation
19:16:37 <sipa> it depends what people work on
19:17:01 <sipa> i don't know if anyone working on rust-miniscript is working on this either, but they may be in a better position to start doing so
19:17:07 <michaelfolkson> "implementation isn't making progress" <- you mean the C++ implementation of Miniscript here right?
19:17:11 <sipa> yes
19:17:43 <michaelfolkson> But there is this stepping stone between just supporting single key Taproot spends and Miniscript generic scripts
19:17:46 <meshcollider> I think we should definitely prioritise it after 22 is done
19:18:06 <michaelfolkson> Descriptor scripts could be supported without Miniscript
19:18:16 <sipa> they are
19:18:22 <sipa> they're just very minimal right now
19:18:38 <sipa> we can add support for OP_CHECKSIGADD based scripts to descriptors and signing logic for them
19:18:45 <michaelfolkson> Taproot descriptor scripts beyond just Taproot single pubkey spends I mean
19:18:47 <sipa> outside of miniscript
19:18:57 <sipa> michaelfolkson: again **they are**
19:19:00 <sipa> read the spec
19:19:21 <michaelfolkson> I'm speaking from Core wallet perspective here
19:19:31 <sipa> just only <pubkey> OP_CHECKSIG ones
19:19:40 <sipa> we're not restricted to inner key only taproot
19:19:56 <michaelfolkson> So I think my statement is correct. Have to be clearer on when taking about the Core wallet and when talking about specs
19:19:56 <sipa> you can construct 1-of-n using what is supported today, for example
19:20:10 <sipa> i'm only talking about core as well
19:21:19 <michaelfolkson> Hmm ok, that is new information to me. I thought it was just 1-of-1 for key path and multiple script paths
19:21:28 <michaelfolkson> With 1-of-1 in each leaf
19:21:40 <sipa> yes, exactly
19:21:44 <sipa> that's 1-of-n
19:21:57 <achow101> michaelfolkson: each leaf is "1-of-1", but you can have as many leaves as you want
19:22:20 <michaelfolkson> Right, I knew that
19:23:01 <michaelfolkson> But not 2-of-3 or m-of-n
19:23:07 <michaelfolkson> m>1
19:23:18 <meshcollider> No, there's no support for threshold
19:23:23 <michaelfolkson> That needs CHECKSIGADD or MuSig
19:23:35 <sipa> or FROST, or other native threshold scheme
19:23:49 <michaelfolkson> Right
19:24:43 <michaelfolkson> But we can do thresholds without Miniscript
19:24:50 <michaelfolkson> So that is probably next step
19:24:55 <michaelfolkson> (for the wallet)
19:25:26 <michaelfolkson> Doing as much as possible without needing generic scripts that would need Miniscript
19:25:52 <meshcollider> Why? Why not just focus on getting miniscript in and then go from there?
19:26:12 <achow101> I would actually prefer to add miniscript so that we don't have any incompatibilities and stop special casing things like multisig
19:26:21 <meshcollider> Exactly ^
19:27:07 <michaelfolkson> meshcollider: I'm just trying to read into sipa comments (or at least what he was thinking on that Miniscript issue)
19:27:28 <sipa> it'd be great to just integrate miniscript
19:27:28 <michaelfolkson> To add Miniscript that needs updating the C++ implementation for Taproot
19:27:40 <sipa> if people would want to work on that :)
19:28:20 <michaelfolkson> Are there difficulties ensuring the C++ implementation and the Rust implementation are equivalent?
19:28:26 <michaelfolkson> (for Miniscript)
19:28:43 <sipa> when we first wrote it, we did comparison testing
19:29:19 <sipa> if integrated into bitcoin core, it'd be also easy to e.g. produce test sets using fuzzing, which could be tested in other implementations
19:29:23 <sipa> or vice verse
19:29:32 <michaelfolkson> "I'd very much want to see it further along in integrating into Bitcoin Core" <- That sounded to me like you'd rather Miniscript was merged into Core before it supported Taproot
19:29:39 <sipa> yes
19:29:51 <sipa> but no reason why both can't happen if people work on it
19:30:17 <michaelfolkson> Do others agree with that viewpoint e.g. achow101 meshcollider? Miniscript into Core first before it is updated to support Taproot?
19:30:21 <achow101> It'd probably be easier to implement taproot into the c++ implementation once it in core
19:30:25 <gene> having a formal verification of miniscript (far future) would also allow mechanically verifying different implementations
19:30:38 <meshcollider> Like sipa said earlier, there's no point working on taproot support for it if it isn't going to get merged anyway, so better to focus on getting it merged first
19:30:53 <michaelfolkson> Cool, makes sense
19:30:59 <sipa> the miniscript c++ repository is currently somewhat in limbo; it works, but it heavily depends on code copied from bitcoin core
19:31:13 <sipa> and testing it is effectively dependent on being able to use bitcoin core's scripting engine
19:31:40 <sipa> so it's not very appealing to see them diverge further if more feature are added to miniscript, independently of bitcoin core's script code
19:32:04 <michaelfolkson> I see
19:32:41 <michaelfolkson> Ok so that should be the focus (if we want the Core wallet to support generic Taproot scripts which would be cool/ideal)
19:32:50 <michaelfolkson> *eventually support
19:33:17 <michaelfolkson> Ok that's all my questions. Thanks all
19:33:32 <meshcollider> Sweet, any other topics?
19:34:47 <meshcollider> #endmeeting