< gmaxwell>
And this is an extension to the former that allows for mutual autentication while keeping the client identity private: https://people.xiph.org/~greg/auth1.txt This is useful because it would protect against a shared server tracking clients (e.g. observing what they broadcast), but still allow the client to authenticate for elevated service.
< gmaxwell>
An example application where this would be important, is if clients paid a server for a priority access account. (more bandwidth, protection against DOS limits).. it would be unfortunate if the existance of such a service compromised the users privacy by giving them a persistant identity that the server could track them with. I don't think it's something we'd implement right away, but it shows
< gmaxwell>
how our channel authentication could be extended.
< jonasschnelli>
gmaxwell: Nice! Will try to fully understand it now...
< GitHub111>
[bitcoin] paveljanik opened pull request #7810: Refactor AlertNotifyOnce out of UpdateTip (master...20160405_AlertNotifyOnce) https://github.com/bitcoin/bitcoin/pull/7810
< jonasschnelli>
I guess if i change this i need to update all static test data.
< wumpus>
apparently I didn't really know what pretty print arguments to use
< jonasschnelli>
heh. Yes. I was also not sure.
< wumpus>
no, I don't think you need to do that
< wumpus>
I probably fixed the excessive indent by hand last time
< sipa>
wumpus: i'm making some changes, and fixing it
< jonasschnelli>
sipa: thanks!
< wumpus>
this was less work than manually formatting the json from everything on one line
< wumpus>
but stil not ideal no
< wumpus>
sipa: ok great!
< * jonasschnelli>
is heading back to GUI RBF
< sipa>
wumpus: any objections to merging the valid and invalid script tests into one file?
< sipa>
it's annoying for generating, and makes the tests less clear
< wumpus>
sipa: I haven't; though you could consider it an interface change, as it's used by other projects
< jonasschnelli>
sipa: I think you should use write(1) (1 whitespace ident) and only use write(1, X) if you want to insert a sublevel at level x
< wumpus>
and it makes it harder to backport/forward-port tests
< wumpus>
so I'm not sure
< wumpus>
I did consider the same at some point
< sipa>
wumpus: well, i'm working on segwit tests, and i have no intention of manually writing everything for both master and backports
< sipa>
so that would also mean backporting that merging
< btcdrak>
wumpus: no thanks!
< wumpus>
okay
< btcdrak>
kinlo: yes, it's only one way though, so you can read on the Bitcoin Core Slack
< kinlo>
as long as this is the only official channel and we don't actually use slack it's all ok
< sipa>
wumpus: and for segwit, an interface change is inevitable, as we'll need to add a witness field
< wumpus>
sipa: I agree
< wumpus>
sipa: that's a good excuse, go ahead :)
< wumpus>
kinlo: I'm not sure how happy I really am about it. I mean, in principe everything here is public, but on the other hand non-technical people will put everything under a magnifying glass and are bound to misinterpret things
< btcdrak>
wumpus: no thanks!
< wumpus>
this happened before a while ago though i don't remember the specific instance, oh yeah some commit that bumped the version to 0.12.1 on the 0.12 branch was misinterpreted as '0.12.1 tagged!'
< GitHub91>
bitcoin/master 92107d5 mruddy: RPC: add versionHex in getblock and getblockheader JSON results; expand data in getblockchaininfo bip9_softforks field.
< GitHub91>
bitcoin/master 916b15a Wladimir J. van der Laan: Merge #7774: RPC: add versionHex in getblock and getblockheader JSON results...
< GitHub102>
[bitcoin] laanwj closed pull request #7774: RPC: add versionHex in getblock and getblockheader JSON results (master...hexver) https://github.com/bitcoin/bitcoin/pull/7774
< GitHub31>
bitcoin/master 0087f26 Pavel Janík: Use relative paths instead of absolute paths
< GitHub31>
bitcoin/master 4dc1b3a Wladimir J. van der Laan: Merge #7788: Use relative paths instead of absolute paths in protoc calls...
< GitHub118>
[bitcoin] laanwj closed pull request #7788: Use relative paths instead of absolute paths in protoc calls (master...20160402_protoc_use_relpath) https://github.com/bitcoin/bitcoin/pull/7788
< Chris_Stewart_5>
sipa: interesting. I didn't realize that limitation was there. I thought you think of the scriptSig & scriptPubKey as one big concatenated list when you were running it through the interpreter.
< sipa>
Chris_Stewart_5: yes
< sipa>
Chris_Stewart_5: but the scriptSig here contains an opcode that says "The next 1 byte is to be pushed: ", and then no more bytes
< sipa>
which is obviously invalid
< sipa>
it's like an unterminated quotation mark, or a missing endif
< sipa>
Chris_Stewart_5: typically you want negative tests that specify the weakest condition under which failure is expected
< Chris_Stewart_5>
sipa: If it was evaluated at as one big concatenated list though the next byte could be in the scriptPubKey. Where does the validation fail in bitcoin core?
< sipa>
Chris_Stewart_5: that changed in early 2010
< sipa>
Chris_Stewart_5: scriptPubKey and scriptSig are evaluated separately
< Chris_Stewart_5>
haha just realized that :-)
< Chris_Stewart_5>
stack state is shared between the two, is there a reason this is done? Is it one of those things "Its always been done this way so we are going to keep doing it that way" or is there more reason to it
< sipa>
Chris_Stewart_5: that's how the scriptSig communicates its resulting stack to the scriptPubKey
< sipa>
Chris_Stewart_5: what alternative would you suggest?
< Chris_Stewart_5>
concatenate the scriptSig ++ scriptPubKey together and run the entire thing through the interpreter instead of mamking two calls to EvalScript and maintaing stack state
< sipa>
that's how Bitcoin was in 2009, and it had massive security risks
< sipa>
as the scriptSig is under control of the attacker
< sipa>
say your scriptPubKey is 47 bytes, you'd just make a scriptSig 0x3F (which means "push the next 47 bytes onto the stack"), and the result would be accepted
< sipa>
as it would treat the whole scriptPubKey that's concatenated after it as data being pushed, rather than code
< instagibbs>
sipa, ok now that section of code makes sense
< Chris_Stewart_5>
sipa: Wow that is a great way to explain it. So basically that would allow the script to trivially succeed since the scriptPubKey != OP_0 || OP_FALSE right?
< sipa>
Chris_Stewart_5: furthermore, changing it back to that model of execution would almost by definition be a hard fork
< sipa>
because if it has any effect at all, it's going to turn invalid things into valid things
< Chris_Stewart_5>
sipa: Ok. Thanks for the explanation. I appreciate it
< gmaxwell>
"errors": "WARNING: check your network connection, 5 blocks received in the last 4 hours (24 expected)"
< gmaxwell>
of course I dunno when that triggered, though I don't think that host has had any network outages.
< wumpus>
that's the one we disabled on 0.12 right?
< gmaxwell>
yep.
< cfields_>
wumpus: have you looked into the spurious (possible) race condition that we're hitting on travis sometimes? I'm going to poke at it now, curious if you have anything to go on