--- Day changed Fri Nov 29 2019 00:30 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has joined ##taproot-bip-review 01:50 -!- rottensox__ is now known as rottensox 01:59 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:d08:949d:9420:76eb] has joined ##taproot-bip-review 02:01 -!- jonatack__ [~jon@37.170.46.209] has joined ##taproot-bip-review 02:04 -!- jonatack_ [~jon@37.170.165.151] has quit [Ping timeout: 250 seconds] 02:52 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:d08:949d:9420:76eb] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:59 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 250 seconds] 03:08 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 05:27 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-bip-review 05:27 -!- jonatack__ [~jon@37.170.46.209] has quit [Read error: Connection reset by peer] 06:33 -!- jonatack__ [~jon@37.170.46.209] has joined ##taproot-bip-review 06:37 -!- jonatack__ [~jon@37.170.46.209] has quit [Client Quit] 06:37 -!- jonatack [~jon@37.170.46.209] has joined ##taproot-bip-review 06:38 < waxwing> probably fairly basic stuff but: in the mailing list post sipa says "Given that there are no known use cases for stack elements larger than 65 bytes", an obvious question arises as to why 520 was the size chosen and why we keep it? 06:39 < waxwing> hmm also is my memory failing me or doesn't/didn't that 520 limit apply to redeem scripts for p2sh? 06:39 < waxwing> (mailing list post i mean this one, it was referred in the week4 doc: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017306.html) 06:43 < waxwing> separate comment, but i really like this "translate resource usage (e.g. sigop) into weight units to make tractable the economic optimisation problem of mining"; i can't help wonder whether we need some "unified theory" for it, so that if there were ever a new thing like conf. trans. in BTC there would be some standardised way to handle resource usage control. 06:45 < waxwing> "Tapscript execution allows one signature opcode per 50 witness weight units plus one free signature opcode." <--- unfairly cheap opcodes to go with your unfairly linear signatures. 06:57 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Quit: Bye] 07:25 < waxwing> "Additionally, the limit applies to the transaction input instead of the block and only actually executed signature opcodes are counted." <-- this is interesting. a miner has to validate the given script + witness anyway, but with taproot notionally you're only ever satisfying "one" condition right, so i find it weird that you'd be dealing with a script with tons of conditional sigops and some of them not executed? 07:26 < waxwing> i was originally wondering about resource exhaustion but that's silly, miner has to validate anyway, so "only executed count" just removes one path of easy optimisation (count sigops, if too high, reject). still it's interesting, i guess there's a use case for tons of (unexecuted) sigops in a taproot situation that I'm not seeing. 07:31 < aj> waxwing: https://github.com/ajtowns/taproot-review/issues/28 is a sketch of a script with potentially many unexecuted sigops fwiw; k-of-n via checksigadd with k much less than n would have many failing sigops which are also ~free 07:31 < waxwing> (if it's jerry-rigged threshold multisig with n of ns there wouldn't be a need for unexecuted?) 07:31 < waxwing> oh lol almost the same time, thanks :) 07:32 < waxwing> oh! i forgot checksigadd lets you do that. yes, that's a bit different. 07:34 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 07:35 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 07:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 07:49 < sipa> waxwing: one reason to keep the 520 byte limit is because the more you change the more justification you need 07:49 < sipa> p2sh redeemscripts are limkted to 520 bytes 07:51 < sipa> waxwing: there are certainly use cases for having unexecuted things in script (mostly because expanding everything to separate leaves would be intractable due to too many combinations) 08:10 -!- andytoshi [~apoelstra@wpsoftware.net] has joined ##taproot-bip-review 08:10 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Changing host] 08:10 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-bip-review 08:48 < waxwing> it's interesting. i was forgetting checksigadd, and the thought occurred to me (in context of 'threshold' instantiated as leaves) that whatever does get executed is like a second-level version of the "taproot" assumption: there is total agreement *within* that executed branch. sort of made me think that it 'should' always work like that. 08:49 < waxwing> but that just makes me realise i need to re-read the rationale for op_checksigadd since it doesn't work like that at all. 08:51 < waxwing> oh right, you wanted something new for batch verify, and you didn't want to ditch a non-musig type multisig. so in that case it's unavoidable to have something *like* that. 08:51 < sipa> yeah we thought about a 08:52 < sipa> yeah we thought about a replacement for cms/cmsv where you'd just give a signature for every key (rather than only passing ones, by providing empties for those) 08:52 < sipa> but csa is barely less efficient, and more flexible than that 09:01 < sipa> since the 201 ops limit is gone we arguably do not actually need op_csa as much anymore 09:08 -!- dr-orlovsky [~dr-orlovs@169.204.90.212.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 245 seconds] 09:09 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 09:10 -!- dr-orlovsky [~dr-orlovs@128-124-89-64.mobile.vf-ua.net] has joined ##taproot-bip-review 09:20 -!- dr-orlovsky [~dr-orlovs@128-124-89-64.mobile.vf-ua.net] has quit [Read error: Connection reset by peer] 09:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 265 seconds] 09:28 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has quit [Ping timeout: 265 seconds] 09:39 -!- dr-orlovsky [~dr-orlovs@128-124-89-64.mobile.vf-ua.net] has joined ##taproot-bip-review 09:41 -!- dr-orlovsky [~dr-orlovs@128-124-89-64.mobile.vf-ua.net] has quit [Read error: Connection reset by peer] 10:10 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 10:46 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has joined ##taproot-bip-review 11:06 < waxwing> isn't the weight of the non-witness part of a txinput 4x(32+4+4) (roughly), i.e. 160 ish, so why is it 1 free sigop if it's 50 wu/sig op? 11:11 -!- dr-orlovsky [~dr-orlovs@2a02:1205:500f:2e90:4ce9:9687:b6b3:dc52] has joined ##taproot-bip-review 11:24 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has quit [Ping timeout: 250 seconds] 11:30 < sipa> waxwing: lame rationalization: looking up and spending an input also has a cost 11:57 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 11:57 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-bip-review 12:15 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has joined ##taproot-bip-review 12:57 -!- rottensox [~rottensox@unaffiliated/rottensox] has quit [Ping timeout: 250 seconds] 13:01 -!- b10c [~Thunderbi@i577BC6DE.versanet.de] has quit [Ping timeout: 252 seconds] 13:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-bip-review 13:21 -!- dr_orlovsky [~dr-orlovs@ip216.ip-54-36-238.eu] has joined ##taproot-bip-review 14:01 -!- jonatack_ [~jon@37.173.18.95] has joined ##taproot-bip-review 14:03 -!- jonatack_ [~jon@37.173.18.95] has quit [Read error: Connection reset by peer] 14:04 -!- jonatack [~jon@37.170.46.209] has quit [Ping timeout: 268 seconds] 14:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 14:57 -!- jonatack [~jon@37.173.18.95] has joined ##taproot-bip-review 15:15 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 252 seconds] 15:44 -!- jonatack [~jon@37.173.18.95] has quit [Quit: jonatack] 15:53 -!- jonatack [~jon@37.173.18.95] has joined ##taproot-bip-review 17:03 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 250 seconds] 17:07 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review 19:03 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-bip-review 19:21 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 19:21 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Read error: Connection reset by peer] 19:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer] 19:21 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Read error: Connection reset by peer] 19:21 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Read error: Connection reset by peer] 19:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-bip-review 19:23 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined ##taproot-bip-review 19:31 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review 19:32 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined ##taproot-bip-review 20:17 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 276 seconds] 20:29 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-bip-review 23:42 -!- jonatack [~jon@37.173.18.95] has quit [Read error: Connection reset by peer]