1 2016-08-08 00:01:53 <jl2012> non-std scripts are valid in a block
 2 2016-08-08 00:02:28 <p2me> okay
 3 2016-08-08 00:05:05 <p2me> so let's pretend pre-p2sh i came up with a "hash puzzle" where i knew some word hash160'd to "xyz123"
 4 2016-08-08 00:05:30 <p2me> and i sent coins to pubkeyscript OP_HASH160 <xyz123> OP_EQUAL
 5 2016-08-08 00:05:50 <p2me> would those coins be lost forever now?
 6 2016-08-08 00:06:41 <p2me> the original locking script only wanted something which hashed to "xyz123", now the new nodes would force that thing to a script and a script which returns true?
 7 2016-08-08 00:14:05 <jl2012> p2me: yes
 8 2016-08-08 01:18:55 <achow101> jl2012: I don't think it would, it would just be seen as non standard. such a script would still verify as the stack will return true if the thing is hashed and it matches xyz123
 9 2016-08-08 01:21:37 <jl2012> achow101: only if the preimage is a valid redeemScript
10 2016-08-08 01:26:20 <p2me> you reveal your redeem script the second you spend from a p2sh address, i can steal all your coins by submitting just the raw <redeemscript> to a pool which mines non-standard tx's if that's the case
11 2016-08-08 01:27:37 <p2me> new nodes must be operating on a "i will not relay but am otherwise fine with non-standard scripts in blocks...UNLESS they look like P2SH scripts in which case they must also have valid redeem scripts otherwise i will explicitly invalidate them"
12 2016-08-08 01:31:39 <p2me> it seems like it would've been safer to structure P2SH to default to false using the old rules and only evaluate to true using the new rules. still backwards compatible but old rules couldn't create valid blocks (in their view) which spend your coins w/ 0 sigs.
13 2016-08-08 01:32:03 <p2me> this is all very confusing/messy to me
14 2016-08-08 02:07:10 <jl2012> Forget standard/non-standard.  For blocks we care only valid/invalid
15 2016-08-08 02:12:13 <p2me> alright. i think i understand now, just needed to process everything. i read over the bip and it seems only blocks AFTER P2SH get evaluated that way so in my example i could still redeem my coins with the simple word.
16 2016-08-08 02:14:43 <p2me> having the P2SH format evaluate to false under the old rules would also make the change a HF so everything makes sense now
17 2016-08-08 02:45:43 <achow101> jl2012: the preimage could just be a blob of arbitrary data, not necessarily a script.If it is a script, the script would have to validate before the hashing happens
18 2016-08-08 05:04:08 <jl2012> achow101: if it is not a script, the bitcoin is permanently lost
19 2016-08-08 18:01:29 <arubi> sorry for 13 hours delay..   jl2012, can you explain what you mean by that ^ ?   isn't p2sh(segwit script) basically a single push of what seems like arbitrary data?
20 2016-08-08 21:13:24 <p2me> i've written some raw tx stuff in PHP. when attempting to push the tx's to testnet it seems to be completely random whether they're accepted or not. i am manually pushing them to testnet via https://live.blockcypher.com/btc-testnet/pushtx/
21 2016-08-08 21:15:31 <p2me> testnet complains about "script failing to verify" but i can run the program again with identical parameters which produces an identical tx hash...
22 2016-08-08 21:16:02 <p2me> but sigScript changes slightly because of the nonce and then magically my tx is fine and testnet accepts it
23 2016-08-08 21:16:13 <p2me> can anyone explain what is possibly going on here?
24 2016-08-08 21:16:39 <arubi> can you give an example of an invalid signature?
25 2016-08-08 21:17:26 <arubi> also, the hash can't stay the same when the transaction is changed, so not sure what you mean by what you said
26 2016-08-08 21:18:01 <p2me> sorry, might be using the wrong terminology
27 2016-08-08 21:18:29 <p2me> not the final tx hash but the intermediary "tx hash" that you sign
28 2016-08-08 21:18:41 <arubi> right, that should stay the same
29 2016-08-08 21:18:42 <p2me> when you're constructing the sigScript
30 2016-08-08 21:18:48 <p2me> ok so...
31 2016-08-08 21:19:03 <arubi> so, you're getting different signatures every time the nonce changes, that's fine
32 2016-08-08 21:19:13 <arubi> your signatures are valid... half the time?
33 2016-08-08 21:19:24 <arubi> are you checking for high-s value?
34 2016-08-08 21:20:41 <p2me> i'm using https://github.com/BitcoinPHP/BitcoinECDSA.php for the ECC stuff
35 2016-08-08 21:21:14 <p2me> 3044022079175d7bb8660827849bc3e362b89344b2dabf9805c7b4d45fd215cdf94d26b6022085f6cc66c5b99e59029a4fc63ee43899f8385f9cc5ecec6a6ee1a9732bebd4a4
36 2016-08-08 21:21:25 <p2me> ^ invalid, rejected
37 2016-08-08 21:21:26 <p2me> 3044022029dc45ac7c50f0bfda4c6464604230bbf270fab865920a0dd77a929a46ba177b02204c2709248622bc05b3d957bf6cc0a400b7a624d4f7817c0a65486e8d85166e1b
38 2016-08-08 21:21:33 <p2me> ^ accepted
39 2016-08-08 21:22:36 <arubi> right, the first one has a high s value
40 2016-08-08 21:22:50 <arubi> that means that s > n/2
41 2016-08-08 21:23:50 <p2me> is that something the bitcoin protocol enforces on top of ecc sigs?
42 2016-08-08 21:23:58 <p2me> or is this lib just generating bullshit sigs?
43 2016-08-08 21:24:01 <arubi> yes.  this S will work : 7A0933993A4661A6FD65B039C11BC764C2767D49E95BB3D150F0B519A44A6C9D
44 2016-08-08 21:24:16 <arubi> so if you replace that with the one on the first sig, it will be valid
45 2016-08-08 21:24:48 <arubi> p2me, that lib doesn't do the final check of 'if ( s > n/2 ) return s % n;
46 2016-08-08 21:28:56 <arubi> er, not s % n.. sorry, (-s) % n or (n - s)
47 2016-08-08 21:30:08 <p2me> ok, that makes more sense
48 2016-08-08 21:30:29 <p2me> would i ever have to go back and choose a new nonce?
49 2016-08-08 21:30:46 <arubi> you can just change s like I said there ^
50 2016-08-08 21:30:48 <p2me> or any nonce is fine so long as i perform that check?
51 2016-08-08 21:31:02 <arubi> p2me, you shouldn't be using just any nonce anyway
52 2016-08-08 21:31:11 <arubi> you should be using rfc6979 to generate nonces
53 2016-08-08 21:32:53 <p2me> i understand nonces must be random, rfc6979 is a specific RNG or?
54 2016-08-08 21:34:01 <arubi> yes, it's deterministic.  folks lost bitcoin from nonce reuse, so generating a single nonce per message is safer
55 2016-08-08 21:48:16 <p2me> hmm, still getting bad sigs. is it as simple as a 1-liner "s = (s>n/2)?n-s:s" or should i just trash this lib? ECC math is something i know very little about
56 2016-08-08 22:11:28 <jl2012> arubi: segwit scripts look random but are valid scripts
57 2016-08-08 22:12:14 <jl2012> You may have invalid scripts, for example, one with OP_RETURN