< promag> an alternative to force the build is to redeliver the webhook, however there's no official API for this. But I think it should be possible by using GET https://github.com/hooks/$HOOK_ID/deliveries and POST https://github.com/hooks/$HOOK_ID/deliveries/$DELIVERY_ID/redeliver with the right headers
< bitcoin-git> [bitcoin] dongcarl opened pull request #15978: .gitignore: Don't ignore depends patches (master...2019-05-no-ignore-depends-patches) https://github.com/bitcoin/bitcoin/pull/15978
< luke-jr> achow101: the travis restart thing won't?
< achow101> restarting a job will just use the same commit for that job
< achow101> you'd need to trigger a new build for the pr, which isn't possible at least from the web ui
< luke-jr> what if we modify our travis scripts to fetch master explicitly?
< gmaxwell> luke-jr: re your list post, "If that is inacceptable, pick as internal key a point with unknown discrete logarithm." there is no reason your forced to have a everyone agress bypass.
< tryphe> i noticed there's not a lot of usage of 'const' in a lot of bitcoin code where there could be. is this for readability purposes, or are changes welcome?
< sipa> tryphe: we reject patches that only improve coding stylr
< sipa> *style
< tryphe> sipa, i was thinking of an improvement like so: say you pass a pointer to a thread, and you expect the pointer to be accessed non-const but the address value to not be modified. now you could enforce that with coverage tests and stuff.
< tryphe> gah, thread/function*
< tryphe> whereas if you don't enforce it, you won't know if you accidentally modified a value
< sipa> yes, improving that is great, but it is very low priority noise compared to other potential changes
< sipa> and review time is limited and precious
< tryphe> true, but in terms of undefined behavior i think it could be helpful
< gwillen> adding "const" feels like it should be slightly different from "mere style" changes, since it's functional rather than aesthetic, and any instance the compiler accepts is almost surely correct
< gwillen> (so review effort ought to be limited)
< sipa> if you actually find an issue, for example by adding const where you expect it to work and it doesn't, it is different
< tryphe> (i realized it's impractical to change this though, there's a crapload of changes that would need be done to enforce this example above)
< gwillen> *nods*
< sipa> but adding const in places where the code already works has no effect except add assurances
< tryphe> alright, that makes sense. i guess there's enough tests anyways to catch most issues.
< gmaxwell> you can also introduce bugs by peppering around const, so it's not like those changes are free to review, even ignoring the effect on change flow.
< sipa> in general adding const can't have too much effect if the code works both before and after... but there are some
< sipa> for example moving a const argument will silently introduce a (deep) copy of certain objects, where a move was expected
< tryphe> yeah, the problem is knowing the intent of the code you are modifying
< sipa> tryphe: exactly!
< sipa> adding such things where they are intended is great, but adding them mechanically is mostly useless without careful review of every individual case
< gmaxwell> That is also a general problem with broad 'cleanup' changes, they're done without much understanding or care about the code they're changing.
< tryphe> one good reason i like to do it, though, is because i get a compiler error when i try to modify something that wasn't intended by the programmer. it's easy for someone to... misuse the code i guess is a better way to put it.
< tryphe> sorta like using nullptr instead of 0, you state the intention of the usage for future programmers to reference, instead of relying on them to make a good guess, hehe
< tryphe> good/correct*
< bitcoin-git> [bitcoin] Bushstar opened pull request #15979: Replace incorrectly named comment with func (master...replace-with-func) https://github.com/bitcoin/bitcoin/pull/15979
< bitcoin-git> [bitcoin] Bushstar opened pull request #15981: Use __func__ for log messages (master...replace-all-with-func) https://github.com/bitcoin/bitcoin/pull/15981
< bitcoin-git> [bitcoin] meshcollider pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/b2a6b0216192...ef802ef5d694
< bitcoin-git> bitcoin/master 4f65af9 Hennadii Stepanov: Remove dead code for walletFile check
< bitcoin-git> bitcoin/master a0a222e Hennadii Stepanov: Replace deprecated Boost Filesystem function
< bitcoin-git> bitcoin/master ef802ef MeshCollider: Merge #15880: utils and libraries: Replace deprecated Boost Filesystem fun...
< bitcoin-git> [bitcoin] meshcollider merged pull request #15880: utils and libraries: Replace deprecated Boost Filesystem functions (master...20190423-boost-coding-guidelines) https://github.com/bitcoin/bitcoin/pull/15880
< jonasschnelli> #15512 is waiting on a final review from sipa
< gribble> https://github.com/bitcoin/bitcoin/issues/15512 | Add ChaCha20 encryption option (XOR) by jonasschnelli · Pull Request #15512 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake closed pull request #15979: Replace incorrectly named comment with func (master...replace-with-func) https://github.com/bitcoin/bitcoin/pull/15979
< fanquake> jonasschnelli Could use some more input from you in #15957 when you have a chance.
< gribble> https://github.com/bitcoin/bitcoin/issues/15957 | Show "No wallets available" in open menu instead of nothing by meshcollider · Pull Request #15957 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ef802ef5d694...bbb7119ca835
< bitcoin-git> bitcoin/master a3592c9 Carl Dong: .gitignore: Don't ignore depends patches
< bitcoin-git> bitcoin/master bbb7119 MarcoFalke: Merge #15978: .gitignore: Don't ignore depends patches
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15978: .gitignore: Don't ignore depends patches (master...2019-05-no-ignore-depends-patches) https://github.com/bitcoin/bitcoin/pull/15978
< luke-jr> gmaxwell: how do you prove it's unknown?
< gmaxwell> luke-jr: hash of G is sufficient.
< gmaxwell> or hash of G concatinated with whatever random number you want, if you want per application randomization for privacy (preferable)
< gmaxwell> (it's better to randomize it so that later when you spend third parties can't tell that there wasn't a key-only path)
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bbb7119ca835...49c1aa5f83d0
< bitcoin-git> bitcoin/master 62d50ef practicalswift: Add LOCKS_EXCLUDED(cs_main) to LimitValidationInterfaceQueue(...) which do...
< bitcoin-git> bitcoin/master 49c1aa5 MarcoFalke: Merge #15971: validation: Add compile-time checking for negative locking r...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15971: validation: Add compile-time checking for negative locking requirement in LimitValidationInterfaceQueue (master...negative-locks) https://github.com/bitcoin/bitcoin/pull/15971
< jonasschnelli> fanquake: thanks... I'll have a look at that asap
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/49c1aa5f83d0...c459c5f70176
< bitcoin-git> bitcoin/master 124ea38 Gregory Sanders: change default Python block serialization to witness
< bitcoin-git> bitcoin/master c459c5f MarcoFalke: Merge #15664: change default Python block serialization to witness
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15664: change default Python block serialization to witness (master...default_wit_block) https://github.com/bitcoin/bitcoin/pull/15664
< instagibbs> provoostenator, meshcollider re-review beg of #15452
< gribble> https://github.com/bitcoin/bitcoin/issues/15452 | Replace CScriptID and CKeyID in CTxDestination with dedicated types by instagibbs · Pull Request #15452 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15982: test: Remove True argument to CBlock::serialize (master...1905-testWitnessTrue) https://github.com/bitcoin/bitcoin/pull/15982
< luke-jr> does C++ have a way to say "this method can be called with a const or non-const `this`, but the types yielded by it have the same constness"?
< jb55> can you re-org from genesis in principle? there's nothing preventing that in the code right?
< sipa> genesis is hardcoded, you can't reorg away from the genesis block
< sipa> even if you disable checkpoints
< jb55> I mean from one after genesis
< sipa> yes
< jb55> kk thx
< luke-jr> jb55: checkpoints prevent that, but can be disabled as sipa points out
< phantomcircuit> luke-jr, iirc the checkpoints don't prevent a re-org like that either exactly
< sipa> they do
< sipa> assumevalid does not
< sipa> but checkpoints actually prevent reorging away feom
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15983: build with -fstack-reuse=none (master...1905-buildStackReuseNone) https://github.com/bitcoin/bitcoin/pull/15983
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15959: refactor: Work around gcc compiler bug 90348 (master...1905-gccBugWorkaround) https://github.com/bitcoin/bitcoin/pull/15959
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c459c5f70176...08788ce1701a
< bitcoin-git> bitcoin/master e0bb279 David A. Harding: Doc: remove text about txes always relayed from -whitelist
< bitcoin-git> bitcoin/master 08788ce MarcoFalke: Merge #15890: Doc: remove text about txes always relayed from -whitelist
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15890: Doc: remove text about txes always relayed from -whitelist (master...2019-04-whitelist-help) https://github.com/bitcoin/bitcoin/pull/15890
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15984: net: Remove -whitelistrelay (master...1905-netWhitelistRelay) https://github.com/bitcoin/bitcoin/pull/15984
< bitcoin-git> [bitcoin] sipa opened pull request #15985: Add test for GCC bug 90348 (master...201905_gccbug90348) https://github.com/bitcoin/bitcoin/pull/15985
< MarcoFalke> gmaxwell: Wouldn't the (blocksonly) border node need to accept txs from whitelisted wallets?
< MarcoFalke> Also, if blocksonly is recommended for security or resource conversation, it shouldn't be a hidden debug option
< MarcoFalke> Anyway, I tend to agree with your idea to make whitelisting more specific
< MarcoFalke> But that should probably happen on a per-node basis. E.g. whitelistfortxrelay=${Node_Address}:{Whitelist_Level}
< gmaxwell> It shouldn't be hidden.
< gmaxwell> MarcoFalke: not levels, flags, most things whitelisty things are not ordereable.
< gmaxwell> It's hidden because of historical reasons, I'd forgotten it was. it's frequently recommended.
< MarcoFalke> So that should be changed first, I guess
< gmaxwell> Flags would be pretty awesome.
< bitcoin-git> [bitcoin] sipa opened pull request #15986: Add unmodified-descriptor-with-checksum to getdescriptorinfo (master...201905_justchecksum) https://github.com/bitcoin/bitcoin/pull/15986
< bitcoin-git> [bitcoin] luke-jr opened pull request #15987: Wallet, GUI: Warn when sending to already-used Bitcoin addresses (also RPC: include such information in getaddressinfo) (master...wallet_no_reuse) https://github.com/bitcoin/bitcoin/pull/15987
< gmaxwell> \O/