--- Log opened Mon Mar 07 00:00:19 2022 01:39 -!- dr_orlovsky [~dr-orlovs@31.14.40.18] has quit [Ping timeout: 256 seconds] 03:35 < sanket1729> sipa: achow101: Should BIP 371 not be considered final then? 03:35 < sanket1729> context: https://github.com/bitcoin/bitcoin/pull/22558#issuecomment-1058426300 03:35 < sanket1729> andytoshi: ^ we are about to make a rust-bitcoin release with taproot psbt support 03:35 < achow101> sanket1729: it's still listed as draft 03:36 < achow101> but if people are already using it, then it should be final 03:40 < sanket1729> We are using it unreleased library code and are about to make a release for it. Should not wait till discussion there settles? 03:41 < achow101> given https://github.com/bitcoin/bitcoin/pull/22558#issuecomment-1058452156, I think it won't be changed 03:45 < darosior> https://github.com/bitcoin/bitcoin/pull/22558#issuecomment-1059262707 seems to imply Ledger are OK with the change? 03:47 < sanket1729> Thanks, it's a shame :( . I really liked separating the key -> leaf hashes map from derivation information. Not a big deal, can live with it 04:24 -!- shesek [~shesek@user/shesek] has quit [Remote host closed the connection] 05:55 < jeremyrubin> fwiw i'm getting close to having support for taproot done in Sapio, have been finding some of the PSBT taproot flows very confusing 05:58 < jeremyrubin> some of the issues that came up are: 05:58 < jeremyrubin> 1) No way of going from descriptor -> taprootspendinfo (there should just be a `pub fn spend_info(&self) -> Arc` but there is only a non-pub fn 05:59 < jeremyrubin> 2) To build it manually, you need to do iter_scripts and then use TaprootBuilder to make a TaprootSpendinfo... however, iter_scripts/TapTree::iter is not documented to go in the correct order to put it into TaprootBuilder, so it's not clear that is correct to do 06:01 < jeremyrubin> 3) There should be an API that allows one to fill out PSBT fields for a given descriptor? As of now you can iter over the map of scripts and then query the descriptor for their control blocks but there isn't an API for it 06:47 < sanket1729> jeremyrubin: 1) That will be made up in an upcoming open PR. 3) Yes, that is also in works and partially completed :) 06:47 < sanket1729> *made pub 06:48 < sanket1729> I was working on an API that looks at descriptor/infers the type of descriptor and puts in redeem_script/witness_script/taproot internal keys/control blocks 06:49 < sanket1729> But got sidetracked by conference stuff. Hopefully, I should have something today/tomorrow 06:50 < sanket1729> I encountered the same pain points when trying to use it when demoing a complex miniscript script path spend in the workshop on Friday 06:51 < sanket1729> For 3), I am still debating the API whether it should accept ranged descriptors 07:15 < jeremyrubin> Fair enough! Just things I noticed, I'm on sapio-rebased alpha releases of master so that I can knock out most of the work now, feel free to tag me on those PRs for review 07:29 < sanket1729> This is appreciated :) . Definitely a pre-release feedback is very valuable. Previously we have released APIs that we did not test/were not public, so it's great that you are testing against master 07:29 < sanket1729> Any opinions on descriptor for updating a psbt should accept range or not? 07:30 <@sipa> why wouldn't it? 07:31 < sanket1729> User can have the correct index and pass a derived descriptor? Or a separate API to match an index with a ranged descriptor for a given address? 07:32 < sanket1729> More of a rust API question, conceptually it will 07:32 <@sipa> hmm, maybe I'm confused about the API level here; this seems like something up to the caller 07:33 <@sipa> parse a ranged descriptor, then expand it for a particular value/range, and the result of that can be used/converted to update a PSBT 07:34 < sanket1729> We need some of matching code to check which index is of interest, right? 07:34 <@sipa> that's up to the caller, i'd think 07:34 <@sipa> but i don't know what kind of user your API is targetting i guess 07:34 < sanket1729> I think it is should same as bitcoin-cli RPC user 07:36 <@sipa> bitcoin-cli doesn't really have anything like that... there is a scantxoutset which takes a (ranged) descriptor and a range, expands for values in that range, and then scans the utxo set with it 07:36 < sanket1729> There is utxoupdatepsbt 07:36 < sanket1729> ? 07:36 < sanket1729> That accepts descriptors 07:36 <@sipa> ah right, perhaps 07:37 < jeremyrubin> hat is a 'ranged descriptor' exactly? 07:37 < sanket1729> wildcard 07:37 < jeremyrubin> ah 07:37 <@sipa> but internally that just works by parsing a descriptor, expanding it for each value, and then updatig with the resulting expansion 07:37 <@sipa> @jeremyrubin Key expressions which end in /* or /*' 07:38 <@sipa> so the caller gets to chose for each value to evaluate 07:38 < jeremyrubin> i think i'd prefer not to support it in psbt 07:39 < sanket1729> Why not? It seems the most useful for wallets 07:39 <@sipa> i don't understand what this has to do with PSBT really 07:39 < jeremyrubin> seems confusing because we can't actually generate the full * when satisfying 07:39 < sanket1729> I am trying to emulate the functionality `uxtoupdatepsbt` without the witness lookup from blockchain 07:39 <@sipa> the caller chooses what to do with the descriptor objects 07:40 < sanket1729> *without the witness UTXO lookup 07:40 <@sipa> after expanding at a certain index, the resulting information can be used for anything 07:40 <@sipa> including PSBT if that happens to be what you do with it 07:41 < jeremyrubin> sanket1729 under what circumstances would you fail to find a derived key in a psbt? 07:42 <@sipa> It seems you're thinking about a much higher level API than what Bitcoin Core's miniscript/descriptor code operates at. It doesn't interact with PSBT anywhere; that's up to the caller. 07:44 < sanket1729> The workflow would be as follows 1) Create psbt 2) Fill in information about prevouts from blockchain 3) Call this API to with a descriptor to feed in information about control blocks/redeem script/witness_script based on descriptor 4) Proceed to signers... 07:44 <@sipa> So I guess it is designed very differently. 07:44 < sanket1729> Step 3) is what I am trying to do 07:46 < jeremyrubin> sanket1729: makes sense. i guess the issue i'm wondering about is e.g. gap limits 07:46 <@sipa> that's all up to the caller 07:46 < sanket1729> Yup, that is an issue. We have to expect the user to provide correct values there 07:46 <@sipa> they have to know what range they care about 07:46 < sanket1729> yes 07:46 < jeremyrubin> gotcha, so we don't want to alow * then, we want a...b? 07:46 < sanket1729> Yup, It will be Range 07:46 <@sipa> sigh 07:47 <@sipa> please read the descriptors spec 07:47 <@sipa> there is no a...b in descriptors; the points to evaluate it depend on the caller, not the user 07:47 <@sipa> e.g. a wallet will typically manage it for you 07:48 < jeremyrubin> i cant tell if youre sighing at sanket1729 or at me 07:48 < sanket1729> sipa: I think we are all on the same page. This API is for wallets, so it will accept another parameter `a..b` along with a descriptor 07:49 < jeremyrubin> my understanding is that * is for _all_ unhardened children 07:49 <@sipa> @jeremyrubin at you; you're inventing spec on the fly, apparently without having a clue 07:49 <@sipa> for the last time: /* just means "wherever the caller chooses to evaluate" 07:50 < jeremyrubin> it seems you're in a bit of a sour mood over this. im really not sure why. 07:50 <@sipa> sorry, i'm tired 07:50 < jeremyrubin> it's ok 07:51 < jeremyrubin> as a consumer of said APIs "wherever i choose to evaluate" is precisely the problem sanket1729 is trying to solve, where to evaluate the range, and if that happens in PSBT logic or in what descriptors you add to said PSBT. 07:51 < sanket1729> (I think) I have all the answers that I need. So, thanks for it 07:51 < jeremyrubin> k 07:51 <@sipa> @jeremyrubin Sure, the range has to come from somewhere, but they cannot be part of the descriptor (or you'd have a descriptor that changes every time you use the wallet e.g.) 07:52 < sanket1729> jeremyrubin: Psbt::utxo_update(&self, input_idx: u32, desc: Descriptor, range: Range) 07:52 < jeremyrubin> this is why i dont think psbts can readily support ranged descriptors without a concrete derivation path, because you need to tell it what child you want in particular. 07:53 < jeremyrubin> sanket1729 yeah that makes sense to me 07:55 <@sipa> @jeremyrubin Yeah, I see. To me these are entirely independent things - you'd have a descriptor object which you .Expand(i) at a particular index, and the output of that can then be used to update a PSBT or something else. 07:56 <@sipa> So it's a bit weird for me to think about the relation between descriptors and PSBTs because they never interact directly in the Bitcoin Core codebase. But things seem different in rustland, which is ok. 07:57 < jeremyrubin> (also FWIW the term "ranged" does not seem to appear in BIP-380, if that's what * is called might make sense to define ranged for easier searchability) 07:58 <@sipa> That'd be good, indeed. 07:58 <@sipa> So it refers to descriptors that contain at least one key expression that ends in /, /', or /*h 07:59 <@sipa> Apologies for my reaction earlier. 07:59 < jeremyrubin> no worries i appreciate you 07:59 < sanket1729> a..b is called `Range` in rust-land :P 08:00 <@sipa> Right, but it's a separate thing, not part of the descriptor, or something that has a descriptor syntax. 08:01 < sanket1729> Indeed, it is a separate argument that the caller decides for all APIs 08:01 < sanket1729> Not mixed with descriptor syntax 08:01 < jeremyrubin> so I think it'd make sense to me that you might pass in e.g. a mapping of key -> Range of some kind to give each key a separate arg 08:01 -!- afilini [~afiliniaf@2001:bc8:1828:245::2] has joined ##miniscript 08:01 < afilini> not sure if this is exactly what you are talking about, but in my bdk testing branch this is how i add taproot metadata to a psbt: https://github.com/afilini/bdk/blob/taproot-testing/src/wallet/mod.rs#L1417-L1461 08:01 < jeremyrubin> maybe Either> 08:02 < afilini> `derived_descriptor` is a `Descriptor` which is guaranteed to not have any wildcards. it's essentially a `Descriptor` with extra metadata 08:02 <@sipa> @jeremyrubin The index of evaluation is for the whole descriptor; all key derivation paths change in lockstep; it's not per keym 08:02 <@sipa> *per key 08:07 < jeremyrubin> it's not clear what algorithm is done from the BIP380 fwiw, so maybe another good point of clarification 08:09 < jeremyrubin> it reads like the /* is evaluated per-key as a e.g. forall children(key_0): forall children(key_1)... 08:11 <@sipa> Ah, descriptors.md does say "Also, to prevent a combinatorial explosion of the search space, if more than one of the multi() key arguments is a BIP32 wildcard path ending in /* or *', the multi() expression only matches multisig scripts with the ith child key from each wildcard path in lockstep, rather than scripts with any combination of child keys from each wildcard path.", but I don't know what made it into the BIPs. 08:12 <@sipa> That text predates multi_a and tr(); it should be updated at least to list those too as ways multiple KEY expressions can be present. 08:14 < jeremyrubin> yeah descriptors.md is presumably core specific whereas the bip-380 permits perhaps more flexibility for implementers 08:15 <@sipa> it was mostly copied 08:20 -!- afilini [~afiliniaf@2001:bc8:1828:245::2] has quit [Quit: Bridge terminating on SIGTERM] 08:20 -!- enick_978 [~afilini-m@2001:bc8:1828:245::2] has quit [Quit: Bridge terminating on SIGTERM] 08:21 -!- enick_724 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 09:12 -!- enick_724 [~afilini-m@2001:bc8:1828:245::2] has quit [Ping timeout: 240 seconds] 09:19 -!- enick_227 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 09:21 -!- enick_227 [~afilini-m@2001:bc8:1828:245::2] has quit [Client Quit] 10:21 -!- enick_91 [~afilini-m@2001:bc8:1828:245::2] has joined ##miniscript 11:23 -!- ashishkr [uid540896@id-540896.tinside.irccloud.com] has joined ##miniscript 12:58 -!- Guest26 [~Guest26@120.57.220.127] has joined ##miniscript 13:31 -!- ashishkr [uid540896@id-540896.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity] 13:53 < jeremyrubin> uh oh: https://github.com/rust-bitcoin/rust-miniscript/blob/f621bbf1fa8c1afc05a9a3e525da72dc9f44f676/src/util.rs#L55 13:53 < jeremyrubin> if i'm reading this right, this should be 34 not 32 13:56 -!- Guest2610 [~Guest26@120.57.220.127] has joined ##miniscript 13:59 -!- Guest26 [~Guest26@120.57.220.127] has quit [Ping timeout: 256 seconds] 14:03 -!- Guest2610 [~Guest26@120.57.220.127] has quit [Quit: Client closed] 14:27 < sanket1729> jeremyrubin: Indeed, that should be 32. I will be using rust-bitcoin script.is_v1_p2tr() instead 14:38 < jeremyrubin> actually yeah it's still broken doubly 14:38 < jeremyrubin> lemme update 14:38 < jeremyrubin> it also is wrong because Instructions yields a PushByte not a Op 14:54 < jeremyrubin> sanket1729: cool, now my errors are "up to the point" that it's where i need to review https://github.com/rust-bitcoin/rust-miniscript/pull/301 :D 14:55 < jeremyrubin> am able to get through finalization otherwise 14:57 < sanket1729> Nice. I got caught up with something else today. Hopefully, will the PR for more psbt APIs ready for review tomorrow. Then some integration tests, and we are good for release/rc 15:02 -!- shesek [~shesek@user/shesek] has joined ##miniscript 15:02 < jeremyrubin> awesome 15:02 < jeremyrubin> it might make sense to switch to 0.28 pre release before releasing 0.28 or rust-miniscript 15:03 < jeremyrubin> make sure that there's no breaking changes you'd want on either end (not sure what plans look like on that) 15:04 < jeremyrubin> ah 15:04 < jeremyrubin> i just started reviewing 301... the 2nd commit is that 17:58 < jeremyrubin> after fixing the bug i noted, my merge has sucessfully worked! 17:59 < jeremyrubin> or at least my integration tests for my taproot based CTV emulation server 22:27 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has quit [Remote host closed the connection] 22:27 -!- elsirion [~quassel@gateway/tor-sasl/elsirion] has joined ##miniscript --- Log closed Tue Mar 08 00:00:19 2022