--- Log opened Mon Dec 07 00:00:38 2020
00:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
00:28 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
05:04 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-yslbdkfqtjhgwjcu] has quit [Ping timeout: 264 seconds]
05:05 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ulqcremawialdixq] has joined ##miniscript
05:07 < michaelfolkson> If someone here can save sipa the time in answering my question it would be appreciated :) https://bitcoin.stackexchange.com/questions/100413/for-a-redeem-script-to-satisfy-the-conditions-of-a-script-what-must-it-leave-on
05:18 < harding> michaelfolkson: TRUE is any non-zero value.  This is often used in scripts involving the former OP_NOPx opcodes that don't pop their values off the stack after verification, e.g. a script that can be spend by a miner after a certain height could use: `<locktime> OP_CLTV` ; if CLTV fails, the transaction is invalid; if it passes, then the non-zero <locktime> value left on the stack allows the script to pass.
05:22 < michaelfolkson> Gotcha, thanks harding. That answers the first part of the question.
05:23 < harding> michaelfolkson: for the second question, all that matters without clenastack is the top value on the stack at the end of execution.  Anything further down the stack doesn't matter.  Note, I'm not 100% sure but I think there's nowhere in Bitcoin today where cleanstack is a consensus rule.  BIP342 says it'll be consensus enforced for tapscript, though.
05:23 < harding> BIP342, Specification, rule 4, ii
05:24 < michaelfolkson> But you'd never get to the end of execution if you encounter a failure with a particular opcode right? 
05:24 < michaelfolkson> So you'd never see a stack of say TRUE FALSE TRUE because the execution would fail and abort immediately on the FALSE
05:26 < michaelfolkson> Are there any opcodes that produce a FALSE but don't terminate execution?
05:27 < harding> michaelfolkson: I think "failure" is ambiguous there; there's different way different opcodes can fail.  E.g. if OP_CHECKSIG fails, it just pushes a 0 to the stack; but if OP_CHECKSIGVERIFY fails, the whole script fails.
05:27 < harding> You can put TRUE FALSE FALSE on the stack using just OP_0 OP_0 OP_1
05:28 < michaelfolkson> So with OP_CHECKSIG in a non-CLEANSTACK you could have a stack that includes a failed OP_CHECKSIG but still passes
05:28 < michaelfolkson> Ok great, that answers my question. Thanks
05:30 < harding> No, I think you're misunderstanding the stack.  All that matters is the state of the stack at the end of script evaluation.  For example, you could do OP_CHECKSIG followed by OP_IF, e.g. if the signature succeeds, take one branch; if it fails, take another branch (people in this room will complain if you do that, though :-).
05:30 < harding> cleanstack is an attempt to prevent malleability by having people put a bunch of junk in your scriptSig or witness data.
05:31 < harding> Because you can just push a bunch of data onto the stack that never gets used and doesn't prevent the script from evaluating correctly.
05:32 < harding> (Pre-segwit, this affected txid malleability; with segwit, all it does is inflate the transaction size, making it's feerate lower.)
05:33 < michaelfolkson> The VERIFY opcodes e.g. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY terminate immediately on failure but the non-VERIFY equivalents don't
05:33 < harding> Correct.
06:24 < andytoshi> if you fail CHECKSIG by giving it an empty signature nobody here will complain :)
06:24 < andytoshi> but yes, please don't make nodes check invalid signatures. this is also consensus in taproot and currently standard (i think)
07:19 -!- prayank [~andr0irc@2409:4053:2e13:900f:d41e:b11b:ed95:2493] has joined ##miniscript
07:42 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript
08:00 -!- roconnor [~roconnor@host-45-58-200-239.dyn.295.ca] has joined ##miniscript
10:12 -!- prayank [~andr0irc@2409:4053:2e13:900f:d41e:b11b:ed95:2493] has quit [Ping timeout: 260 seconds]
10:32 < sanket1729_> personally, I like to use word 'abort' vs fail. script aborts if checksigverify fails, pushes a zero checksig fails but does not abort. 
10:45 < sanket1729_> suggested some edits to the answer
11:01 < michaelfolkson> It is a good suggestion, the language here is tough. Assuming all "aborts" or early terminations are script failures then this terminology can work
11:08 < michaelfolkson> The alternative is to refer to specific opcode failures and overall redeem script failures...
14:02 -!- Netsplit *.net <-> *.split quits: midnight
14:23 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##miniscript
16:03 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
16:15 -!- jonatack [~jon@213.152.161.170] has quit [Quit: jonatack]
16:27 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined ##miniscript
23:22 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
--- Log closed Tue Dec 08 00:00:39 2020