--- Log opened Tue Aug 25 00:00:59 2020
00:08 -!- jonatack [~jon@37.166.120.102] has quit [Ping timeout: 240 seconds]
00:12 -!- jonatack [~jon@37.166.120.102] has joined ##taproot-bip-review
00:16 -!- jonatack [~jon@37.166.120.102] has quit [Ping timeout: 246 seconds]
00:20 -!- jonatack [~jon@37.166.201.6] has joined ##taproot-bip-review
00:22 -!- jonatack [~jon@37.166.201.6] has quit [Read error: Connection reset by peer]
00:23 -!- jonatack [~jon@37.166.201.6] has joined ##taproot-bip-review
00:23 -!- jonatack [~jon@37.166.201.6] has quit [Client Quit]
00:23 -!- jonatack [~jon@37.166.120.102] has joined ##taproot-bip-review
00:28 -!- jonatack [~jon@37.166.120.102] has quit [Ping timeout: 256 seconds]
01:09 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
01:10 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review
01:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
01:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review
03:05 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review
03:16 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-zcrgwbzzktutshgw] has quit [Ping timeout: 260 seconds]
03:17 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-zagxgkeksxnjlhza] has joined ##taproot-bip-review
03:33 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
03:39 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-bip-review
03:50 -!- felixweis [sid154231@gateway/web/irccloud.com/x-tjakxxqoraoowpeh] has quit [Ping timeout: 244 seconds]
03:50 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-tvwaejwbstchkagt] has quit [Ping timeout: 260 seconds]
04:00 -!- felixweis [sid154231@gateway/web/irccloud.com/x-jlmbxhhtbxlzhkla] has joined ##taproot-bip-review
04:00 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ktcafifpocehctxo] has joined ##taproot-bip-review
05:31 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:32 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-bip-review
06:09 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-bip-review
06:12 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
10:30 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review
10:33 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
11:26 -!- roconnor [~roconnor@host-45-58-217-138.dyn.295.ca] has joined ##taproot-bip-review
11:27 < roconnor> In taproot do I understand correctly? that the sighash modes of 0x00 and 0x01 are identical (beyond the fact that the sign the specific sighash flag)
11:44 < luke-jr> roconnor: 00 is omitted in the signature too
11:45 < luke-jr> which I'm thinking is a design flaw we should undo
11:45 < luke-jr> aj (IIRC) argued that it reduces weight due to reduced complexity to verify, but I'm not sure it does :/
11:46 < roconnor> luke-jr: That doesn't sound right.  The hash_type is always included as the first byte in SigMsg even if it is 0x00.
11:47 < roconnor> Oh right you mean in the signature itself. yes it is ommitted there.
11:47 < roconnor> and if you use hash_type 0x01 then it is included.
12:59 -!- reallll is now known as belcher
13:28 < roconnor> What would be the hypothetical path to adding SigHashNoInput to segwit v1?  It would involve a new pubkey key type?
13:50 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
19:39 < jeremyrubin> roconnor: unclear do you want it to work with bare keys?
22:05 < aj> roconnor: the path proposed in PR 943 is taking over an unknown pubkey type, yeah. (an alternative approach would be taking over witness version 16, in which case it could work via the key path as well, but that seems unnecessary/premature to me)
22:07 < aj> roconnor: practically, i think we're just about at the point where taproot is usable on signet (see my signet-tr branch on github), so once that works, i'd like to have signet support anyprevout as well, at which point we should be able to test out eltoo and do non-theoretical attacks against anyprevout to see if it all makes sense
22:07 < jeremyrubin> aj: can I PR CTV on signet too?
22:08 < aj> luke-jr: not today, but that's the goal, yeah
22:08 < aj> luke-jr?
22:08 < aj> jeremyrubin: not today, but that's the goal, yeah
22:09 < aj> jeremyrubin: (and you can certainly setup your own signet fork with CTV enabled today, of course)
22:09 < jeremyrubin> yeah may do this... could be fun to set up an amazon signet AMI so you can click-deploy a new network
22:10 < jeremyrubin> if I'm feeling like it maybe I'll put it together
22:11 < luke-jr> aj: ?
22:11 < aj> luke-jr: misdirected
22:12 < luke-jr> aj: did I remember correctly, that you had argued omitting hash_type was justified by a reduction in CPU time?
22:13 < aj> luke-jr: was going to say: if you've got many inputs to a tx spending via SIGHASH_ALL means fewer hash recalculations than the other options, so justifies saving a byte. being able to spend an extra byte with the explicit sighash_all mode i don't have a real justification for
22:14 < luke-jr> well, can always pad junk data other ways too, so no point stopping that
22:14 < luke-jr> if you have all SIGHASH_SINGLE (for example), though, isn't the sum hashing identical to SIGHASH_ALL for all of them?
22:15 < luke-jr> (ignoring that the current code precalculates SIGHASH_ALL unnecessarily in this case)
22:19 < aj> luke-jr: if you're doing SINGLE, you have to generate sha_single_output for each input as an additional hashing op compared to doing SIGHASH_ALL
22:19 < luke-jr> aj: but that's *instead* of hashing *all* the inputs for SIGHASH_ALL
22:19 < luke-jr> so you have 1+1+1+1 rounds instead of 4 rounds in a single hash
22:20 < aj> luke-jr: right, for 10 ALL vs 10 SINGLE; for 10 ALL vs (1 ALL plus 9 SINGLE) you get the saving
22:21 < luke-jr> for 1 ALL + 9 SINGLE, the additional cost is in the ALL, not the SINGLEs :P
--- Log closed Wed Aug 26 00:01:00 2020