--- Day changed Mon Jul 13 2020 01:15 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##miniscript 01:35 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:95bd:7701:97ff:1c7] has joined ##miniscript 01:46 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:95bd:7701:97ff:1c7] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 01:50 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:95bd:7701:97ff:1c7] has joined ##miniscript 02:02 -!- dr_orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 02:06 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:95bd:7701:97ff:1c7] has quit [Ping timeout: 256 seconds] 02:18 -!- dr_orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Read error: Connection reset by peer] 02:20 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 02:22 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Client Quit] 02:37 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 04:01 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 265 seconds] 04:22 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 04:43 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 05:19 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:50 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 06:27 -!- Netsplit *.net <-> *.split quits: meshcollider 06:28 -!- Netsplit over, joins: meshcollider 07:00 -!- Davterra [~tralfaz@104.200.129.62] has joined ##miniscript 07:01 -!- Davterra [~tralfaz@104.200.129.62] has left ##miniscript [] 07:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 07:22 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##miniscript 07:39 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 258 seconds] 07:40 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##miniscript 10:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 10:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 10:14 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##miniscript 10:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 10:37 -!- darosior [~darosior@194.36.189.246] has joined ##miniscript 12:25 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 12:52 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 13:20 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##miniscript 13:39 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has joined ##miniscript 14:00 -!- dr-orlovsky [~dr-orlovs@2001:171b:c9ab:8170:4965:f2af:eef9:3dbb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 14:10 < shesek> are `and(A, and(B, and(C, D)))` and `or(A, or(B, or(C, D)))` always equivalent to `thresh(4, A, B, C, D)` and `thresh(1, A, B, C, D)`? (apart from not being able to assign probabilities with thresh()) 14:11 < sipa> yes 14:11 < sipa> my compiler will try a sequence of ands/ors if you give it a threshold with k=1 or k=n, iirc 14:12 < shesek> nice, thanks 14:13 < sipa> (or maybe i just thought about it but never implemented it...) 14:13 < shesek> haha, I see :) 14:14 < shesek> I did a few tests and it seemed to produce the same result, but it was far from extensive 14:14 < sipa> just checked; it does 14:15 < shesek> my infix boolean syntax supports more than two arguments by compiling down to thresh() (`pk(A) || pk(B) || pk(C)` -> `thresh(1, ...)` or with && to `thresh(N, ...)), I was wondering if I should use nested and()s/or()s instead 14:16 < shesek> if there's no difference, I think thresh() is probably more readable 14:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 14:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##miniscript 16:03 < shesek> it seems like sha256() results in `OP_SIZE <20>` 16:04 < sipa> yes, preimage is assumed to be 32 bytes 16:06 < shesek> oh, right, this is in hex... 16:06 < shesek> but how come ripemd160() also results in 0x20? 16:06 < sipa> because it also assumes a preimage of 32 bytes :) 16:09 < shesek> ah ugh, I utterly missed what's that supposed to do, I thought it was checking the size of the hash and not of the preimage, which of course makes no sense. I now remember reading somewhere that this is somehow related to cross-chain compatibility, right? 16:10 < sipa> indeed 16:10 < sipa> otherwise you could construct an atomic swap with say a 1000 byte preimage, which might work on one side but not the other 16:12 < shesek> thanks for the explanation, makes sense 16:12 < shesek> why an exact size rather than an upper limit? 16:12 < sipa> why not? 16:13 < sipa> if you're going to waste bytes on checking the size, no reason to permit anything but the intended size 16:13 < shesek> just because there's no real need for varying sizes, or maybe because more efficient that way? 16:13 < sipa> s/waste/spend/ 16:14 < shesek> right, definitely makes sense if setting a ceiling costs more weight units 16:15 < sipa> no, it wouldn't 16:15 < sipa> my point is that being more precise is desirable 16:19 < shesek> that argument makes sense too (I misunderstood your previous statement about wasting/spending bytes, I now see what you meant there) 16:22 < shesek> is there any benefit to using a preimage bigger than the digest? wouldn't the security be limited by the size of the digest regardless? 16:23 < sipa> yes, i think so 16:24 < shesek> that there is a benefit or that there isn't? 16:24 < sipa> i don't think there is an addition security benefit 16:25 < shesek> btw, the notation under "Miniscript reference" -> "Translation table" uses integers for sizes rather than hex like the compiler (`SIZE <32>`), which is somewhat confusing 16:25 < shesek> so why not have hash160/ripemd160 use 20 bytes preimages? 16:25 < sipa> i'm not aware of anything using anything other than 32 byte preimages 16:25 < sipa> but i think our plan was to make it configurable at some point 16:26 < sipa> so you'd have sha256(hash,17) or so if you want a 17-byte preimage 16:31 < shesek> I sent a PR for the hex notation: https://github.com/sipa/miniscript/pull/38 16:32 < sipa> maybe we should fix the compiler output instead 16:32 < shesek> prefixing hex values with 0x can also help make things clearer, but this is something that would have to be done in the compiler 16:32 < sanket1729> change to 0x20 instead of 20? 16:32 < sipa> bitcoin core's script disassembler is ugly, it uses decimal for small numbers, but anything else as hex bytearrays 16:33 < sipa> maybe we should use <..> for numbers, and <0x...> for hex stuff? 16:34 < sipa> and do the same in bitcoin core 16:34 < shesek> I think this makes sense 16:38 < sipa> actually, it does 16:38 < shesek> there's some danger of people accidentally copy-pasting the integer values and treating them as hex values, so maybe better to use a notation that's harder to mix up? 16:38 < sipa> maybe i just misremember 16:38 < sipa> OP_n is formatted as just n 16:38 < sipa> but pushes are formatted as 0x... 16:40 < sipa> oh, no, it's even uglier 16:40 < sipa> it outputs the push opcode itself in hex too 20:16 -!- shesek [~shesek@5.22.128.126] has quit [Read error: Connection reset by peer] 20:16 -!- shesek [~shesek@5.22.128.126] has joined ##miniscript 21:31 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 21:31 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined ##miniscript 22:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]