--- Log opened Mon Feb 07 00:00:52 2022
00:59 < darosior> Hmmm so i rushed into making after() support up to 2**32, but now i'm sure we already discussed this. I'm seeing some of my code comments in rust-miniscript regarding the 4-bytes vs 5-bytes limit. Maybe there was a reason for not making a B fragment consume up to 5 bytes. sanket1729 do you remember?
01:01 < darosior> Found the PR introducing the comment https://github.com/rust-bitcoin/rust-miniscript/pull/246
01:02 < darosior> And the mentioned IRC discussion is https://gnusha.org/miniscript/2021-06-16.log . So we just overlooked that the CLTV logic special-cased to 5 bytes.
01:11 < darosior> Also, i don't think we need to make the change before the integration into Bitcoin Core. It'd only make something possible that was invalid before
01:13 < sanket1729> yes
01:13 < sanket1729> darosior: AND_B (AFAIR) does not operate on more than 4 bytes
01:14 < sanket1729> any of the arith operators
01:18 < darosior> Oh, right they all use a CScriptNum() with the default 4-bytes maximum push... Then the carve-out to 5 bytes for CLTV isn't super useful :/
01:20 < darosior> Hmm i think a `CLTV VERIFY TRUE` would work
01:23 < darosior> Or just `CLTV DROP TRUE`, for that matter.
01:25 < sanket1729> Are you suggesting a change to after() fragment?
01:27 < sanket1729> Yes it would work and would solve "2038 problem". But that would also make it inefficient. 
01:27 < darosior> I'm not proposing a change, i'm speculating
01:30 < sanket1729> We are always open to the possibility of "extending" miniscript to allow new fragments. Maybe we can add after_t(<upto 5 byte>) at some point later. 
01:34 < sanket1729> Should miniscript descriptors have some sort of versioning? Or is that implicit under the the descriptor/fragment name. I image us having checksigfromstack() style things in future.
01:39 < darosior> I guess you have to support fragments in a given context "forever", so you don't need versioning: it'd only be possible to extend the language.
04:50 <@sipa> My thinking on compatibility is: if a fragment is supported, its meaning should match other implementations.
04:50 <@sipa> But implementations may choose to not support some.
11:30 -!- darosior5 [~darosior@194.36.189.246] has joined ##miniscript
11:37 -!- Netsplit *.net <-> *.split quits: sanket1729, darosior
11:37 -!- darosior5 is now known as darosior
11:42 -!- Netsplit over, joins: sanket1729
11:46 -!- sipa [~sipa@user/sipa] has quit [Ping timeout: 250 seconds]
11:46 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Ping timeout: 250 seconds]
11:46 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Ping timeout: 256 seconds]
11:46 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has quit [Ping timeout: 250 seconds]
12:06 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
12:18 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
12:18 -!- sipa [~sipa@user/sipa] has joined ##miniscript
12:18 -!- mode/##miniscript [+o sipa] by ChanServ
13:16 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined ##miniscript
13:35 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has quit [Write error: Connection reset by peer]
13:35 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Read error: Connection reset by peer]
13:35 -!- sipa [~sipa@user/sipa] has quit [Write error: Connection reset by peer]
13:35 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Write error: Connection reset by peer]
13:37 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined ##miniscript
13:52 -!- sipa [~sipa@user/sipa] has joined ##miniscript
13:52 -!- mode/##miniscript [+o sipa] by ChanServ
13:52 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined ##miniscript
13:52 -!- ademan[m] [~ademanmat@2001:470:69fc:105::1:16db] has joined ##miniscript
16:25 <@sipa> darosior: I've found a big simplification for the signing algorithm, and I'm playing with it my random_fuzz branch. Unfortunately, it doesn't quite work yet, and I won't have time to look into more until next week.
16:29 <@sipa> Roughly the idea is to only have one signing algorithm, which always tries to produce non-malleable solutions. If a non-malleable solution exists, and the script is sane, that solution should satisfy all requirement.
16:30 <@sipa> If the script is nonmalleable on top, such a nonmalleable solution should always exist (if the necessary keys/hashes/locktimes are present).
--- Log closed Tue Feb 08 00:00:53 2022