--- Log opened Sun Feb 06 00:00:51 2022
08:49 < darosior> Alright i'm going to push without the bugfix.
08:49 <@sipa> I'm close!
08:50 <@sipa> So!
08:52 <@sipa> With this change to make the malleable satisfier prefer canonical solutions, I can drop !IsMalleable() from IsSane().
08:52 <@sipa> And the fuzzer keeps working.
08:53 <@sipa> That means that with that change (if the code is right), the logic for signing (even malleably) exactly matches what the BKVWzondu type system rules say.
08:54 <@sipa> Let me push what I have.
08:57 < darosior> Cool, i'll have a look
08:58 <@sipa> https://github.com/sipa/bitcoin/commits/random_fuzz
08:58 < darosior> Btw why do we refuse timelocks >2**31 also for after()?
08:59 <@sipa> Requires a 5-byte push.
09:00 <@sipa> Oh, I think CLTV/CSV may have an exception for that.
09:01 < darosior> Well for CSV there is the disable flag at 2**31 anyways
09:03 <@sipa> Hmm, should we update the language for this?
09:04 <@sipa> I hit another ops counting issue, it seems. Investigating.
09:05 < darosior> I think it'd make sense to allow CLTVs up to 2**32 if there is the exception you mentioned. What's with 5-bytes pushes? I've seen it mentioned a couple times but i'm not sure
09:06 <@sipa> Arithmetic operations only accept operands up to 4 bytes.
09:06 <@sipa> But the signed encoding bitcoin script uses for numbers means values over 2**31-1 need 5 bytes.
09:08 <@sipa> But both OP_CSV and OP_CLTV accept arguments up to 5 bytes.
09:08 < darosior> Ooh right you had already told me :) Thanks.
09:08 <@sipa> So indeed I think we can change after() to go up to 2^32
12:18 <@sipa> Ok, I was wrong. We cannot just drop the non-malleability requirement from IsSane().
--- Log closed Mon Feb 07 00:00:52 2022