< 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]
< 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)
< 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] 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
< 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
< 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
< 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
< 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>
< 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.
<@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
< 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?
<@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 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>
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.
<@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?
< 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_.
< 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)
< 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
< 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.
< 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>
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.
< 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.
< 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