--- Day changed Thu Sep 10 2020 00:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 00:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 01:20 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 01:56 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##miniscript 02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 02:58 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 258 seconds] 05:42 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 06:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 07:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 07:29 -!- jeremyrubin [~jr@2601:645:c200:f539:bd11:45e8:9cd8:a7e6] has quit [Ping timeout: 244 seconds] 07:29 -!- jeremyrubin [~jr@2601:645:c200:f539:bd31:eec8:b7c2:d5b0] has joined ##miniscript 08:54 < andytoshi> lol where is sipa 08:55 < andytoshi> i wanna talk about https://min.sc/#time-durations 08:55 -!- martindale [ericfabric@gateway/shell/matrix.org/x-afdxptierovhrniq] has joined ##miniscript 09:00 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript 09:05 < andytoshi> hey sipa ... what do you think about the notation in https://min.sc/#time-durations 09:05 < andytoshi> do you think we should pull this into miniscript itself 09:05 < andytoshi> rather than using integers 10:05 < sanket1729> andytoshi: I like the way min.sc did it 10:06 < sipa> yeah, we've talked about that before 10:06 < sipa> not sure about miniscript itself, but certainly in policy 10:12 < andytoshi> sanket1729: cool, wanna go ahead and do this? 10:13 < andytoshi> i think we ought to do it in both policy and miniscript 10:14 < sanket1729> I agree 10:15 < sanket1729> I am also not sure about miniscript 10:15 < sanket1729> because it enforces some other rules for wallets to understand miniscript 10:15 < sipa> miniscript will become part of the descriptor language 10:15 < sipa> so if that ends up being a widely-adopted standard it may mean complication for anything that implements it 10:16 < sanket1729> yup, agreed 10:16 < sipa> i think for miniscript, whatever we do, it should be one unique encoding 10:16 < andytoshi> yeah agreed 10:17 < sipa> either just what we have now, or a compact way of doing height/time representation 10:17 < andytoshi> i'd really like if there were an explicit differentiation between height and blocks 10:18 < sipa> i think it would make sense 10:18 < sipa> especially if the miniscript type system is going to reason about those anyway 10:18 < andytoshi> i wouldn't mind if we just took the timestamp format for after(), and had seconds/minutes/hours/days suffixes for older() 10:18 < andytoshi> i don't like this "heightwise 1 week" business 10:18 < sipa> though no spaces though... descriptors are passed on the cmdline etc 10:19 < andytoshi> ok, so for timestamps we could use the iso format where T is a separator 10:19 < andytoshi> and for relative timestamps we could use s/m/h/d/w as suffixes 10:19 < andytoshi> and for blocks we'd just have no suffix 10:20 < sipa> how do we deal with the fact that relative timelocks are multiples of 512 seconds? 10:20 < andytoshi> lol i'd totally forgotten that they were 10:21 < sipa> the rule could just be that you can't have seconds precision in those 10:21 < andytoshi> yeah that seems reasonable 10:21 < sipa> and the minutes value must be one that is a rounded-down multiple of 512s 10:22 < andytoshi> hmm 10:22 < andytoshi> yeah that's probably reasonable 10:22 < sipa> i don't really have time to work on this now 10:22 < sipa> but i'd appreciate PRs :) 10:22 < andytoshi> cool :) 10:23 < sanket1729> andytoshi: Unrelated, but a psbt can have both nonwitness and witness according to specification 10:23 < andytoshi> i'm tempted to say "minutes are unrestrained" but document that the result you get is gonna be off by up to 8.5 minutes 10:23 < andytoshi> i also think we should always round up 10:23 < andytoshi> sanket1729: lol it can? 10:23 < sanket1729> Yes 10:23 < sanket1729> Infact, some wallets are using it. 10:23 < andytoshi> hmm 10:24 < sipa> yes, it had to be changed since the segwit value signing thing :( 10:24 < andytoshi> ok, then i guess your logic is right 10:24 < andytoshi> fair enough 10:24 < sanket1729> Why can both UTXO types be provided? Many wallets began requiring the full previous transaction (i.e. PSBT_IN_NON_WITNESS_UTXO) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting PSBT_IN_WITNESS_UTXO, both UTXO types must be allowed. 10:24 < sanket1729> from the BIP 10:25 < sipa> andytoshi: in miniscript i really think it should be unique 10:25 < sipa> otherwise you can have weird normalization issues 10:25 < sipa> so if it's not a rounded-down multiple of 512s, it's illegal 10:26 < andytoshi> how about specifying in weeks vs minutes 10:26 < sipa> ? 10:26 < sanket1729> Don't support low precision? 10:26 < andytoshi> sipa: 1w and 10080m would be the same thing 10:26 < andytoshi> do we have a normalization rule that requires you use 1w in this case? 10:26 < sipa> ah 10:27 < sipa> hmm 10:27 < andytoshi> i mean, it seems reasonable enough to me to do this.. 10:27 < andytoshi> if you're 0 mod 10080 you have to use w, 0 mod 60 you have to use h, etc 10:28 < andytoshi> hmm 60 minutes is a rounded-down multiple of 512 seconds 10:28 < sipa> it would be really silly to have to write 1w2m 10:29 < andytoshi> yeah i think we should only support one unit at a time 10:29 < sipa> ah, that's a nice compromise 10:29 < sanket1729> Why do you we want uniqueness in policy specification? 10:29 < sipa> this is about miniscript 10:29 < andytoshi> sanket1729: we don't really care, but it wolud be nice to have the same rules for both policy and miniscript 10:29 < andytoshi> and miniscript needs uniqueness 10:29 < sipa> i don't care about policy being well-specified 10:30 < sipa> well, doesn't need it 10:30 < sipa> i guess it already isn't really unique 10:32 < sipa> but it could be surprising if serializing and deserializing a miniscript to script changes such details 10:32 < sipa> maybe this isn't really a good reason 10:32 < sanket1729> I thought miniscript we are using script-integers. I think for miniscript, we should keep it really simple(perhaps use script number as it is? ). As sipa said, it could mean extra implementation for others to support it. 10:33 < sanket1729> We could add something to denote whether it is height based or time based 10:33 < sipa> sanket1729: yeah, though the fact that with the time/height reasoning miniscript implementations will need to reason about height vs time based stuff anyway, it's not crazy to actually put that in the language somehow 10:34 < andytoshi> ok, can we prefix timestamps with @ or something 10:34 < andytoshi> and otherwise use script integers 10:34 < sanket1729> @ is for probabilities 10:34 < andytoshi> not in miniscript :) 10:35 < andytoshi> but ok sure, we can use a different character 10:35 < sipa> maybe it could just be after(s) after(b) older(d) older(b) where b=blocks, s=seconds, d=512s 10:35 < andytoshi> yeah i'm happy with that 10:35 < sipa> happy to bikeshed the letter d 10:36 < andytoshi> eh d is fine 10:36 < sanket1729> I like that 10:36 < sipa> though having suffix s/b for absolute times is also strange 10:36 < sipa> whatever 10:37 < sipa> it's intended to be engineer-readable and exact 10:39 < andytoshi> i like it too 10:52 < sanket1729> So, it is the same for policy? We can allow non-unique and more descriptive things there. 12:15 -!- windsok [~windsok@unaffiliated/windsok] has joined ##miniscript 17:42 < darosior> sgeisler: re DescriptorKey in rust-miniscript, do you think it makes sense to have the source also for "raw" pubkeys ? 17:44 < darosior> (context: i'm polishing your branch locally and noticed that bitcoind does support it but not your implem)