--- Day changed Wed Jan 22 2020
00:05 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Ping timeout: 265 seconds]     
00:09 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has joined ##taproot-bip-review     
04:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds]     
04:38 -!- jonatack [~jon@134.19.179.203] has joined ##taproot-bip-review     
06:45 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has joined ##taproot-bip-review     
06:55 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has quit [Quit: Sleep mode]     
06:56 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has joined ##taproot-bip-review     
08:12 -!- jonatack [~jon@134.19.179.203] has quit [Ping timeout: 268 seconds]     
08:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review     
11:38 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has quit [Quit: Sleep mode]     
12:19 < sipa> ok, should taproot be capitalized?
12:19 < andytoshi> Yes     
12:19 < andytoshi> Taproot
12:20 < moneyball> no per optech style guidelines :) https://github.com/bitcoinops/bitcoinops.github.io/blob/master/STYLE.md
12:20 < sipa> ok, should Taproot be capitalized?
12:20 < sipa> according to your link:
12:20 < sipa> Common nouns
12:20 < sipa> The first letter of a common noun is only capitalized at the start of a sentence or heading.
12:20 < sipa> taproot
12:21 < moneyball> yes, that is why i answered "no" to whether it should be capitalized. i assumed you meant in general, not just at the beginning of a sentence.
12:21 < sipa> of course
12:21 < sipa> i mean
12:21 < sipa> Of course.
12:22 < sipa> oh, i completely missed that andytoshi and moneyball were distinct people here (same nick length...)
12:22 < moneyball> one of us has longer hair than the other :)
12:30 < gmaxwell> Luxuriant flowing hair
13:49  * andytoshi blushes
13:49 < andytoshi> oh, i defer to moneyball if he actually wrote a document
13:49 < andytoshi> but i feel like Taproot is a proper noun
13:50 < sipa> it     
13:50 < moneyball> i actually haven't taken part in the development of the optech style guidelines, but i like the concept of a community resource around them with rationale. that doesn't mean it is perfect or can't be improved. feel free to open PRs against it :)
13:51 < sipa> i feel like it's been elevated to a proper noun; similar to how "segregated witness" isn't one, but Segwit often is capitalized
13:52 < sipa> that said, it doesn't matter
14:49 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]     
14:53 < maaku> moneyball: in this context Taproot is a proper noun
14:57 < BlueMatt> can we use the next bitcoin block hash' low bit to decide?
15:19 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-bip-review     
15:19 < aj> BlueMatt: hmm, i wonder how well "let's use the next bitcoin block hash's high bit to decide" would work in place of a double-headed coin
15:21 < BlueMatt> high bit would probably be pretty 0-biased, but low bit should be pretty good :)
15:22 < aj> double-headed coins are pretty heads biased too :)
15:22  * sipa grabs popcorn for the ensuing bit-order-of-SHA256 discussion that follows
15:24 < aj> nah, even rusty has accepted satoshi's vision for sha256 byte order https://github.com/rustyrussell/bitcoin-iterate/commit/4c53810afc3e0979054965514d64a3e05b74869f
15:27 -!- michaelfolkson [~textual@92.6.97.247] has joined ##taproot-bip-review     
15:27 -!- michaelfolkson [~textual@92.6.97.247] has quit [Client Quit]     
15:50 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has quit [Ping timeout: 268 seconds]     
15:50 -!- orlovsky [~dr-orlovs@194.230.155.171] has joined ##taproot-bip-review     
16:02 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has joined ##taproot-bip-review     
16:02 -!- michaelfolkson [~textual@host-92-6-97-247.as43234.net] has quit [Client Quit]     
19:09 -!- davterra [~dulyNoded@195.206.105.106] has quit [Ping timeout: 260 seconds]     
20:47 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined ##taproot-bip-review     
20:52 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has quit [Quit: Konversation terminated!]     
21:00 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory]     
21:16 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has joined ##taproot-bip-review     
21:48 -!- jeremyrubin [~jr@c-67-180-60-249.hsd1.ca.comcast.net] has joined ##taproot-bip-review     
22:29 < jeremyrubin> How critical is the no P2SH rule for Taproot? Is it just to discourage/soft deprecate p2sh?
22:31 < sipa> and privacy
22:31 < jeremyrubin> Hm ok.
22:31 < 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
22:31 < jeremyrubin> I'm thinking of the "maximally interesting CTV scripts" that we discussed last week
22:32 < jeremyrubin> One of the interesting restrictions I can write is "I must be paid by these specific P2SH Witness Scripts"
22:32 < jeremyrubin> That's by comitting to the scriptsigs being the p2sh reveal
22:33 < aj> the 160bits of p2sh hash isn't really great for multiparty security so doesn't seem great for CTV?
22:33 < 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
22:33 < jeremyrubin> aj: it's useful for vaults
22:33 < 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)
22:34 < 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?
22:35 < 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
22:35 < 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
22:36 < aj> "is" -> "seems to me to be"
22:36 < jeremyrubin> aj: it enables non soft-fork upgrade
22:37 < aj> sure, that's the "useless" side :)
22:38 < jeremyrubin> what's useless? The P2sh taproot?
22:38 < aj> "people don't [follow the standard] and it's useless"
22:38 < jeremyrubin> Ah     
22:38 < jeremyrubin> Sure
22:39 < aj> aren't you looking at the NOP approach though?
22:40 < 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
22:40 < jeremyrubin> Ah let me explain more clearly
22:40 < jeremyrubin> so suppose I have a UTXO A. I then create a new output B which is <some hash> OP_CTV
22:41 < 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
22:42 < 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"
22:43 < jeremyrubin> But if there is no P2SH Taproot, this would only work for P2SH Classic or P2SH Segwit V0
22:44 < jeremyrubin> because this has potential applications for vaults, people might then prefer to not use Taproot for cold storage... which isn't great.
22:44 < aj> "some hash commits to the scriptSigs" ? is this a CTV variation then?
22:44 < jeremyrubin> Nope, this is the current proposal
22:44 < jeremyrubin> You always have to commit to the scriptsigs
22:44 < jeremyrubin> txid malleability otherwise
22:44 < aj> variation as opposed to the CTV type that commits to the outputs?
22:45 < jeremyrubin> CTV hash comitts to everything non-COutpoint
22:45 < jeremyrubin> https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki#Detailed_Specification
22:46 < jeremyrubin> The outputs are also committed to
22:50 < aj> what happens if you just commit to the witnesses as well as the scriptsigs then?
22:50 < aj> oh, can't do that :(
22:51 < jeremyrubin> You could?
22:51 < jeremyrubin> The issue is that then it wouldn't be opt-in by using p2sh
22:51 < aj> you wouldn't be able to have a tree of tapscripts doing different CTVs
22:51 < jeremyrubin> Ah right
22:52 < jeremyrubin> You would have to commit to just the root of the taproot program
22:53 < 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?
22:53 < 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"
22:54 < 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
22:55 < jeremyrubin> but that is way too much extra eng work
22:57 -!- notmandatory [~textual@cpe-76-169-37-102.socal.res.rr.com] has quit [Quit: notmandatory]     
22:59 < aj> mmm, seems kinda hacky as is
22:59 < jeremyrubin> I agree -- a future template version you might just include a bitvec of witness programs to hash
23:00 < jeremyrubin> which would give you the same binding power
23:00 < aj> figuring that out would be useful for checksig probably too
23:01 < aj> i wonder if using bits from nsequence for it would be interesting?
23:01 < 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
23:01 < jeremyrubin> aj: probably not, you need more bits than that
23:02 < jeremyrubin> unless you want to just do a *hash all witnesses* | *hash no witness* which is OK
23:02 < jeremyrubin> (you can't hash your own witness tho which is odd)
23:02 < jeremyrubin> Also i don't want to hijack the taproot bip review channel -- just happened to feel this was more taproot related than CTV
23:03 < 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
23:04 < jeremyrubin> Hm I don't think that works... how can two bits choose the group of inputs?
23:04 < jeremyrubin> You need N bits
23:04 < 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
23:05 < jeremyrubin> yikes
23:05 < jeremyrubin> That's really messy for OP_CTV to deal with cleanly
23:05 < jeremyrubin> Much better to localize the grouping per-input
23:05 < jeremyrubin> so different inputs can sign different input groups
23:06 < 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
23:07 < jeremyrubin> AJ: Fair; I think then just all-or-nothing is best then.
23:08 < aj> yeah, people have been thinking about this for years (for sigs not CTV anyway), so solutions are probably hard
23:08 < aj> (without hindsight anyway)
23:10 < jeremyrubin> Anyways -- one interesting suggestion would be to make the taproot spend be 3 elements on the stack
23:10 < 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
23:12 < jeremyrubin> Actually it should be fine (if tedious) because future select-a-script can condition on witness version of what to select
23:12 < aj> hmm, i guess OP_DATACOMMIT and an "<inputidx> OP_PUSH_INPUT_HASH" could do it
23:12 < aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-December/017511.html <-- op_datacommit
23:13 < jeremyrubin> Ah     
23:14 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]     
23:14 < 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
23:14 < aj> DUP OP_PUSHINPUTHASH TOALT ADD DUP OP_PUSHINPUTHASH FROMALT CAT SHA256 DATACOMMIT <hash> CTV
23:14 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined ##taproot-bip-review     
23:15 < jeremyrubin> aj: it's too late for me to read bitcoin scripts right now ;)
23:16 < 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>
23:16 < aj> input=witness stack
23:18 < aj> okay the a+b bit is nonsense
23:18 < aj> anyway, yeah, i think it's fine to have a CTV that doesn't solve this
23:19 < jeremyrubin> One option would be a separate opcode which does input commitments
23:19 < jeremyrubin> I think this is pretty reasonable
23:20 < aj> not sure how it should be costed; it might need a CHECKSIG-like weighting
23:20 < jeremyrubin> E.g., OP_CHECKWITNESSPROGRAM or OP_CHECKCOUTPOINTATINDEX or OP_CHECKSPK
23:20 < jeremyrubin> I think CHECKSPK is pretty reasonable
23:20 < aj> checkspk sounds like something you do before a concert. testing test 1 2 3... are you ready to rock ##taproot-bip-review?
23:21 < jeremyrubin> hah     
23:21 < jeremyrubin> Ok I think I may retire for the evening.
23:22 < aj> having them get combined and tested against a single hash/sig means less bytes which seems worthwhile
23:22 < aj> yeah, sounds sensible, night!
23:22 < jeremyrubin> aj: I agree; but in the main use case you're just having 1 output checked
23:22 < jeremyrubin> so hashing won't save you anything
23:23 < jeremyrubin> more than one is pretty exotic I think?
23:23 < aj> saves you 8 bytes for the value?
23:23 < jeremyrubin> You don't need the value for CHECKSPK
23:23 < jeremyrubin> Because you either have enough coin or not for the proposed txn
23:23 < aj> 1 input checked you mean?
23:24 < jeremyrubin> correct
23:24 < jeremyrubin> CHECKSPKFORINPUT or CHECKINPUT
23:24 < aj> but you'd not do CHECKSPK without also doing a CHECKCTV or CHECKSIG presumably?
23:24 < jeremyrubin> You might actually
23:25 < aj> poor man's cross-input sig aggregation
23:25 < jeremyrubin> Imagine a taproot branch "you can spend this with Bob's coins after a week"
23:25 < jeremyrubin> aj: yeah exactly
23:25 < jeremyrubin> also delegation-y stuff
23:25 < jeremyrubin> "If Bob Signed it I'm OK"
23:26 < jeremyrubin> aj: did you ever see my covenants talk from a while back
23:26 < aj> probably not
23:26 < jeremyrubin> http://www.mit.edu/~jlrubin/public/pdfs/multi-txn-contracts.pdf
23:28 < jeremyrubin> See Input Join covenants
23:29 < jeremyrubin> https://www.youtube.com/watch?v=r7xN7K0OqaA&feature=youtu.be
23:58 -!- Netsplit *.net <-> *.split quits: philbw4, dr_orlovsky, asoltys
23:58 -!- Netsplit *.net <-> *.split quits: nehan_, real_or_random, nothingmuch, raj_