12019-11-29T00:18:30  *** arik_ has quit IRC
  22019-11-29T00:46:47  *** arik_ has joined ##taproot-bip-review
  32019-11-29T00:57:47  *** arik_ has quit IRC
  42019-11-29T01:53:39  *** devrando1 has quit IRC
  52019-11-29T02:10:42  *** andrewtoth_ has quit IRC
  62019-11-29T02:13:42  *** devrando1 has joined ##taproot-bip-review
  72019-11-29T02:24:25  *** devrando1 has quit IRC
  82019-11-29T02:24:42  *** dr-orlovsky has quit IRC
  92019-11-29T03:07:55  *** andrewtoth_ has joined ##taproot-bip-review
 102019-11-29T03:29:57  *** belcher has quit IRC
 112019-11-29T03:33:47  *** belcher has joined ##taproot-bip-review
 122019-11-29T03:58:58  *** rottensox_ is now known as rottensox
 132019-11-29T04:13:36  *** arik_ has joined ##taproot-bip-review
 142019-11-29T04:23:11  *** arik_ has joined ##taproot-bip-review
 152019-11-29T05:55:20  *** arik_ has quit IRC
 162019-11-29T06:01:05  *** arik_ has joined ##taproot-bip-review
 172019-11-29T06:04:46  *** arik_ has quit IRC
 182019-11-29T06:08:10  *** arik_ has joined ##taproot-bip-review
 192019-11-29T06:21:48  *** rottensox_ has joined ##taproot-bip-review
 202019-11-29T06:23:18  *** rottensox__ has joined ##taproot-bip-review
 212019-11-29T06:23:32  *** rottensox_ has quit IRC
 222019-11-29T06:24:48  *** rottensox has quit IRC
 232019-11-29T06:49:28  *** arik_ has quit IRC
 242019-11-29T07:01:15  *** rottensox__ has quit IRC
 252019-11-29T07:01:20  *** rottensox_ has joined ##taproot-bip-review
 262019-11-29T07:03:48  *** rottensox__ has joined ##taproot-bip-review
 272019-11-29T07:07:21  *** rottensox_ has quit IRC
 282019-11-29T07:09:21  *** rottensox__ has quit IRC
 292019-11-29T07:09:46  *** rottensox__ has joined ##taproot-bip-review
 302019-11-29T07:14:21  *** rottensox__ has quit IRC
 312019-11-29T07:15:01  *** rottensox__ has joined ##taproot-bip-review
 322019-11-29T07:16:51  *** rottensox__ has quit IRC
 332019-11-29T07:17:18  *** rottensox__ has joined ##taproot-bip-review
 342019-11-29T08:30:47  *** b10c has joined ##taproot-bip-review
 352019-11-29T09:50:15  *** rottensox__ is now known as rottensox
 362019-11-29T09:59:44  *** dr-orlovsky has joined ##taproot-bip-review
 372019-11-29T10:01:11  *** jonatack__ has joined ##taproot-bip-review
 382019-11-29T10:04:11  *** jonatack_ has quit IRC
 392019-11-29T10:52:50  *** dr-orlovsky has quit IRC
 402019-11-29T10:59:13  *** rottensox has quit IRC
 412019-11-29T11:08:34  *** rottensox has joined ##taproot-bip-review
 422019-11-29T13:27:35  *** dr-orlovsky has joined ##taproot-bip-review
 432019-11-29T13:27:49  *** jonatack__ has quit IRC
 442019-11-29T14:33:44  *** jonatack__ has joined ##taproot-bip-review
 452019-11-29T14:37:28  *** jonatack__ has quit IRC
 462019-11-29T14:37:44  *** jonatack has joined ##taproot-bip-review
 472019-11-29T14:38:50  <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?
 482019-11-29T14:39:06  <waxwing> hmm also is my memory failing me or doesn't/didn't that 520 limit apply to redeem scripts for p2sh?
 492019-11-29T14:39:54  <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)
 502019-11-29T14:43:03  <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.
 512019-11-29T14:45:27  <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.
 522019-11-29T14:57:44  *** rottensox has quit IRC
 532019-11-29T15:25:05  <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?
 542019-11-29T15:26:27  <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.
 552019-11-29T15:31:19  <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
 562019-11-29T15:31:25  <waxwing> (if it's jerry-rigged threshold multisig with n of ns there wouldn't be a need for unexecuted?)
 572019-11-29T15:31:37  <waxwing> oh lol almost the same time, thanks :)
 582019-11-29T15:32:52  <waxwing> oh! i forgot checksigadd lets you do that. yes, that's a bit different.
 592019-11-29T15:34:41  *** _andrewtoth_ has joined ##taproot-bip-review
 602019-11-29T15:35:28  *** andrewtoth_ has quit IRC
 612019-11-29T15:42:00  *** _andrewtoth_ has quit IRC
 622019-11-29T15:49:05  <sipa> waxwing: one reason to keep the 520 byte limit is because the more you change the more justification you need
 632019-11-29T15:49:17  <sipa> p2sh redeemscripts are limkted to 520 bytes
 642019-11-29T15:51:12  <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)
 652019-11-29T16:10:34  *** andytoshi has joined ##taproot-bip-review
 662019-11-29T16:10:34  *** andytoshi has joined ##taproot-bip-review
 672019-11-29T16:48:45  <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.
 682019-11-29T16:49:07  <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.
 692019-11-29T16:51:06  <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.
 702019-11-29T16:51:57  <sipa> yeah we thought about a
 712019-11-29T16:52:33  <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)
 722019-11-29T16:52:50  <sipa> but csa is barely less efficient, and more flexible than that
 732019-11-29T17:01:23  <sipa> since the 201 ops limit is gone we arguably do not actually need op_csa as much anymore
 742019-11-29T17:08:38  *** dr-orlovsky has quit IRC
 752019-11-29T17:09:22  *** rottensox has joined ##taproot-bip-review
 762019-11-29T17:10:32  *** dr-orlovsky has joined ##taproot-bip-review
 772019-11-29T17:20:59  *** dr-orlovsky has quit IRC
 782019-11-29T17:24:18  *** luke-jr has quit IRC
 792019-11-29T17:28:10  *** b10c has quit IRC
 802019-11-29T17:39:52  *** dr-orlovsky has joined ##taproot-bip-review
 812019-11-29T17:41:17  *** dr-orlovsky has quit IRC
 822019-11-29T18:10:14  *** _andrewtoth_ has joined ##taproot-bip-review
 832019-11-29T18:46:26  *** b10c has joined ##taproot-bip-review
 842019-11-29T19:06:52  <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?
 852019-11-29T19:11:17  *** dr-orlovsky has joined ##taproot-bip-review
 862019-11-29T19:24:55  *** b10c has quit IRC
 872019-11-29T19:30:21  <sipa> waxwing: lame rationalization: looking up and spending an input also has a cost
 882019-11-29T19:57:32  *** _andrewtoth_ has quit IRC
 892019-11-29T19:57:44  *** _andrewtoth_ has joined ##taproot-bip-review
 902019-11-29T20:15:15  *** b10c has joined ##taproot-bip-review
 912019-11-29T20:57:13  *** rottensox has quit IRC
 922019-11-29T21:01:24  *** b10c has quit IRC
 932019-11-29T21:02:24  *** luke-jr has joined ##taproot-bip-review
 942019-11-29T21:21:45  *** dr_orlovsky has joined ##taproot-bip-review
 952019-11-29T22:01:12  *** jonatack_ has joined ##taproot-bip-review
 962019-11-29T22:03:26  *** jonatack_ has quit IRC
 972019-11-29T22:04:36  *** jonatack has quit IRC
 982019-11-29T22:53:27  *** belcher has quit IRC
 992019-11-29T22:57:44  *** jonatack has joined ##taproot-bip-review
1002019-11-29T23:15:36  *** andytoshi has quit IRC
1012019-11-29T23:44:38  *** jonatack has quit IRC
1022019-11-29T23:53:39  *** jonatack has joined ##taproot-bip-review