< jeremyrubin>
That's the fix for it to work in TestChain100Setup
< jeremyrubin>
(And then a call to GenerateCoinbaseComittment)
< jeremyrubin>
Maybe I should pr that...
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #9920: [0.14] Allow any subkey in verify-commits (BlueMatt) (0.14...Mf1703-verifySubkeys) https://github.com/bitcoin/bitcoin/pull/9920
< wumpus>
would P2P over UNIX sockets be useful? it obviously can't be used for anything like address advertisement, but if you want to set up a local test network (as the tests do) with -connect/-addnode it may make sense
< wumpus>
also maybe Tor hidden services could connect to us over a UNIX socket?
< Tinglysning>
you guys are amazing. have a nice day.
< Tinglysning>
cya :)
< bitcoin-git>
[bitcoin] laanwj opened pull request #9921: build: Probe MSG_DONTWAIT in the same way as MSG_NOSIGNAL (master...2017_03_cloudabi_netcompat) https://github.com/bitcoin/bitcoin/pull/9921
< bitcoin-git>
bitcoin/master fa7da3f MarcoFalke: [contrib] gh-merge: Move second sha512 check to before signing
< bitcoin-git>
bitcoin/master 01b7cda Wladimir J. van der Laan: Merge #9905: [contrib] gh-merge: Move second sha512 check to the end...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9905: [contrib] gh-merge: Move second sha512 check to the end (master...Mf1703-gh-merge) https://github.com/bitcoin/bitcoin/pull/9905
< bitcoin-git>
[bitcoin] laanwj closed pull request #9920: [0.14] Allow any subkey in verify-commits (BlueMatt) (0.14...Mf1703-verifySubkeys) https://github.com/bitcoin/bitcoin/pull/9920
< MarcoFalke>
wumpus: Sorry, I missed that #9884 needs backport as well.
< BlueMatt>
wumpus: see #9880's latest commit which will fix 0.14 verify-commits
< gribble>
https://github.com/bitcoin/bitcoin/issues/9880 | Verify Tree-SHA512s in merge commits, enforce sigs are not SHA1 by TheBlueMatt · Pull Request #9880 · bitcoin/bitcoin · GitHub
< MarcoFalke_lab>
BlueMatt: As the script will now accept different subkeys, you might have to track the which subkey was revoked for revsigs.
< MarcoFalke_lab>
I think the easiest solution is to just revert my pull on 0.14
< BlueMatt>
hmm?
< BlueMatt>
no, gpg knows whats revoked
< BlueMatt>
and gpg prints the same VALIDSIG line whether it was signed by a revoked key or not
< MarcoFalke_lab>
We don't need the commit for 0.14 as only laanwj commits on that branch and his key is all fine
< BlueMatt>
yea, but pieter has merged things on that branch with a subkey that is now revoked?
< BlueMatt>
(same commit as on the master branch)
< MarcoFalke_lab>
Yeah, but that subkey is in trusted keys and all commits are already marked as trusted as well
< MarcoFalke_lab>
We only need that commit if pieter uses a different subkey on 0.14
< BlueMatt>
well we need the revsig checking fix either way
< BlueMatt>
?
< MarcoFalke_lab>
verify-commits in case of a revsig, will only check against the hardcoded keys in trusted-keys
< MarcoFalke_lab>
so if the keys are replaced by the root keys, it will no longer detect the revsig
< MarcoFalke_lab>
BlueMatt: Jup, on master we need the fix at some time
< BlueMatt>
ahh, es, ok, so travis wil pass by not backporting that fix....I mean, sure, but I'd rather fix it so that others can merge on 0.14?
< MarcoFalke_lab>
I don't think there is a need for others to merge on 0.14 right now. Though you are still welcome to fix that until tomorrow :P
< BlueMatt>
MarcoFalke_lab: well the commit i just pushed should fix it
< BlueMatt>
or, it fixes the current failure for me
< wumpus>
ok, going to try that
< wumpus>
cherry-picked that commit to 0.14, looks like verify-commits is taking a very long time
< BlueMatt>
it always does
< wumpus>
ok
< BlueMatt>
hum, failed
< BlueMatt>
wtf
< BlueMatt>
oh, you didnt push yet
< BlueMatt>
heh, nvm
< BlueMatt>
its massively slow with the --tree-checks option after the new pr
< BlueMatt>
because git-cat is slow as fuck cat'ing every file :(
< BlueMatt>
(other option is to do a checkout as you go and then hash, which is faster, but does a checkout in your repo which really sucks)
< gmaxwell>
wumpus: p2p on domain sockets would be useful to avoid port conflicts when running test tnings. oh man, and tor using it would give a nice way of distinguishing tor HS without needing to listen on another port the a user might forget to firewall off.
< gmaxwell>
(I think the biggest argument against having a HS listening port is that the user will not firewall it off and it'll be awful for privacy.)
< wumpus>
BlueMatt: i didn't push yet, was waiting for it to succeed first. But it does: "There is a valid path from HEAD to 82bcf405f6db1d55b684a1f63a4aabad376cdad7 where all commits are signed!", so pushing