--- Day changed Wed Sep 30 2020 02:18 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 03:15 < darosior> [rust-miniscript]: check_older(&self, csv_value) (Satisfier trait) cannot actually check anything on a Psbt Input. 03:15 < darosior> More generally, what about adding a nSequence field to PSBT input ? As the signer (https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#signer) needs to verify the input. 03:38 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds] 03:43 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript 05:53 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 05:57 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 06:32 < sanket1729> darosior: yup, that is ugly 06:33 < sanket1729> I think we should probably implement satisfier for (psbt, index) instead of psbt::Input 06:34 < darosior> sanket1729: don't you think the Psbt Input struct should be added the nSequence field ? 06:35 < darosior> As the BIP recommends for the signer (and the finalizer) to check the input(s) out of the PSBT input data which.. Doest not contain the sequence 06:35 < sanket1729> That is implemented according to the specification in BIP 174 06:35 < darosior> Yeah, that's why i'm talking about adding it to the BIP and wanted to know if this had been mentioned before 06:36 < sanket1729> oh, I misunderstood. 06:38 < sanket1729> I think the way probably psbt was designed was with the intend that "all parties have the entire psbt" instead of parties only having Psbt::inputs they care about. 06:39 < sanket1729> Parties do need the unsigned raw tx anyways for signing anyways 06:39 < sanket1729> So, they do have access to nSequence for all inputs. 06:43 < sanket1729> I don't think the BIP specification should change. It has all the data we need. I think we create another struct in rust-miniscript and implement satisfier on it. 06:44 < sanket1729> andytoshi: should we merge PRs look for another release? 06:47 < sanket1729> darosior: unrelated, generic finalizer( https://github.com/rust-bitcoin/rust-miniscript/pull/119 ) maybe useful. 06:49 < darosior> Ok, thanks for the input this helps me organize my code The Right Way 06:51 < sanket1729> But as you point out the current implementation of satisfier on psbt::Input is incorrect. 06:52 < sanket1729> andytoshi: Any thoughts implementing it on another struct that has psbt and index? or maybe a pair? 06:53 < sanket1729> I am awaiting on https://github.com/rust-bitcoin/rust-bitcoin/pull/478 in rust-bitcoin to implement the complete Satisfier for psbt 06:53 < sanket1729> Right now, it only has pk, pkh sigs. 06:54 < sanket1729> I need to add methods hashlocks and timelocks after #478 in rust-bitcoin is merged. 07:07 < andytoshi> darosior: doesn't the psbt have the transaction in it? 07:08 < andytoshi> oh i see, we were trying to use psbt::Input directly .. heh clever 07:08 < andytoshi> but apparently too clever 07:09 < andytoshi> looking at 478 now 07:11 < sanket1729> If the last commit requires more review. I can split into 2 PRs. One for adding hash preimages and another one for sighash 07:29 < andytoshi> lol @ slipping the vscode .gitignore commit into there 07:30 < andytoshi> yeah, can you split the sigcache thing into another PR 07:30 < andytoshi> sanket1729: ^ 07:31 < sanket1729> sure 07:34 < andytoshi> ok ack from me 18:00 < jeremyrubin> Would anyone be opposed to adding a Unsatisifiable and Satisfied type to Policy. Context: sometimes when writing generic code to generate conditions, a component want to return "no further condition required" or "we don't want to authorize ever on this path". This is, of course, emulable with a higher order wrapper around the Policy type, but it seems simpler to add the types into Policy itself. There would be some identities, e.g. 18:00 < jeremyrubin> , Or([A, Unsat]) = A, Or([A, Sat]) = Sat, And([A, Unsat]) = Unsat, And([A, Sat]) = A 18:07 < jeremyrubin> In particular, it's inconvenient if these types don't exist because it's tricky to propagate an Unsat/Sat type -- e.g., if I construct an And tree, and one branch is Unsat, I should return an Unsat. But if I was expecting to plug the result of that And tree clause into e.g., an Or, I need to always manually handle these identities rather than having them baked in to Policy 18:14 < jeremyrubin> In theory, you *could* use Sha256(0) to represent an unsatisfiable, and PK(G) to represent satisfiable BTW 18:14 < jeremyrubin> maybe PK(G) is not good given the miniscript key abstraction 18:15 < jeremyrubin> perhaps sha256(0) and sha256(H(0)) are better constants 18:16 < jeremyrubin> My point is then I guess more that it might be nice to define these as constants and add a special compilation pass that simplifies them when detected. 21:00 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Bye] 21:00 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##miniscript 22:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 23:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 23:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 23:54 -!- Netsplit *.net <-> *.split quits: Aleru, felixweis