--- Day changed Wed Jul 29 2020
01:31 -!- jeremyrubin [~jr@2601:645:c200:f539:149c:f818:6125:256e] has quit [Ping timeout: 244 seconds]     
03:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 244 seconds]     
04:25 -!- jonatack [~jon@194.187.251.115] has joined ##miniscript     
05:18 -!- jonatack [~jon@194.187.251.115] has quit [Ping timeout: 246 seconds]     
06:12 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
06:38 -!- shesek [~shesek@164.90.217.137] has joined ##miniscript     
06:38 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]     
06:38 -!- shesek [~shesek@unaffiliated/shesek] has joined ##miniscript     
07:28 < roconnor> Setting aside the issue of timelocks for the moment, my plan for decideing policy entailment of the form P |- Q was to either (1)
07:30 < roconnor> put P into DNF when P is a small policy (i.e. when P is the authorization constraint), and for each term in P test of Q hold when every clause in the term of P holds but everything else not in P fails.
07:30 < roconnor> or (2) put Q in CNF and do "the opposite".
07:32 < roconnor> which should be for teach term in Q, set each clause in that term to false, and otherwise set every clause to true, and then check to see if P fails under those conditions.
07:33 < roconnor> But I haven't got the point yet to convince myself that this reasoning via (2) is sounds.  The double negatives were making my head spin.
09:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript     
09:47 -!- jeremyrubin [~jr@2601:645:c200:f539:149c:f818:6125:256e] has joined ##miniscript     
12:00 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript     
12:05 < andytoshi> ok looking at 70
12:07 < andytoshi> sanket1729: in my experience dr-orlovsky's PRs can take a while to shepherd (in particular if weird git stuff is required)
12:07 < andytoshi> do you want me to prioritize this? i can review when it's 12 jumbled commits, i just don't want to :)
12:22 < andytoshi> sanket1729: actually this PR's history is a mess, i really do need dr-orlovsky to fix it befoer merging
12:22 < sanket1729> Yeah, it needs a rebase for sure
12:23 < sanket1729> and squashing too
12:23 < andytoshi> sanket1729: so, the issue is that commit f2a979a has two parents but it isn't labelled as a merge commit
12:25 < sanket1729> Actually, it's not a blocker for me. I thought that iterators would be a clean way to get all timelocks/hashlcks/pks from polices. But I realize that this is iterators for miniscript, and what I would have required is one for policy. 
12:25 < andytoshi> ah ok
12:26 < sanket1729> I plan to review #116 next, reading a bit on bip32. 
12:26 < sanket1729> Realted to psbt: How does one store hash preimages in it?
12:27 < sanket1729> 116 is the one adding descriptor keys by sgeisler and afilini. 
12:27 < andytoshi> sanket1729: heh, oops, achow101 and i agreed to add hash preimages to PSBT but i don't think either of us actually did it
12:27 < andytoshi> IIRC i said that I'd write a PR to update the bips repo (which would then have to go through review from the bitcoin community)
12:28 < andytoshi> and then i never did this
12:28 < achow101> andytoshi: IIRC you were supposed to do that
12:28 < andytoshi> yeah, sorry, my bad
12:28 < achow101> that is very on brand for you
12:29 < andytoshi> i bought a new sticky pad, whenever i agree to do shit i put a note on my monitor now
12:29 < andytoshi> so i'll follow through on shit until this pad runs out
12:30 < andytoshi> achow101: so what do i do? is the process actually "make a PR to the bips repo"?
12:30 < andytoshi> or do i need to make more noise on the ML or something
12:30 < achow101> was there any discussion on the ML about this?
12:31 < andytoshi> there was, i wrote up a list of things i wanted and you said "yeah sounds good"
12:31 < achow101> i guess just make a PR then
12:31 < andytoshi> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016720.html
12:31 < achow101> it's probably not controversial
12:32 < andytoshi> yeah, and in any case i have a ML post i can link so if people want to complain they know where to do it
12:32 < achow101> we have lots of spare type bytes anyways
12:34 < andytoshi> ok that post actually has some other shit like p2c tweaks that would probably be controversial (are hard to implement, only help liquid)
12:34 < andytoshi> but I'll PR to add hash preimages and height/depth of txouts
12:35 < andytoshi> which is all we need for miniscirpt
12:36 < sipa> height/depth?
12:36 < sipa> i'm not sure that's meaningful as it's not signed data
12:36 < achow101> for the txout depth, any concern if a malicious actor lies about it?
12:37 < sipa> but it does affect which spending path is used, hmm
12:37 < andytoshi> sipa: the point is to help the finalizer
12:37 < andytoshi> yeah
12:37 < sipa> that's kind of annoying
12:37 < sipa> but then you need to consider what if someone lies about it
12:37 < andytoshi> hmmm
12:37 < sipa> it won't affect the validity of the spending transaction
12:38 < sipa> only when it becomes minable
12:38 < andytoshi> well, if the finalizer tries to satisfy a CSV branch that isn't actually satisfiable
12:38 < andytoshi> ah yeah i see your paint
12:38 < andytoshi> point
12:39 < sipa> it could be advisory like the hashtype flag
12:39 < sipa> in psbt
12:39 < sipa> actually
12:39 < sipa> i don't think this applies to psbt at all
12:39 < andytoshi> should we be on a more bitcoin-general channel?
12:39 < andytoshi> heh ok
12:39 < andytoshi> if you can convince me we don't need it that simplifies thing-
12:40 < sipa> because the locktime and nsequence are already decided by the time you get the psbt to a signer
12:41 < sipa> and that determines which signing branch to use
12:41 < sipa> not what the relation with the real world is
12:41 < sipa> it may apply to the "pre psbt" discussion, about having a format to negotiate what the to-be-signed transaction is going to be
12:43 < andytoshi> ahh right ofck
12:43 < andytoshi> yeah sure
12:43 < andytoshi> ok so actually we only need hash preimages in PSBT to have full miniscript support? lol shit i should've done this PR 2 years ago
12:58 < sanket1729> andytoshi: I am looking at the mailing list proposal and you only mention SHA2 hashes, whereas we in minicsript we have four types of hashes
13:00 < sanket1729> Maybe, we should 4 fields for doing this, or one field with some encoding for the types. But I think we should probably support all 4 types of hashlocks 
13:00 < andytoshi> agreed
13:01 < sipa> or drop support for some of them in miniscript :p
13:01 < sanket1729> not a bad idea :) 
13:02 < sanket1729> There is good reason to use hash160 vs sha2 for fees. 
13:02 < andytoshi> what choice is least likely to invite bikeshedding?
13:03 < andytoshi> i think we should just support them all, it's quick and easy, both hashes need to be supported by implementors anyway for pkh reasons
13:03 < andytoshi> it's extra typing but mostly copy-and-paste :P
13:04 < sanket1729> Yeah, we should have all of them. Given that we have already implemented it :P . 
13:58 < andytoshi> do we restrict to 32-byte preimages? do we length-prefix them?
13:58 < andytoshi> sounds a bit silly to hav ea 32-byte preimage for a 20-byte hash
13:58 < andytoshi> though i guess this is what we've implemented
13:59 < andytoshi> also is the PSBT invalid if the preimage doesn't match the hash? i guess it shuold be, though that's extra verification burden on the psbt parser
14:01 < andytoshi> part of me feels that length enforcement is not PSBT's job
14:03 < sipa> andytoshi: i think the PSBT side shouldn't need a length restriction
14:03 < sipa> it's giving the preimage, so obviously its length is known
14:05 < andytoshi> yeah agreed
14:05 < achow101> the preimage should match the hash
14:05 < sanket1729> Is the pbst invalid if the sigs are invalid w.r.t to pubkey. If so, psbt should be invalid if the preimage does not has correctly. 
14:05 < andytoshi> sanket1729: (a) good question; (b) checking a hash is waaay cheaper than checking a signature
14:05 < andytoshi> fwiw
14:06 < andytoshi> and programattically was simpler as you don't need to compute a sighash
14:06 < sipa> sanket1729: the security requirement is that if you're given a malicious PSBT, you won't end up signing something you don't want to
14:07 < sipa> but as long as the worst case is that the resulting transaction is just invalid, that's not been a consideration so far
14:07 < sipa> it could be detected, or not
14:07 < achow101> signatures require understanding script
14:07 < andytoshi> sipa: agreed in principle
14:07 < achow101> hashes are just hashes, so it's easy to check
14:07 < andytoshi> but otoh it's a super cheap check to just see if the hashes match
14:08 < andytoshi> and reject a psbt if not
14:10 < andytoshi> interestingly, the BIP is silent about what to do about say, invalid public keys
14:11 < andytoshi> but rust-bitcoin will reject these in practice. i expect that Core will not, in practice
14:11 < andytoshi> because Core has a preference for avoiding parsing public keys if it can avoid the computation
14:12 < achow101> I think Core only checks the first byte and then the length
14:12 < sipa> indeed
14:13 < sipa> IsFullyValid does the is-on-curve check, but that's not done at parsing time
14:22 < andytoshi> ok https://github.com/bitcoin/bips/pull/955 
14:22 < andytoshi> it has nothing about validating fields. and also no test vectors, which i assume i'm going to be asked to add
14:26 < sanket1729> idk if this is required for standard hash constructions or not. But is it worth specifying the endianess? 
14:28 < andytoshi> lol i refuse on principle
14:28 < andytoshi> "endianness" is not the correct term btw
14:28 < andytoshi> you may mean, "should i specify whether the hash should be reversed bytewise", and i think it's reasonable to expect people to infer "no"
14:28 < sanket1729> I know there are wierd things in bitcoin about hash256 seralization
14:29 < andytoshi> yes, in RPC and other user-facing display, many hashes are reversed
14:29 < andytoshi> i don't think we should add any more intsances of this
14:29 < sipa> bytes are never reversed, anywhere
14:29 < andytoshi> ah, that's true, only hex encoding
14:29 < sipa> they're printed in little-endian in some human representation
15:36 < sanket1729> andytoshi: One question I had about the scope of rust-miniscript library. Right now, we only have Satisfier trait which does not care how one gets the witnesses for the miniscript. Does it make sense to accept privatekeys at an API level and fill in the witness? Or should that be something the user should do on it's own. 
16:39 < jeremyrubin> sanket1729: is there any safety benefit to including it inside of miniscript?
16:39 < jeremyrubin> Otherwise I think it sounds like you want signing logic to be a very separate module/library 
22:50 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]     
23:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript