--- Day changed Wed Nov 27 2019 00:04 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds] 00:06 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 00:35 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 00:36 -!- kabaum [~kabaum@185.224.57.161] has quit [Ping timeout: 265 seconds] 00:42 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 00:51 -!- b10c [~Thunderbi@mue-88-130-54-006.dsl.tropolys.de] has joined ##taproot-bip-review 00:51 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Ping timeout: 265 seconds] 00:52 -!- davterra [~dulyNoded@91.132.136.84] has quit [Remote host closed the connection] 00:52 -!- davterra [~dulyNoded@91.132.136.84] has joined ##taproot-bip-review 00:52 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 00:55 -!- jonatack [~jon@37.172.19.142] has joined ##taproot-bip-review 01:07 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 01:16 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 01:24 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 01:26 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 01:27 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-jxjnizqxjvmgltht] has quit [Remote host closed the connection] 01:38 -!- kabaum [~kabaum@93.182.128.34] has joined ##taproot-bip-review 02:17 -!- evoskuil[m] [evoskuilma@gateway/shell/matrix.org/x-xkanmtzketqxuqsk] has joined ##taproot-bip-review 02:38 -!- dr_orlovsky [~dr-orlovs@2a02:1205:500f:2e90:945d:41d:a690:8c28] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:42 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 02:45 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 03:09 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Ping timeout: 276 seconds] 03:11 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 03:40 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 03:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 03:55 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-bip-review 03:58 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has joined ##taproot-bip-review 04:36 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 05:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-bip-review 05:08 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 05:16 -!- arik_ [~arik@c-73-162-137-55.hsd1.ca.comcast.net] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 05:43 -!- jonatack [~jon@37.172.19.142] has joined ##taproot-bip-review 05:57 -!- rottensox__ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 05:59 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 276 seconds] 06:02 < instagibbs_> fun fact from roconnor: even with gigameg blocks codeseparator_position still cannot overflow because of the MAX_SIZE constant for serialization 06:02 -!- rottensox__ [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 268 seconds] 06:05 < gmaxwell> assuming that you haven't increased MAX_SIZE 06:06 < instagibbs_> yeah it's 2 implicit bounds... 06:06 < gmaxwell> or bypassed it for compact_size. 06:06 < instagibbs_> related email https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017056.html 06:06 < instagibbs_> (missed this email thread first time) 06:25 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-bip-review 06:25 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 06:25 -!- jonatack [~jon@37.172.19.142] has joined ##taproot-bip-review 06:27 -!- jonatack [~jon@37.172.19.142] has quit [Read error: Connection reset by peer] 07:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection] 07:15 -!- jonatack [~jon@37.170.114.135] has joined ##taproot-bip-review 07:46 -!- kabaum [~kabaum@93.182.128.34] has quit [Ping timeout: 240 seconds] 08:14 -!- andytoshi [~apoelstra@wpsoftware.net] has joined ##taproot-bip-review 08:14 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 08:14 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 08:40 -!- pyskell [~pyskell@194.36.111.51] has joined ##taproot-bip-review 08:40 -!- pyskell [~pyskell@194.36.111.51] has quit [Changing host] 08:40 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review 08:41 -!- pyskell [~pyskell@unaffiliated/pyskell] has quit [Client Quit] 08:41 -!- pyskell [~pyskell@unaffiliated/pyskell] has joined ##taproot-bip-review 09:01 < andytoshi> i kinda wish the taproot bip would have a newline after every sentence so that github could render the diffs properly 09:06 < gmaxwell> I wish github's diffs were as good as mediawiki's. 09:07 < sipa> git diff --word-diff 09:08 < andytoshi> yes, you can pull locally and use real tools 09:08 < andytoshi> but that is roughly 50 times as much work as clicking "diff" on github 09:09 < sipa> yeah 09:09 < sipa> i also only do it for reviewing bigger things 09:09 < andytoshi> for code you generally have to pull anyway to compile-test, run valgrind, etc 09:22 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 09:29 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has joined ##taproot-bip-review 09:31 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 09:33 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 240 seconds] 09:37 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 265 seconds] 09:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 09:43 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 268 seconds] 09:43 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 09:43 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 09:43 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 09:55 -!- instagibbs_ [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds] 09:56 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##taproot-bip-review 10:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds] 10:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-bip-review 10:08 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 10:22 -!- meshcollider [meshcollid@quantumznc.com] has quit [Ping timeout: 250 seconds] 10:22 -!- meshcollider [meshcollid@quantumznc.com] has joined ##taproot-bip-review 10:23 -!- ariard_ [~ariard@167.99.46.220] has quit [Ping timeout: 250 seconds] 10:24 -!- ariard [~ariard@167.99.46.220] has joined ##taproot-bip-review 10:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 276 seconds] 10:47 -!- vernon99995 [5a6e262d@lfbn-1-6077-45.w90-110.abo.wanadoo.fr] has joined ##taproot-bip-review 11:13 -!- potatoe_face [~potatoe_f@157.230.27.253] has joined ##taproot-bip-review 11:16 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 252 seconds] 11:30 -!- arik_ [~arik@cpe-108-184-175-69.socal.res.rr.com] has joined ##taproot-bip-review 11:37 -!- arik_ [~arik@cpe-108-184-175-69.socal.res.rr.com] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 11:54 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 12:00 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has quit [Quit: Sleep mode] 12:03 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has joined ##taproot-bip-review 12:04 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:5c04:89ce:9939:6587] has quit [Client Quit] 12:10 -!- jonatack [~jon@37.170.114.135] has quit [Read error: Connection reset by peer] 12:23 -!- michaelfolkson [~textual@host86-146-216-209.range86-146.btcentralplus.com] has joined ##taproot-bip-review 12:25 -!- kabaum [~kabaum@84.216.156.34] has joined ##taproot-bip-review 12:33 -!- kabaum [~kabaum@84.216.156.34] has quit [Remote host closed the connection] 12:34 -!- michaelfolkson [~textual@host86-146-216-209.range86-146.btcentralplus.com] has quit [Quit: Sleep mode] 12:35 -!- kabaum [~kabaum@84.216.156.34] has joined ##taproot-bip-review 12:38 -!- vernon99995 [5a6e262d@lfbn-1-6077-45.w90-110.abo.wanadoo.fr] has quit [Remote host closed the connection] 12:42 -!- kabaum [~kabaum@84.216.156.34] has quit [Read error: Connection reset by peer] 13:46 -!- pyskell [~pyskell@unaffiliated/pyskell] has quit [Quit: Leaving] 14:04 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has quit [Read error: Connection reset by peer] 14:05 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-bip-review 14:16 -!- jonatack [~jon@37.167.197.45] has joined ##taproot-bip-review 14:35 < aj> andytoshi: having "fetch = +refs/pull/*/head:refs/pull/origin/*" in .git/config makes pulling locally and using real tools pretty easy though? 14:56 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 14:56 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 14:56 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 15:13 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 246 seconds] 15:20 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Ping timeout: 260 seconds] 15:21 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 15:24 < gmaxwell> aj: but it doesn't make commenting easy. 15:30 -!- b10c [~Thunderbi@mue-88-130-54-006.dsl.tropolys.de] has quit [Ping timeout: 276 seconds] 15:53 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:b836:abdc:a37:9e09] has joined ##taproot-bip-review 15:53 < aj> gmaxwell: i had a go at writing a script that'd convert a text file of comments on a diff into a github review, but the api didn't seem to work as advertised :-/ 16:20 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:b836:abdc:a37:9e09] has quit [Ping timeout: 246 seconds] 17:35 < sipa> no q&a? 17:35 < sipa> in half an hour? 17:52 < gmaxwell> sipa: you can ask me questions! 18:00 < moneyball> I’ve asked sipa before but I’ll ask again for clarity. Is it possible with taproot to use a trusted third party as an emergency backup key co-signer and retain privacy on your balance and spends as long as you don’t utilize their key? (Like a Casa 3of5 where they have one of the keys) 18:02 -!- ZmnSCPxj_ [~ZmnSCPxj@180.190.32.251] has quit [Quit: ZmnSCPxj_] 18:10 < gmaxwell> moneyball: the most straight forward way would be to put their key under a branch rather than at the top level. 18:11 < gmaxwell> moneyball: the normal way to make a schnorr threshold signature require interaction. The interaction doesn't actually break your privacy, but I assume for that application you also don't want the interaction. 18:12 < aj> gmaxwell: i think you'd want to pair it was an "OP_RETURN nonce" script, so that you'd never reveal the script hash even if you wanted to spend via some other script 18:12 < gmaxwell> (or at least the interaction doesn't necessarily break your privacy.) 18:13 < gmaxwell> aj: well normally what you do to hide a key is tweak it, which has no overhead. 18:13 < aj> gmaxwell: though you'd have to keep the merkle path to their script more redundantly than you kept your private keys 18:13 < gmaxwell> aj: well 3 of 5 right, so you put all the setup information with every copy of your keys. 18:14 < gmaxwell> (or a seed which is used to generate your setup info) 18:15 < aj> gmaxwell: yeah. if you tweak their key should be fine to be at the top level privacy-wise 18:15 < gmaxwell> aj: tweak works toplevel or in a branch, really there should never be a reason for a nonce in a branch that contains a pubkey. 18:16 < gmaxwell> instead you just compute some H(pubkey||chaincode||index)G+P and have that in the branch. 18:17 < gmaxwell> The top level has an additional storage complication though, since you have to do an interactive protocol and store the result. E.g. casa couldn't just publish a pubkey which you can add as a backup without ever talking to them. 18:18 < aj> top level as in key path, do you mean? 18:19 < gmaxwell> FWIW, that kind of backup service could also be done so that it's private even when used. Where you make a version of pubkey tweaked a commitment to your identity, ... then if you want them to backup sign for you, you could prove your identity and ask them to blind sign, so they never see the txn they're signing for. 18:19 < gmaxwell> aj: yes. 18:19 < aj> ah, i was meaning top level as in when there was only one tapscript 18:20 < moneyball> gmaxwell: that’s interesting I didn’t realize that 18:21 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 18:22 < gmaxwell> Another way of doing the "never see the txn", is that you ask them to generate a keypair for you, and give you the pubkey but you only use it in tweaked form so they can't see it being used. Then later, if you need it in an emergency, you identify to them and then they give you the private key. 18:22 < gmaxwell> And that even works with ECDSA. 18:23 < gmaxwell> There was some 'blockchain oracle' service called reality keys that published pubkeys for events, and depending on the outcome published one or the other private keys... which worked with this sort of use. 18:23 < gmaxwell> The 'give away the private key' usage isn't compatible with public derrivation sadly. 18:24 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 276 seconds] 18:25 -!- rottensox__ [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 18:28 -!- rottensox_ [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 250 seconds] 18:30 -!- ZmnSCPxj [9258463b@146.88.70.59] has joined ##taproot-bip-review 18:35 < gmaxwell> The right intution though is that _any_ key can be made private prior to its use by adding tweake*G to it, -- private to anyone that doesn't know that tweak value. This is true for ECDSA just as well, e.g. BIP32 public derrivation is essentially that. 18:35 < gmaxwell> For schnorr you just also gain the ability to do thresholds, but it works the same there. Come up with some threshold key P, and tweak it. 18:38 < gmaxwell> The 'interactive setup' for a threshold key is that each person generates an secret. Then each person N of M shares their secret using a verifyable secret sharing scheme. Everyone checks that the shares are all consistent. Everyone adds up all the shares they recieved. So the final result is each party learns an N of M share of the sum of everyone's secrets. Once you've done that, you can 18:38 < gmaxwell> go ahead and just tweak the result to keep it private from participants not knowing the tweak. 18:38 -!- rottensox__ is now known as rottensox 18:39 < ZmnSCPxj> "_any_ key can be made private": just to be clear, this means "any published pubkey can be used to create an unpublished pubkey that the original published pubkey signer(s) can sign for" 18:40 < gmaxwell> And since the tweak is mathmathcically equivient to AND-ing knowledge of the secret in the policy. (so your N of M policy because ((N of M) AND TWEAK)) it should just drop right into the signing process-- by either just adding the tweak to one of the signers' keys or by adding a 'fake participant' that signs with the tweak key. 18:40 < gmaxwell> And the same also works w/ blind signing. 18:41 < ZmnSCPxj> Would adding just `e * tweak * G` to the summed final `s` be enough? 18:41 < gmaxwell> -tweak, I believe if you want to be pedantic. 18:41 < aj> ZmnSCPxj: you want to add "x" so they can't mention on the nonce they signed too 18:41 < ZmnSCPxj> ok 18:41 < aj> if you're doing blind sigs at least 18:42 < gmaxwell> If you're _blind_ signing you have to hide the nonce. 18:42 < gmaxwell> which means the signer can't see the input to e... and there are some additional security considerations. 18:43 < gmaxwell> [and anyone reading this log in the future should be aware that virtually all descriptions of blind signatures out there are insecure and ignore wagner's algorithim, but it's possible to securely do... which should be sufficient for discussing taproot functionality] 18:44 < gmaxwell> sipa: so you're not gonna ask me any questions? :( 18:44 < ZmnSCPxj> Hmmm why `-tweak`? bip-schnorr uses `k + ed` 18:45 < ZmnSCPxj> Or possibly based on whether it is square or not 18:46 < gmaxwell> ZmnSCPxj: ah right you are. (sorry thought without thinking much was "you added it to the key so you should subtract it in the signature" but here you want to be signing for the tweaked value, not having a tweaked signer sign for the original value :P) 18:47 < ZmnSCPxj> okay 18:47 < gmaxwell> in any case, I expect that a complete schnorr multisigning api will end up with some 'tweak input' which must be input as a scalar, and bypasses delinearization. ... which you will need to sign with taprooted keys, and stuff like this. 18:47 < aj> gmaxwell: sipa just tricked you into asking him a question, i think that means he won 18:47 < gmaxwell> (I dunno what nickler's -zkp interface currently does) 18:48 < ZmnSCPxj> aj: Is that how high-level cryptographers play? 18:49 < gmaxwell> aj: it's a zero knoweldge protocol, we can't even tell if he's here or not. 18:50 < ZmnSCPxj> I believe I have seen elsewhere that blind Schnorr signing can be fixed somehow by requiring multiple blind signing attempts and then rejecting all except one that you randomly select, is that correct? 18:51 < gmaxwell> ZmnSCPxj: We don't have a security proof for that, but I believe that is secure. 18:52 < gmaxwell> Alternatively, you can only have exactly one signing session going at any one point in time, and begin a second only when the first finishes or times out. 20:29 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 20:29 -!- shesek [~shesek@185.3.145.80] has joined ##taproot-bip-review 20:29 -!- shesek [~shesek@185.3.145.80] has quit [Changing host] 20:29 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-bip-review 21:08 < gmaxwell> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017495.html < wouldn't this require a lot more hashing? 21:10 < sipa> gmaxwell: you mean at signing time 21:10 < sipa> ? 21:11 < gmaxwell> at verification time 21:12 < sipa> i thought about responding that this woukd break scenarios where the signer acrually doesn't know the checksig execution time (bexause it may depend on which other signers are availavle) 21:12 < sipa> but i don't actually know any such scenario 21:12 < sipa> gmaxwell: no, 4 bytes 21:13 < sipa> per checksig 21:14 < gmaxwell> sipa: but it requires invoking the sha256 compression function for each checksig operation when otherwise they'd share them, no? 21:14 < gmaxwell> sipa: if there is a long checksig add sequence, you'll know which checksig you're signing for, but not which other ones will be used. 21:14 < sipa> gmaxwell: oh, yes, but only at the end 21:15 < sipa> so you could use midstate caching if you really wamted to 21:15 < gmaxwell> sure, but even if you do that it'll still be an extra compression function run per checksig. 21:16 < sipa> that seems a very marginal issue 21:16 < sipa> i'm more concerned about complicating implementation of orrect signers 21:16 < sipa> *correct 21:18 < gmaxwell> The benefit of the change is unclear to me-- at least the example roconnor gives doesn't work AFAIK-- you already sign the script you're signing for, so you won't get substituted for a whole different script. 21:19 < gmaxwell> I mean, it essentially reitroduces a quadratic validation cost (though with a pretty small constant) 21:19 < sipa> no, it doesn't 21:19 < sipa> the cost per checksig is constant, with or without this change 21:20 < gmaxwell> okay, true _if_ you midstate cache. 21:20 < sipa> no, even if you do 't 21:20 < sipa> because all variable-length data fed to the sighash is precomputed per tx or per input 21:21 < sipa> midstate caching lets you reduce it from 200 ish bytes max to a few bytes (+ hashing of padding) 21:24 < sipa> if you know of an example where a signer in general wouldn't be able to predict the checksig position for a given signature he's producing, i'd very much like to hear it 21:24 < sipa> i'm also not convinced this change improves very much 21:25 < sipa> in practice 21:26 < gmaxwell> Some back of the envelope math suggests to me that this might asympotically slow validation by about 2% 21:26 < sipa> assuming you i. 21:27 < sipa> assuming you implement the caching of sighashes to begin with, you mean? 21:28 < gmaxwell> yes, and assuming batch validation is in use with ~infinite batch sizes... and assuming the transaction is all lots of checksigs in a single script. (ignoring the limits on scriptsize) 21:29 < gmaxwell> basically 2*sqrt+affine-add+2-fieldmul+sha2compression vs that plus one more sha2compression. (no sha-ni) 21:29 < sipa> it's only an average case performanxe reduction though, not a worst case one 21:29 < sipa> (as in the worst case you'd use codesep for every chechsig already? 21:30 < gmaxwell> ah. codesep... well thats why bluematt wants to get rid of codesep. 21:30 < gmaxwell> :) 21:30 < sipa> that's not really comparable 21:30 < sipa> the effect in legacy sighashes is much more significant 21:33 < gmaxwell> sipa: so my understanding of his concern is that you have a script leaf where you have something like "if hash160 equalverify pubkey1 checksigverify else pubkey2 checksigverify endif", and you're tricked into signing for the second clause when you think you're signing for the first. 21:33 < gmaxwell> as avoiding this rebinding would require doing stuff like making sure your pubkey only happens in the expected place and not someplace else. 21:36 < sipa> gmaxwell: it's primarily an issue if you reuse the same pubkey in multiple places in a script 21:37 < sipa> but (a) it's not even a full protection in that case (multiple code paths resulting in the same pubkey does not imply the checksig position will be different; ideally you'd sign all the if/then/else and other conditionals in the whole script 21:38 < gmaxwell> sipa: but the 'reuse' might be done by another user. 21:38 < gmaxwell> If you sign all the conditions that will absolutely break non-interactive checkmultisig like usage. 21:39 < sipa> yep. 21:39 < sipa> i agree with that 21:39 < sipa> i feel like this exact suggestions doesn't break much in practice,but also does 't protect aginst much in practice 21:39 < ZmnSCPxj> Would banning `OP_IF` and forcing every branch to use MAST work? 21:40 < gmaxwell> I think if you sign _which_ checksig you were executing (as in like it's byte position in the witness program) then thats sufficient for his concern. 21:40 < sipa> ZmnSCPxj: that woukd absolutely kill a whole bunch of interesting use cases 21:40 < gmaxwell> ZmnSCPxj: that would be tremendiously destructive. 21:40 < ZmnSCPxj> ok 21:41 < sipa> gmaxwell: that's exactly what he's suggesting 21:41 < sipa> (except it's opcode number, not byte position) 21:42 < gmaxwell> ZmnSCPxj: imagine your policy is like a 25 of 100... you can't build a MAST tree of that-- it would be about 2^80 hashing operations to do so. Yet it's a fairly straight forward script otherwise, not even terribly expensive fees wise. 21:44 < gmaxwell> sipa: opcode number is maybe a little softfork hostile though, since it means the counting needs to be consistent in implementations with different rules. 21:44 < sipa> gmaxwell: i don't think that is hard 21:44 < gmaxwell> K. 21:44 < gmaxwell> (no strong opinion) 21:47 < gmaxwell> I guess there is no performance overhead (well depending on how much data is going into hashes) in the common case that there is only a single checksig in any case. 21:47 < gmaxwell> and no increase in the worst case, as you note. 21:47 < ZmnSCPxj> For 25 of 100, is not `OP_CHECKSIGADD` enough? There is still no need for `OP_IF`? 21:48 < gmaxwell> sipa: so, if the pubkey going into the checksig is decided by an earlier part of the script, you may not know your position. 21:48 < sipa> gmaxwell: yep, i see how that is the case in theory 21:48 < gmaxwell> ZmnSCPxj: if you want to be forced to have an extra 75 zero pushes for no good reason. :P 21:49 < gmaxwell> ZmnSCPxj: though replace my example with a bunch of hash preimages and your dodge goes away. 21:49 < sipa> gmaxwell: i wanted to bring that uo, but i can't actually come up with a useful script that needs this 21:49 < sipa> even the crazy 3-of-10000 wouldn't be affected 21:50 < gmaxwell> sipa: well if OP_CAT is reenabled then e.g. pubkey checked against a hashtree in the script is potentially such a case. 21:50 < sipa> gmaxwell: mmmmaybe 21:50 < gmaxwell> it could be controlled by a sighash flag... 21:50 < gmaxwell> :-/ 21:52 < gmaxwell> so for example, a OP_CAT key tree that emerges a couple keys from the tree, and checks that they're distinct, then checksigs with them, -- like a way of doing the 4 of 10000 that doesn't include 10,000 pubkeys in the witness program. 21:53 < gmaxwell> you couldn't non-interactively sign for that, if the checksig positions are tagged (except via signing for each of the 4 possibilities) 21:57 < gmaxwell> (or change that to 4 of 65535 and then you even get a script that there is no other way to construct, yet is reasonably efficient to use, non-interactively signable, etc...) 21:58 < gmaxwell> If it somehow signed it's location in terms of which _branch_ rather than which checksig, it wouldn't break that case anymore. 21:59 < gmaxwell> like the opcode location of the nearest enclosing if. 21:59 < gmaxwell> (so every 'if' acts like a codeseperator for this purpose) 22:00 < ZmnSCPxj> gmaxwell: "though replace my example with a bunch of hash preimages and your dodge goes away." `OP_SWAP OP_HASH160 OP_EQUAL OP_ADD`, which is equivalent to `OP_CHECKSIGADD` except for hashes? 22:01 < ZmnSCPxj> Or `OP_ADD` is not enabled yet? 22:03 < gmaxwell> that works, but consider-- you've removed IFs and now so any conditional operation people have to just accomplish using arithmetic thresholds..okay, but then roconnor's concern about your signing for the wrong checksig still applies. The complaint I had about your original suggestion is that requiring all control flow to be precomputed in the hashtree is pratically limiting... 22:05 < gmaxwell> So: you can't replace "effectively conditional" logic in scripts with the tree because of exponential blowup in converting to disjunctive form. And any workaround to preserve conditional behavior (e.g. by doing it with arithmetic) still has the 'you might sign the wrong place' issue. 22:06 < gmaxwell> sipa: an alternative that maybe people would hate is that checksig could reject any script that reuses a pubkey. 22:06 < gmaxwell> so leaving it on validation to catch those cases, instead of the signer. 22:06 < ZmnSCPxj> okay 22:12 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: ZNC 1.7.4+deb0+bionic0 - https://znc.in] 22:13 -!- mryandao_ [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 22:14 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review 22:14 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 23:38 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-bip-review 23:39 -!- ZmnSCPxj [9258463b@146.88.70.59] has quit [Remote host closed the connection]