1 2016-10-19 11:04:40 <rafalcpp> hi, in Gitian, how do you actually get the resulting binay build file and yml file out to the host? it remains inside the LXC image and builder manually takes it out with some commands or mount?
 2 2016-10-19 11:30:57 <rafalcpp> oh right, never mind, there is mv build/out/.  I'm hacking around gitian a bit and used other approach so far
 3 2016-10-19 19:29:58 <earlz> I asked yesterday about the semantics of invalid script causing invalid transaction. On the wiki page for Script though there is an odd note on the reserved word opcodes, such as OP_RESERVED
 4 2016-10-19 19:30:20 <earlz> "Transaction is invalid unless occuring in an unexecuted OP_IF branch"
 5 2016-10-19 19:31:05 <earlz> Would this mean a vout of the form `OP_IF OP_RESERVED OP_ENDIF PUSH_1` would thus be valid and spendable, but only if the redeem script was `PUSH_0`?
 6 2016-10-19 19:31:50 <earlz> er, I mean PUSH 0 and PUSH 1 there, not the no-ops..
 7 2016-10-19 19:34:03 <earlz> Or for even more weirdness, would a vout of the form `OP_ENDIF` be valid and potentially spendable by usign a redemption script of `PUSH 1 OP_IF`
 8 2016-10-19 19:55:21 <arubi> you can't push opcodes to the stack
 9 2016-10-19 19:55:28 <arubi> unbalanced if's are invalid
10 2016-10-19 19:56:37 <arubi> op reserved in an unexecuted if branch just means that there's some type of FALSE just as the IF is executed, and the op reserved ends up not executing
11 2016-10-19 19:56:44 <earlz> Ah... I forgot it is basically just a stack for the redemption portion
12 2016-10-19 19:57:14 <arubi> for... signatures, "sigscript" :)
13 2016-10-19 19:57:28 <arubi> but who cares about sigscript now that we have witnesses
14 2016-10-19 19:57:42 <earlz> yea, still working on wrapping my head around those
15 2016-10-19 19:58:10 <arubi> imagine if transaction signing actually made sense -> segwit
16 2016-10-19 19:58:50 <earlz> I've read high level details about it, but is there a good consise technical description of how it works?
17 2016-10-19 19:59:12 <arubi> bip143 is very good
18 2016-10-19 21:37:43 <earlz> Has there ever been a proposal or BIP or anything for a method to use the hash of a transaction in it's own vout/vin script? Like basically what OP_CHECKSIG does without the signature checking and instead pushing the hash onto the stack
19 2016-10-19 21:38:14 <earlz> It seems like an odd lacking thing from the Script opcodes unless I'm just missing something
20 2016-10-19 21:39:46 <arubi> what for?
21 2016-10-19 21:41:35 <arubi> see that you can't put a hash of your own transaction to the scriptpubkey because that would chage the hash of your transaction
22 2016-10-19 21:42:26 <earlz> yes, that's true.. You can't push the hash manually, but after the construction is complete, Script actually knows the hash (since it's used in OP_CHECKSIG), but just doesn't expose it in anyway
23 2016-10-19 21:42:29 <arubi> but.. you could push the unsigned hex to the stack and hash that.  if it's in the witness, you could get the same hash
24 2016-10-19 21:43:34 <arubi> I'm still not sure why though :)
25 2016-10-19 21:45:45 <earlz> yea, I'm not sure either to be honest heh.. I do wonder why Satoshi chose to make all the specialized opcodes like checksig and such and not expose the same functionality to be put together as 2 or 3 opcodes.. I guess transaction/script size concerns would be the only thing I can think of
26 2016-10-19 21:47:01 <arubi> well..  checksig is pretty cool in itself.  you don't have to feed it <sig> <pubkey>, you can have a script "... SWAP CHECKSIG" and feed it "<pubkey> <sig>"
27 2016-10-19 21:47:37 <arubi> and if you control the sig (which you are), and you have the redeeming tx hash
28 2016-10-19 21:47:51 <arubi> then checksig kinda becomes like op_ec_multiply :)
29 2016-10-19 21:48:11 <arubi> and bonus checksig at the end, but the pubkey you put in is arbitrary :)
30 2016-10-19 21:48:31 <earlz> heh that's an interesting way of looking at it