12020-01-23T00:02:22  *** michaelfolkson has joined ##taproot-bip-review
  22020-01-23T00:02:36  *** michaelfolkson has quit IRC
  32020-01-23T03:09:03  *** davterra has quit IRC
  42020-01-23T04:47:47  *** notmandatory has joined ##taproot-bip-review
  52020-01-23T04:52:11  *** jeremyrubin has quit IRC
  62020-01-23T05:00:13  *** notmandatory has quit IRC
  72020-01-23T05:16:20  *** notmandatory has joined ##taproot-bip-review
  82020-01-23T05:48:53  *** jeremyrubin has joined ##taproot-bip-review
  92020-01-23T06:29:28  <jeremyrubin> How critical is the no P2SH rule for Taproot? Is it just to discourage/soft deprecate p2sh?
 102020-01-23T06:31:02  <sipa> and privacy
 112020-01-23T06:31:19  <jeremyrubin> Hm ok.
 122020-01-23T06:31:30  <aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/017297.html were the discussion
 132020-01-23T06:31:39  <jeremyrubin> I'm thinking of the "maximally interesting CTV scripts" that we discussed last week
 142020-01-23T06:32:11  <jeremyrubin> One of the interesting restrictions I can write is "I must be paid by these specific P2SH Witness Scripts"
 152020-01-23T06:32:28  <jeremyrubin> That's by comitting to the scriptsigs being the p2sh reveal
 162020-01-23T06:33:02  <aj> the 160bits of p2sh hash isn't really great for multiparty security so doesn't seem great for CTV?
 172020-01-23T06:33:04  <jeremyrubin> Which is kinda cool, because I can then write covenants which different spenders can drive forward, but restricted to knowing that it's a key from an in-protocol party
 182020-01-23T06:33:16  <jeremyrubin> aj: it's useful for vaults
 192020-01-23T06:33:42  <jeremyrubin> Becuase then I can restrict that a vault program must be spent with coin from a specific address (i.e. one under my control)
 202020-01-23T06:34:58  <jeremyrubin> So if the deprecation is discourage/privacy/soft deprecate, I think it might be nice to just make them not standard instead of not enforced?
 212020-01-23T06:35:49  <jeremyrubin> Also if this is a really interesting feature; it would also be possible to just explictly add a mode where you commit to the witness programs in CTV
 222020-01-23T06:35:53  <aj> making things not standard for anything other than anyonecanspend-upgrade reasons is kinda pointless -- either everyone follows the standard rule it's effectively enforced, or people don't, and it's useless
 232020-01-23T06:36:13  <aj> "is" -> "seems to me to be"
 242020-01-23T06:36:25  <jeremyrubin> aj: it enables non soft-fork upgrade
 252020-01-23T06:37:55  <aj> sure, that's the "useless" side :)
 262020-01-23T06:38:18  <jeremyrubin> what's useless? The P2sh taproot?
 272020-01-23T06:38:48  <aj> "people don't [follow the standard] and it's useless"
 282020-01-23T06:38:55  <jeremyrubin> Ah
 292020-01-23T06:38:58  <jeremyrubin> Sure
 302020-01-23T06:39:46  <aj> aren't you looking at the NOP approach though?
 312020-01-23T06:40:06  <jeremyrubin> I guess the "rough edge" I'm looking at is if there is a feature of composition with CTV that is *only* available with P2SH spends, I don't want that to be a reason for people avoid upgrading to taproot outputs
 322020-01-23T06:40:15  <jeremyrubin> Ah let me explain more clearly
 332020-01-23T06:40:50  <jeremyrubin> so suppose I have a UTXO A. I then create a new output B which is <some hash> OP_CTV
 342020-01-23T06:41:48  <jeremyrubin> Some hash commits to the scriptSigs in the transaction. If A is a p2sh output (for simplicity, assume segwit), then comitting to the scriptSig commits that the second output is that specifc witness program
 352020-01-23T06:42:23  <jeremyrubin> So I can make a covenant which says "Only allow this transaction if it is spent with one of the inputs being Bob's coins"
 362020-01-23T06:43:22  <jeremyrubin> But if there is no P2SH Taproot, this would only work for P2SH Classic or P2SH Segwit V0
 372020-01-23T06:44:06  <jeremyrubin> because this has potential applications for vaults, people might then prefer to not use Taproot for cold storage... which isn't great.
 382020-01-23T06:44:23  <aj> "some hash commits to the scriptSigs" ? is this a CTV variation then?
 392020-01-23T06:44:34  <jeremyrubin> Nope, this is the current proposal
 402020-01-23T06:44:43  <jeremyrubin> You always have to commit to the scriptsigs
 412020-01-23T06:44:54  <jeremyrubin> txid malleability otherwise
 422020-01-23T06:44:58  <aj> variation as opposed to the CTV type that commits to the outputs?
 432020-01-23T06:45:17  <jeremyrubin> CTV hash comitts to everything non-COutpoint
 442020-01-23T06:45:30  <jeremyrubin> https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki#Detailed_Specification
 452020-01-23T06:46:00  <jeremyrubin> The outputs are also committed to
 462020-01-23T06:50:26  <aj> what happens if you just commit to the witnesses as well as the scriptsigs then?
 472020-01-23T06:50:42  <aj> oh, can't do that :(
 482020-01-23T06:51:08  <jeremyrubin> You could?
 492020-01-23T06:51:21  <jeremyrubin> The issue is that then it wouldn't be opt-in by using p2sh
 502020-01-23T06:51:22  <aj> you wouldn't be able to have a tree of tapscripts doing different CTVs
 512020-01-23T06:51:37  <jeremyrubin> Ah right
 522020-01-23T06:52:08  <jeremyrubin> You would have to commit to just the root of the taproot program
 532020-01-23T06:53:40  <aj> what if you just tell OP_CTV which other inputs scriptsig+witness to commit to to get the right result? some extra bytes, or a flag to look at two stack elements or something?
 542020-01-23T06:53:41  <jeremyrubin> Anyways, this isn't a huuuge concern as it's not clear that by the time people are looking to do this we won't have some other good ideas and stuff... but it seems kinda sad that Taproot wouldn't get this "feature"
 552020-01-23T06:54:49  <jeremyrubin> I mean the ideal case would be adding 32 byte P2SH or something, for the weird cases where you want another signer on a tx to be able to sign the other scriptsigs to pick a specific branch
 562020-01-23T06:55:20  <jeremyrubin> but that is way too much extra eng work
 572020-01-23T06:57:27  *** notmandatory has quit IRC
 582020-01-23T06:59:12  <aj> mmm, seems kinda hacky as is
 592020-01-23T06:59:57  <jeremyrubin> I agree -- a future template version you might just include a bitvec of witness programs to hash
 602020-01-23T07:00:31  <jeremyrubin> which would give you the same binding power
 612020-01-23T07:00:45  <aj> figuring that out would be useful for checksig probably too
 622020-01-23T07:01:14  <aj> i wonder if using bits from nsequence for it would be interesting?
 632020-01-23T07:01:38  <jeremyrubin> sure. I guess I'm just wondering if it's pretty useful (there are some nice vault constructs which use this kind of stuff) then may as well not avoid p2sh... even though I hate it
 642020-01-23T07:01:47  <jeremyrubin> aj: probably not, you need more bits than that
 652020-01-23T07:02:07  <jeremyrubin> unless you want to just do a *hash all witnesses* | *hash no witness* which is OK
 662020-01-23T07:02:19  <jeremyrubin> (you can't hash your own witness tho which is odd)
 672020-01-23T07:02:49  <jeremyrubin> Also i don't want to hijack the taproot bip review channel -- just happened to feel this was more taproot related than CTV
 682020-01-23T07:03:11  <aj> nah, use a bit or two from nseq to choose a group of inputs, and SIGHASH_GROUP in between single and all to allow a sig commit to each one in the group
 692020-01-23T07:04:04  <jeremyrubin> Hm I don't think that works... how can two bits choose the group of inputs?
 702020-01-23T07:04:16  <jeremyrubin> You need N bits
 712020-01-23T07:04:34  <aj> every input with nseq set is in the group, the rest aren't. 1 bit = at most 1 group per tx; 2 bits = at most 2 groups per tx
 722020-01-23T07:05:00  <jeremyrubin> yikes
 732020-01-23T07:05:11  <jeremyrubin> That's really messy for OP_CTV to deal with cleanly
 742020-01-23T07:05:27  <jeremyrubin> Much better to localize the grouping per-input
 752020-01-23T07:05:41  <jeremyrubin> so different inputs can sign different input groups
 762020-01-23T07:06:36  <aj> sure, but that means you have every input / every sig being able to choose random different groups of inputs to merge together, which probably gets O(N^2) and you have have big bitfields in the witness
 772020-01-23T07:07:51  <jeremyrubin> AJ: Fair; I think then just all-or-nothing is best then.
 782020-01-23T07:08:41  <aj> yeah, people have been thinking about this for years (for sigs not CTV anyway), so solutions are probably hard
 792020-01-23T07:08:49  <aj> (without hindsight anyway)
 802020-01-23T07:10:26  <jeremyrubin> Anyways -- one interesting suggestion would be to make the taproot spend be 3 elements on the stack
 812020-01-23T07:10:59  <jeremyrubin> This improves the case where some future select-a-script-from-input commitment wants to commit to the entire root and not a particular path
 822020-01-23T07:12:10  <jeremyrubin> Actually it should be fine (if tedious) because future select-a-script can condition on witness version of what to select
 832020-01-23T07:12:17  <aj> hmm, i guess OP_DATACOMMIT and an "<inputidx> OP_PUSH_INPUT_HASH" could do it
 842020-01-23T07:12:26  <aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017511.html <-- op_datacommit
 852020-01-23T07:13:34  <jeremyrubin> Ah
 862020-01-23T07:14:34  *** sipa has quit IRC
 872020-01-23T07:14:47  <jeremyrubin> For the record I think an OK outcome is that we don't worry too heavily about making Taproot compatible with this edge case CTV use, and if for some reason it becomes really popular we can soft fork to support it in a more first-class way
 882020-01-23T07:14:49  <aj> DUP OP_PUSHINPUTHASH TOALT ADD DUP OP_PUSHINPUTHASH FROMALT CAT SHA256 DATACOMMIT <hash> CTV
 892020-01-23T07:14:49  *** sipa has joined ##taproot-bip-review
 902020-01-23T07:15:25  <jeremyrubin> aj: it's too late for me to read bitcoin scripts right now ;)
 912020-01-23T07:16:37  <aj> input is "a" "b", takes hashes of the inputs "a" and "a+b" cats them together, hashes that and makes CTV include that when it calculates the tx hash and compares it to the given <hash>
 922020-01-23T07:16:47  <aj> input=witness stack
 932020-01-23T07:18:07  <aj> okay the a+b bit is nonsense
 942020-01-23T07:18:58  <aj> anyway, yeah, i think it's fine to have a CTV that doesn't solve this
 952020-01-23T07:19:16  <jeremyrubin> One option would be a separate opcode which does input commitments
 962020-01-23T07:19:23  <jeremyrubin> I think this is pretty reasonable
 972020-01-23T07:20:03  <aj> not sure how it should be costed; it might need a CHECKSIG-like weighting
 982020-01-23T07:20:03  <jeremyrubin> E.g., OP_CHECKWITNESSPROGRAM or OP_CHECKCOUTPOINTATINDEX or OP_CHECKSPK
 992020-01-23T07:20:21  <jeremyrubin> I think CHECKSPK is pretty reasonable
1002020-01-23T07:20:47  <aj> checkspk sounds like something you do before a concert. testing test 1 2 3... are you ready to rock ##taproot-bip-review?
1012020-01-23T07:21:06  <jeremyrubin> hah
1022020-01-23T07:21:58  <jeremyrubin> Ok I think I may retire for the evening.
1032020-01-23T07:22:13  <aj> having them get combined and tested against a single hash/sig means less bytes which seems worthwhile
1042020-01-23T07:22:23  <aj> yeah, sounds sensible, night!
1052020-01-23T07:22:38  <jeremyrubin> aj: I agree; but in the main use case you're just having 1 output checked
1062020-01-23T07:22:45  <jeremyrubin> so hashing won't save you anything
1072020-01-23T07:23:01  <jeremyrubin> more than one is pretty exotic I think?
1082020-01-23T07:23:02  <aj> saves you 8 bytes for the value?
1092020-01-23T07:23:23  <jeremyrubin> You don't need the value for CHECKSPK
1102020-01-23T07:23:42  <jeremyrubin> Because you either have enough coin or not for the proposed txn
1112020-01-23T07:23:54  <aj> 1 input checked you mean?
1122020-01-23T07:24:02  <jeremyrubin> correct
1132020-01-23T07:24:11  <jeremyrubin> CHECKSPKFORINPUT or CHECKINPUT
1142020-01-23T07:24:31  <aj> but you'd not do CHECKSPK without also doing a CHECKCTV or CHECKSIG presumably?
1152020-01-23T07:24:45  <jeremyrubin> You might actually
1162020-01-23T07:25:14  <aj> poor man's cross-input sig aggregation
1172020-01-23T07:25:14  <jeremyrubin> Imagine a taproot branch "you can spend this with Bob's coins after a week"
1182020-01-23T07:25:27  <jeremyrubin> aj: yeah exactly
1192020-01-23T07:25:33  <jeremyrubin> also delegation-y stuff
1202020-01-23T07:25:39  <jeremyrubin> "If Bob Signed it I'm OK"
1212020-01-23T07:26:08  <jeremyrubin> aj: did you ever see my covenants talk from a while back
1222020-01-23T07:26:24  <aj> probably not
1232020-01-23T07:26:46  <jeremyrubin> http://www.mit.edu/~jlrubin/public/pdfs/multi-txn-contracts.pdf
1242020-01-23T07:28:33  <jeremyrubin> See Input Join covenants
1252020-01-23T07:29:48  <jeremyrubin> https://www.youtube.com/watch?v=r7xN7K0OqaA&feature=youtu.be
1262020-01-23T07:58:41  *** dr_orlovsky has quit IRC
1272020-01-23T07:58:42  *** philbw4 has quit IRC
1282020-01-23T07:58:42  *** asoltys has quit IRC
1292020-01-23T07:58:42  *** real_or_random has quit IRC
1302020-01-23T07:58:50  *** nothingmuch has quit IRC
1312020-01-23T07:58:50  *** nehan_ has quit IRC
1322020-01-23T07:58:50  *** raj_ has quit IRC
1332020-01-23T08:01:55  *** evoskuil[m] has quit IRC
1342020-01-23T08:02:51  *** real_or_random has joined ##taproot-bip-review
1352020-01-23T08:02:51  *** nothingmuch has joined ##taproot-bip-review
1362020-01-23T08:02:51  *** nehan_ has joined ##taproot-bip-review
1372020-01-23T08:02:51  *** raj_ has joined ##taproot-bip-review
1382020-01-23T08:45:35  *** asoltys has joined ##taproot-bip-review
1392020-01-23T08:45:35  *** dr_orlovsky has joined ##taproot-bip-review
1402020-01-23T08:45:35  *** philbw4 has joined ##taproot-bip-review
1412020-01-23T10:34:24  *** belcher has quit IRC
1422020-01-23T10:55:33  *** belcher has joined ##taproot-bip-review
1432020-01-23T11:29:35  *** jonatack has quit IRC
1442020-01-23T12:18:06  *** evoskuil[m] has joined ##taproot-bip-review
1452020-01-23T12:22:25  *** jonatack has joined ##taproot-bip-review
1462020-01-23T12:44:33  *** jonatack has quit IRC
1472020-01-23T13:21:47  *** jonatack has joined ##taproot-bip-review
1482020-01-23T15:10:22  *** jonatack has quit IRC
1492020-01-23T15:27:39  *** jonatack has joined ##taproot-bip-review
1502020-01-23T15:40:50  *** jonatack has quit IRC
1512020-01-23T15:51:07  *** notmandatory has joined ##taproot-bip-review
1522020-01-23T16:12:28  *** notmandatory has quit IRC
1532020-01-23T17:00:26  *** jonatack has joined ##taproot-bip-review
1542020-01-23T19:41:42  *** jeremyrubin has quit IRC
1552020-01-23T19:42:33  *** jeremyrubin has joined ##taproot-bip-review
1562020-01-23T19:57:35  *** jeremyrubin has quit IRC
1572020-01-23T19:58:01  *** jeremyrubin has joined ##taproot-bip-review
1582020-01-23T20:24:14  *** orlovsky has quit IRC
1592020-01-23T20:25:06  *** dr-orlovsky has joined ##taproot-bip-review
1602020-01-23T21:06:03  *** pigeons has quit IRC
1612020-01-23T21:18:21  *** willcl_ark has quit IRC
1622020-01-23T21:18:21  *** maaku has quit IRC
1632020-01-23T21:18:22  *** jkczyz has quit IRC
1642020-01-23T21:25:38  *** jkczyz has joined ##taproot-bip-review
1652020-01-23T21:25:40  *** pigeons has joined ##taproot-bip-review
1662020-01-23T21:26:02  *** pigeons is now known as Guest92238
1672020-01-23T21:50:28  *** jonatack has quit IRC
1682020-01-23T21:58:27  *** jonatack has joined ##taproot-bip-review
1692020-01-23T22:01:40  *** willcl_ark has joined ##taproot-bip-review
1702020-01-23T22:01:40  *** maaku has joined ##taproot-bip-review