1 2017-08-17 01:03:21	0|gmaxwell|Wow, this is super dishonest https://segwit2x.github.io/segwit2x-announce.html  ... "Bitcoin Upgrade" is untrue... it claims Bitcoin "Classic" and unlimited are compatible "Compatible Fully-Validating Node Software" but they don't implement the S2X rules and don't even implement segwit!
  2 2017-08-17 01:17:53	0|luke-jr|gmaxwell: Classic and BU merged 2X code
  3 2017-08-17 01:19:00	0|luke-jr|funny how they didn't include XT, Knots, btcsuite, et al on their lists
  4 2017-08-17 01:19:02	0|gmaxwell|luke-jr: they merged segwit?!
  5 2017-08-17 01:19:06	0|luke-jr|gmaxwell: no, just 2X
  6 2017-08-17 01:19:29	0|luke-jr|it's still super dishonest, just not *totally* bogus
  7 2017-08-17 01:19:33	0|gmaxwell|then they're not compatible fully validating s2x nodes.
  8 2017-08-17 01:19:44	0|luke-jr|remember that crowd thinks SPV is fine
  9 2017-08-17 01:19:46	0|gmaxwell|they don't list bitcoinj
 10 2017-08-17 01:20:01	0|gmaxwell|or any other SPV client.
 11 2017-08-17 01:20:33	0|luke-jr|‎[01:19:28] ‎<‎luke-jr‎>‎ it's still super dishonest, just not *totally* bogus
 12 2017-08-17 01:21:01	0|gmaxwell|if they said "[compatible fully validating nodes] btc1 \n [compatible wallet software] bitcoin classic\n" it would n... oh okay, well I suppose because it's not a lie in every possible sense it's okay. :P
 13 2017-08-17 01:21:58	0|luke-jr|in other news, Texas Bitcoin conference is promoting 2X as if it's Bitcoin, so I think that makes the decision to go simple (ie, not to)
 14 2017-08-17 01:53:36	0|morcos|BlueMatt: is there an ascii middle finger? 3- or something?
 15 2017-08-17 02:15:14	0|jimpo|This grant doesn't appear to be checked in ThreadOpenConnections. https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1712. Only the one in ProcessOneShot is. Why is that?
 16 2017-08-17 02:17:04	0|jimpo|Ah, got it. It's the fTry constructor param.
 17 2017-08-17 04:05:29	0|shesek|gmaxwell, luke-jr: I mentioned that to them: https://github.com/segwit2x/segwit2x.github.io/pull/6#discussion_r132615997 https://github.com/segwit2x/segwit2x.github.io/pull/6#discussion_r132616222
 18 2017-08-17 04:05:32	0|shesek|they ignored me.
 19 2017-08-17 04:07:29	0|chainhead|I also mentioned it, multiple times and they deny that it is even possibly misleading
 20 2017-08-17 05:01:23	0|gmaxwell|https://twitter.com/bcoreproject/status/897966294083018760  people faking our project on twitter and pretending that we're supporting s2x. :(
 21 2017-08-17 05:46:43	0|fanquake|sipa such biased technical opinions :p
 22 2017-08-17 05:47:13	0|sipa|fanquake: i realized too late i should just have said "this belongs on the mailinglist"
 23 2017-08-17 07:11:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11053: refactor: Make all #includes relative to project root (06master...062017_08_includes_absolute) 02https://github.com/bitcoin/bitcoin/pull/11053
 24 2017-08-17 07:26:44	0|wumpus|so if I compute correctly, going from base58 to base62 would make addresses 1.6% shorter, so for the usual bitcoin address length of 34 characters it would save half a character. Wow. Yes, definitely enough reason to break compatibility with all other wallets :)
 25 2017-08-17 07:28:58	0|gmaxwell|hah where was that from
 26 2017-08-17 07:29:45	0|wumpus|https://github.com/bitcoin/bitcoin/issues/11072 - ah base62x is apparently that person's own project
 27 2017-08-17 07:31:02	0|gmaxwell|hehe Meets all these requirements, except it doesn't. :P
 28 2017-08-17 07:33:17	0|gmaxwell|well, I suppose it does have advantages over base64...  but man his c code is scary.
 29 2017-08-17 07:33:57	0|wumpus|they provide code examples but not even really a description, there seems to be a link to a paper in chinese
 30 2017-08-17 07:34:47	0|gmaxwell|it's an encoding with upper and lower alpha plus nums 2*26+10  which does have the advantage that a single line of it will click copy and paste.
 31 2017-08-17 07:35:17	0|gmaxwell|Which was a consideration for us in bech32 (and made use leave out - as a seperator character)
 32 2017-08-17 07:41:24	0|midnightmagic|Uh.
 33 2017-08-17 07:47:01	0|midnightmagic|wumpus: Now that segwit2x is essentially pretending to be core, perhaps finally there's enough damage accrued from jgarzik that removing him from the team page is a good idea. :-( Re: https://segwit2x.github.io/segwit2x-announce.html and https://news.ycombinator.com/item?id=15032360 :-(
 34 2017-08-17 07:48:04	0|midnightmagic|In particular, the confusion that his presence on that list will likely be causing will be significant, and difficult to properly counter as long as he's still on there.
 35 2017-08-17 07:49:03	0|wumpus|I agree...
 36 2017-08-17 07:51:11	0|wumpus|though the bitcoin core organization pages are https://github.com/bitcoin-core and https://bitcoincore.org/en/team/  and he's on neither of them
 37 2017-08-17 07:51:37	0|midnightmagic|I was thinking of this one: https://github.com/orgs/bitcoin/people
 38 2017-08-17 07:52:03	0|wumpus|yes...
 39 2017-08-17 07:52:28	0|gmaxwell|perhaps that should just be made private, it's kinda lopsided if you don't know what it means.
 40 2017-08-17 07:52:54	0|gmaxwell|(I mean it's alphabetic or something, and lists people who don't have any special privledges except being taggable on issues)
 41 2017-08-17 07:55:54	0|midnightmagic|I'm pretty sure (but don't have concrete evidence) that he himself points people at that list as a proof-of-core team list, which would be if so kinda crappy. I mean after all *I* know who's doing what but I'm just some rando. Meh. Just a thought.
 42 2017-08-17 07:57:00	0|wumpus|so, evryone in favor of removing him from that list?
 43 2017-08-17 07:57:56	0|gmaxwell|I would be confused as to why he was there at all if I didn't know about how that particular list doesn't mean much of anything in particular.
 44 2017-08-17 07:58:21	0|wumpus|well the idea is, indeed, to add frequent contributors so that they can be tagged
 45 2017-08-17 07:58:34	0|wumpus|Mr. Garzik hasn't been a contributor of any frequency for a loong time
 46 2017-08-17 07:59:59	0|wumpus|also he spreads damaging lies in name of the project
 47 2017-08-17 08:00:03	0|wumpus|so I think it's clear
 48 2017-08-17 08:00:58	0|gmaxwell|Last commit was almost two years ago. In the total year of 2015 he made 4.
 49 2017-08-17 08:01:21	0|gmaxwell|And he says a lot of things that are over the top untrue, I've complained privately to him about his conduct dozens of times.
 50 2017-08-17 08:02:00	0|gmaxwell|His responses are unprofesional (though, to be fair, after the Nth time of finding them falling on deaf ears my complaints have been none too kind.)
 51 2017-08-17 08:02:49	0|gmaxwell|In any case I hope you'd remove me if I'd been inactive much less creating problems.
 52 2017-08-17 08:03:08	0|midnightmagic|you troublemaker you ;-)
 53 2017-08-17 08:09:27	0|achow101|I'm in favor of removing him
 54 2017-08-17 08:28:56	0|wumpus|I'd like to add a few people too, just sent achow101 an invite, any other suggestions for active contributors that should be on the list?
 55 2017-08-17 08:29:18	0|fanquake|kallewoof ?
 56 2017-08-17 08:29:36	0|wumpus|I was thinking of them too
 57 2017-08-17 08:30:01	0|fanquake|maybe ryanofsky
 58 2017-08-17 08:30:15	0|fanquake|Do they both work for chaincode ?
 59 2017-08-17 08:30:23	0|wumpus|invited kallewoof
 60 2017-08-17 08:30:24	0|wumpus|ryanofsky is already in the list
 61 2017-08-17 09:03:47	0|gmaxwell|is anyone collecting feerate | rough arrival time | n blocks to confirm data for all transactions for the last couple months so I could try some feerate estimation ideas
 62 2017-08-17 12:29:46	0|bitcoin-git|[13bitcoin] 15BitonicEelis opened pull request #11073: Remove dead store in ecdsa_signature_parse_der_lax. (06master...06deadstore) 02https://github.com/bitcoin/bitcoin/pull/11073
 63 2017-08-17 13:35:21	0|bitcoin-git|[13bitcoin] 15BitonicEelis opened pull request #11074: Assert that CWallet::SyncMetaData finds oldest transaction. (06master...06syncassert) 02https://github.com/bitcoin/bitcoin/pull/11074
 64 2017-08-17 13:45:17	0|webuser232|gmaxwell, what do you think about this? https://github.com/bitcoin/bitcoin/issues/11064
 65 2017-08-17 14:31:17	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11076: 0.15 release-note nits: fix redundancy, remove accidental parenthesis & fix range style (060.15...060.15-release-notes) 02https://github.com/bitcoin/bitcoin/pull/11076
 66 2017-08-17 14:48:47	0|BlueMatt|morcos: I appreciate that you ask me, but I'm certainly not hip with the ascii art
 67 2017-08-17 14:55:43	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11077: [tests] fix timeout issues from TestNode (06master...06test_node_fixes) 02https://github.com/bitcoin/bitcoin/pull/11077
 68 2017-08-17 15:01:27	0|morcos|BlueMatt: well it was most relevant what you would interpret that way... :)
 69 2017-08-17 15:06:45	0|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
 70 2017-08-17 15:07:53	0|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
 71 2017-08-17 15:08:58	0|wumpus|without going into detail about what exactly you want to do, there's no useful responses to give
 72 2017-08-17 15:11:46	0|webuser232|wumpus, I agree with you mostly. I just wanted to see peoples first/gut/intuitive reaction to the idea proposed, that's all.
 73 2017-08-17 15:12:57	0|webuser232|jnewbery, thanks for you input!
 74 2017-08-17 15:17:14	0|sipa|"use AI to solve it!" is not very different from saying "use software to solve it!"
 75 2017-08-17 15:17:30	0|wumpus|why not use physics to solve it!
 76 2017-08-17 15:19:37	0|webuser232|sipa, wumpus, very rich. I get it first time. No need to mock.
 77 2017-08-17 15:19:55	0|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
 78 2017-08-17 15:19:59	0|karelb|Hello, nobody replied at #bitcoin, I hope I am not interrupting a meeting again, I will ask here
 79 2017-08-17 15:20:06	0|karelb|question about bitcoin 0.15.0 ... does estimatesmartfee return the same fees as estimatefee?
 80 2017-08-17 15:20:23	0|karelb|ignoring the errors and the conservative mode
 81 2017-08-17 15:20:24	0|promag|morcos: is it relevant to call UpdateMovingAverages while syncing?
 82 2017-08-17 15:20:29	0|jnewbery|karelb no, it's a new implementation
 83 2017-08-17 15:20:32	0|karelb|ok
 84 2017-08-17 15:20:46	0|promag|morcos: there is some performance improvement if not
 85 2017-08-17 15:21:39	0|karelb|so esttimatefee returns the same fees, estimatesmartfee returns a better estimate
 86 2017-08-17 15:21:41	0|karelb|great
 87 2017-08-17 15:21:42	0|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
 88 2017-08-17 15:22:18	0|morcos|karelb: estimatefee is deprecated for 0.15.  it returns something slightly different than 0.14's estimatefee and likely slightly worse
 89 2017-08-17 15:22:38	0|morcos|but as close as it could be wihtout a lot of work given the new internals
 90 2017-08-17 15:22:53	0|morcos|got to run
 91 2017-08-17 15:23:14	0|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
 92 2017-08-17 15:26:11	0|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
 93 2017-08-17 15:26:45	0|webuser232|jnewbery, I think it's a good candidate too. I'll investigate further. I've got to run for now. Thanks!
 94 2017-08-17 15:44:38	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11078: [tests] Make p2p-leaktests.py more robust (06master...06p2p_leaktests_robust) 02https://github.com/bitcoin/bitcoin/pull/11078
 95 2017-08-17 16:11:35	0|BlueMatt|grr, does someone have a fucking openbsd box to test build on?
 96 2017-08-17 16:14:20	0|wumpus|yes
 97 2017-08-17 16:15:25	0|wumpus|BlueMatt: I have an openbsd 6.1 box to test on - what do you need tested?
 98 2017-08-17 16:19:26	0|BlueMatt|wumpus: just looks like there's been a few build errors on openbsd recently (I assume 15rc1 testing) eg #11057
 99 2017-08-17 16:20:12	0|wumpus|ooh the gui on opennsd? I don't think anyone even tried that before, certainly not me
100 2017-08-17 16:23:29	0|wumpus|#11057 looks like a conflict between GL driver and libdrm version?
101 2017-08-17 16:25:25	0|BlueMatt|possibly? I dunno
102 2017-08-17 16:25:32	0|wumpus|nothing we can help in any case
103 2017-08-17 16:29:44	0|wumpus|building anything on openbsd is difficult, I can't imagine the nightmare of getting the opengl/X/qt stack to work on that
104 2017-08-17 16:33:21	0|BlueMatt|wumpus: have you managed to repro the crashes in bitcoind in #11063?
105 2017-08-17 16:33:27	0|BlueMatt|wasnt there a similar one in test_bitcoin, too?
106 2017-08-17 16:34:02	0|wumpus|haven't tried yet
107 2017-08-17 16:34:30	0|wumpus|last time I ran the tests on openbsd it was all ok, but it's been a few months ago
108 2017-08-17 16:34:36	0|BlueMatt|oh, no, it was in bench
109 2017-08-17 16:34:43	0|BlueMatt|yea, #10801
110 2017-08-17 16:34:56	0|BlueMatt|yea, sounds like openbsd got fucked again :(
111 2017-08-17 16:35:10	0|wumpus|(no, shorter ago, this was around the time the asm changes went in)
112 2017-08-17 16:35:15	0|BlueMatt|wonder where we can find an openbsd dev to contribute :p
113 2017-08-17 16:36:04	0|wumpus|it's funny how gdb is fucked on all BSD
114 2017-08-17 16:36:25	0|BlueMatt|yea :/
115 2017-08-17 16:36:50	0|wumpus|at least on freebsd it's easy (and encouraged) to install a newer one, but the default one is ancient, from 2004
116 2017-08-17 16:37:33	0|wumpus|this means it cannot understand the debug information (DWARF 3) generated by compilers of this decennium
117 2017-08-17 16:37:37	0|BlueMatt|so they're taking the debian approach of keeping people on ancient versions of things :(
118 2017-08-17 16:37:48	0|wumpus|it has some license-related reason
119 2017-08-17 16:38:35	0|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
120 2017-08-17 16:38:48	0|BlueMatt|lol
121 2017-08-17 16:38:53	0|BlueMatt|man licensing sucks
122 2017-08-17 16:39:11	0|wumpus|would be wiser to go to llvm/clang as that does have a bsd compatible license, FreeBSD did that for many platforms already
123 2017-08-17 16:39:17	0|grubles|yeah i think obsd is completely ditching gcc for clang soon
124 2017-08-17 16:39:22	0|grubles|i think i read that the other day
125 2017-08-17 16:39:28	0|wumpus|finally!
126 2017-08-17 16:39:56	0|grubles|yeah https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-Default-Clang
127 2017-08-17 16:40:49	0|wumpus|(oh, FreeBSD already switched to clang a while ago, what they're doing now is switching the *linker* to clang's linker)
128 2017-08-17 16:41:39	0|wumpus|probably gdb to lldb
129 2017-08-17 16:46:09	0|wumpus|'gmake check' passes on openbsd
130 2017-08-17 16:47:24	0|wumpus|bench also runs succesfully
131 2017-08-17 16:47:39	0|wumpus|(this is with master, not 0.15 branch, but they have hardly diverged)
132 2017-08-17 16:49:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
133 2017-08-17 17:17:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
134 2017-08-17 17:18:53	0|wumpus|gribble: why are you repeating that?
135 2017-08-17 17:19:12	0|sipa|17:17:57 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
136 2017-08-17 17:22:28	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #11080: doc: Update build-openbsd for 6.1 (06master...062017_08_openbsd_bump) 02https://github.com/bitcoin/bitcoin/pull/11080
137 2017-08-17 17:28:52	0|praxeology|where can I find a spec on how to craft bch transactions? gmaxwell, you said you had/were making a patch?
138 2017-08-17 17:29:58	0|praxeology|Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
139 2017-08-17 17:30:11	0|arubi|and p2pkh\p2sh instead of p2wpkh\p2wpsh
140 2017-08-17 17:30:59	0|arubi|p2wsh*
141 2017-08-17 17:32:47	0|luke-jr|praxeology: it's just Segwit's signature format, with the extra bit set in the sighash flags
142 2017-08-17 17:33:43	0|wumpus|praxeology: this patch adds ALL|ABC support to signrawtransaction: https://github.com/laanwj/bitcoin/commit/22a4c47643203f86e03f4b001e776fcff1fe8d92
143 2017-08-17 17:34:37	0|wumpus|it's not mine, has been floating around for a while - and I guess it's strongly off topic here
144 2017-08-17 17:35:39	0|sipa|i think it's mine :)
145 2017-08-17 17:36:11	0|wumpus|sipa: I wasn't sure whether you wanted credit for it lol
146 2017-08-17 17:36:48	0|praxeology|wumpus: at least I'm not interrupting a meeting this time :p
147 2017-08-17 17:37:13	0|sipa|praxeology: off by 23 minutes
148 2017-08-17 17:38:30	0|praxeology|... So if I run core w/ that patch... I can sign my bch over to shapeshift.io for example?
149 2017-08-17 17:38:56	0|wumpus|yes, that works. Do run it with -nolisten -noconnect to avoid bch transactions from getting into your mempool.
150 2017-08-17 17:39:50	0|praxeology|I'll be running it on an airgapped computer
151 2017-08-17 17:39:53	0|wumpus|you can use https://github.com/laanwj/bitcoin-submittx to submit the signed transaction to a list of BCH nodes
152 2017-08-17 17:41:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/11063 | bitcoind aborts · Issue #11063 · bitcoin/bitcoin · GitHub
153 2017-08-17 17:41:39	0|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
154 2017-08-17 17:41:58	0|wumpus|gribble: huh?
155 2017-08-17 17:45:05	0|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
156 2017-08-17 18:00:02	0|sipa|*DING*
157 2017-08-17 18:00:14	0|BlueMatt|sipa: you're an hour early
158 2017-08-17 18:00:18	0|sipa|oops?
159 2017-08-17 18:00:18	0|wumpus|huuh are you sure you're not an hour early?
160 2017-08-17 18:00:54	0|sipa|yes, it was the "warning, meeting in one hour!" alarm </whateverhappenspretenditwasintentional>
161 2017-08-17 18:01:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10801 | bench_bitcoin segfaults · Issue #10801 · bitcoin/bitcoin · GitHub
162 2017-08-17 18:01:54	0|sipa|maybe that'll teach gribble
163 2017-08-17 18:03:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/11057 | Connection timed out.
164 2017-08-17 18:56:09	0|achow101|wut
165 2017-08-17 19:00:04	0|BlueMatt|sipa: try again now?
166 2017-08-17 19:00:15	0|lightningbot|Meeting started Thu Aug 17 19:00:14 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
167 2017-08-17 19:00:15	0|wumpus|#startmeeting
168 2017-08-17 19:00:16	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
169 2017-08-17 19:00:21	0|sipa|DUNG
170 2017-08-17 19:00:32	0|achow101|hi
171 2017-08-17 19:00:42	0|Chris_Stewart_5|present
172 2017-08-17 19:00:44	0|jtimon|dong
173 2017-08-17 19:00:50	0|jonasschnelli|hi
174 2017-08-17 19:00:56	0|instagibbs|prezent
175 2017-08-17 19:00:58	0|wumpus|topics?
176 2017-08-17 19:01:02	0|cfields|hi
177 2017-08-17 19:01:15	0|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
178 2017-08-17 19:01:40	0|BlueMatt|blockers for review
179 2017-08-17 19:01:40	0|wumpus|let's start with 0.15.0rc1 - have any serious issues been reported?
180 2017-08-17 19:01:45	0|BlueMatt|and that
181 2017-08-17 19:01:55	0|wumpus|#topic 0.15.0
182 2017-08-17 19:02:09	0|BlueMatt|there's the openbsd stuff, but I'm not sure thats really 0.15 per se, more than just openbsd brokenness
183 2017-08-17 19:02:16	0|BlueMatt|there's also the version-reporting thing gmaxwell mentioned
184 2017-08-17 19:02:18	0|cfields|only thing i'm aware of is the version number issue, but that's nothing
185 2017-08-17 19:02:29	0|wumpus|that's just openbsd brittleness, I'm looking at it
186 2017-08-17 19:02:33	0|achow101|there's the duplicate hex in getrawtransaction
187 2017-08-17 19:02:37	0|BlueMatt|plus the new compiler warnings
188 2017-08-17 19:02:37	0|wumpus|cfields: do we have a patch for that?
189 2017-08-17 19:02:50	0|sipa|and the other things marked for 0.15... #11044 #11027
190 2017-08-17 19:03:10	0|cfields|wumpus: i haven't decided on where to fix it yet. Either way I'll PR something today/tomorrow
191 2017-08-17 19:03:39	0|wumpus|cfields: I guess in a hurry we could just revert luke-jr's patch that introduces the problem, for 0.15
192 2017-08-17 19:04:18	0|cfields|wumpus: yes, that was my initial suggestion, but luke-jr isn't a fan
193 2017-08-17 19:04:29	0|jonasschnelli|Can you elaborate on the version number issue (via luke-jr's PR)?
194 2017-08-17 19:04:38	0|wumpus|yes I saw the new compiler warnings, something about signed to unsigned comparison in the wallet version logic
195 2017-08-17 19:04:42	0|wumpus|is that something serious?
196 2017-08-17 19:05:11	0|cfields|jonasschnelli: the version string doesn't show v0.15.0 as it should, but a git commit instead
197 2017-08-17 19:05:12	0|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]
198 2017-08-17 19:05:17	0|cfields|sec for offending PR
199 2017-08-17 19:05:31	0|sipa|suggestion: have travis (which has a deterministic compiler version) in one of the tests run with -Werror... but not for default builds
200 2017-08-17 19:05:37	0|wumpus|and another one on the same line
201 2017-08-17 19:05:56	0|BlueMatt|sipa: #10923
202 2017-08-17 19:06:03	0|kanzure|hi.
203 2017-08-17 19:06:10	0|wumpus|sipa: yeah, no that we no longer have any annoying warnings such as Wshadow we could do that
204 2017-08-17 19:06:16	0|cfields|jonasschnelli: #7522
205 2017-08-17 19:06:27	0|jonasschnelli|wumpus: isn't that (-WSign-compare) fixed with #11044?
206 2017-08-17 19:06:39	0|sipa|BlueMatt: oops, never read the second part of the title
207 2017-08-17 19:06:45	0|wumpus|jonasschnelli: could be!
208 2017-08-17 19:06:50	0|jonasschnelli|It is. Just checked
209 2017-08-17 19:06:58	0|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
210 2017-08-17 19:07:11	0|BlueMatt|sipa: that pr enables it for thread-safety-analysis and then turns it on on travis-osx
211 2017-08-17 19:07:15	0|cfields|sipa: +1. I think 10923 is a great idea
212 2017-08-17 19:07:32	0|BlueMatt|10923 is blocked on switching mutexes and sync.h to std, but I think we can just do that (tm)
213 2017-08-17 19:07:51	0|cfields|BlueMatt: not yet :(
214 2017-08-17 19:08:03	0|wumpus|we can just take the travis-werror part
215 2017-08-17 19:08:18	0|wumpus|I don't see how that is strongly related to the thread analysis
216 2017-08-17 19:08:22	0|BlueMatt|true
217 2017-08-17 19:08:44	0|wumpus|switching over mutexes and sync definitely sounds like a post-0.15 thing
218 2017-08-17 19:08:47	0|cfields|yea, we should just go ahead with that and add the thread checking when it's ready
219 2017-08-17 19:08:48	0|BlueMatt|cfields: oh? none of that stuff is used directly in the remaining threadGroup threads
220 2017-08-17 19:09:07	0|BlueMatt|oh, y'all want to turn on -Werror on travis for 15? yea, ok, not that then
221 2017-08-17 19:09:35	0|BlueMatt|anyway, looks like #11044 fixes the warnings, and its already tagged 0.15.0
222 2017-08-17 19:09:48	0|cfields|oh, i thought we were talking about it for master
223 2017-08-17 19:10:04	0|wumpus|the topic is 0.15 so I was assuming we were talking about 0.15
224 2017-08-17 19:10:11	0|jonasschnelli|cfields: I have a correct version string in 0.15.0rc1 (Qt, debug log). What do I miss?
225 2017-08-17 19:10:15	0|wumpus|anyhow, I don't mind, let's enable it for some branch...
226 2017-08-17 19:10:33	0|cfields|BlueMatt: i'll double-check. But I thought we had some outstanding condvars that we couldn't switch yet. Will look after meeting.
227 2017-08-17 19:10:33	0|wumpus|master is what the PRs will be tested against so that makes most sense I suppose
228 2017-08-17 19:10:59	0|BlueMatt|cfields: we do, but they're directly calling boost::condition_variable, not CConditionVariable, I believe
229 2017-08-17 19:11:00	0|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.
230 2017-08-17 19:11:08	0|wumpus|ok: does anything need tagging for 0.15.0?
231 2017-08-17 19:11:24	0|cfields|jonasschnelli: the splash screen, at least, shows the git revision
232 2017-08-17 19:11:44	0|BlueMatt|as for 0.15, I think its jsut the 3 tags + whatever for the version string issue
233 2017-08-17 19:11:49	0|BlueMatt|or, nothing else was brought up
234 2017-08-17 19:11:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
235 2017-08-17 19:11:56	0|jonasschnelli|cfields: Ah. I see now.. releases don't have the commit&dirty.. nm
236 2017-08-17 19:12:21	0|wumpus|okay
237 2017-08-17 19:12:31	0|wumpus|#topic high-priority for review
238 2017-08-17 19:13:14	0|wumpus|now that 0.15 is branched, we can start doing this again
239 2017-08-17 19:13:36	0|wumpus|added
240 2017-08-17 19:13:43	0|wumpus|it's lonely https://github.com/bitcoin/bitcoin/projects/8
241 2017-08-17 19:14:04	0|sipa|i'd like to draw some attention to #10785 (serialization improvements)
242 2017-08-17 19:14:08	0|BlueMatt|thats ok, 10286 needs to simmer on master for a month or three, so it is actually a should-go-soon, thing
243 2017-08-17 19:14:14	0|BlueMatt|:p
244 2017-08-17 19:14:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/11027 | [RPC] Only return hex field once in getrawtransaction by achow101 · Pull Request #11027 · bitcoin/bitcoin · GitHub
245 2017-08-17 19:14:29	0|jonasschnelli|sipa: It's on my list.. reviewed most of it and running on my node
246 2017-08-17 19:14:44	0|gmaxwell|lol poor gribble.
247 2017-08-17 19:14:51	0|gmaxwell|(he's way behind)
248 2017-08-17 19:15:14	0|cfields|I'd like to add #10756 please, as lots of things for 0.16 will build on top of that
249 2017-08-17 19:15:21	0|jonasschnelli|(gribble probably needs to process all the spam first)
250 2017-08-17 19:16:00	0|wumpus|gribble damnit you made me add 11027, which makes no sense as it's already tagged 0.15
251 2017-08-17 19:16:06	0|jonasschnelli|cfields. done
252 2017-08-17 19:16:10	0|cfields|(that's the signals -> interface class switch for message processing)
253 2017-08-17 19:16:15	0|sipa|cfields: ack
254 2017-08-17 19:16:21	0|BlueMatt|yes! 10756!
255 2017-08-17 19:16:22	0|cfields|jonasschnelli: thanks
256 2017-08-17 19:16:23	0|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
257 2017-08-17 19:17:06	0|jtimon|I would suggest #8498 but not sure if it can be high priority
258 2017-08-17 19:17:09	0|BlueMatt|poor gribble
259 2017-08-17 19:17:19	0|wumpus|aww :)
260 2017-08-17 19:17:21	0|jonasschnelli|:)
261 2017-08-17 19:17:32	0|cfields|haha
262 2017-08-17 19:18:33	0|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
263 2017-08-17 19:18:46	0|wumpus|jtimon: added
264 2017-08-17 19:18:50	0|jtimon|cool
265 2017-08-17 19:18:52	0|wumpus|ok, any other topics?
266 2017-08-17 19:19:43	0|jonasschnelli|short topic: adding bench to gitian build package?
267 2017-08-17 19:19:59	0|jonasschnelli|I can PR
268 2017-08-17 19:20:00	0|cfields|wasn't it just explicitly removed? :)
269 2017-08-17 19:20:07	0|jonasschnelli|Yes. At least on Win
270 2017-08-17 19:20:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
271 2017-08-17 19:21:00	0|achow101|+
272 2017-08-17 19:21:05	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/7776
273 2017-08-17 19:21:10	0|wumpus|#topic adding bench to gitian build package
274 2017-08-17 19:21:24	0|jonasschnelli|I stumbled over it when wanted to bench sse4
275 2017-08-17 19:21:27	0|wumpus|I removed it because it was useless at the time, bench had only the examle benchmark
276 2017-08-17 19:21:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
277 2017-08-17 19:21:40	0|wumpus|but now that bench is actually useful I agree with enabling it for the distributions, for all platforms
278 2017-08-17 19:22:36	0|jonasschnelli|I think its useful now.
279 2017-08-17 19:22:40	0|jonasschnelli|I'll PR that then
280 2017-08-17 19:22:41	0|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
281 2017-08-17 19:22:52	0|jtimon|suggested topic, what do we want to do about configs for different chains? related to issue #9374 and prs #10267 #8994
282 2017-08-17 19:23:26	0|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
283 2017-08-17 19:23:49	0|wumpus|jonasschnelli: thanks
284 2017-08-17 19:23:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/10785 | Connection reset by peer.
285 2017-08-17 19:24:02	0|sipa|do we want to discuss bip159 more?
286 2017-08-17 19:24:03	0|wumpus|jonasschnelli: no rush, we don't really need it in 0.15 yet
287 2017-08-17 19:24:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/10756 | Connection reset by peer.
288 2017-08-17 19:24:25	0|jonasschnelli|Yes. Certenly not for 0.15
289 2017-08-17 19:24:48	0|luke-jr|sorry, here
290 2017-08-17 19:24:56	0|wumpus|#topic bip159: (NODE_NETWORK_LIMITED service bits)
291 2017-08-17 19:24:58	0|jonasschnelli|last updates on BIP159: threat bits independently, fingerprinting protection
292 2017-08-17 19:25:06	0|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
293 2017-08-17 19:25:21	0|jonasschnelli|The address relay and whole peering maybe needs discussion
294 2017-08-17 19:25:22	0|jonasschnelli|cfields mentioned once some potential issues
295 2017-08-17 19:25:36	0|sipa|so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
296 2017-08-17 19:25:38	0|wumpus|luke-jr: ok, well, can you help cfields fixing the problem then?
297 2017-08-17 19:25:49	0|luke-jr|wumpus: yes, already suggested a few ideas
298 2017-08-17 19:26:09	0|sipa|that gets 90% of the benefit I believe (nodes who are already caught up, and want to stay caught up)
299 2017-08-17 19:26:22	0|sipa|without needing to know what other ranges are important
300 2017-08-17 19:26:25	0|cfields|jonasschnelli: yea, i'll jot down my concerns.
301 2017-08-17 19:26:49	0|jonasschnelli|sipa: we could start with that. What's you concerns about definig two bots?
302 2017-08-17 19:26:51	0|jonasschnelli|bits?
303 2017-08-17 19:27:07	0|sipa|jonasschnelli: i'm beginning to think a second bit is just unnecessary for now
304 2017-08-17 19:27:19	0|sipa|and we may be able to make a more informed choice later
305 2017-08-17 19:27:26	0|instagibbs|sipa, prefer the week or day?
306 2017-08-17 19:27:29	0|sipa|day
307 2017-08-17 19:27:36	0|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.
308 2017-08-17 19:27:47	0|jonasschnelli|I think the week usecase can be interesting with SPV (client side)
309 2017-08-17 19:27:51	0|gmaxwell|the 288 matches the current minimum.
310 2017-08-17 19:28:20	0|jonasschnelli|You could run a pruned peer while syncing your phone
311 2017-08-17 19:28:32	0|jonasschnelli|(in an ideal BIP150 world)
312 2017-08-17 19:28:36	0|jonasschnelli|(or via tor)
313 2017-08-17 19:28:40	0|gmaxwell|sure, so long as you don't ever forget to run your wallet once a week. :)
314 2017-08-17 19:28:57	0|gmaxwell|you can still do that without the flag however.
315 2017-08-17 19:29:05	0|sipa|the most important benefit is that pruned nodes can and should help with partition resistence of the network, but they currently don't
316 2017-08-17 19:29:28	0|gmaxwell|as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
317 2017-08-17 19:29:35	0|jonasschnelli|I agree. I think defining only the 288 depth bit is okay. We can define another later.
318 2017-08-17 19:29:40	0|gmaxwell|sipa: well they do a littl.
319 2017-08-17 19:29:57	0|gmaxwell|jonasschnelli: yea, that was my thought. Now quick, slip it into 0.15rc2  _me ducks and runs_
320 2017-08-17 19:30:00	0|jonasschnelli|gmaxwell: good point about the whitepeer, right
321 2017-08-17 19:30:22	0|jonasschnelli|gmaxwell: No 0.15. Sadly
322 2017-08-17 19:30:47	0|sipa|jonasschnelli: i believe gmaxwell may not have been very serious ;)
323 2017-08-17 19:30:49	0|gmaxwell|I'm kidding. :)
324 2017-08-17 19:31:21	0|jonasschnelli|No joking about releases. :)
325 2017-08-17 19:31:35	0|gmaxwell|If we cannot laugh all there is left to do is cry.
326 2017-08-17 19:31:36	0|gmaxwell|:)
327 2017-08-17 19:32:03	0|wumpus|exactly
328 2017-08-17 19:32:12	0|jonasschnelli|Indeed
329 2017-08-17 19:32:37	0|jonasschnelli|Any other thoughts on dropping the 1'152 dept NODE_NETWORK_LIMITED_HIGH flag?
330 2017-08-17 19:33:02	0|gmaxwell|that gets rid of anything to be debated.
331 2017-08-17 19:33:37	0|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.
332 2017-08-17 19:33:45	0|wumpus|yes, let's drop it for now
333 2017-08-17 19:34:09	0|wumpus|it's better to continue with something; the bits debate goes on and on :)
334 2017-08-17 19:34:19	0|gmaxwell|smaller changes faster plz.
335 2017-08-17 19:34:24	0|cfields|3 bits!
336 2017-08-17 19:34:27	0|jonasschnelli|Heh. Right... okay, will update the bip and the PR.
337 2017-08-17 19:34:37	0|cfields|:)
338 2017-08-17 19:34:42	0|wumpus|cfields: moar!
339 2017-08-17 19:34:55	0|sipa|3.14 bits!
340 2017-08-17 19:35:01	0|jonasschnelli|hehe
341 2017-08-17 19:35:02	0|gmaxwell|next subject?
342 2017-08-17 19:35:04	0|cfields|sipa: that's just irrational.
343 2017-08-17 19:35:08	0|jnewbery|sipa gmaxwell do you have data about what blocks are requested on the network? Have you shared it anywhere?
344 2017-08-17 19:35:14	0|gmaxwell|damn, I almost saved us from that pun.
345 2017-08-17 19:35:30	0|gmaxwell|jnewbery: we do, we have, I can dig it up again later today.
346 2017-08-17 19:35:32	0|jonasschnelli|jnewbery: sipa has that blocks-requested-chart
347 2017-08-17 19:35:37	0|wumpus|#topic what do we want to do about configs for different chains (jtimon)
348 2017-08-17 19:35:41	0|jnewbery|thanks
349 2017-08-17 19:35:57	0|gmaxwell|jtimon: 12:35:36 <@wumpus> #topic what do we want to do about configs for different chains (jtimon)
350 2017-08-17 19:36:20	0|achow101|pr/issue for reference?
351 2017-08-17 19:36:30	0|gmaxwell|there was an overlay config file PR I saw, I like that general idea.
352 2017-08-17 19:36:35	0|wumpus|related to issue #9374 and prs #10267 #8994
353 2017-08-17 19:37:05	0|jtimon|sorry, I just fell
354 2017-08-17 19:37:09	0|jtimon|so jnewbery had some suggestions for #8994 https://github.com/bitcoin/bitcoin/pull/8994#issuecomment-321355349
355 2017-08-17 19:37:11	0|jtimon|#10267 is slightly related
356 2017-08-17 19:37:39	0|jtimon|and there's the issue #9374
357 2017-08-17 19:38:22	0|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
358 2017-08-17 19:39:38	0|wumpus|not much to discuss from my side really, I think the idea of additional per-chain config files is good
359 2017-08-17 19:39:42	0|sipa|we know but one gribble, and his name is BlueMatt
360 2017-08-17 19:39:43	0|wumpus|need to review the PRs
361 2017-08-17 19:40:03	0|wumpus|also we really need test for initialization order / argument precedence stuff
362 2017-08-17 19:40:12	0|wumpus|as it becomes more complex with this
363 2017-08-17 19:40:17	0|gmaxwell|The Gribble is dead, long live the Gribble.
364 2017-08-17 19:40:24	0|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
365 2017-08-17 19:41:02	0|gmaxwell|okay, so comment on PRs?
366 2017-08-17 19:41:13	0|jtimon|well, I guess it can be discussed on the prs, yeah
367 2017-08-17 19:41:44	0|jtimon|just poiting out the 3 things seem related to me
368 2017-08-17 19:41:54	0|wumpus|yes
369 2017-08-17 19:42:08	0|luke-jr|wumpus: bitcoin_rw.conf solves per-chain at the same time, so IMO the approach to take there
370 2017-08-17 19:42:19	0|wumpus|luke-jr: that's a different issue
371 2017-08-17 19:42:38	0|wumpus|luke-jr: let's not blur everything together now jsut because jtimon started off with a whole list...
372 2017-08-17 19:42:42	0|wumpus|any other topics?
373 2017-08-17 19:43:03	0|gmaxwell|yea.. I want to talk about the impersonation issues and comms stuff for a moment.
374 2017-08-17 19:43:04	0|jnewbery|I don't think that #10996 (per network configuration) and #10267 (additional config file) should be held up on #8994 (custom chains)
375 2017-08-17 19:43:21	0|wumpus|jnewbery: no, I don't think so either
376 2017-08-17 19:43:38	0|wumpus|#topic impersonation issues and comms stuff
377 2017-08-17 19:43:42	0|gmaxwell|Kind of OT for the normal material here; but everyone should be aware that the developer of S2X is going around
378 2017-08-17 19:43:45	0|gmaxwell|spreading misinformation about S2X describing it as a harmless "upgrade" to bitcoin, misstating that things like
379 2017-08-17 19:43:48	0|gmaxwell|classic and BU are compatible (though they don't even implement segwit), and not making any mention of the serious
380 2017-08-17 19:43:51	0|gmaxwell|issues like its lack of replay protection, no HF bit, lack of a spec, this is especially bad because there have
381 2017-08-17 19:43:54	0|gmaxwell|been a bunch of efforts to impersonate our project supporting this stuff:
382 2017-08-17 19:43:57	0|gmaxwell|https://twitter.com/bcoreproject/status/897966294083018760 (click internal link for the S2X stuff)
383 2017-08-17 19:44:00	0|gmaxwell|I'm not sure of what to do but it appears to be a widescale effort to misinform people. :(
384 2017-08-17 19:44:07	0|gmaxwell|In the past twitter hasn't done much with people impersonating me, and this is happening on more than twitter.
385 2017-08-17 19:44:24	0|sipa|:(
386 2017-08-17 19:44:29	0|wumpus|yea :/
387 2017-08-17 19:44:31	0|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
388 2017-08-17 19:44:47	0|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"
389 2017-08-17 19:44:59	0|achow101|for twitter impersonation, you can report it to twitter and they might do something about it
390 2017-08-17 19:45:08	0|luke-jr|maybe a bitcoincore.org blog explicitly rejecting 2X and warning people of the misinformation campaigns?
391 2017-08-17 19:45:16	0|wumpus|right, I'm not sure what recourse there is, fake news everywhere on the internet
392 2017-08-17 19:45:21	0|gmaxwell|achow101: I've heard that several project contributors have; so sure; but I wouldn't expect much.
393 2017-08-17 19:45:35	0|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"
394 2017-08-17 19:45:38	0|wumpus|yes certainly report to sites where the impersonation is hosted
395 2017-08-17 19:45:43	0|BlueMatt|luke-jr: if carefully worded, seems fine
396 2017-08-17 19:45:46	0|wumpus|github is quite active with that at least
397 2017-08-17 19:46:00	0|wumpus|twitter usually ignores report unless a lot of people report
398 2017-08-17 19:46:11	0|gmaxwell|Right we may need to each be more outspoken personally, and perhaps organize some project things too.
399 2017-08-17 19:46:17	0|achow101|I like luke-jr's idea. having something explicitly rejecting s2x would be good
400 2017-08-17 19:46:26	0|Murch|I had already reported that account last week, I suggest that others which use twitter do so as well.
401 2017-08-17 19:46:44	0|jtimon|jnewbery: agreed, nor the other way around imo
402 2017-08-17 19:47:42	0|gmaxwell|luke-jr: I've used S2X, but yea people are confused thinking 2X = 2MB  not 4MB (8peak) and other crazy stuff.
403 2017-08-17 19:47:58	0|gmaxwell|or thinking that segwit activation means s2x activation.
404 2017-08-17 19:48:30	0|wumpus|luke-jr: yes, I think an explicit post rejecting s2x would be a good idea
405 2017-08-17 19:48:34	0|praxeology|didn't help that the slashdot article was wrong, portraying it bcash vs segwit2x
406 2017-08-17 19:48:52	0|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.
407 2017-08-17 19:49:17	0|gmaxwell|ironically, BCash seems the more honest and responsible of the two.
408 2017-08-17 19:49:19	0|Murch|gmaxwell: And no development activity since "rc2"
409 2017-08-17 19:49:25	0|achow101|gmaxwell: unfortunately their doing basically a misinformation campaign to get more people to run btc1
410 2017-08-17 19:49:36	0|achow101|e.g. bitpay telling people to use btc1 for segwit
411 2017-08-17 19:49:44	0|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"?
412 2017-08-17 19:49:46	0|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.
413 2017-08-17 19:49:57	0|BlueMatt|simple faq/error correction, not political "fuck this thing"
414 2017-08-17 19:50:17	0|gmaxwell|BlueMatt: would depend on the text! someone could propose some, maybe harding.
415 2017-08-17 19:50:23	0|luke-jr|I'll throw up a draft GDoc people can hack at after the meeting?
416 2017-08-17 19:50:28	0|BlueMatt|gmaxwell: yes, of course
417 2017-08-17 19:50:34	0|gmaxwell|We can also talk to the bitcoin.org folks in general.
418 2017-08-17 19:51:02	0|gmaxwell|luke-jr: It might be a streach for your approach to get something the rest of the contributors would find super agreeable.
419 2017-08-17 19:51:20	0|praxeology|How close is bitcoin.org w/ the core dev team?  Who runs it?
420 2017-08-17 19:51:24	0|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.
421 2017-08-17 19:51:46	0|Chris_St1|maybe bitcoin.org people can throw up a warning about people promoting consensus imcompatible implementations
422 2017-08-17 19:51:53	0|gmaxwell|praxeology: it's run by the bitcoin.org people. They're generally reasonable folks.
423 2017-08-17 19:51:56	0|BlueMatt|praxeology: not at all, but we can at least contact them or open github issues since they do put the source on github
424 2017-08-17 19:51:58	0|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
425 2017-08-17 19:51:59	0|luke-jr|gmaxwell: maybe someone else can write a draft then?
426 2017-08-17 19:52:13	0|luke-jr|what I wrote so far: https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit?usp=sharing
427 2017-08-17 19:52:16	0|sipa|cfields: indeed
428 2017-08-17 19:52:47	0|Murch|BlueMatt: Factual statement that the two are unrelated and perhaps a mention of the lack in replay protection
429 2017-08-17 19:53:05	0|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.
430 2017-08-17 19:53:31	0|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"
431 2017-08-17 19:54:05	0|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.
432 2017-08-17 19:54:21	0|gmaxwell|I dunno if everyone has seen morcos' blog posts but they've been fantastic.
433 2017-08-17 19:54:35	0|wumpus|gmaxwell: can you link them please?
434 2017-08-17 19:54:43	0|wumpus|(for the sake of the meeting log)
435 2017-08-17 19:54:48	0|gmaxwell|BlueMatt: even just many rather than most (while I don't doubt most is also true, a narrower thing can be said)
436 2017-08-17 19:54:58	0|BlueMatt|fair
437 2017-08-17 19:55:28	0|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_.
438 2017-08-17 19:55:34	0|sipa|https://medium.com/@morcos/no2x-bad-governance-model-97b8e521e751 https://medium.com/@morcos/no2x-centralized-services-539e3b1b56c9 https://medium.com/@morcos/no2x-full-nodes-889c20100a8d
439 2017-08-17 19:55:45	0|BlueMatt|yea, ^ those are great!
440 2017-08-17 19:56:11	0|wumpus|#link https://medium.com/@morcos/no2x-bad-governance-model-97b8e521e751
441 2017-08-17 19:56:17	0|wumpus|#link  https://medium.com/@morcos/no2x-centralized-services-539e3b1b56c9
442 2017-08-17 19:56:19	0|luke-jr|some open source projects just do blog aggregation
443 2017-08-17 19:56:19	0|wumpus|#link https://medium.com/@morcos/no2x-full-nodes-889c20100a8d
444 2017-08-17 19:56:27	0|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.
445 2017-08-17 19:57:04	0|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.
446 2017-08-17 19:57:09	0|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.
447 2017-08-17 19:57:20	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #11081: Add length check for CExtKey deserialization (06master...062017/08/fix_cextkey) 02https://github.com/bitcoin/bitcoin/pull/11081
448 2017-08-17 19:57:26	0|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
449 2017-08-17 19:57:38	0|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.
450 2017-08-17 19:57:52	0|gmaxwell|luke-jr: aka bitcoin press center.
451 2017-08-17 19:57:59	0|BlueMatt|wumpus: I think we should include Mr Buckethead! I find his points on Brexit to be rather well-informed.
452 2017-08-17 19:57:59	0|luke-jr|:x
453 2017-08-17 19:58:12	0|luke-jr|gmaxwell: some people don't know to follow individual developers, though
454 2017-08-17 19:58:22	0|sipa|BlueMatt: *Lord* Buckethead please
455 2017-08-17 19:58:31	0|wumpus|lol BlueMatt
456 2017-08-17 19:58:39	0|BlueMatt|sipa: oops, sorry
457 2017-08-17 19:59:03	0|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.
458 2017-08-17 19:59:19	0|BlueMatt|if folks agree, @bitcoincoreorg could also r/t morcos' blog posts
459 2017-08-17 19:59:33	0|wumpus|@btcdrak
460 2017-08-17 20:00:04	0|lightningbot|Meeting ended Thu Aug 17 20:00:03 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
461 2017-08-17 20:00:04	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.html
462 2017-08-17 20:00:04	0|wumpus|#endmeeting
463 2017-08-17 20:00:05	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.log.html
464 2017-08-17 20:00:05	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.txt
465 2017-08-17 20:00:14	0|gmaxwell|BlueMatt: I think it would be good, can be done in a way that it's clearly not project stuff.
466 2017-08-17 20:00:31	0|BlueMatt|yea, i mean just r/t would still show it as a tweet from morcos
467 2017-08-17 20:00:56	0|Murch|BlueMatt: Still would be considered an endorsement
468 2017-08-17 20:01:05	0|BlueMatt|Murch: yes, it would be
469 2017-08-17 20:01:07	0|BlueMatt|thats on purpose
470 2017-08-17 20:01:13	0|BlueMatt|hence my question :)
471 2017-08-17 20:01:13	0|instagibbs|Quote Tweet to make it more obvious :P
472 2017-08-17 20:01:35	0|luke-jr|not everyone reads Twitter either
473 2017-08-17 20:01:39	0|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.
474 2017-08-17 20:01:48	0|gmaxwell|Murch: somewhat, and a failure to counter is implicitly an endorcement of things like https://twitter.com/bcoreproject/status/897966294083018760
475 2017-08-17 20:02:04	0|luke-jr|the vaccine to misinformation is truth
476 2017-08-17 20:02:13	0|instagibbs|Merely informing users that it's "not just an upgrade" cannot be controversial to anyone on the project
477 2017-08-17 20:02:19	0|gmaxwell|Murch: well they should, cause otherwise no one is gonna know.
478 2017-08-17 20:02:29	0|Murch|gmaxwell: That needs a response from the actual Bitcoin Core twitter account to condemn it as false flag.
479 2017-08-17 20:03:14	0|gmaxwell|yes, we can condemn the impersonation (that isn't the only one, also)
480 2017-08-17 20:03:14	0|jnewbery|Murch - I agree. Have misgivings about "Bitcoin Core" endorsing a personal opinion
481 2017-08-17 20:03:16	0|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.
482 2017-08-17 20:03:28	0|luke-jr|"Of the 25 Bitcoin Core developers who have stated a position on 2X, all of them are opposed."
483 2017-08-17 20:03:43	0|luke-jr|Murch: bitcoincore.org is important IMO
484 2017-08-17 20:03:47	0|Murch|luke-jr: Yeah, that's better.
485 2017-08-17 20:03:49	0|instagibbs|the impersonation is break of ToS
486 2017-08-17 20:04:07	0|luke-jr|so should I junk https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit?usp=sharing ?
487 2017-08-17 20:04:59	0|instagibbs|hmm I need a "company email" to report theft of brand
488 2017-08-17 20:05:16	0|BlueMatt|instagibbs: I just made it up, they'll figure it out that its not a "company", its an organization
489 2017-08-17 20:05:24	0|achow101|instagibbs: it's only impersonation if they don't state that they are a parody account
490 2017-08-17 20:05:32	0|instagibbs|achow101, they do not, at least in profile
491 2017-08-17 20:05:45	0|achow101|so what usually happens is that they put "parody" in the profile somewhere, and no one actually notices that
492 2017-08-17 20:05:51	0|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
493 2017-08-17 20:05:55	0|instagibbs|that's fine, but they aren't hence ToS :)
494 2017-08-17 20:05:57	0|gmaxwell|ud.
495 2017-08-17 20:06:09	0|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
496 2017-08-17 20:07:15	0|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.
497 2017-08-17 20:07:40	0|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..
498 2017-08-17 20:07:49	0|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.
499 2017-08-17 20:07:56	0|BlueMatt|can also just quote tweet and say like "Some thoughts on 2x, from a major contributor to Bitcoin Core"
500 2017-08-17 20:08:10	0|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)
501 2017-08-17 20:08:20	0|jnewbery|BlueMatt - I think that's better
502 2017-08-17 20:08:37	0|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.
503 2017-08-17 20:08:40	0|jnewbery|slightly better
504 2017-08-17 20:08:52	0|gmaxwell|yea, I don't think we should endorse it, but increase visiblity of it.
505 2017-08-17 20:09:04	0|praxeology|Maybe there should be discussion or a link to discussion about core's opinion/roadmap on block size increases?
506 2017-08-17 20:09:10	0|gmaxwell|Because otherwise opponents will flood with disinfo, and pay to advertise it, and thats all people will see.
507 2017-08-17 20:09:18	0|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"
508 2017-08-17 20:09:27	0|instagibbs|praxeology, already on mailing list, fwiw, search for Paul... Sz... whatever :)
509 2017-08-17 20:10:20	0|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.
510 2017-08-17 20:10:49	0|BlueMatt|anyway, quoting it and pointing out that its a personal opinion is a lower bar, and ~as effective
511 2017-08-17 20:10:50	0|BlueMatt|so whatever
512 2017-08-17 20:11:47	0|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.
513 2017-08-17 20:11:53	0|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!"
514 2017-08-17 20:12:14	0|gmaxwell|cfields: indeed, and I've done that on prior releases (called out people who overstated their gains)
515 2017-08-17 20:12:36	0|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
516 2017-08-17 20:12:57	0|jnewbery|cfields - yes. Absolutely no issue with calling out shadiness
517 2017-08-17 20:12:59	0|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
518 2017-08-17 20:13:06	0|gmaxwell|jnewbery: yes, I think we want to avoid that.
519 2017-08-17 20:13:39	0|gmaxwell|jnewbery: but we can pass on some links while saying that they're worth a read without stating it as a position.
520 2017-08-17 20:14:49	0|jnewbery|Perhaps. I'm not going to NACK, and I think I've made my point that we need to be careful with tone
521 2017-08-17 20:14:57	0|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.
522 2017-08-17 20:15:13	0|instagibbs|could we also try to get a blue checkmark for the twitter account?
523 2017-08-17 20:15:33	0|instagibbs|(heard it's a PITA)
524 2017-08-17 20:15:34	0|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.
525 2017-08-17 20:17:35	0|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
526 2017-08-17 20:21:28	0|wumpus|another openbsd issue I can't reproduce https://github.com/bitcoin/bitcoin/issues/11063, seems to work fine here
527 2017-08-17 20:21:56	0|Murch|luke-jr: I've added a suggestion to the bottom of your gdoc.
528 2017-08-17 20:22:55	0|Murch|BlueMatt: What do you think? https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit
529 2017-08-17 20:23:45	0|BlueMatt|lol, we said non-political statement...."altcoin"
530 2017-08-17 20:24:35	0|Murch|BlueMatt: I've added the sentences below the line
531 2017-08-17 20:24:46	0|BlueMatt|yea, ok, the version below the line is actually a decent start
532 2017-08-17 20:26:44	0|Murch|BlueMatt: Good changes if that is you. ;)
533 2017-08-17 20:30:26	0|luke-jr|BlueMatt: "altcoin" is objective fact, not political..
534 2017-08-17 20:31:00	0|luke-jr|praxeology: everyone is familiar with "2X"
535 2017-08-17 20:32:12	0|Murch|luke-jr: "Altcoin" is also needlessly polarizing.
536 2017-08-17 20:33:42	0|luke-jr|Murch: I don't see how.
537 2017-08-17 20:33:48	0|BlueMatt|luke-jr: feel free to replace the original text with the stuff below the line
538 2017-08-17 20:33:58	0|luke-jr|Murch: it's a neutral term, I'm not sure how to make it any better
539 2017-08-17 20:34:10	0|BlueMatt|luke-jr: its politically polarizing, whether you intend it to be or not
540 2017-08-17 20:35:34	0|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.
541 2017-08-17 20:35:56	0|BlueMatt|fork'd https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM
542 2017-08-17 20:39:11	0|Murch|The google doc has hardforked :p
543 2017-08-17 20:41:24	0|jnewbery|I've added my suggested wording to the doc (under =====)
544 2017-08-17 20:42:49	0|luke-jr|jnewbery: it seems to fail to address the main misinformation (that they are misrepresenting an altcoin as an upgrade to Bitcoin)
545 2017-08-17 20:43:05	0|luke-jr|(or worse, does so by implying Bitcoin Core is Bitcoin!)
546 2017-08-17 20:50:05	0|sturles|btc1 calls their node software Bitcoin Core as well.
547 2017-08-17 20:50:54	0|wumpus|great, as if we didn't have enough confusion
548 2017-08-17 20:51:18	0|Murch|as usual with forks, both edit chains live and thrive. ;)
549 2017-08-17 20:51:28	0|Murch|There is some replay attacks going on though ;)
550 2017-08-17 20:51:39	0|wumpus|we should have trademarked the name...
551 2017-08-17 20:52:06	0|Murch|ah, I thought you meant the two google docs
552 2017-08-17 20:52:11	0|luke-jr|wumpus: trademarks don't require registration
553 2017-08-17 20:52:14	0|luke-jr|at least in the US
554 2017-08-17 20:52:17	0|wumpus|impersonating software projects isn't cool
555 2017-08-17 20:52:31	0|luke-jr|(BTW, if anyone wants direct edit/approval access to the GDoc, PM me your GDocs email)
556 2017-08-17 20:52:46	0|wumpus|it's close to what many malware does
557 2017-08-17 20:53:06	0|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
558 2017-08-17 20:53:16	0|wumpus|luke-jr: good point...
559 2017-08-17 21:40:36	0|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?
560 2017-08-17 21:41:03	0|jimpo|Said otherwise, is it safe to split into SendRejects and separately CheckIfBanned and only call CheckIfBanned there?
561 2017-08-17 21:48:58	0|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
562 2017-08-17 21:49:03	0|BlueMatt|eg an "I banned you because" message
563 2017-08-17 21:50:26	0|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?
564 2017-08-17 21:53:51	0|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.
565 2017-08-17 21:54:26	0|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
566 2017-08-17 21:56:38	0|karelb|thx. I am already looking forward to it
567 2017-08-17 21:56:57	0|cfields|jimpo: what he said.
568 2017-08-17 21:57:09	0|jimpo|thx
569 2017-08-17 21:58:31	0|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
570 2017-08-17 22:06:42	0|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?
571 2017-08-17 22:09:31	0|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
572 2017-08-17 22:09:35	0|karelb|I am interested in the graph
573 2017-08-17 22:10:03	0|karelb|on the bottom left you see the various estimators compared
574 2017-08-17 22:12:55	0|BlueMatt|jimpo: SendMessages is confusingly named, it really should be PeerProcessingTimerFunction
575 2017-08-17 22:13:12	0|BlueMatt|and, eg, block reject messages may be generated async
576 2017-08-17 22:13:28	0|BlueMatt|(and also dos points based on the same blocks)
577 2017-08-17 22:14:28	0|jimpo|OK, thx
578 2017-08-17 22:15:21	0|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
579 2017-08-17 22:15:44	0|BlueMatt|morcos: even in a "this is someone's view, but its informative" quote?
580 2017-08-17 22:15:48	0|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
581 2017-08-17 22:15:57	0|morcos|BlueMatt: yes, there is no reason that needs to come from core
582 2017-08-17 22:16:14	0|BlueMatt|morcos: see greg's comments - people are claiming to "be" bitcoin core saying otherwise
583 2017-08-17 22:16:21	0|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
584 2017-08-17 22:16:25	0|BlueMatt|i did
585 2017-08-17 22:17:06	0|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
586 2017-08-17 22:17:13	0|instagibbs|i think there's the two issues: 1) claiming to be core 2) claiming to offer bitcoin upgrades
587 2017-08-17 22:17:27	0|morcos|But again we need to be quite careful with tone, to not judge what others are saying too much
588 2017-08-17 22:17:47	0|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.
589 2017-08-17 22:17:54	0|morcos|instagibbs: re: upgrades, i think better than disputing their description is to just provide our own factual description
590 2017-08-17 22:18:14	0|morcos|people can individually condemn the "upgrade" nomenclature if they choose
591 2017-08-17 22:18:30	0|morcos|gmaxwell: i'd rather do that than stoop to their level
592 2017-08-17 22:18:59	0|morcos|certainly we can point out that people using similar names are not us and don't represent our views
593 2017-08-17 22:19:12	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #11082: Add new bitcoin_rw.conf file that is used for settings modified by this software itself (06master...06rwconf) 02https://github.com/bitcoin/bitcoin/pull/11082
594 2017-08-17 22:20:10	0|instagibbs|+1
595 2017-08-17 22:20:32	0|gmaxwell|morcos: there aren't just those two choices though.
596 2017-08-17 22:21:31	0|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...)
597 2017-08-17 22:22:05	0|BlueMatt|^ that
598 2017-08-17 22:22:28	0|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
599 2017-08-17 22:26:07	0|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.
600 2017-08-17 22:26:29	0|bitcoin-git|[13bitcoin] 15runn1ng closed pull request #10370: [pull request idea] addressindex, spentindex, timestampindex (Bitcore patches) (06master...06rebase_bitcoin_master) 02https://github.com/bitcoin/bitcoin/pull/10370
601 2017-08-17 22:26:39	0|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.
602 2017-08-17 22:29:12	0|BlueMatt|anyway, so thoughts on the current proposed doc? https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM/edit
603 2017-08-17 22:29:15	0|BlueMatt|(and the pending edits to it)
604 2017-08-17 22:36:38	0|morcos|I had one objection, i commented, but overall i think its quite good
605 2017-08-17 22:37:11	0|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
606 2017-08-17 22:37:41	0|morcos|they don't, i'm glad a lot of you guys like them.. but it would also be fine if you disagreed.
607 2017-08-17 22:38:25	0|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.
608 2017-08-17 22:38:44	0|gmaxwell|In any case, lets talk about what the people suggesting this hope to achieve.
609 2017-08-17 22:39:23	0|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.
610 2017-08-17 22:40:45	0|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.
611 2017-08-17 22:49:24	0|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
612 2017-08-17 23:20:49	0|sipa|Receiving objects: 100% (98150/98150), 83.68 MiB | 3.68 MiB/s, done.
613 2017-08-17 23:21:14	0|sipa|i find it amazing that all of bitcoin core's history, is less than 100 MB