< michagogo>
If anyone's around, my rc2 sigs have been up since Friday
< michagogo>
They're in the PR that cfields closed... I should really change my script to comment if there's already a PR
< luke-jr_>
gmaxwell: is there any crypto/security problem if we were to use SHA256(witness script) rather than SHA256d(witness script) for anything? (thinking P2SH^2..)
< sipa>
luke-jr_: you mean the other way around, i guess
< luke-jr_>
sipa: no, I mean to use SHA256(program) in the "address" (or equivalent) rather than SHA256d(program) which is fixed on the consensus protocol
< luke-jr_>
oh great, looks like AT&T is going to spam me with "malware infection" emails every day I run my Bitcoin node.
< luke-jr_>
and trying to reply bounces because their RBL is apparently incompetent as well
< GitHub55>
[bitcoin] MarcoFalke opened pull request #7853: [qa] py2: Unfiddle strings into bytes explicitly (master...Mf1604-qaBytes) https://github.com/bitcoin/bitcoin/pull/7853
< Chris_Stewart_5>
Can some one explain to me why we can sometimes have 5 byte numbers in Script? When is it ok to have numbers larger than 4 bytes?
< Chris_Stewart_5>
The context I'm looking at is this test case in script_valid.json
< Chris_Stewart_5>
"2147483647", "1ADD 2147483648 EQUAL", "P2SH,STRICTENC", "We can do math on 4-byte integers, and compare 5-byte ones"
< sipa>
the (historically defined) rules are that arithmetic operators don't accept inputs larger than 4 bytes
< sipa>
but adding 2 4-byte integers together may result in one that takes 5 bytes to represent
< sipa>
and stack elements are only restricted to 520 bytes
< sipa>
so while you can't feed the output of such an addition to another addition for example, you can feed it to other operators that don't interpret it as a number
< Chris_Stewart_5>
Hmm so basically no arithmetic operation accepts a number > 4 bytes?
< sipa>
indeed
< GitHub139>
[bitcoin] sipa opened pull request #7854: [0.12 backport] Various script_tests improvements from master and #7818 (0.12...refactorscriptests_12) https://github.com/bitcoin/bitcoin/pull/7854
< Chris_Stewart_5>
sipa: Does that pull request force the script tests to make sure it failed with the correct error?
< Chris_Stewart_5>
also what is the reasoning behind combing script_valid & script_invalid? From a outsiders perspective it is much easier to figure what is going on having two individual files
< Chris_Stewart_5>
combining*
< sipa>
Chris_Stewart_5: i disagree
< sipa>
almost all tests are doing two nearly identical tests, but with one slight change, where one succeeds and one fails
< sipa>
the interesting part is knowing what makes it succeed or fail
< sipa>
having to look at two different files makes this completely nonobvious
< Chris_Stewart_5>
Actually yeah the more I look at it you are right. Really like the specific script errors.
< michagogo>
cfields_: is there any *downside* to having a set of rc1 in there too?
< michagogo>
Now I need to massage my tree and reset and stuff :-(
< michagogo>
(And force-push etc)
< michagogo>
(To avoid breaking anything my scripts all use --ff-only)
< btcdrak>
michagogo: no, the rc failed, there is zero point building it.
< michagogo>
btcdrak: I get that
< michagogo>
But given that the sigs exist…
< michagogo>
I don't see a significant downside to pulling them in anyway
< michagogo>
OTOH this way forces me to fetch, reset, force push, etc