< bitcoin-git> [bitcoin] fanquake opened pull request #11541: Build: Fix Automake warnings when running autogen.sh (master...fix-automake-warnings) https://github.com/bitcoin/bitcoin/pull/11541
< bitcoin-git> [bitcoin] fanquake closed pull request #11013: Build: Fix Automake warnings when running autogen.sh (master...override_gzip_env) https://github.com/bitcoin/bitcoin/pull/11013
< bitcoin-git> [bitcoin] laanwj closed pull request #11428: Better understandable text for sending transaction option "Request Replace-By-Fee" (master...master) https://github.com/bitcoin/bitcoin/pull/11428
< bitcoin-git> [bitcoin] lyrra opened pull request #11542: freebsd 11.1 g++7 build (master...freebsd-11) https://github.com/bitcoin/bitcoin/pull/11542
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ff92fbf24739...e668a6e61d4f
< bitcoin-git> bitcoin/master d23be30 Matt Corallo: [verify-commits] Allow revoked keys to expire
< bitcoin-git> bitcoin/master e668a6e Wladimir J. van der Laan: Merge #11539: [verify-commits] Allow revoked keys to expire...
< bitcoin-git> [bitcoin] laanwj closed pull request #11539: [verify-commits] Allow revoked keys to expire (master...2017-10-verify-regsig-expsig) https://github.com/bitcoin/bitcoin/pull/11539
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/e668a6e61d4f...c0e513941398
< bitcoin-git> bitcoin/master ce8cd7a Suhas Daftuar: Don't process unrequested, low-work blocks...
< bitcoin-git> bitcoin/master 08fd822 Suhas Daftuar: qa: add test for minchainwork use in acceptblock
< bitcoin-git> bitcoin/master 01b52ce Suhas Daftuar: Add comment explaining forced processing of compact blocks
< bitcoin-git> [bitcoin] laanwj closed pull request #11458: Don't process unrequested, low-work blocks (master...2017-10-blocks-before-minwork) https://github.com/bitcoin/bitcoin/pull/11458
< sdaftuar> cfields: if you have a chance, i could use advice on #11534 -- i needed to write a unit test where i manipulated the nodes in a CConnman, and I didn't know what the right way to do that was.
< gribble> https://github.com/bitcoin/bitcoin/issues/11534 | Evict outbound peers if tip is stale by sdaftuar · Pull Request #11534 · bitcoin/bitcoin · GitHub
< sdaftuar> (so i did something awful in the interim)
< bitcoin-git> [bitcoin] patikkangayon opened pull request #11543: thebitcoinscode (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11543
< jtimon> so, the other day we discussed the size of txs in tests is not deterministic because the size of the signatures may vary with the private key (yuck, but thanks aj again for pointing it out, I was hopelessly reading coin selection code)
< sipa> coin selection is also non-deterministic
< jtimon> would it make sense to publish some private keys in some tests to make those sizes deterministic ? (related to https://github.com/bitcoin/bitcoin/pull/10757 )
< jtimon> sipa: mhmm, right, but I think the txs in https://github.com/bitcoin/bitcoin/pull/10757/files#diff-57972ed7ff896d0805470e4b660ba895 are simple enough that it shouldn't matter, no?
< jtimon> for example, in https://github.com/bitcoin/bitcoin/pull/10757/files#diff-57972ed7ff896d0805470e4b660ba895R126 I'm getting some times 192 and some times 191, it seems like that's due to signatures
< bitcoin-git> [bitcoin] instagibbs opened pull request #11545: Support CMV signing of 17~20 key template (master...20of20) https://github.com/bitcoin/bitcoin/pull/11545
< cfields> sipa: around? I'm finally re-implementing bech32 to learn/test, and there's an inconsistency that's tripping me up.
< sipa> cfields: ok?
< sipa> i'm half here
< cfields> sipa: hmm, ok. Just noticed something. I'll form a solid question, and maybe some percentage of you will still be around :)
< cfields> sipa: the bip shows a test vector of 'A12UEL5L', which i presume to be a hrp of 'A' and empty data....
< cfields> It says "Encoders MUST always output an all lowercase Bech32 string".
< cfields> Confusingly, the c ref returns a failure on an uppercase HRP, but c++ returns an invalid encoding instead.
< cfields> I *think* the c++ ref needs to lc() the hrp input first, but the c ref leads me to believe that encoders should expect the hrp to already be lowercased.
< sipa> cfields: i think someone has ponted out that it's not entirely consistent
< sipa> either we alwaya assume the hrp is already lowercase
< sipa> or lc it
< cfields> well the bip specifies what decoders must not accept mixed case, maybe it would be worth amending to specify that either "encoders must not accept an uppercase hrp", or "encoders must first lowecase the hrp" ?
< cfields> either way, as-is, the c++ ref returns an incorrect encoding for bech32::encode('A', {})
< cfields> I'll open an issue for discussion
< bitcoin-git> [bitcoin] fanquake closed pull request #11543: thebitcoinscode (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11543