19:00:15 #startmeeting 19:00:15 Meeting started Tue Nov 12 19:00:15 2019 UTC. The chair is aj. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:17 hi 19:00:20 hi 19:00:20 hi 19:00:40 Hi 19:00:43 hi 19:00:44 hi 19:00:49 hi 19:00:54 hi 19:01:00 hi 19:01:31 hi 19:01:31 hi 19:01:31 hi 19:02:15 Hi 19:02:19 Q from group 5 (1/2): 1. What happens when using other leaf versions now before they are defined? 19:02:48 hi 19:03:22 hebasto: they're spendable by anyone (who can give the internal key and merkle path) 19:03:51 I was having the same question and I don't think this is specified in the BIP. 19:04:05 bjarnem: it is, i think, though not explicitly 19:04:19 yes, it is not obvious from bip... 19:04:27 bip-taproot just states that any relevant scripts are executed 19:04:43 would those spends be non-standard initially? 19:04:48 jnewbery: of course 19:04:49 I think taproot rationale [10] is what we're looking for, 19:04:58 hi 19:05:07 bip-tapscript defines one for one particular leaf version 19:05:21 sipa: "of course" -- should it be written down somewhere which bits should be treated as non-standard? 19:05:42 I think standardness falls outside the BIPs, which only deal with consensus, no? 19:05:42 perhaps we can add that if no script semantics are defined for a particular leaf version, the spend is unconditionally valid 19:05:52 jnewbery: yeah, that's my thinking 19:05:53 Hi 19:06:23 That'd be a nice addition 19:06:45 aj: it feels strange to specify standardness rules in these bips, as they're far less "everyoneust agree on this" than the consensus parts 19:06:52 treating things as non-standard is important for future soft-forks to be safe (so that nodes that don't validate the new rules dont relay new tx's that might violate them) though? 19:07:04 but i also see that it'd be nice to have it written up somewhere 19:07:18 sipa: yeah, agree on both points :) 19:08:04 Q from group 5 (2/2). Disabled script opcodes."unexecuted branch" means unexecuted branch in the revealed script? 19:08:18 hebasto: correct 19:08:26 sipa; ty 19:08:27 i see how branch can be confusing here 19:08:45 a bit ;) 19:08:49 it means execution branch of the script, not merkle branch 19:09:08 Related: aborting when decoding the script instead of executing is merely a performance improvement, or am I missing something? 19:09:33 maybe "execution branch" and "merkle branch" are good wording for bip? 19:10:09 cdecker: it also implies that any later success isn't apllicable 19:10:17 hebasto: sure 19:10:23 Q: Regarding the tweak value `t` must be less than the SECP256K1_ORDER: What to do if the calculated value is greater/equal? 19:10:33 bjarnem: it won't be 19:10:44 bjarnem: buy a lottery ticket 19:10:47 Right, but it allows statically discarding things early on, without having to execute 19:11:25 cdecker: if your question is whether you can write an alternative way to interpreting that does not actually return false immediately upon abort, of course 19:12:05 but abort in this context is more than giving a suggested optimization for implementers; it's stating that if that condition is reached, the script must fail 19:12:44 The Taproot BIP says: "To the best of the authors' knowledge, no existing use of SHA256 in Bitcoin feeds it a message that starts with two single SHA256 outputs, making collisions between hashtag with other hashes extremely unlikely." What is meant by it and what would happen if it's true? Mostly interested because it's stated in somewhat uncertain terms. 19:12:44 Yep, just felt strange to abort on a script branch that isn't even executed :-) 19:13:11 cdecker: i see 19:13:28 Q: Regarding the squareness of `Q`: (Disclaimer: I am not a cryptographer, so I hope this question is not naive) 19:13:28 I am unsure regarding the necesity of using a bit to indicate the `has_square_y(Q)` in the control block (Ad7 and Ad6 explain that the squareness of y cannot be guaranteed for `Q`). 19:13:28 The `Q` value (tweaked pubkey) is commited as scriptPubKey. It can hence also be spend using the key path with a Schnorr signature. But BIP-Schnorr then requires the (tweaked) pubkey `Q` to pass `has_square_y(Q)`. Shouldn't it therefore be guaranteed that for `Q` such a y-coord exists? Or am I misunderstanding something completely? 19:14:17 cdecker: not sure how to formulate more clearly... you can see it as a preprocessing step of executing the script (in which case it's just a failure rather than aborting during execution itself 19:15:16 The formulation is clear, I was just wondering about the rationale. All good, don't want to hold up the QA ^^ 19:15:23 bjarnem: for key spending Q doesn't have a y coordinate. So the verifier will choose the y coordinate that is square (there's only two options). 19:15:27 bjarnem: when spending using the key path, you interpret Q as a has_square point, regardlesz of how it was constructed, and sign possibly with its negation 19:15:34 Is it referring to the SHA256 opcode or something else? 19:15:59 bjarnem: when signing using the script path, you have to actually know the squaredness of Y, otherwise the commitment equation won't hold 19:16:20 One thing that we spent a bit of time talking about in our group session was the annex. Both the format (ie starting with 0x50) and the purpose. 19:16:30 For the format, I think we explicitly want a leading byte that can't be interpreted as a pubkey (so it can't be confused for P2WPKH) or a opcode (so it can't be confused for P2WSH). 0x50 fits the bill because it can't be a pubkey leading byte (which must be 0x02 or 0x03) and it's an invalid opcode (defined as OP_RESERVED internally, but with unconditional fail semantics). 19:16:45 sipa, bjarnem: and you can't just try both options if we want to batch verify to make it more efficient 19:17:26 jnewbery: it's stronger than that! you can recognize an annex in an input without knowing which output is being spent 19:17:27 citation 3: https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki#cite_note-3 explains that briefly, but I think it could be expanded a bit (I had to dig around to find 0x50 in script/interpreter.cpp 19:17:39 jnewbery: which is by design 19:17:40 sipa: ok, I see, so for the script path it is important to show exactly which point, and the x-coord is not enough. I will try to read up on that to understand it a little better :) 19:18:13 right. What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent? 19:18:14 bjarnem: feel free to PR a clarification if you find text that would make it easier to understand for you 19:18:46 jnewbery: did you get the idea of using an annex to artifically increase an input's weight? 19:19:10 I understood the purpose, but wondered why you couldn't just do that in the tapscript 19:19:21 ? 19:19:51 oh you mean by putting a big push + OP_DROP in the script? 19:20:24 I think the idea is that if we redefine an OP_SUCCESS to be something like OP_VERIFYSNARK, then we want to increase the weight becuase of the increased validation cost 19:20:42 yes, why not just add that weight to the script 19:20:57 jnewbery: that seems.like highly inefficient use of the chain 19:21:17 if you need to pad it with garbage 19:21:28 isn't that what the annex is doing? 19:21:31 Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)? 19:21:32 can't it be used also for a per-input locktime IIRC ? 19:21:35 jnewbery: no! 19:21:46 oh, then I misunderstand! 19:22:28 jnewbery: the idea would be for example that an annex whose first byte (after the 0x50, using some encoding) is 0x37, a 2-byte field follows 19:22:47 and the value of that two byte field is added to the weight of the tx 19:23:15 while simultaneously equivalently increasing the budget for expensivw opcodes in tbe script 19:23:36 ariard: for examlle 19:23:49 ariard: or a block height hash requirement 19:23:55 sipa: yes but the value of that two byte can be choosed by the spender how would you make it mandatory ? 19:24:21 ariard: if they set it tol high, they'll pay extra fees 19:24:22 after this imaginary future OP_VERIFYSNARK softfork, are unupgraded miners still able to mine? How do they account block weight? 19:24:29 don't you need to combine with some sighash flags to force annex value being covered by transaction digest 19:24:35 of they set it too low, the script will fail 19:24:37 ariard: if you spend more computation than the budget, your tx is invalid; so to increase the budget, you put the smallest value you can into the annex 19:24:54 ariard: annexes are always covered by signatures 19:24:58 sipa: annex could increase weight without bloating chain, right? 19:25:04 hebasto: right 19:25:17 jnewbery: increasing the weight for a transaction is a softfork 19:25:32 and using an unknown annex is nonstandard 19:25:41 so i think this is perfectly possible to deploy 19:25:59 (that doesn't mean we need to; there may never be a reason to) 19:26:11 aj: okay so it means we track budget during script evaluation and if committed budget in annex doesn't match it's a failure ? 19:26:13 unupgraded miners just don't include anything with an annex because it's non-standard? 19:26:18 right 19:26:45 ariard: the budget is the size of the input, which if amended by an annex, includes that amount 19:27:07 wait surely we expect miners to upgrade in SF scenarios to avoid mis-mining? 19:27:27 sipa: with op_zkverify would the limit be something like #(OP_CHECKSIG)*50 + #(OP_ZKVERIFY)*X <= weight? 19:27:35 nickler: exactly 19:27:36 sipa: and you check the budget against which reference value ? that's where I choke 19:27:49 ariard: the weight of the input 19:28:04 right now that is literally the number of bytes of the witness 19:28:24 if an annex is defined that increments the weight, that counts too 19:28:40 nickler: op_zkverify? 19:28:56 elichai2: a hypothetical example 19:29:34 What are the benefits of being able to recognise a P2TR spend without having the UTXO being spent? 19:29:57 jnewbery: for this annex weight increase example it's useful 19:30:17 as otherwise you wouldn't be able to compute a tx's weight without access to the output being spent 19:30:53 group 3 Q 1/?: "The total number of bytes hashed is at most 211" - this doesn't include the sub-hashes, like computing sha_prevouts, etc., right? the reason sub-hashes are not included in the 211 bytes is because they can be cached across sigs for the same tx? 19:31:09 devrandom: exactly 19:31:19 moneyball: :) I thought we're already planning tapscript V2 :P 19:31:45 maybe that sentence can be expanded to mention the sub-hashes? I can PR? or do you think it's clear enough as is? 19:32:20 devrandom: feel free 19:32:28 OK 19:32:57 group 3 Q/?: "Just like other existing output types, taproot outputs should never reuse keys" - this is for the standard privacy reason, as in "don't reuse addresses"? 19:32:59 would there ever be a reason to need more than one annex? 19:33:19 jnewbery: possibly 19:33:50 jnewbery: if you need a per input timelock and are using OP_ZKVERIFY, you'd use two annex entries maybe 19:34:26 Couldn't they be serialized back to back then? 19:34:28 so should we change the definition to be that any n trailing witness elements starting 0x50 are annexes? 19:34:58 jnewbery: yes, that's possible, but concatenating them is more efficient i think 19:35:04 0x50 { } seems a fine encoding to only use a single witness element 19:35:14 got it 19:35:34 (makes lightning people twitch since they like tag/length/value though) 19:35:53 it's also a tradeoff between taking a complexity hit now, and wondering whether we'll ever even need it 19:36:05 aj: just thought the same :-) 19:36:13 devrandom: agree that this is confusing. Made more sense when the section was called Privacy. 19:36:24 by saying some annex but not specifying any of its semantics we maximally defer the complexity to when it's needed 19:36:46 sipa: makes sense. Thanks 19:39:00 pyskell: the comment on the tagged hashes use refers to all sha256 anywhere in any protocol related to bitcoin 19:39:05 not just inside script 19:39:20 and the effect of being wrong about it is very likely nothing 19:40:08 in most cases tagged hashing is not needed 19:40:19 The control block can just be (one leading byte plus) the tapleaf hash in the case where only one script is committed. I thought it was slightly interesting that this is the only case where you can know for sure that no other spending conditions were committed to (with keypath spend you don't know whether there was a tweak and with a taptree spend you don't know the other branches) 19:40:52 jnewbery: good point 19:41:07 group 3 Q 3/?: there was some group discussion about the fact that specifying the pubkey in the output saves bytes in the blockchain overall, but it's actually heavier in *vbytes*. The discussion then got into whether the weight calculation should be different for taproot (I assume so as to encourage use by not penalizing with higher fees). what do you think? 19:41:35 sipa: Gotcha, thanks for clarifying 19:41:54 devrandom, i think i remember coming up with 1.5 vbytes heavier for p2tr vs p2wpkh when discussing it with aj last week 19:41:55 devrandom: for starters, i don't think this matters, because the output cost is paid by the sender 19:41:59 i mean average of course, not exact 19:42:28 and the sender is already willing to pay fot 32-byte witness programs, or he'd not have implemented bip173 19:43:00 that's an argument on segwit v1 vs v0 uptake, but not legacy to v1 uptake right 19:43:06 right 19:43:35 Q: Regarding wording for signature hash: 19:43:35 Under "Constructing and spending Taproot outputs" -> "Spending using the key path": 19:43:35 "[...] To do so, a witness stack consists of a single element: a bip-schnorr signature on the signature hash as defined above, [...]" <- Is the "transaction digest" defined above the same as what is called "signature hash" here? 19:43:37 waxwing: I came up with 1.25 :) https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7 19:44:25 nickler, lol i'll take it. 19:44:33 bjarnem: yep 19:45:10 the difference in vbytes for the sender is (32 - 20) * 4 = 48 if I'm not mistaken. that said I don't have an opinion about this personally, if anybody from group 3 does they can say something ;) 19:45:26 sipa: thoughts on adjusting the weight calculation to make spending PT2R slightly more favorable? advantage being increased adoption of it + improved privacy/fungibility 19:45:45 moneyball: that would be a hard fork. good luck. 19:45:52 oh... 19:46:09 a much less technical point, but our group (6) felt that the Motivation section of BIP-taproot does not actually address the motivation, at least to a reader who doesn't know all historical context. it seems like the motivation is in the "Design" section that immediately follows. 19:47:34 sipa, or maybe swipe a byte or two off the witness program? :) 19:47:51 sipa: I feel that those terms could be defined as being the same under "Transaction digest", or maybe just use one term. Becuase it also happens in BIP-Taproot that sometimes it refers to the "transaction digest" and other times to the "signature hash". But if they are the same maybe just use one term? 19:48:13 devrandom: (32-20)*4 gives difference in weight units, vbytes is just (32-20) (and if you were counting witness data, you'd divide that part by 4) 19:48:14 bjarnem: agreed 19:48:38 (edit: I meant also in BIP-TapSCRIPT) 19:48:44 aj: got it 19:49:14 waxwing: can you open an issue in my bips repo for that? i think that perhaps needs some more discussion than just a PR 19:49:48 sipa, the motivation? sure yeah that makes sense. i'll copy in the notes i made about it earlier. 19:50:04 bjarnem: good point, let's use signature hash everywhere (transaction digest is confusing, as it contains some data that's not actually in the transaction) 19:50:07 waxwing: yeah 19:50:35 sipa: maybe "signature digest" for the stuff you feed into the hash function and "signature hash" for the result? 19:50:55 sipa: it keeps annoying me there's no term to use for the stuff you feed into the hash 19:51:16 aj: "message digest" is a historical name for cryptographic hash function, so i wouldn't use digest to refer to its preimage 19:51:35 group 3 Q 4/?: "The new signature hashing algorithm fixes the verification capabilities of offline signing devices by including amount and scriptPubKey in the digest" - the difference is that segwit commits to input value, but taproot commits to *all* inputs, right? is the difference mainly for transaction with inputs from different parties? 19:51:41 sipa: fair 19:52:11 devrandom, yes i was wondering about that, is it related to the kinds of attacks instagibbs came up with wrt coinjoin and similar? 19:52:24 devrandom: no, there is an existing issue where you ask a device to sign a 2-input tx twice, and each time you lie about the other input's value 19:52:41 the result is that a malicious online wallet can trick an offline wallet in spending more on fees than it intends to 19:54:25 right so not specifically coinjoin but that's one of the main ways it might come up 19:54:32 right 19:54:40 it's more general than that, but indeed 19:54:53 I already asked but cannot find an answer, so in case it was overlooked in the discussion here it comes again :) 19:54:54 Q: What is reasoning behind OP_SUCCESSx instead of only using the available versioning fields to soft-fork new Tapscript logic into the system (e.g. using the leaf version)? 19:55:09 sipa: got it, I assumed that HW wallets signed all inputs at the same time 19:55:11 bjarnem: OP_SUCCESSx is the most powerful upgrade mechanism there is 19:55:38 bjarnem: if you'd have me pick one of leaf versions, upgradable pubkeys, or op_success, i'd pick the last one 19:56:07 sipa: Doesn't leaf versioning have the same power, allowing to change the semantics of the script language like segwit versioning?? 19:56:29 bjarnem: yes, but you need a new leaf version any time you introduce a new opcode for example 19:56:48 with OP_SUCCESSx you just pick a number and define it; it can be done in parallel with other new opcodes even 19:57:13 group 3 Q 5/5: should the BIP have a Requires header referring to schnorr, etc.? 19:57:27 sipa: ah, ok I see that 19:57:46 bjarnem: OP_SUCCESSx is the most natural choice for new opcodes, i think; leaf versions are the most natural choice for large redefinitions of the language 19:58:02 and leaf versions essentially come at zero cost, because we have a few unused bits in the control block anyway 19:58:12 devrandom: yeah 19:58:16 devrandom: I think so. there's a PR for that already https://github.com/sipa/bips/pull/135 19:58:17 sipa: thanks for the clarifiaction of the reasoning! 19:59:16 as time is running out here... i feel there have been a lot of good questions here that got a response consisting of a rationale that isn't actually in the BIPs; i'll do an effort to go through the transcript and addressing the ones asked, but feel free to help with that 20:00:04 "feel free to help" ~= "please do help" :) 20:00:28 shall we wrap? 20:00:29 if you got a satisfactory answer, you're probably in the best position to add to the bip exactly what insight would have made the text more clear to you 20:00:44 will PR for the stuff I asked 20:00:50 awesome, thanks 20:00:56 i need to run, thanks everyone! 20:00:59 #endmeeting 20:01:06 thanks! 20:01:11 Thanks! 20:01:12 Thanks 20:01:15 Thanks a lot!! 20:01:23 Thanks ^^ 20:01:24 also, quick tip since a few people haven't had much luck getting groups together -- (a) if no one else has taken the initiative to choose a time, or talk about things, that might just be a cue for you to do it; (b) it might be that everyone else in your group really is too busy, so feel free to contact to join a different group 20:01:28 #endmeeting