< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7db65c363a0c...b6a48914c506
< bitcoin-git> bitcoin/master 6e8c48d practicalswift: Add const to methods that do not modify the object for which it is called
< bitcoin-git> bitcoin/master b6a4891 MarcoFalke: Merge #9964: Add const to methods that do not modify the object for which it is called...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9964: Add const to methods that do not modify the object for which it is called (master...const) https://github.com/bitcoin/bitcoin/pull/9964
< gmaxwell> 0.15 branch has a warning now
< gmaxwell> wallet/wallet.cpp:3668:38: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
< gmaxwell> return setExternalKeyPool.size() >= min_keys && (setInternalKeyPool.size() >= min_keys || !CanSupportFeature(FEATURE_HD_SPLIT));
< gmaxwell> ^
< gmaxwell> wallet/wallet.cpp:3668:80: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
< gmaxwell> return setExternalKeyPool.size() >= min_keys && (setInternalKeyPool.size() >= min_keys || !CanSupportFeature(FEATURE_HD_SPLIT));
< BlueMatt> well we're gonna do an rc2 anyway, for the version issue, right?
< Lightsword> has anyone verified that getentropy is getting built for release builds on osx?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b6a48914c506...655970d9c60a
< bitcoin-git> bitcoin/master 9862550 practicalswift: Use the noexcept specifier (C++11) instead of deprecated throw()
< bitcoin-git> bitcoin/master 655970d MarcoFalke: Merge #10965: Replace deprecated throw() with noexcept specifier (C++11)...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10965: Replace deprecated throw() with noexcept specifier (C++11) (master...noexcept) https://github.com/bitcoin/bitcoin/pull/10965
< jimpo> Is it preferred to have function/method comments in the header files or cpp files? (I would think header?)
< sipa> yes, header
< sipa> unless they're implementation details
< gmaxwell> jimpo: header should comment the interface, cpp the implementation, generally. (I don't think we've documented it in our coding style docs, but it's my preference)
< jimpo> Understood, thx
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/655970d9c60a...a46a671e2535
< bitcoin-git> bitcoin/master 3eb53b8 practicalswift: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git> bitcoin/master a46a671 MarcoFalke: Merge #10957: Avoid returning a BIP9Stats object with uninitialized values...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10957: Avoid returning a BIP9Stats object with uninitialized values (master...bip9status) https://github.com/bitcoin/bitcoin/pull/10957
< bitcoin-git> [bitcoin] jimpo opened pull request #11058: Comments: More comments on functions/globals in standard.h. (master...standard-comments) https://github.com/bitcoin/bitcoin/pull/11058
< bitcoin-git> [bitcoin] Ilikenumber0 opened pull request #11059: Its just for education, not a real pull request (master...master) https://github.com/bitcoin/bitcoin/pull/11059
< bitcoin-git> [bitcoin] sipa closed pull request #11059: Its just for education, not a real pull request (master...master) https://github.com/bitcoin/bitcoin/pull/11059
< wumpus> cfields_: as long as it is deterministic, it is no big deal
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a46a671e2535...d451d0bcf15d
< bitcoin-git> bitcoin/master 844b73e Gregory Sanders: disable jni in builds
< bitcoin-git> bitcoin/master d451d0b Wladimir J. van der Laan: Merge #11056: disable jni in builds...
< bitcoin-git> [bitcoin] laanwj closed pull request #11056: disable jni in builds (master...disablejni) https://github.com/bitcoin/bitcoin/pull/11056
< wumpus> as I had to test binary upload I've already uploaded rc1 to both sites https://bitcoin.org/bin/bitcoin-core-0.15.0/test.rc1/ https://bitcoincore.org/bin/bitcoin-core-0.15.0/test.rc1/ - but we should wait with announcing this publicly until there's at least two more gitian sigs for the code-signed executables
< bitcoin-git> [bitcoin] kallewoof opened pull request #11062: [mempool] Mark mempool import fails that were found in mempool as 'already there' (master...mempool-alreadythere) https://github.com/bitcoin/bitcoin/pull/11062
< fanquake> wumpus I've pushed up signed sigs
< wumpus> fanquake: thanks!
< bitcoin-git> [bitcoin] BitonicEelis opened pull request #11073: Remove dead store in ecdsa_signature_parse_der_lax. (master...deadstore) https://github.com/bitcoin/bitcoin/pull/11073
< bitcoin-git> [bitcoin] BitonicEelis opened pull request #11074: Assert that CWallet::SyncMetaData finds oldest transaction. (master...syncassert) https://github.com/bitcoin/bitcoin/pull/11074
< webuser232> gmaxwell, what do you think about this? https://github.com/bitcoin/bitcoin/issues/11064
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d451d0bcf15d...c484ec6c9b85
< bitcoin-git> bitcoin/master 36d326e practicalswift: Use nullptr instead of zero (0) as the null pointer constant
< bitcoin-git> bitcoin/master c484ec6 MarcoFalke: Merge #10645: Use nullptr (C++11) instead of zero (0) as the null pointer constant...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10645: Use nullptr (C++11) instead of zero (0) as the null pointer constant (master...welcome-nullptr-goodbye-0) https://github.com/bitcoin/bitcoin/pull/10645
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c484ec6c9b85...22e301a3d56d
< bitcoin-git> bitcoin/master a622a17 João Barbosa: Fix constness of ArgsManager methods
< bitcoin-git> bitcoin/master 22e301a MarcoFalke: Merge #10901: Fix constness of ArgsManager methods...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #10901: Fix constness of ArgsManager methods (master...2017-07-args-manager-constness) https://github.com/bitcoin/bitcoin/pull/10901
< bitcoin-git> [bitcoin] practicalswift opened pull request #11076: 0.15 release-note nits: fix redundancy, remove accidental parenthesis & fix range style (0.15...0.15-release-notes) https://github.com/bitcoin/bitcoin/pull/11076
< BlueMatt> morcos: I appreciate that you ask me, but I'm certainly not hip with the ascii art
< bitcoin-git> [bitcoin] jnewbery opened pull request #11077: [tests] fix timeout issues from TestNode (master...test_node_fixes) https://github.com/bitcoin/bitcoin/pull/11077
< morcos> BlueMatt: well it was most relevant what you would interpret that way... :)
< webuser232> wumpus, re your reply over https://github.com/bitcoin/bitcoin/issues/11064 , posting an idea publicly like that usually saves you all the work you listed in case you missed something obvious to begin with
< BlueMatt> alrighty, what should I be reviewing?
< wumpus> I don't think you missed anything obvious, it should absolutely be possible to use "AI" for fee estimation, if you include all possible things that are counted under the buzzword "AI" nowadays
< wumpus> without going into detail about what exactly you want to do, there's no useful responses to give
< webuser232> wumpus, I agree with you mostly. I just wanted to see peoples first/gut/intuitive reaction to the idea proposed, that's all.
< webuser232> jnewbery, thanks for you input!
< sipa> "use AI to solve it!" is not very different from saying "use software to solve it!"
< wumpus> why not use physics to solve it!
< webuser232> sipa, wumpus, very rich. I get it first time. No need to mock.
< wumpus> but yeah, I'm sure the current fee estimation can be classified as AI of some kind already, despite not yet having gained consciousness
< karelb> Hello, nobody replied at #bitcoin, I hope I am not interrupting a meeting again, I will ask here
< karelb> question about bitcoin 0.15.0 ... does estimatesmartfee return the same fees as estimatefee?
< karelb> ignoring the errors and the conservative mode
< promag> morcos: is it relevant to call UpdateMovingAverages while syncing?
< jnewbery> karelb no, it's a new implementation
< karelb> ok
< promag> morcos: there is some performance improvement if not
< karelb> so esttimatefee returns the same fees, estimatesmartfee returns a better estimate
< karelb> great
< morcos> promag: that issue has already been raised.. i think cfields has a proposed fix he is going to PR.. but yeah we should optimize it
< morcos> karelb: estimatefee is deprecated for 0.15. it returns something slightly different than 0.14's estimatefee and likely slightly worse
< morcos> but as close as it could be wihtout a lot of work given the new internals
< morcos> got to run
< jnewbery> webuser232 I happen to think fee estimation might be a good candidate for reinforcement learning, but I'm no expert in AI. Run a bitcoind node for some time to get a good history of transactions/blocks and estimaterawfee should give you good data
< promag> BlueMatt: #11006 it's one line :P
< karelb> hm, that is a bit confusing. We are using the old API in our fee estimates, I hoped we could just upgrade the node without new logic for the new call. OK
< webuser232> jnewbery, I think it's a good candidate too. I'll investigate further. I've got to run for now. Thanks!
< bitcoin-git> [bitcoin] practicalswift opened pull request #11066: Document the preference of nullptr over NULL or (void*)0 (master...document-nullptr-preference) https://github.com/bitcoin/bitcoin/pull/11066
< gribble> https://github.com/bitcoin/bitcoin/issues/11006 | Improve shutdown process by promag · Pull Request #11006 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jnewbery opened pull request #11078: [tests] Make p2p-leaktests.py more robust (master...p2p_leaktests_robust) https://github.com/bitcoin/bitcoin/pull/11078
< BlueMatt> cfields: can you rebase #10756 ?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #11067: [qa] TestNode: Add wait_until_node_stopped helper method (master...Mf1708-qaTestnodeWaitStopHelper) https://github.com/bitcoin/bitcoin/pull/11067
< cfields> BlueMatt: sure
< gribble> https://github.com/bitcoin/bitcoin/issues/10756 | net processing: swap out signals for an interface class by theuni · Pull Request #10756 · bitcoin/bitcoin · GitHub
< BlueMatt> cfields: thnks, gonna take a crack at rebasing on it :)
< BlueMatt> grr, does someone have a fucking openbsd box to test build on?
< wumpus> yes
< wumpus> BlueMatt: I have an openbsd 6.1 box to test on - what do you need tested?
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #11068: [WIP] qa: Replace wait_until with wait_until_mn (scripted) (master...Mf1708-qaWaitUntilMiniNode) https://github.com/bitcoin/bitcoin/pull/11068
< BlueMatt> wumpus: just looks like there's been a few build errors on openbsd recently (I assume 15rc1 testing) eg #11057
< wumpus> ooh the gui on opennsd? I don't think anyone even tried that before, certainly not me
< wumpus> #11057 looks like a conflict between GL driver and libdrm version?
< BlueMatt> possibly? I dunno
< wumpus> nothing we can help in any case
< wumpus> building anything on openbsd is difficult, I can't imagine the nightmare of getting the opengl/X/qt stack to work on that
< BlueMatt> wumpus: have you managed to repro the crashes in bitcoind in #11063?
< BlueMatt> wasnt there a similar one in test_bitcoin, too?
< wumpus> haven't tried yet
< wumpus> last time I ran the tests on openbsd it was all ok, but it's been a few months ago
< BlueMatt> oh, no, it was in bench
< BlueMatt> yea, #10801
< BlueMatt> yea, sounds like openbsd got fucked again :(
< wumpus> (no, shorter ago, this was around the time the asm changes went in)
< BlueMatt> wonder where we can find an openbsd dev to contribute :p
< wumpus> it's funny how gdb is fucked on all BSD
< BlueMatt> yea :/
< wumpus> at least on freebsd it's easy (and encouraged) to install a newer one, but the default one is ancient, from 2004
< wumpus> this means it cannot understand the debug information (DWARF 3) generated by compilers of this decennium
< BlueMatt> so they're taking the debian approach of keeping people on ancient versions of things :(
< wumpus> it has some license-related reason
< wumpus> same reason why the default gcc on openbsd is a patched 4.2, that was the last one before going to GPL3 which is no longer acceptable
< BlueMatt> lol
< BlueMatt> man licensing sucks
< wumpus> would be wiser to go to llvm/clang as that does have a bsd compatible license, FreeBSD did that for many platforms already
< grubles> yeah i think obsd is completely ditching gcc for clang soon
< grubles> i think i read that the other day
< wumpus> finally!
< wumpus> (oh, FreeBSD already switched to clang a while ago, what they're doing now is switching the *linker* to clang's linker)
< wumpus> probably gdb to lldb
< wumpus> 'gmake check' passes on openbsd
< wumpus> bench also runs succesfully
< wumpus> (this is with master, not 0.15 branch, but they have hardly diverged)
< gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] popenkomaksim opened pull request #11069: Trivial: Lossless image optimization. (master...master) https://github.com/bitcoin/bitcoin/pull/11069
< gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
< wumpus> gribble: why are you repeating that?
< sipa> 17:17:57 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj opened pull request #11080: doc: Update build-openbsd for 6.1 (master...2017_08_openbsd_bump) https://github.com/bitcoin/bitcoin/pull/11080
< praxeology> where can I find a spec on how to craft bch transactions? gmaxwell, you said you had/were making a patch?
< praxeology> Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
< arubi> and p2pkh\p2sh instead of p2wpkh\p2wpsh
< arubi> p2wsh*
< cfields> morcos: ping
< luke-jr> praxeology: it's just Segwit's signature format, with the extra bit set in the sighash flags
< cfields> morcos: while profiling some new net code yesterday, i noticed that TxConfirmStats::UpdateMovingAverages is a notable hotspot
< wumpus> praxeology: this patch adds ALL|ABC support to signrawtransaction: https://github.com/laanwj/bitcoin/commit/22a4c47643203f86e03f4b001e776fcff1fe8d92
< cfields> during IBD, it accounted for ~5-10% of the message handler thread
< wumpus> it's not mine, has been floating around for a while - and I guess it's strongly off topic here
< cfields> cpu usage, that is
< sipa> i think it's mine :)
< wumpus> sipa: I wasn't sure whether you wanted credit for it lol
< praxeology> wumpus: at least I'm not interrupting a meeting this time :p
< sipa> praxeology: off by 23 minutes
< praxeology> ... So if I run core w/ that patch... I can sign my bch over to shapeshift.io for example?
< wumpus> yes, that works. Do run it with -nolisten -noconnect to avoid bch transactions from getting into your mempool.
< sipa> cfields: during IBD? :o
< cfields> sipa: that was my thought :\
< praxeology> I'll be running it on an airgapped computer
< wumpus> you can use https://github.com/laanwj/bitcoin-submittx to submit the signed transaction to a list of BCH nodes
< cfields> IBD up to 200k blocks, anyway
< gribble> https://github.com/bitcoin/bitcoin/issues/11063 | bitcoind aborts · Issue #11063 · bitcoin/bitcoin · GitHub
< wumpus> so to be clear that patch won't make it generate BCH transactios by default, you need to run signrawtransaction with 'ALL|ABC' as signature type
< wumpus> gribble: huh?
< BlueMatt> cfields: well, it'll be in the background in 16 :/
< praxeology> alrighty guys... thanks for the help, and the secret private messages so that only I can benefit :p. I think I have a solid plan now
< cfields> BlueMatt: surely it's not necessary until we're nearly caught up?
< sdaftuar> cfields: i'd guess the implementation is probably just trying to make sure that the estimates properly decay when a node is catching up after being down for a while
< cfields> well i have a quick optim to speed up that function, but i figured it'd just result in a discussion about avoiding it during early IBD
< gmaxwell> I assume a simple branch to skip decays when everything is zero would speed that right up.
< cfields> I'll PR the speedup, and create an issue to discuss avoidance
< gmaxwell> sipa: we test too much with reindex chainstate
< cfields> gmaxwell: ah, i was wondering why you hadn't nagged about it :)
< sipa> *DING*
< BlueMatt> sipa: you're an hour early
< wumpus> huuh are you sure you're not an hour early?
< sipa> oops?
< sipa> yes, it was the "warning, meeting in one hour!" alarm </whateverhappenspretenditwasintentional>
< gribble> https://github.com/bitcoin/bitcoin/issues/10801 | bench_bitcoin segfaults · Issue #10801 · bitcoin/bitcoin · GitHub
< sipa> maybe that'll teach gribble
< gribble> https://github.com/bitcoin/bitcoin/issues/11057 | Connection timed out.
< cfields> BlueMatt: rebased
< achow101> wut
< BlueMatt> gmaxwell: well its gonna be slow after sync anyway, so just move it into the background where it wont slow down ibd at all and will be fast later, too :p
< BlueMatt> cfields: thanks
< gmaxwell> BlueMatt: well I agree, but a branch on already zero is perhaps a four line change.
< BlueMatt> sipa: try again now?
<@wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 17 19:00:14 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< sipa> DUNG
< achow101> hi
< Chris_Stewart_5> present
< jtimon> dong
< jonasschnelli> hi
< instagibbs> prezent
<@wumpus> topics?
< cfields> hi
<@wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
< BlueMatt> blockers for review
<@wumpus> let's start with 0.15.0rc1 - have any serious issues been reported?
< BlueMatt> and that
<@wumpus> #topic 0.15.0
< BlueMatt> there's the openbsd stuff, but I'm not sure thats really 0.15 per se, more than just openbsd brokenness
< BlueMatt> there's also the version-reporting thing gmaxwell mentioned
< cfields> only thing i'm aware of is the version number issue, but that's nothing
<@wumpus> that's just openbsd brittleness, I'm looking at it
< achow101> there's the duplicate hex in getrawtransaction
< BlueMatt> plus the new compiler warnings
<@wumpus> cfields: do we have a patch for that?
< sipa> and the other things marked for 0.15... #11044 #11027
< cfields> wumpus: i haven't decided on where to fix it yet. Either way I'll PR something today/tomorrow
<@wumpus> cfields: I guess in a hurry we could just revert luke-jr's patch that introduces the problem, for 0.15
< BlueMatt> gmaxwell: a branch to put it in the background is probably 3 at this point :p
< cfields> wumpus: yes, that was my initial suggestion, but luke-jr isn't a fan
< jonasschnelli> Can you elaborate on the version number issue (via luke-jr's PR)?
<@wumpus> yes I saw the new compiler warnings, something about signed to unsigned comparison in the wallet version logic
<@wumpus> is that something serious?
< cfields> jonasschnelli: the version string doesn't show v0.15.0 as it should, but a git commit instead
<@wumpus> src/wallet/wallet.cpp:3668:38: warning: comparison of integers of different signs: 'std::set<long, std::less<long>, std::allocator<long> >::size_type' (aka 'unsigned long') and 'int' [-Wsign-compare]
< cfields> sec for offending PR
< sipa> suggestion: have travis (which has a deterministic compiler version) in one of the tests run with -Werror... but not for default builds
<@wumpus> and another one on the same line
< BlueMatt> sipa: #10923
< BlueMatt> can someone remind me whats left to switch the sync.h stuff to std::mutex?
< BlueMatt> looks like it may be needed for #10923
< kanzure> hi.
<@wumpus> sipa: yeah, no that we no longer have any annoying warnings such as Wshadow we could do that
< cfields> jonasschnelli: #7522
< jonasschnelli> wumpus: isn't that (-WSign-compare) fixed with #11044?
< sipa> BlueMatt: oops, never read the second part of the title
<@wumpus> jonasschnelli: could be!
< jonasschnelli> It is. Just checked
< BlueMatt> sipa: we already have --enable-werror which is an even more limited set of -W's that we error on, but we never enable it on anything
< gribble> https://github.com/bitcoin/bitcoin/issues/10923 | Use -Wthread-safety-analysis if available (+ -Werror=[…] if --enable-werror) by practicalswift · Pull Request #10923 · bitcoin/bitcoin · GitHub
< BlueMatt> sipa: that pr enables it for thread-safety-analysis and then turns it on on travis-osx
< cfields> sipa: +1. I think 10923 is a great idea
< BlueMatt> 10923 is blocked on switching mutexes and sync.h to std, but I think we can just do that (tm)
< cfields> BlueMatt: not yet :(
<@wumpus> we can just take the travis-werror part
<@wumpus> I don't see how that is strongly related to the thread analysis
< BlueMatt> true
<@wumpus> switching over mutexes and sync definitely sounds like a post-0.15 thing
< cfields> yea, we should just go ahead with that and add the thread checking when it's ready
< BlueMatt> cfields: oh? none of that stuff is used directly in the remaining threadGroup threads
< BlueMatt> oh, y'all want to turn on -Werror on travis for 15? yea, ok, not that then
< BlueMatt> anyway, looks like #11044 fixes the warnings, and its already tagged 0.15.0
< cfields> oh, i thought we were talking about it for master
<@wumpus> the topic is 0.15 so I was assuming we were talking about 0.15
< jonasschnelli> cfields: I have a correct version string in 0.15.0rc1 (Qt, debug log). What do I miss?
<@wumpus> anyhow, I don't mind, let's enable it for some branch...
< cfields> BlueMatt: i'll double-check. But I thought we had some outstanding condvars that we couldn't switch yet. Will look after meeting.
<@wumpus> master is what the PRs will be tested against so that makes most sense I suppose
< BlueMatt> cfields: we do, but they're directly calling boost::condition_variable, not CConditionVariable, I believe
< gmaxwell> We can turn of travis Werroring if it turns out to be a pain (or even when not if...) but gain advantages from it until then.
<@wumpus> ok: does anything need tagging for 0.15.0?
< cfields> jonasschnelli: the splash screen, at least, shows the git revision
< BlueMatt> as for 0.15, I think its jsut the 3 tags + whatever for the version string issue
< BlueMatt> or, nothing else was brought up
< gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
< jonasschnelli> cfields: Ah. I see now.. releases don't have the commit&dirty.. nm
<@wumpus> okay
<@wumpus> #topic high-priority for review
< * BlueMatt> puts #10286 on the list
<@wumpus> now that 0.15 is branched, we can start doing this again
<@wumpus> added
< * jonasschnelli> puts Implement BIP159 / #10387 on the list
< sipa> i'd like to draw some attention to #10785 (serialization improvements)
< BlueMatt> thats ok, 10286 needs to simmer on master for a month or three, so it is actually a should-go-soon, thing
< BlueMatt> :p
< gribble> https://github.com/bitcoin/bitcoin/issues/11027 | [RPC] Only return hex field once in getrawtransaction by achow101 · Pull Request #11027 · bitcoin/bitcoin · GitHub
< jonasschnelli> sipa: It's on my list.. reviewed most of it and running on my node
< gmaxwell> lol poor gribble.
< gmaxwell> (he's way behind)
< cfields> I'd like to add #10756 please, as lots of things for 0.16 will build on top of that
< jonasschnelli> (gribble probably needs to process all the spam first)
<@wumpus> gribble damnit you made me add 11027, which makes no sense as it's already tagged 0.15
< jonasschnelli> cfields. done
< cfields> (that's the signals -> interface class switch for message processing)
< sipa> cfields: ack
< BlueMatt> yes! 10756!
< cfields> jonasschnelli: thanks
< gribble> https://github.com/bitcoin/bitcoin/issues/10923 | Use -Wthread-safety-analysis if available (+ -Werror=[…] if --enable-werror) by practicalswift · Pull Request #10923 · bitcoin/bitcoin · GitHub
< * gmaxwell> can't breathe
< jtimon> I would suggest #8498 but not sure if it can be high priority
< BlueMatt> poor gribble
<@wumpus> aww :)
< jonasschnelli> :)
< cfields> haha
< gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
<@wumpus> jtimon: added
< jtimon> cool
<@wumpus> ok, any other topics?
< jonasschnelli> short topic: adding bench to gitian build package?
< jonasschnelli> I can PR
< cfields> wasn't it just explicitly removed? :)
< jonasschnelli> Yes. At least on Win
< * jonasschnelli> searching PR
< gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
< achow101> +
<@wumpus> #topic adding bench to gitian build package
< jonasschnelli> I stumbled over it when wanted to bench sse4
<@wumpus> I removed it because it was useless at the time, bench had only the examle benchmark
< gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
<@wumpus> but now that bench is actually useful I agree with enabling it for the distributions, for all platforms
< jonasschnelli> I think its useful now.
< jonasschnelli> I'll PR that then
< gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
< jtimon> suggested topic, what do we want to do about configs for different chains? related to issue #9374 and prs #10267 #8994
< gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
<@wumpus> jonasschnelli: thanks
< gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Connection reset by peer.
< sipa> do we want to discuss bip159 more?
<@wumpus> jonasschnelli: no rush, we don't really need it in 0.15 yet
< gribble> https://github.com/bitcoin/bitcoin/issues/10756 | Connection reset by peer.
< jonasschnelli> Yes. Certenly not for 0.15
< luke-jr> sorry, here
<@wumpus> #topic bip159: (NODE_NETWORK_LIMITED service bits)
< jonasschnelli> last updates on BIP159: threat bits independently, fingerprinting protection
< luke-jr> ‎[19:03:38] ‎<‎wumpus‎>‎ cfields: I guess in a hurry we could just revert luke-jr's patch that introduces the problem, for 0.15 <-- it fixes other (more real) problems
< jonasschnelli> The address relay and whole peering maybe needs discussion
< jonasschnelli> cfields mentioned once some potential issues
< sipa> so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
<@wumpus> luke-jr: ok, well, can you help cfields fixing the problem then?
< luke-jr> wumpus: yes, already suggested a few ideas
< sipa> that gets 90% of the benefit I believe (nodes who are already caught up, and want to stay caught up)
< sipa> without needing to know what other ranges are important
< cfields> jonasschnelli: yea, i'll jot down my concerns.
< jonasschnelli> sipa: we could start with that. What's you concerns about definig two bots?
< jonasschnelli> bits?
< sipa> jonasschnelli: i'm beginning to think a second bit is just unnecessary for now
< sipa> and we may be able to make a more informed choice later
< instagibbs> sipa, prefer the week or day?
< sipa> day
< gmaxwell> It's also the case that the second bit doesn't really jive with UTXO sync, so it may just end up totally surpflous within a couple months.
< jonasschnelli> I think the week usecase can be interesting with SPV (client side)
< gmaxwell> the 288 matches the current minimum.
< jonasschnelli> You could run a pruned peer while syncing your phone
< jonasschnelli> (in an ideal BIP150 world)
< jonasschnelli> (or via tor)
< gmaxwell> sure, so long as you don't ever forget to run your wallet once a week. :)
< gmaxwell> you can still do that without the flag however.
< sipa> the most important benefit is that pruned nodes can and should help with partition resistence of the network, but they currently don't
< gmaxwell> as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
< jonasschnelli> I agree. I think defining only the 288 depth bit is okay. We can define another later.
< gmaxwell> sipa: well they do a littl.
< gmaxwell> jonasschnelli: yea, that was my thought. Now quick, slip it into 0.15rc2 _me ducks and runs_
< jonasschnelli> gmaxwell: good point about the whitepeer, right
< jonasschnelli> gmaxwell: No 0.15. Sadly
< sipa> jonasschnelli: i believe gmaxwell may not have been very serious ;)
< gmaxwell> I'm kidding. :)
< jonasschnelli> No joking about releases. :)
< gmaxwell> If we cannot laugh all there is left to do is cry.
< gmaxwell> :)
<@wumpus> exactly
< * sipa> mourns the untimely passing of rc1
< jonasschnelli> Indeed
< jonasschnelli> Any other thoughts on dropping the 1'152 dept NODE_NETWORK_LIMITED_HIGH flag?
< gmaxwell> that gets rid of anything to be debated.
< jonasschnelli> A single flag was also my original idea.. but we had then discussions and the second one came up. So going back to a single bit is fine for me.
<@wumpus> yes, let's drop it for now
< bitcoin-git> [bitcoin] practicalswift opened pull request #11071: Use static_assert(…, …) instead of assert(…) where appropriate (master...static_assert) https://github.com/bitcoin/bitcoin/pull/11071
<@wumpus> it's better to continue with something; the bits debate goes on and on :)
< gmaxwell> smaller changes faster plz.
< cfields> 3 bits!
< jonasschnelli> Heh. Right... okay, will update the bip and the PR.
< * jonasschnelli> curses cfields
< cfields> :)
<@wumpus> cfields: moar!
< sipa> 3.14 bits!
< jonasschnelli> hehe
< gmaxwell> next subject?
< cfields> sipa: that's just irrational.
< jnewbery> sipa gmaxwell do you have data about what blocks are requested on the network? Have you shared it anywhere?
< gmaxwell> damn, I almost saved us from that pun.
< gmaxwell> jnewbery: we do, we have, I can dig it up again later today.
< jonasschnelli> jnewbery: sipa has that blocks-requested-chart
<@wumpus> #topic what do we want to do about configs for different chains (jtimon)
< jnewbery> thanks
< gmaxwell> jtimon: 12:35:36 <@wumpus> #topic what do we want to do about configs for different chains (jtimon)
< achow101> pr/issue for reference?
< gmaxwell> there was an overlay config file PR I saw, I like that general idea.
<@wumpus> related to issue #9374 and prs #10267 #8994
< morcos> cfields: hmm... that's somewhat surprising, but yes i guess if all the other operations are basically very quick with the early blocks, that one takes just as long
< morcos> i'd be happy to look at your speedup
< jtimon> sorry, I just fell
< jtimon> so jnewbery had some suggestions for #8994 https://github.com/bitcoin/bitcoin/pull/8994#issuecomment-321355349
< jtimon> #10267 is slightly related
< jtimon> and there's the issue #9374
< morcos> i think we could also do something relatively simple to avoid doing it if blocks are less than some reasonable checkpointed height or something
< BlueMatt> <gribble> https://github.com/bitcoin/bitcoin/issues/10267 | INew -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
<@wumpus> not much to discuss from my side really, I think the idea of additional per-chain config files is good
< sipa> we know but one gribble, and his name is BlueMatt
<@wumpus> need to review the PRs
<@wumpus> also we really need test for initialization order / argument precedence stuff
<@wumpus> as it becomes more complex with this
< gmaxwell> The Gribble is dead, long live the Gribble.
< jtimon> network.conf idea seems good to me, perhaps I could the something similar for /chain.conf, but not sure about jnewbery's suggestion because that would allow them to be used with the mainnet
< gmaxwell> okay, so comment on PRs?
< jtimon> well, I guess it can be discussed on the prs, yeah
< jtimon> just poiting out the 3 things seem related to me
<@wumpus> yes
< luke-jr> wumpus: bitcoin_rw.conf solves per-chain at the same time, so IMO the approach to take there
<@wumpus> luke-jr: that's a different issue
<@wumpus> luke-jr: let's not blur everything together now jsut because jtimon started off with a whole list...
<@wumpus> any other topics?
< gmaxwell> yea.. I want to talk about the impersonation issues and comms stuff for a moment.
< jnewbery> I don't think that #10996 (per network configuration) and #10267 (additional config file) should be held up on #8994 (custom chains)
<@wumpus> jnewbery: no, I don't think so either
<@wumpus> #topic impersonation issues and comms stuff
< gmaxwell> Kind of OT for the normal material here; but everyone should be aware that the developer of S2X is going around
< gmaxwell> spreading misinformation about S2X describing it as a harmless "upgrade" to bitcoin, misstating that things like
< gmaxwell> classic and BU are compatible (though they don't even implement segwit), and not making any mention of the serious
< gmaxwell> issues like its lack of replay protection, no HF bit, lack of a spec, this is especially bad because there have
< gmaxwell> been a bunch of efforts to impersonate our project supporting this stuff:
< gmaxwell> https://twitter.com/bcoreproject/status/897966294083018760 (click internal link for the S2X stuff)
< gmaxwell> I'm not sure of what to do but it appears to be a widescale effort to misinform people. :(
< gmaxwell> In the past twitter hasn't done much with people impersonating me, and this is happening on more than twitter.
< sipa> :(
<@wumpus> yea :/
< BlueMatt> I'm not sure what can be done about it, sadly, either, aside from everyone spending some time vigorously condemning such blatant fraud and reaching out to corners of the community to point this out
< gmaxwell> E.g. seen it on reddit and hacker news; and our community links people to https://en.bitcoin.it/wiki/Segwit_support but then gets trolls responding that its "fake" and "censored by theymos"
< achow101> for twitter impersonation, you can report it to twitter and they might do something about it
< luke-jr> maybe a bitcoincore.org blog explicitly rejecting 2X and warning people of the misinformation campaigns?
<@wumpus> right, I'm not sure what recourse there is, fake news everywhere on the internet
< gmaxwell> achow101: I've heard that several project contributors have; so sure; but I wouldn't expect much.
< praxeology> gmaxwell: I saw in #bitcoin someone was saying that bitpay was linking to use btc1 https://blog.bitpay.com/bitcore-segwit-activation/ with "bitcore"
<@wumpus> yes certainly report to sites where the impersonation is hosted
< BlueMatt> luke-jr: if carefully worded, seems fine
<@wumpus> github is quite active with that at least
<@wumpus> twitter usually ignores report unless a lot of people report
< gmaxwell> Right we may need to each be more outspoken personally, and perhaps organize some project things too.
< achow101> I like luke-jr's idea. having something explicitly rejecting s2x would be good
< Murch> I had already reported that account last week, I suggest that others which use twitter do so as well.
< jtimon> jnewbery: agreed, nor the other way around imo
< * luke-jr> notes he personally calls it simply "2X" because he doesn't want to give the impression Segwit is connected to it.
< gmaxwell> luke-jr: I've used S2X, but yea people are confused thinking 2X = 2MB not 4MB (8peak) and other crazy stuff.
< gmaxwell> or thinking that segwit activation means s2x activation.
<@wumpus> luke-jr: yes, I think an explicit post rejecting s2x would be a good idea
< praxeology> didn't help that the slashdot article was wrong, portraying it bcash vs segwit2x
< gmaxwell> I looked a week or two ago and there were under two dozen btc1 nodes after excluding VPSes and only something like 60 including. Non-entity on the network.
< gmaxwell> ironically, BCash seems the more honest and responsible of the two.
< Murch> gmaxwell: And no development activity since "rc2"
< achow101> gmaxwell: unfortunately their doing basically a misinformation campaign to get more people to run btc1
< achow101> e.g. bitpay telling people to use btc1 for segwit
< BlueMatt> ok, so objections to luke-jr's proposal to put something on bitcoincore.org that simply points out that s2x is unrelated to segwit, and a fork of bitcoin, not a "harmless upgrade"?
< gmaxwell> In any case, we're not going to solve it here, but I think we each can make little pushes to better inform people.
< BlueMatt> simple faq/error correction, not political "fuck this thing"
< gmaxwell> BlueMatt: would depend on the text! someone could propose some, maybe harding.
< luke-jr> I'll throw up a draft GDoc people can hack at after the meeting?
< BlueMatt> gmaxwell: yes, of course
< gmaxwell> We can also talk to the bitcoin.org folks in general.
< gmaxwell> luke-jr: It might be a streach for your approach to get something the rest of the contributors would find super agreeable.
< praxeology> How close is bitcoin.org w/ the core dev team? Who runs it?
< gmaxwell> luke-jr: I think you do well staking out your own more extreme position and adding to the discussion that way, though-- so no offense intended.
< Chris_St1> maybe bitcoin.org people can throw up a warning about people promoting consensus imcompatible implementations
< gmaxwell> praxeology: it's run by the bitcoin.org people. They're generally reasonable folks.
< BlueMatt> praxeology: not at all, but we can at least contact them or open github issues since they do put the source on github
< cfields> i think it's important that we point out that this isn't some NIH issue or aversion to change, rather a reaction to a fork that has not only ignored what we've learned from the recent split, but even manages to regress from it
< luke-jr> gmaxwell: maybe someone else can write a draft then?
< sipa> cfields: indeed
< Murch> BlueMatt: Factual statement that the two are unrelated and perhaps a mention of the lack in replay protection
< gmaxwell> cfields: yes, indeed, in the few places where he even responded to concerns it was to claim things were non-issues with bcash when they actually were, and when bcash's better decisions were highly protective.
< BlueMatt> yea, that seems reasonable, just "hey, this is unrelated to Bitcoin Core or Bitcoin, really, they are playing a very, very risky game and most folks dont condone this"
< gmaxwell> In any case, beyond some factual statement... part of the consequence of having the project itself speak less is that each of us in the community sometimes needs to speak more. Otherwise the vacuum is easily filled with fakes and lies.
< gmaxwell> I dunno if everyone has seen morcos' blog posts but they've been fantastic.
<@wumpus> gmaxwell: can you link them please?
<@wumpus> (for the sake of the meeting log)
< gmaxwell> BlueMatt: even just many rather than most (while I don't doubt most is also true, a narrower thing can be said)
< BlueMatt> fair
< BlueMatt> morcos: the height-at-which-0.15-was-released is sufficient, cause your estimates get wiped anyway :p
< Murch> BlueMatt: Yeah, Replay Protection might be a bit over the head for the general audience. It should be mentioned though that it is unrelated to and _not supported by Bitcoin Core_.
< BlueMatt> yea, ^ those are great!
< luke-jr> some open source projects just do blog aggregation
< gmaxwell> it's a fine line to walk, to express the gist without seeming like there isn't substance or alternatively dropping people into the weeds.
< gmaxwell> luke-jr: I'm generally glad that we don't, in that joe-blow who just doesn't get open projects and is looking for an authority won't understand that a blog aggregation isn't an official position.
< Murch> luke-jr: That's why I'm putting it so carefully: "not supported" is easily true. Stating that there is no Core contributors that do support it, is probably hard to check and easily false.
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #11081: Add length check for CExtKey deserialization (master...2017/08/fix_cextkey) https://github.com/bitcoin/bitcoin/pull/11081
<@wumpus> luke-jr: yes, something like https://planet.freedesktop.org/ would be nice, though on the other hand for bitcoin that would result in endless political discussions about who to include and who not
< gmaxwell> In any case, even if you don't have the energy or skills to write your own statements, if you agree with stuff like morcos' you can still link to it and let others know you support it.
< gmaxwell> luke-jr: aka bitcoin press center.
< BlueMatt> wumpus: I think we should include Mr Buckethead! I find his points on Brexit to be rather well-informed.
< luke-jr> :x
< luke-jr> gmaxwell: some people don't know to follow individual developers, though
< sipa> BlueMatt: *Lord* Buckethead please
<@wumpus> lol BlueMatt
< BlueMatt> sipa: oops, sorry
< Murch> luke-jr: That's why a statement coming from Core would be useful. Especially since Core as an entity doesn't usually have a position.
< BlueMatt> if folks agree, @bitcoincoreorg could also r/t morcos' blog posts
<@wumpus> @btcdrak
<@wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 17 20:00:03 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gmaxwell> BlueMatt: I think it would be good, can be done in a way that it's clearly not project stuff.
< BlueMatt> yea, i mean just r/t would still show it as a tweet from morcos
< Murch> BlueMatt: Still would be considered an endorsement
< BlueMatt> Murch: yes, it would be
< BlueMatt> thats on purpose
< BlueMatt> hence my question :)
< instagibbs> Quote Tweet to make it more obvious :P
< luke-jr> not everyone reads Twitter either
< Murch> I think that the position is pretty broadly held here, but if someone disagrees with it, I'm not sure they'd want to speak up.
< gmaxwell> Murch: somewhat, and a failure to counter is implicitly an endorcement of things like https://twitter.com/bcoreproject/status/897966294083018760
< luke-jr> the vaccine to misinformation is truth
< instagibbs> Merely informing users that it's "not just an upgrade" cannot be controversial to anyone on the project
< gmaxwell> Murch: well they should, cause otherwise no one is gonna know.
< Murch> gmaxwell: That needs a response from the actual Bitcoin Core twitter account to condemn it as false flag.
< jnewbery> Murch - I agree. Have misgivings about "Bitcoin Core" endorsing a personal opinion
< gmaxwell> yes, we can condemn the impersonation (that isn't the only one, also)
< Murch> luke-jr: It'll get linked on reddit in no time. And I'm sure that BCT also would get some discussion on something like that.
< luke-jr> "Of the 25 Bitcoin Core developers who have stated a position on 2X, all of them are opposed."
< luke-jr> Murch: bitcoincore.org is important IMO
< Murch> luke-jr: Yeah, that's better.
< instagibbs> the impersonation is break of ToS
< instagibbs> hmm I need a "company email" to report theft of brand
< BlueMatt> instagibbs: I just made it up, they'll figure it out that its not a "company", its an organization
< achow101> instagibbs: it's only impersonation if they don't state that they are a parody account
< instagibbs> achow101, they do not, at least in profile
< achow101> so what usually happens is that they put "parody" in the profile somewhere, and no one actually notices that
< gmaxwell> to be clear, if the S2X posts were "This is a thing we're doing, it's controversial, but we think it's right. Here are the risks and protective steps" I'd disagree but have little to complain about. But the burying the risks, describing it as an upgrade, dovetails perfectly with the troll false flags to pretend that the authors of most of the software they're shipping supports it... it's fra
< instagibbs> that's fine, but they aren't hence ToS :)
< gmaxwell> ud.
< BlueMatt> jnewbery: I'm with gmaxwell, while its always bad to endorse a personal opinion, as far as I know every major and even the vast majority of minor contributors support that view, at which point if you want the org to not endorse it, you should speak up
< gmaxwell> I think we can make things clear that they're personal opinions. Yes, it's something thats fraught with problems. But other than the meta issues, is there anyone who actually disagrees with Morcos on the whole whos a regular contributor, much less disagrees with sharing it? I think the answer is no.
< luke-jr> I think we're fine endorsing a "personal opinion" in cases where as-far-as-we-know all developers are of the same opinion..
< gmaxwell> We do have to make a balance, and I think the sucess of the misinformation has been high enough to indicate that we're strking the balance a little too far to one sid.
< BlueMatt> can also just quote tweet and say like "Some thoughts on 2x, from a major contributor to Bitcoin Core"
< jnewbery> ok, I'll speak up. I think there's a difference between condemning impersonation and misinformation (which we should definitely do) and endorsing someone's opionion (which is a road I think we shouldn't go down)
< jnewbery> BlueMatt - I think that's better
< gmaxwell> luke-jr: well I'm sure we don't all agree with every last detail of morcos' post.. but broadly. certantly the wiki page and 1:1 discussions support that generally.
< jnewbery> slightly better
< gmaxwell> yea, I don't think we should endorse it, but increase visiblity of it.
< praxeology> Maybe there should be discussion or a link to discussion about core's opinion/roadmap on block size increases?
< gmaxwell> Because otherwise opponents will flood with disinfo, and pay to advertise it, and thats all people will see.
< BlueMatt> jnewbery: heh, that wasnt my point, I asked if people disagreed with the views stated, not disagreed with the concept of endorsing a personal opion....at some point if everyone agrees its no longer a "personal opinion"
< instagibbs> praxeology, already on mailing list, fwiw, search for Paul... Sz... whatever :)
< gmaxwell> BlueMatt: I think the objective should be to increase the quality of the public discussion. Getting more people morcos' links would objectively do that, even if there was some disagreement about them, it's even more obviously a win because there doesn't appear to be.
< BlueMatt> anyway, quoting it and pointing out that its a personal opinion is a lower bar, and ~as effective
< BlueMatt> so whatever
< gmaxwell> in any case, I've also heard from several community members that it would help them if we helped shut down some of this misinformation.
< cfields> jnewbery: agreed. you don't even have to take a position on the matter to call out shadyness. I like to think we'd equally call out a large campaign claiming something stupid like "0.15 solves the scaling issue, update immediately!"
< gmaxwell> cfields: indeed, and I've done that on prior releases (called out people who overstated their gains)
< jnewbery> to be clear, I'm not disputing the quality of morcos's posts, and I personally agree with them, but I find the idea of 'Bitcoin Core thinks <x>' objectionable
< jnewbery> cfields - yes. Absolutely no issue with calling out shadiness
< luke-jr> long term I think we should link blogs with only agreement from maybe 2 or 3 devs, but have a clear notice at the top saying "x, y, z agree; a, b, c don't agree; e, f, g think this is interesting, but don't necessarily agree or disagree" :P this would get info out there better, and make it more obvious that Core is just an open source project, not a formal top-down group
< gmaxwell> jnewbery: yes, I think we want to avoid that.
< gmaxwell> jnewbery: but we can pass on some links while saying that they're worth a read without stating it as a position.
< jnewbery> Perhaps. I'm not going to NACK, and I think I've made my point that we need to be careful with tone
< gmaxwell> All our efforts to do the right thing don't matter if we let less ethical people bury us. I don't think we should adopt those techniques, but we do need to act with the full range and power of what we can agree is acceptable.
< instagibbs> could we also try to get a blue checkmark for the twitter account?
< instagibbs> (heard it's a PITA)
< gmaxwell> jnewbery: btcdrak would probably write it, I'll suggest he also consult with you on the presentation. I think your point is perfectly reasonable.
< praxeology> I disagree with luke's suggested rename to "2X". Ideally we could get the whole bitcoin/altcoin community to change the name, but its too late now, should just stick w/ what everyone is familiar with
<@wumpus> another openbsd issue I can't reproduce https://github.com/bitcoin/bitcoin/issues/11063, seems to work fine here
< Murch> luke-jr: I've added a suggestion to the bottom of your gdoc.
< BlueMatt> lol, we said non-political statement...."altcoin"
< Murch> BlueMatt: I've added the sentences below the line
< BlueMatt> yea, ok, the version below the line is actually a decent start
< Murch> BlueMatt: Good changes if that is you. ;)
< luke-jr> BlueMatt: "altcoin" is objective fact, not political..
< luke-jr> praxeology: everyone is familiar with "2X"
< Murch> luke-jr: "Altcoin" is also needlessly polarizing.
< luke-jr> Murch: I don't see how.
< BlueMatt> luke-jr: feel free to replace the original text with the stuff below the line
< luke-jr> Murch: it's a neutral term, I'm not sure how to make it any better
< BlueMatt> luke-jr: its politically polarizing, whether you intend it to be or not
< Murch> luke-jr: It's a technical term but often used to disparage other projects. It would just be an unnecessary affront to users that actually like some of those projects.
< * luke-jr> wonders how to decide when to accept suggested changes
< Murch> The google doc has hardforked :p
< * Murch> needs to get back to work
< jnewbery> I've added my suggested wording to the doc (under =====)
< luke-jr> jnewbery: it seems to fail to address the main misinformation (that they are misrepresenting an altcoin as an upgrade to Bitcoin)
< luke-jr> (or worse, does so by implying Bitcoin Core is Bitcoin!)
< sturles> btc1 calls their node software Bitcoin Core as well.
<@wumpus> great, as if we didn't have enough confusion
< Murch> as usual with forks, both edit chains live and thrive. ;)
< Murch> There is some replay attacks going on though ;)
<@wumpus> we should have trademarked the name...
< Murch> ah, I thought you meant the two google docs
< luke-jr> wumpus: trademarks don't require registration
< luke-jr> at least in the US
<@wumpus> impersonating software projects isn't cool
< luke-jr> (BTW, if anyone wants direct edit/approval access to the GDoc, PM me your GDocs email)
<@wumpus> it's close to what many malware does
< luke-jr> wumpus: we could probably sue them and win if they're actually doing that, but who wants to deal with the lawyers? :p
<@wumpus> luke-jr: good point...
< jimpo> If I rebroadcast an already-confirmed transaction, will Bitcoin Core nodes add it as an orphan tx?
< sipa> it may
< jimpo> When would an old output be in the pcoinsTip cache?
< sipa> because its output isn't spent yet
< jimpo> OK, makes sense
< jimpo> So in the case where you rebroadcast a transaction with all spent outputs, and it is added as an orphan, the node will then reject all of the parent transactions to that one?
< jimpo> request* not reject
< sipa> right, which other peers likely don't have anymore
< jimpo> cfields: Is there a reason that the "send rejects" part of SendRejectsAndCheckBanned should be called at the end of ProcessMessages as introduced in https://github.com/bitcoin/bitcoin/pull/9720?
< jimpo> Said otherwise, is it safe to split into SendRejects and separately CheckIfBanned and only call CheckIfBanned there?
< BlueMatt> jimpo: the reason is to (try, there are no guarnatees) to get reject messages out to the peer that we're about to disconnect
< BlueMatt> eg an "I banned you because" message
< praxeology> Maybe... the people who would be duped into downloading/installing btc1... haven't even/don't/won't install Bitcoin Core in the first place. So that set of people is probably pretty small, like maybe 0 people?
< gmaxwell> praxeology: it would be true except they are advertising it as how to upgrade for segwit. Even though 90%+ of the network is already upgraded for segwit.
< morcos> karelb: re: estimate fee.. emphasis was on _slight_ differences.. I think you should upgrade to use estimatesmartfee, but if you do nothing, i don't think the world will end. you'll probably be ok
< karelb> thx. I am already looking forward to it
< cfields> jimpo: what he said.
< jimpo> thx
< cfields> jimpo: iirc i explained in pretty good detail in the commit message/pr for that change. You might want to have a quick look if you haven't already
< jimpo> Thanks, the commit messages are very helpful. I understand why the call was added at the end of ProcessMessages, but why is it called again in SendMessages?
< karelb> morcos: I asked P2SH.info guy if he wants to update this - https://p2sh.info/dashboard/db/fee-estimation - to include the new estimatesmartfee
< karelb> I am interested in the graph
< karelb> on the bottom left you see the various estimators compared
< BlueMatt> jimpo: SendMessages is confusingly named, it really should be PeerProcessingTimerFunction
< BlueMatt> and, eg, block reject messages may be generated async
< BlueMatt> (and also dos points based on the same blocks)
< jimpo> OK, thx
< morcos> Just caught up on backlog, for the record, I was already asked about bitcoincoreorg retweeting or pointing to my medium posts and i was fairly strongly opposed
< BlueMatt> morcos: even in a "this is someone's view, but its informative" quote?
< morcos> I agree with jnewbery , I don't think we can all agree on what Core's opinions are, so we should steer very far away from core having opinions
< morcos> BlueMatt: yes, there is no reason that needs to come from core
< BlueMatt> morcos: see greg's comments - people are claiming to "be" bitcoin core saying otherwise
< morcos> you can retweet it (you probably did) and any one else can, but i think the official core communication should stay away from that
< BlueMatt> i did
< morcos> i haven't read the text yet about an announcement regarding 2x, but i think that makes a lot more sense to factually let people know what the Core project will be supporting in terms of rules
< instagibbs> i think there's the two issues: 1) claiming to be core 2) claiming to offer bitcoin upgrades
< morcos> But again we need to be quite careful with tone, to not judge what others are saying too much
< gmaxwell> then in our efforts to be so holy we'll suffer failures at the hands of people with no scruples, because when we don't speak they'll speak for us and use our names.
< morcos> instagibbs: re: upgrades, i think better than disputing their description is to just provide our own factual description
< morcos> people can individually condemn the "upgrade" nomenclature if they choose
< morcos> gmaxwell: i'd rather do that than stoop to their level
< morcos> certainly we can point out that people using similar names are not us and don't represent our views
< bitcoin-git> [bitcoin] luke-jr opened pull request #11082: Add new bitcoin_rw.conf file that is used for settings modified by this software itself (master...rwconf) https://github.com/bitcoin/bitcoin/pull/11082
< instagibbs> +1
< gmaxwell> morcos: there aren't just those two choices though.
< gmaxwell> (also, "here is a really interesting view you should read and consider" is not morally equivilent to /pretending to be us/ or faking that s2x is just an uncontroversial and low risk bitcoin upgrade...)
< BlueMatt> ^ that
< BlueMatt> I mean can you seriously claim that almost the entirety of your rather short blog posts is disagreed with by almost any contributor to bitcoin core
< gmaxwell> We shouldn't make the mistake of being naieve that thinking that being right is sufficent against opponents who will do whatever it takes. That doesn't mean that I think we need to stoop to their level in any way. I think you could potentially extend your argument about speaking for others against writing your post in the first place.
< bitcoin-git> [bitcoin] runn1ng closed pull request #10370: [pull request idea] addressindex, spentindex, timestampindex (Bitcore patches) (master...rebase_bitcoin_master) https://github.com/bitcoin/bitcoin/pull/10370
< gmaxwell> Surely even if we do not tweet it, some people will see it and think it speaks for the project. Not many, nor would it be a reasonable conclusion to jump to.. but some will.
< BlueMatt> anyway, so thoughts on the current proposed doc? https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM/edit
< BlueMatt> (and the pending edits to it)
< morcos> I had one objection, i commented, but overall i think its quite good
< morcos> gmaxwell: yes its enough of a problem that people might mistake my posts as representing the project, thats why its important for the project to not tweet them
< morcos> they don't, i'm glad a lot of you guys like them.. but it would also be fine if you disagreed.
< gmaxwell> in this climate I hope we'd also consider tweeting it if we didn't agree but thought it was a useful contribution to the discussion.
< gmaxwell> In any case, lets talk about what the people suggesting this hope to achieve.
< gmaxwell> I want people to not be getting only the distorted s2x version of the world shoved down their throats, and know that many people have a dissenting view.
< gmaxwell> And in particular, the people that the users of bitcoin are generally reseting a fair amount of trust to create and maintain the software the network is using, for the most part (or completely though we can't be sure) don't agree with the narative they're being sold.
< morcos> I'm going to be mostly afk for rest of today, but will check back in. I think we should let this proposed blog post sit for a while after we get the wording nailed down and just make sure contributors to the project are ok with it
< sipa> Receiving objects: 100% (98150/98150), 83.68 MiB | 3.68 MiB/s, done.
< sipa> i find it amazing that all of bitcoin core's history, is less than 100 MB