1 2017-03-09T00:05:22  *** CubicEar_ has joined #bitcoin-core-dev
  2 2017-03-09T00:06:43  *** CubicEarth has quit IRC
  3 2017-03-09T00:10:31  *** MarcoFalke has joined #bitcoin-core-dev
  4 2017-03-09T00:17:40  *** bityogi has quit IRC
  5 2017-03-09T00:21:26  *** AaronvanW has quit IRC
  6 2017-03-09T00:25:45  *** CubicEar_ has quit IRC
  7 2017-03-09T00:26:12  <MarcoFalke> funny how the release announcement on twitter comes with a screenshot of java script code
  8 2017-03-09T00:26:30  <gmaxwell> I laughed at that too.
  9 2017-03-09T00:26:52  <MarcoFalke> it should come with a screenshot of the four redundant indentation levels
 10 2017-03-09T00:27:34  <sipa> where does that picture come from?
 11 2017-03-09T00:27:42  <sipa> it's not in the URL linked to
 12 2017-03-09T00:27:50  <achow101> who controls the account?
 13 2017-03-09T00:27:54  *** grubles has quit IRC
 14 2017-03-09T00:28:07  <MarcoFalke> maybe ask btcdrak
 15 2017-03-09T00:28:40  <btcdrak> LOL, google image search
 16 2017-03-09T00:28:41  <gmaxwell> there was some popular press article with that picture.
 17 2017-03-09T00:28:56  <gmaxwell> oh no, actually a similar one.
 18 2017-03-09T00:29:07  <gmaxwell> btcdrak: don't do that, for one-- copyright problems. :P
 19 2017-03-09T00:29:28  *** JackH has quit IRC
 20 2017-03-09T00:30:37  *** grubles has joined #bitcoin-core-dev
 21 2017-03-09T00:31:12  <MarcoFalke> jonasschnelli:  has a nice one: https://bitcoin.jonasschnelli.ch/img/header.jpg
 22 2017-03-09T00:31:38  <MarcoFalke> Needs more colors, though.
 23 2017-03-09T00:31:53  <btcdrak> yeah
 24 2017-03-09T00:45:37  *** goregrin1 has joined #bitcoin-core-dev
 25 2017-03-09T00:48:35  *** goregrind has quit IRC
 26 2017-03-09T00:59:45  *** abpa has quit IRC
 27 2017-03-09T01:05:37  <gmaxwell> jonasschnelli: sipa: both of you are rehashing old arguments that have already been made to voskuil on the list. He is either flagrantly incompetent or actively working against the public interest. He is not worth your time or attention, and he gets _no say_ in this. Supporting authenticated links is something each indivigual node can decide to do for itself.
 28 2017-03-09T01:06:45  <gmaxwell> sipa: your addnode argument was directly made my me previously in a private email, which he has dishonestly described as a threat (because I said that I thought I would write him to him privately before mentally writing him off, and he responded that this was 'a threat'-- absurd.)
 29 2017-03-09T01:08:06  <gmaxwell> https://0bin.net/paste/zGcQVRFoTt7rsaZH#ZI5dYJ4GVIWYRFmeKzPQ6C3lorBGQ7LV6IrePetem2z  the 'threat'
 30 2017-03-09T01:08:30  <gmaxwell> Abusive asshole like that are a big part of the reason I unsubscribed. You just enable them when you argue with them where you don't have to.
 31 2017-03-09T01:26:46  *** MarcoFalke has left #bitcoin-core-dev
 32 2017-03-09T01:30:56  <bitcoin-git> [bitcoin] sdaftuar opened pull request #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools (master...2017-03-cnb-optimizations) https://github.com/bitcoin/bitcoin/pull/9959
 33 2017-03-09T01:37:11  <gmaxwell> jeremyrubin: I can't make sense of your comment on #9955
 34 2017-03-09T01:37:13  <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 35 2017-03-09T01:40:49  *** alpalp has joined #bitcoin-core-dev
 36 2017-03-09T01:40:49  *** alpalp has joined #bitcoin-core-dev
 37 2017-03-09T01:44:18  *** PaulCapestany has quit IRC
 38 2017-03-09T01:44:50  <isle2983> plug for a bitcoin-maintainer-tools PR I just submitted:
 39 2017-03-09T01:44:56  <isle2983> https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/10
 40 2017-03-09T01:45:31  <isle2983> it is a set of functionality previously submitted to contrib/devtool, but closed because it was decided that was the wrong spot
 41 2017-03-09T01:46:10  <isle2983> the pointer was to bitcoin-maintainer-tools, so I ran with that
 42 2017-03-09T01:46:29  <isle2983> the scripts use a common shared framework
 43 2017-03-09T01:46:31  *** PaulCapestany has joined #bitcoin-core-dev
 44 2017-03-09T01:46:58  <isle2983> hopefully it will help accelerate further automation in the future
 45 2017-03-09T01:54:04  *** Ylbam has quit IRC
 46 2017-03-09T02:16:12  *** wudayoda_ has quit IRC
 47 2017-03-09T02:33:23  <bitcoin-git> [bitcoin] NicolasDorier opened pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960
 48 2017-03-09T02:49:05  *** harrymm has quit IRC
 49 2017-03-09T02:51:25  *** harrymm has joined #bitcoin-core-dev
 50 2017-03-09T02:55:17  *** wudayoda has joined #bitcoin-core-dev
 51 2017-03-09T03:02:27  *** wudayoda has quit IRC
 52 2017-03-09T03:04:12  *** wudayoda has joined #bitcoin-core-dev
 53 2017-03-09T03:08:27  *** wudayoda has quit IRC
 54 2017-03-09T03:13:48  *** wudayoda has joined #bitcoin-core-dev
 55 2017-03-09T03:14:10  *** dodomojo has joined #bitcoin-core-dev
 56 2017-03-09T03:18:27  *** wudayoda has quit IRC
 57 2017-03-09T03:23:25  *** jannes has quit IRC
 58 2017-03-09T03:44:04  *** alpalp has quit IRC
 59 2017-03-09T03:50:02  <jeremyrubin> gmaxwell: if a miner doesn't want to support segwit, and won't mine them, maybe they should not keep such transactions in their memory pool
 60 2017-03-09T03:50:23  <jeremyrubin> gmaxwell: e.g., to keep room for the most-fee nonsegwit txns
 61 2017-03-09T04:12:29  <luke-jr> jeremyrubin: what if a miner does want to support segwit, but is locked-into mining software that doesn't support it, on some machines?
 62 2017-03-09T04:15:36  <jeremyrubin> this still applies
 63 2017-03-09T04:15:45  <jeremyrubin> they will make more money evicting segwit txs
 64 2017-03-09T04:19:06  *** wudayoda has joined #bitcoin-core-dev
 65 2017-03-09T04:23:10  *** jtimon has quit IRC
 66 2017-03-09T04:25:43  <luke-jr> jeremyrubin: they won't be supporting segwit with that logic, and they might not make more money either so long as their mempool is a decent size
 67 2017-03-09T04:26:09  *** Giszmo has quit IRC
 68 2017-03-09T04:32:01  *** wasi has joined #bitcoin-core-dev
 69 2017-03-09T04:45:57  *** wudayoda has quit IRC
 70 2017-03-09T04:48:06  *** dodomojo has quit IRC
 71 2017-03-09T04:49:02  *** dodomojo has joined #bitcoin-core-dev
 72 2017-03-09T04:53:22  *** dodomojo has quit IRC
 73 2017-03-09T05:12:43  <jeremyrubin> luke-jr: false. they can still validate segwit blocks.
 74 2017-03-09T05:12:59  <jeremyrubin> luke-jr: and check the witnesses (full validation)
 75 2017-03-09T05:13:07  <luke-jr> jeremyrubin: all miners need to validate segwit blocks once it activates; that's not support, it's just mining
 76 2017-03-09T05:18:36  <jeremyrubin> that's not completely true.
 77 2017-03-09T05:18:54  <jeremyrubin> A miner can mine a non segwit block, it will just get orphaned by the segwit-mining majority
 78 2017-03-09T05:19:41  <jeremyrubin> (if any of the txs have a witness)
 79 2017-03-09T05:20:20  <jeremyrubin> and even in that case, such a miner might not want segwit transactions in their mempool if they can't mine them?
 80 2017-03-09T05:24:28  <warren> I suspect your discussion there may be confused by absolutism on one hand, and a common misconception that I also made on the other.
 81 2017-03-09T05:31:21  <jeremyrubin> warren: that sentence doesn't say anything
 82 2017-03-09T05:32:30  <jeremyrubin> In general, if I am a miner, and I have a 10 MB mempool (let's say), and there is a backlog of 100MB of transactions, and the top 10MB are all segwit transactions I absolutely want to exclude them from my mempool if I can't mine them
 83 2017-03-09T05:34:25  <warren> jeremyrubin: pre-segwit nodes see segwit transactions as non-standard and it won't enter the mempool to begin with
 84 2017-03-09T05:36:20  <warren> nevermind, I don't care enough about this to continue
 85 2017-03-09T05:37:43  <jeremyrubin> warren: context is a miner wanting to be a fully validating segwit node running on the latest, but with segwit incompatible mining hardware #9955
 86 2017-03-09T05:37:45  <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
 87 2017-03-09T05:39:13  <jeremyrubin> The question is, if you're never going to mine a transaction why would you want it in your mempool? (other than, perhaps, compact blocks)
 88 2017-03-09T05:40:52  <luke-jr> jeremyrubin: it would be fairly irresponsible for a miner to have a mere 10 MB mempool in the first place..
 89 2017-03-09T05:41:26  <luke-jr> the default of 300 MB is for non-mining nodes
 90 2017-03-09T05:42:39  <jeremyrubin> luke-jr: was only for convenience picking a number.
 91 2017-03-09T05:42:58  <luke-jr> point is they should have more than enough
 92 2017-03-09T05:43:02  <jeremyrubin> no
 93 2017-03-09T05:43:30  *** dodomojo has joined #bitcoin-core-dev
 94 2017-03-09T05:43:43  <jeremyrubin> there is actually an attack that you can do with a more well resourced miner (larger mempool) against a less well resourced node that can't mine segwit txns
 95 2017-03-09T05:44:46  <jeremyrubin> e.g., let's say I have a consistent segwit fee around 10 sat/byte, filling up at all times the top 10MB of the mempool
 96 2017-03-09T05:44:58  <jeremyrubin> all txns will be selected from that range always
 97 2017-03-09T05:45:58  <jeremyrubin> so then, I issue 290 MB of txns that are at 9 sat/byte, with segwit, such that they won't be mined
 98 2017-03-09T05:46:35  <jeremyrubin> let's say I also have a bunch on non-segwit txns at 9 sat/byte
 99 2017-03-09T05:46:47  <jeremyrubin> I can push them out with my segwit txns
100 2017-03-09T05:47:27  <jeremyrubin> so that your less well resourced miner now has a mempool full of txns you can't mine
101 2017-03-09T05:47:58  *** dodomojo has quit IRC
102 2017-03-09T06:19:41  <gmaxwell> jeremyrubin: we don't know in advance of someone calling GBT what they're going to call it with, and they may call it with a mix of arguments.
103 2017-03-09T06:20:33  <gmaxwell> jeremyrubin: their normal operation as a node shouldn't be impared ... e.g. logical conclusion of what you suggest is that someone who doesn't mine shouldn't have a mempool at all-- which is clearly not true, as its integral to other functions of a node (fast block propagation, fee estimation, txn relay)
104 2017-03-09T06:21:43  <gmaxwell> luke-jr: you say a lot of confusing things, there is nothing wrong with having a 300 mb mempool as a miner and CNB is effectively the same speed for all mempool sizes.  Having a small mempool may also adversely impact your block reception speed.
105 2017-03-09T06:22:53  <gmaxwell> tiny mempools also prevent users from being able to create low priority transactions that get mined in off hours... which is bad because without a supply of lower priority transactions the spare capacity will instead by used for less useful/efficient uses that continually rebroadcast.
106 2017-03-09T06:22:55  <luke-jr> gmaxwell: I'm saying a small mempool is bad..
107 2017-03-09T06:22:59  <gmaxwell> oh okay!
108 2017-03-09T06:23:20  <gmaxwell> I had read your comment backwards.
109 2017-03-09T06:23:49  <gmaxwell> jeremyrubin: okay thanks for at least clarifying what you meant. (I don't think it's a good idea at all-- but at least it makes logical sense to me now)
110 2017-03-09T06:25:15  *** afk11 has quit IRC
111 2017-03-09T06:25:56  *** afk11 has joined #bitcoin-core-dev
112 2017-03-09T06:27:44  <jeremyrubin> gmaxwell: that's fair; what I'm suggesting might be better off as a startup time argument
113 2017-03-09T06:28:40  <jeremyrubin> gmaxwell: I also think that you can relay a txn w/o having it in your mempool (e.g., to your immediate peers)
114 2017-03-09T06:29:18  <jeremyrubin> gmaxwell: w.r.t. fee estimation, you could collect the fee estimate information for such transactions without storing them
115 2017-03-09T06:29:21  <sipa> jeremyrubin: BIP152 relay speed depends on having transactions in your mempool
116 2017-03-09T06:29:29  <sipa> (or at least, stored somewhere)
117 2017-03-09T06:29:31  <gmaxwell> jeremyrubin: not as soon as there is a dependency, and we also use the mempool as a dynamic rate control.
118 2017-03-09T06:29:43  <jeremyrubin> yes, as I said, compact blocks is the place where it does make sense to keep them
119 2017-03-09T06:30:16  <gmaxwell> jeremyrubin: you have to remember information about them, it could be just their IDs and feerates, rather than the whole things. but you would get less accurate results since you'd overestimate the time it took for things that were evicted.
120 2017-03-09T06:30:56  <gmaxwell> In any case what you are suggesting is 99% orthorgonal, since you do not know at the rest of operation what your future GBT calls will be.
121 2017-03-09T06:32:18  <jeremyrubin> yeah; this would only make sense where you know that none of your calls would need it
122 2017-03-09T06:35:22  *** arubi has quit IRC
123 2017-03-09T06:35:49  *** arubi has joined #bitcoin-core-dev
124 2017-03-09T06:37:32  *** dodomojo has joined #bitcoin-core-dev
125 2017-03-09T06:41:01  *** juscamarena has quit IRC
126 2017-03-09T06:41:52  *** dodomojo has quit IRC
127 2017-03-09T06:42:05  *** juscamarena has joined #bitcoin-core-dev
128 2017-03-09T06:42:45  *** chris2000 has joined #bitcoin-core-dev
129 2017-03-09T06:43:28  *** wudayoda has joined #bitcoin-core-dev
130 2017-03-09T06:43:37  *** chris2000 has joined #bitcoin-core-dev
131 2017-03-09T06:47:57  *** wudayoda has quit IRC
132 2017-03-09T07:13:31  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/6996e066b538...c047b1663d47
133 2017-03-09T07:13:32  <bitcoin-git> bitcoin/master 8a52281 Karl-Johan Alm: Refactor: Remove using namespace <xxx> from wallet/
134 2017-03-09T07:13:32  <bitcoin-git> bitcoin/master a57845c Karl-Johan Alm: Refactor: Remove using namespace <xxx> from util*
135 2017-03-09T07:13:33  <bitcoin-git> bitcoin/master c047b16 Wladimir J. van der Laan: Merge #9643: [refactor] Remove using namespace <xxx> from wallet/ & util*...
136 2017-03-09T07:13:48  <bitcoin-git> [bitcoin] laanwj closed pull request #9643: [refactor] Remove using namespace <xxx> from wallet/ & util* (master...no-using-namespace-wallet-util) https://github.com/bitcoin/bitcoin/pull/9643
137 2017-03-09T07:16:07  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/c047b1663d47...8152d3fe57a9
138 2017-03-09T07:16:08  <bitcoin-git> bitcoin/master f3c264e Karl-Johan Alm: Refactor: Remove using namespace <xxx> from rpc/
139 2017-03-09T07:16:08  <bitcoin-git> bitcoin/master 8cbfc4e Karl-Johan Alm: Refactor: Remove using namespace <xxx> from script/
140 2017-03-09T07:16:09  <bitcoin-git> bitcoin/master 8152d3f Wladimir J. van der Laan: Merge #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources...
141 2017-03-09T07:16:18  <bitcoin-git> [bitcoin] laanwj closed pull request #9476: [refactor] Remove using namespace <xxx> from rpc/ & script/ sources (master...no-using-namespace-rpc-script) https://github.com/bitcoin/bitcoin/pull/9476
142 2017-03-09T07:24:35  *** justanotheruser has quit IRC
143 2017-03-09T07:28:18  <bitcoin-git> [bitcoin] laanwj closed pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (master...RPC_refactor) https://github.com/bitcoin/bitcoin/pull/9958
144 2017-03-09T07:31:29  *** dodomojo has joined #bitcoin-core-dev
145 2017-03-09T07:36:23  *** dodomojo has quit IRC
146 2017-03-09T07:41:57  *** BashCo has quit IRC
147 2017-03-09T07:49:38  <wumpus> okay, that removes the last uses of "using namespace" in the code (apart from one in the tests)
148 2017-03-09T07:50:17  <sipa> nice
149 2017-03-09T07:51:20  <wumpus> I can imagine it's a bit painful for some patches (I have some rebasing to do now, too) but at least this is only a one-time thing
150 2017-03-09T07:53:11  <paveljanik> small pain for big gain!
151 2017-03-09T07:53:15  *** Ylbam has joined #bitcoin-core-dev
152 2017-03-09T08:04:05  *** Guyver2 has joined #bitcoin-core-dev
153 2017-03-09T08:08:08  *** Victorsueca has quit IRC
154 2017-03-09T08:08:13  *** BashCo has joined #bitcoin-core-dev
155 2017-03-09T08:09:10  *** Victorsueca has joined #bitcoin-core-dev
156 2017-03-09T08:10:04  *** veleiro has quit IRC
157 2017-03-09T08:33:08  *** Victorsueca has quit IRC
158 2017-03-09T08:33:17  *** Victor_sueca has joined #bitcoin-core-dev
159 2017-03-09T08:33:30  *** Victor_sueca is now known as Victorsueca
160 2017-03-09T08:44:11  *** wudayoda has joined #bitcoin-core-dev
161 2017-03-09T08:48:57  *** wudayoda has quit IRC
162 2017-03-09T08:51:41  *** juscamarena has quit IRC
163 2017-03-09T08:52:06  *** juscamarena has joined #bitcoin-core-dev
164 2017-03-09T09:01:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8152d3fe57a9...6805c4112cfd
165 2017-03-09T09:01:25  <bitcoin-git> bitcoin/master 54fae05 practicalswift: Remove unreachable code (g_rpcSignals.PostCommand)
166 2017-03-09T09:01:26  <bitcoin-git> bitcoin/master 6805c41 Wladimir J. van der Laan: Merge #9575: Remove unused, non-working RPC PostCommand signal...
167 2017-03-09T09:01:36  <bitcoin-git> [bitcoin] laanwj closed pull request #9575: Remove unused, non-working RPC PostCommand signal (master...never-executed-comment) https://github.com/bitcoin/bitcoin/pull/9575
168 2017-03-09T09:02:37  <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/6805c4112cfd...02bd6e9bc6de
169 2017-03-09T09:02:38  <bitcoin-git> bitcoin/master 6d07c62 John Newbery: Return correct error codes in bumpfee()....
170 2017-03-09T09:02:39  <bitcoin-git> bitcoin/master c119096 John Newbery: Return correct error codes in blockchain.cpp....
171 2017-03-09T09:02:39  <bitcoin-git> bitcoin/master 960bc7f John Newbery: Return correct error codes in removeprunedfunds()....
172 2017-03-09T09:03:01  <bitcoin-git> [bitcoin] laanwj closed pull request #9853: Fix error codes from various RPCs (master...fixerrorcodes) https://github.com/bitcoin/bitcoin/pull/9853
173 2017-03-09T09:03:15  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/02bd6e9bc6de...b403ec5c0f2f
174 2017-03-09T09:03:16  <bitcoin-git> bitcoin/master 292112f kobake: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
175 2017-03-09T09:03:16  <bitcoin-git> bitcoin/master 8e0720b kobake: Fix msvc compiler error C4146 (unary minus operator applied to unsigned type)...
176 2017-03-09T09:03:17  <bitcoin-git> bitcoin/master b403ec5 Wladimir J. van der Laan: Merge #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type)...
177 2017-03-09T09:03:36  <bitcoin-git> [bitcoin] laanwj closed pull request #9916: Fix msvc compiler error C4146 (minus operator applied to unsigned type) (master...fix-minus-operator-target-for-msvc-c4146) https://github.com/bitcoin/bitcoin/pull/9916
178 2017-03-09T09:06:48  *** Victorsueca has quit IRC
179 2017-03-09T09:07:20  *** Victorsueca has joined #bitcoin-core-dev
180 2017-03-09T09:12:38  *** pavel_ has joined #bitcoin-core-dev
181 2017-03-09T09:15:28  *** paveljanik has quit IRC
182 2017-03-09T09:15:39  *** Guyver2 has quit IRC
183 2017-03-09T09:19:57  *** dodomojo has joined #bitcoin-core-dev
184 2017-03-09T09:19:59  <bitcoin-git> [bitcoin] practicalswift opened pull request #9962: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06 (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
185 2017-03-09T09:22:49  *** BashCo_ has joined #bitcoin-core-dev
186 2017-03-09T09:22:54  *** whphhg has quit IRC
187 2017-03-09T09:23:11  *** Lauda has quit IRC
188 2017-03-09T09:23:48  *** Victorsueca has quit IRC
189 2017-03-09T09:23:55  *** Lauda has joined #bitcoin-core-dev
190 2017-03-09T09:24:16  *** dodomojo has quit IRC
191 2017-03-09T09:25:27  *** BashCo has quit IRC
192 2017-03-09T09:25:55  *** Victorsueca has joined #bitcoin-core-dev
193 2017-03-09T09:27:57  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b403ec5c0f2f...c71f0ca5f839
194 2017-03-09T09:27:57  <bitcoin-git> bitcoin/master 3cef950 NicolasDorier: Trivial: Add const modifier to GetHDChain and IsHDEnabled
195 2017-03-09T09:27:58  <bitcoin-git> bitcoin/master c71f0ca Wladimir J. van der Laan: Merge #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled...
196 2017-03-09T09:28:15  <bitcoin-git> [bitcoin] laanwj closed pull request #9960: Trivial: Add const modifier to GetHDChain and IsHDEnabled (master...consthd) https://github.com/bitcoin/bitcoin/pull/9960
197 2017-03-09T09:31:41  *** pavel_ has quit IRC
198 2017-03-09T09:33:48  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c71f0ca5f839...e3e7db829ecd
199 2017-03-09T09:33:49  <bitcoin-git> bitcoin/master 53a2ba3 practicalswift: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)
200 2017-03-09T09:33:49  <bitcoin-git> bitcoin/master e3e7db8 Wladimir J. van der Laan: Merge #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr)...
201 2017-03-09T09:34:01  <bitcoin-git> [bitcoin] laanwj closed pull request #9538: [util] Remove redundant call to get() on smart pointer (thread_specific_ptr) (master...remove-redundant-get-on-smartptr) https://github.com/bitcoin/bitcoin/pull/9538
202 2017-03-09T09:41:08  *** chjj has quit IRC
203 2017-03-09T09:47:09  *** whphhg has joined #bitcoin-core-dev
204 2017-03-09T09:48:55  *** chjj has joined #bitcoin-core-dev
205 2017-03-09T09:57:18  *** whphhg has quit IRC
206 2017-03-09T10:03:51  *** JackH has joined #bitcoin-core-dev
207 2017-03-09T10:14:16  *** whphhg has joined #bitcoin-core-dev
208 2017-03-09T10:36:17  *** MarcoFalke has joined #bitcoin-core-dev
209 2017-03-09T10:39:18  *** BirneGetreide_ has joined #bitcoin-core-dev
210 2017-03-09T10:40:47  *** MarcoFalke has left #bitcoin-core-dev
211 2017-03-09T10:42:30  <bitcoin-git> [bitcoin] laanwj opened pull request #9963: util: Properly handle errors during log message formatting (master...2017_03_handle_exception_tinyformat) https://github.com/bitcoin/bitcoin/pull/9963
212 2017-03-09T10:44:58  *** wudayoda has joined #bitcoin-core-dev
213 2017-03-09T10:47:03  *** BirneGetreide_ has quit IRC
214 2017-03-09T10:48:25  *** BirneGetreide_ has joined #bitcoin-core-dev
215 2017-03-09T10:49:27  *** wudayoda has quit IRC
216 2017-03-09T10:49:57  *** MarcoFalke has joined #bitcoin-core-dev
217 2017-03-09T10:51:06  *** BirneGetreide_ has quit IRC
218 2017-03-09T10:57:59  *** chris200_ has joined #bitcoin-core-dev
219 2017-03-09T11:01:56  *** chris2000 has quit IRC
220 2017-03-09T11:02:27  <jonasschnelli> I still try to understand why importing a P2PKH address into the wallet leads to ISMINE_WATCH_UNSOLVABLE (and not ISMINE_WATCH_SOLVABLE).
221 2017-03-09T11:02:41  <jonasschnelli> The comment for ISMINE_WATCH_SOLVABLE says: "Indicates that we know how to create a scriptSig that would solve this if we were given the appropriate private keys"
222 2017-03-09T11:03:36  <jonasschnelli> Isn't this true for P2PKH (== importaddress could identify P2PKH)?
223 2017-03-09T11:06:40  <luke-jr> I suspect the requirement of the public key might play a part
224 2017-03-09T11:06:51  <luke-jr> you could calculate it from the private key, but that may not count
225 2017-03-09T11:08:00  *** dodomojo has joined #bitcoin-core-dev
226 2017-03-09T11:08:44  *** chris200_ has quit IRC
227 2017-03-09T11:09:11  *** chris2000 has joined #bitcoin-core-dev
228 2017-03-09T11:12:25  *** dodomojo has quit IRC
229 2017-03-09T11:13:27  <jonasschnelli> luke-jr: Yes. When I import a pubkey it will marke the P2PKH watch-only as solveble.
230 2017-03-09T11:13:51  <jonasschnelli> But I don't see a clear reason for that. I understand that for P2SH but not for P2PKH...
231 2017-03-09T11:16:27  *** AaronvanW has joined #bitcoin-core-dev
232 2017-03-09T11:19:09  *** jannes has joined #bitcoin-core-dev
233 2017-03-09T11:34:55  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e3e7db829ecd...5703dff0939f
234 2017-03-09T11:34:55  <bitcoin-git> bitcoin/master 9ea2490 practicalswift: [trival] Fix typo introduced into rpc/protocol.h in commit 338bf06...
235 2017-03-09T11:34:56  <bitcoin-git> bitcoin/master 5703dff MarcoFalke: Merge #9962: [trivial] Fix typo in rpc/protocol.h...
236 2017-03-09T11:35:16  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9962: [trivial] Fix typo in rpc/protocol.h (master...fix-typo-in-protocol-h) https://github.com/bitcoin/bitcoin/pull/9962
237 2017-03-09T12:01:53  <wumpus> I just had the wallet RPC test pass... on a leveldb-based wallet on top of #9951. It's a bit of a hack right now but hopefully enough to be able to run all the RPC tests against the cloudabi bitcoind at some point.
238 2017-03-09T12:01:54  <gribble> https://github.com/bitcoin/bitcoin/issues/9951 | Wallet database handling abstractions/simplifications by laanwj · Pull Request #9951 · bitcoin/bitcoin · GitHub
239 2017-03-09T12:02:15  *** dodomojo has joined #bitcoin-core-dev
240 2017-03-09T12:06:40  *** dodomojo has quit IRC
241 2017-03-09T12:45:45  *** wudayoda has joined #bitcoin-core-dev
242 2017-03-09T12:47:40  <bitcoin-git> [bitcoin] practicalswift opened 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
243 2017-03-09T12:50:18  *** wudayoda has quit IRC
244 2017-03-09T13:01:52  *** adiabat has quit IRC
245 2017-03-09T13:17:44  <wumpus> shouldn't we at least be logging a warning if pwallet->GetKey() returns false in https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcdump.cpp#L639?  Or are there legitimate reasons why this could happen?
246 2017-03-09T13:18:14  <wumpus> seems that a dump may be incomplete if it could not find all keys
247 2017-03-09T13:27:27  *** justanotheruser has joined #bitcoin-core-dev
248 2017-03-09T13:30:36  <wumpus> (not that I've ever seen an instance of that problem, but I just wonder that seeing the code)
249 2017-03-09T13:46:12  *** chjj has quit IRC
250 2017-03-09T13:46:45  *** paveljanik has joined #bitcoin-core-dev
251 2017-03-09T13:50:16  *** dodomojo has joined #bitcoin-core-dev
252 2017-03-09T13:50:17  *** alpalp has joined #bitcoin-core-dev
253 2017-03-09T13:50:17  *** alpalp has joined #bitcoin-core-dev
254 2017-03-09T13:54:54  *** dodomojo has quit IRC
255 2017-03-09T14:00:14  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9965: Allow to use unsolveable P2PKH watch-only in fundrawtransaction (master...2017/03/watch_solve) https://github.com/bitcoin/bitcoin/pull/9965
256 2017-03-09T14:27:56  *** bityogi has joined #bitcoin-core-dev
257 2017-03-09T14:44:31  *** dodomojo has joined #bitcoin-core-dev
258 2017-03-09T14:46:31  *** wudayoda has joined #bitcoin-core-dev
259 2017-03-09T14:48:43  *** dodomojo has quit IRC
260 2017-03-09T14:51:34  *** wudayoda has quit IRC
261 2017-03-09T14:54:25  *** wudayoda has joined #bitcoin-core-dev
262 2017-03-09T15:03:27  *** wudayoda has quit IRC
263 2017-03-09T15:04:04  *** jtimon has joined #bitcoin-core-dev
264 2017-03-09T15:11:47  *** wudayoda has joined #bitcoin-core-dev
265 2017-03-09T15:23:43  *** Giszmo has joined #bitcoin-core-dev
266 2017-03-09T15:38:38  *** dodomojo has joined #bitcoin-core-dev
267 2017-03-09T15:42:58  *** dodomojo has quit IRC
268 2017-03-09T15:54:51  *** Sosumi has joined #bitcoin-core-dev
269 2017-03-09T15:59:34  *** rafalcpp_ has joined #bitcoin-core-dev
270 2017-03-09T15:59:37  *** rafalcpp has quit IRC
271 2017-03-09T16:07:21  *** veleiro has joined #bitcoin-core-dev
272 2017-03-09T16:32:42  *** dodomojo has joined #bitcoin-core-dev
273 2017-03-09T16:36:52  *** dodomojo has quit IRC
274 2017-03-09T16:38:35  *** rafalcpp_ has quit IRC
275 2017-03-09T16:38:57  *** rafalcpp has joined #bitcoin-core-dev
276 2017-03-09T16:49:00  *** abpa has joined #bitcoin-core-dev
277 2017-03-09T17:09:05  *** BashCo_ has quit IRC
278 2017-03-09T17:28:21  *** CubicEarth has joined #bitcoin-core-dev
279 2017-03-09T17:32:51  *** adiabat has joined #bitcoin-core-dev
280 2017-03-09T17:46:34  *** BashCo has joined #bitcoin-core-dev
281 2017-03-09T17:49:00  *** voyager_ has quit IRC
282 2017-03-09T17:58:19  *** CubicEarth has quit IRC
283 2017-03-09T18:04:16  *** CubicEarth has joined #bitcoin-core-dev
284 2017-03-09T18:08:10  *** voyager_ has joined #bitcoin-core-dev
285 2017-03-09T18:35:09  *** mol has joined #bitcoin-core-dev
286 2017-03-09T18:37:52  *** veleiro has quit IRC
287 2017-03-09T18:37:58  *** moli_ has quit IRC
288 2017-03-09T18:44:15  *** CubicEarth has quit IRC
289 2017-03-09T19:00:32  <sipa> ploink
290 2017-03-09T19:00:39  *** molz_ has joined #bitcoin-core-dev
291 2017-03-09T19:00:43  <wumpus> #startmeeting
292 2017-03-09T19:00:43  <lightningbot> Meeting started Thu Mar  9 19:00:43 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
293 2017-03-09T19:00:43  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
294 2017-03-09T19:00:47  <jonasschnelli> hi
295 2017-03-09T19:01:02  <sipa> short topic: great work on 0.14 all!
296 2017-03-09T19:01:07  <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt
297 2017-03-09T19:01:08  <wumpus> instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs
298 2017-03-09T19:01:20  <wumpus> yes! congrats all on another great release
299 2017-03-09T19:01:37  <btcdrak> +1
300 2017-03-09T19:02:08  * BlueMatt has seen really great results for miners that have upgraded to 0.14 =D
301 2017-03-09T19:02:08  <morcos> yes i feel like we did a good job getting most of the major things we wanted into it!
302 2017-03-09T19:02:16  <BlueMatt> net seems to have really helped a lot
303 2017-03-09T19:02:50  <achow101> hi
304 2017-03-09T19:02:50  *** jnewbery has joined #bitcoin-core-dev
305 2017-03-09T19:03:02  <wumpus> proposed topic: disclosure of alert key (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1534 reminded me)
306 2017-03-09T19:03:16  <gmaxwell> Hi.
307 2017-03-09T19:03:49  <gmaxwell> There are DOS vulnerablities in older verions that the final alert does not block. :(
308 2017-03-09T19:03:55  <wumpus> #topic alert key disclosure timeline
309 2017-03-09T19:04:00  *** mol has quit IRC
310 2017-03-09T19:04:05  <sipa> gmaxwell: below what version?
311 2017-03-09T19:04:12  <gmaxwell> (unfortunately the old code is stupid)
312 2017-03-09T19:04:18  <achow101> what kind of DOS vulns?
313 2017-03-09T19:04:21  <gmaxwell> All versions. They're worse in older ones.
314 2017-03-09T19:04:38  <gmaxwell> (obviously all versions with alerts enabled)
315 2017-03-09T19:04:51  <sipa> when was that changed?
316 2017-03-09T19:04:53  <wumpus> yes, what kind? just a slowdown, or a crash, or potential remote code execution?
317 2017-03-09T19:05:00  <sipa> OOM
318 2017-03-09T19:05:04  <gmaxwell> No RCE, just OOM.
319 2017-03-09T19:05:41  <btcdrak> so versions <0.12.0 affected?
320 2017-03-09T19:05:52  <wumpus> well. some versions have already been marked as "insecure" on bitcoin.org due to other bugs. Let me see what the threshold is.
321 2017-03-09T19:06:09  <sipa> when was the alert feature disabled by default?
322 2017-03-09T19:06:16  <achow101> 0.12.1
323 2017-03-09T19:06:29  <btcdrak> oh
324 2017-03-09T19:06:39  <BlueMatt> wumpus: we have a list somewhere?
325 2017-03-09T19:06:46  <sipa> are there any major altcoins forked before 0.12 that did not change the alaert key?
326 2017-03-09T19:07:00  <wumpus> https://bitcoin.org/bin/insecure/
327 2017-03-09T19:07:01  <gmaxwell> All the 0.14 nodes sending final alerts constantly is somewhat protective, but unforuntately not absoltely protective.
328 2017-03-09T19:07:22  <gmaxwell> sipa: already looked for that, there were no major ones, but some obscure & dead ones that have been nagged.
329 2017-03-09T19:07:40  <gmaxwell> There are also funds paid to the alert key in the network, I believe 0.01 BTC or so. :P
330 2017-03-09T19:08:18  <wumpus> heheh
331 2017-03-09T19:08:25  <cfields> heh
332 2017-03-09T19:08:27  <gmaxwell> in any case, one possibility would be to not worry too much about it, announce again that version <0.12.1 are vulnerable (there is a lot else they're vulnerable too, I think).
333 2017-03-09T19:08:29  <wumpus> surprised no one ever swiped that
334 2017-03-09T19:08:46  <btcdrak> sipa: most altcoins are on <0.12 codebase, and many never changed the alter key
335 2017-03-09T19:08:53  <gmaxwell> btcdrak: not so.
336 2017-03-09T19:09:08  <wumpus> from what I've seen, altcoins generally do change the alert key, at least from the bitcoin one
337 2017-03-09T19:09:15  <gmaxwell> btcdrak: (didn't change the _litecoin_ alert key, yes, but I searched extensively for this already, months ago.)
338 2017-03-09T19:09:17  <wumpus> many have the litecoin or feathercoin key
339 2017-03-09T19:09:20  <wumpus> yes :)
340 2017-03-09T19:09:43  <sipa> ah
341 2017-03-09T19:09:47  <btcdrak> ah yes, most coins forked from litecoin (and didnt change the network magic either)
342 2017-03-09T19:09:59  <morcos> remind me again what the advantage is of disclosing the key?
343 2017-03-09T19:10:23  <achow101> morcos: making the alert system entirely unreliable (as if it weren't already)
344 2017-03-09T19:10:25  <gmaxwell> to not be responsible for someone else abusing it, among other things.
345 2017-03-09T19:10:41  <gmaxwell> we don't believe the key is actually secure right now in any case.
346 2017-03-09T19:10:54  <sipa> there is no hurry in disclosing it either
347 2017-03-09T19:11:11  <sipa> just a nice to have to close that chapter
348 2017-03-09T19:11:18  <wumpus> to force people to not use it anymore
349 2017-03-09T19:11:24  <btcdrak> they key is useless now anyway that final alert is out.
350 2017-03-09T19:11:25  <wumpus> and also for sake of history
351 2017-03-09T19:11:26  <paveljanik> We can make people upgrade because of the planned alert key discolsure...
352 2017-03-09T19:11:37  <luke-jr> not sure how litecoin alerts are affects if they use a different key
353 2017-03-09T19:11:42  <gmaxwell> we can't make anyone upgrade, and even if we could we wouldn't. :)
354 2017-03-09T19:11:43  <morcos> yes but if there is even nuisance harm that can be done with it.. i think we should announce that its not considred secure but that we're not going to aid people doing nuisance with it by publicly disclosing it until a) we see nuisance or b) some predetermine future point
355 2017-03-09T19:11:52  <wumpus> litecoin is not affected luke-jr - what they do is up to them
356 2017-03-09T19:12:13  <btcdrak> wumpus: they also removed the alert system, but there's a lot on 0.10.x nodes in litecoin
357 2017-03-09T19:12:24  <gmaxwell> morcos: well we're at the predetermined future point now, we announced.. 6 months ago we'd do this after 0.14. The issue there is on careful review of the old code I found several DOS vulnerablities.
358 2017-03-09T19:12:37  <wumpus> yes, this was announced on a timeline
359 2017-03-09T19:12:56  <morcos> right, so change the predetermined point to be further out...  the risk is only that someone blames us for nuisance right?
360 2017-03-09T19:13:02  <achow101> maybe just push back the date even further until <0.12.1 nodes are even fewer?
361 2017-03-09T19:13:25  <BlueMatt> yea, I would vote push another release given old 0.12.0 isnt otherwise insecure?
362 2017-03-09T19:13:32  <wumpus> right, if anyone abuses the key now, they may blame us. If it is public knowledge not so much.
363 2017-03-09T19:13:35  <gmaxwell> It's fine with me, we should emphasize that those older versions are insecure.  If someone dosses them later it's not the end of the world.
364 2017-03-09T19:13:52  <morcos> Except of course we will be blamed if we make it public and someone creates nuisance with it!
365 2017-03-09T19:14:02  <gmaxwell> BlueMatt: I believe it is otherwise insecure at a greater magnitude than the alert DOS attacks.
366 2017-03-09T19:14:06  <paveljanik> gmaxwell, yes, and by emphasizing it, maybe people update...
367 2017-03-09T19:14:26  <gmaxwell> Well anything that has alerts is displaying the hardcoded final alert now...
368 2017-03-09T19:14:33  <achow101> what version did BU remove the alert system? If it is in their 0.12.1, people could dos them, and I don't think they would take kindly to that (drama and FUD and all that)
369 2017-03-09T19:14:42  <btcdrak> so let's announce the vulnerability first that should motivate more people to upgrade old systems or disable the alert system.
370 2017-03-09T19:14:43  <gmaxwell> which says something like (allcaps) warning alert key compromised! upgrade required!.
371 2017-03-09T19:14:53  <jtimon> ACK "<sipa> there is no hurry in disclosing it either"
372 2017-03-09T19:15:34  <luke-jr> gmaxwell: can you get a CVE assigned for one or more of the old DoS?
373 2017-03-09T19:15:38  <gmaxwell> I think some of you are underestimating the cost of this thing... but sure, no rush required.
374 2017-03-09T19:15:44  <wumpus> anyhow, everyone with the alert key could disclose it, even anonymously
375 2017-03-09T19:16:12  <wumpus> don't even know who has it exactly so...
376 2017-03-09T19:16:14  <luke-jr> yes, nobody can be blamed individually if nobody knows who disclosed it
377 2017-03-09T19:16:39  <wumpus> anyhow, any other topics?
378 2017-03-09T19:17:27  <luke-jr> FWIW, ignoring alert keys, I see 539 vulnerable nodes (0.94%)
379 2017-03-09T19:17:28  <gmaxwell> Can we get a clear plan of action here? We'll CVE old versions and remind people these old things are insecure? should we review other fixes and determine if we want to set a higher bar for holy-shit-dont-run-that than 0.12.1?
380 2017-03-09T19:18:02  <luke-jr> updating http://luke.dashjr.org/programs/bitcoin/files/charts/security.html to consider <0.12.1 vulnerable, that goes to 2606 vulnerable nodes (4.54%)
381 2017-03-09T19:18:37  <wumpus> you can't be entirely sure that all of them are vulnerable, they may have patched the code to remove the alert system
382 2017-03-09T19:18:48  <luke-jr> sure, but that's unlikely
383 2017-03-09T19:18:53  <gmaxwell> I think 5% dropping offline would be inconsequential, so avoiding the dos is just a politeness to the users to avoid disrupting other things they may have going on.
384 2017-03-09T19:19:02  <wumpus> many are running old versions to be able to run their own (outdated) patches on top
385 2017-03-09T19:19:25  <achow101> gmaxwell: how about CVE the dos vulns you found, post messages an all forums about vulnerable nodes, and then release the key a few weeks later?
386 2017-03-09T19:19:32  <luke-jr> if we're really worried, we could release a 0.12.2 with just those exploits fixed
387 2017-03-09T19:19:41  <luke-jr> or maybe simply disabling alerts
388 2017-03-09T19:19:49  <gmaxwell> luke-jr: 0.12.1 has them disabled.
389 2017-03-09T19:19:52  <achow101> luke-jr: 0.12.1 already disabled alrets
390 2017-03-09T19:19:54  <morcos> if it was me, i wouldn't do any of it...  lets put our effort where it matters.. 0.15
391 2017-03-09T19:19:55  <luke-jr> oh, duh
392 2017-03-09T19:20:09  <luke-jr> so why wouldn't people held back by patches just rebase?
393 2017-03-09T19:20:13  <luke-jr> to 0.12.1
394 2017-03-09T19:20:24  <wumpus> 0.12.0 can easily upgrad to 0.12.1, 0.11.x maybe less so
395 2017-03-09T19:20:47  <btcdrak> considering there's an alert message broadcasting to all those vulnerable nodes right now saying they should upgrade, I think we've probably done enough.
396 2017-03-09T19:20:55  <wumpus> not going to do a new 0.11.x release though
397 2017-03-09T19:21:55  <luke-jr> get and publish a CVE, then 2 weeks later publish the key
398 2017-03-09T19:21:57  <luke-jr> ?
399 2017-03-09T19:22:23  <wumpus> I guess we could push a patch to the 0.11 branch that disables the alert system
400 2017-03-09T19:22:33  <gmaxwell> it's a trivial patch.
401 2017-03-09T19:22:40  <wumpus> yes
402 2017-03-09T19:22:42  <achow101> luke-jr: +1
403 2017-03-09T19:22:44  *** adiabat has quit IRC
404 2017-03-09T19:23:08  <gmaxwell> nothing before 0.8 still works at all, and the 0.9x nodes I have looked at are all fake.
405 2017-03-09T19:23:21  <gmaxwell> 0.10 / 0.11 are probably still running in practice.
406 2017-03-09T19:23:56  <gmaxwell> luke-jr: okay fine with CVE and we can patch the old branch. thats enough plan for me for now.
407 2017-03-09T19:24:11  <wumpus> it's a one-line patch, could even do a tag, just not going to build executables for them anymore
408 2017-03-09T19:25:55  <gmaxwell> Thanks.
409 2017-03-09T19:26:44  <sipa> sgtm
410 2017-03-09T19:27:10  <achow101> I suppose the bitcoin.org alert page should be updated with that info then
411 2017-03-09T19:27:11  <jtimon> I'm happy to review any backports for an alert patch, even if they're old, won't go below 0.8, sorry
412 2017-03-09T19:28:29  <btcdrak> everything from 0.10 and below is EOL https://bitcoincore.org/en/lifecycle/#schedule
413 2017-03-09T19:29:06  <sipa> btcdrak: 0.14 should be added to that page
414 2017-03-09T19:29:29  <btcdrak> sipa: https://github.com/bitcoin-core/bitcoincore.org/pull/347
415 2017-03-09T19:29:45  <gmaxwell> what other subjects?
416 2017-03-09T19:30:54  <cfields> Is there a timeline for 0.14.1? Or just when deemed necessary?
417 2017-03-09T19:31:07  <achow101> it seems that 0.10 is the only one that needs an alert disabling patch. 0.11 already has it, just not tagged
418 2017-03-09T19:31:22  <wumpus> cfields: eh not really; any pressing reason you'd want one right away?
419 2017-03-09T19:32:05  <wumpus> the more-than-8-addnode hang at shutdown problem is annoying but not enough to warrant an immediate release
420 2017-03-09T19:32:10  <gmaxwell> I don't see a reason one couldn't wait a few weeks, though we do have material for one.
421 2017-03-09T19:32:17  <cfields> wumpus: nope, just couldn't remember if we usually set a date or just wing it
422 2017-03-09T19:32:29  <wumpus> no, we never set dates in advance for minor releases
423 2017-03-09T19:32:46  <wumpus> for 0.15 I've posted the release schedule: https://github.com/bitcoin/bitcoin/issues/9961
424 2017-03-09T19:33:09  <gmaxwell> I'm sure that some more things will show up for 0.14.1 in not too long as people start using some of the new features.
425 2017-03-09T19:33:35  <wumpus> yes
426 2017-03-09T19:33:36  <achow101> I feel like those should have been caught during RCs..
427 2017-03-09T19:33:47  <wumpus> 'should have been'
428 2017-03-09T19:33:54  <BlueMatt> #9959 and #9955 are interesting for 0.14.1
429 2017-03-09T19:33:56  <gribble> https://github.com/bitcoin/bitcoin/issues/9959 | Mining: Prevent slowdown in CreateNewBlock on large mempools by sdaftuar · Pull Request #9959 · bitcoin/bitcoin · GitHub
430 2017-03-09T19:33:57  <gribble> https://github.com/bitcoin/bitcoin/issues/9955 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
431 2017-03-09T19:34:33  <wumpus> there's always issues in major releases that only get found when the final is tagged, it's a fact of life
432 2017-03-09T19:34:42  <gmaxwell> achow101: any kind of bug that requires special configuration to find is much less likely to get caught, this is why you hear groans when people propose solving problems with more config options. :)
433 2017-03-09T19:34:46  <wumpus> no number of rcs can solve that
434 2017-03-09T19:34:46  <luke-jr> 9955 is more of a new feature IMO, but I don't care if people want to backport it
435 2017-03-09T19:34:58  <morcos> agreed, we should tag those for 0.14 or backport or whatever we say, but not cause for expedited minor release
436 2017-03-09T19:35:08  <wumpus> ok tagging them
437 2017-03-09T19:36:13  <cfields> wumpus: 0.15 schedule sgtm.
438 2017-03-09T19:36:36  <luke-jr> note that backporting 9955 is likely a hazard since priority mining doesn't pay attention to fIncludeWitness I think
439 2017-03-09T19:36:38  <wumpus> cfields: thanks, good to know
440 2017-03-09T19:37:03  <luke-jr> should be a trivial thing to fix, but might not conflict
441 2017-03-09T19:37:43  <achow101> are we going to do the release notes wiki thing again?
442 2017-03-09T19:38:03  <wumpus> yes, at the end of the 0.15 release cycle
443 2017-03-09T19:38:22  <achow101> ok
444 2017-03-09T19:38:42  <sdaftuar> priority mining did pay attention to fIncludeWitness, so i think it would be fine, but i haven't tested
445 2017-03-09T19:39:28  *** JackH has quit IRC
446 2017-03-09T19:39:33  <wumpus> achow101: I think it worked quite well; the only problem that came up is merging it with that is in the tree. So better to leave it until the end when people start caring about writing release notes, and until then leave it up to pulls to add something there
447 2017-03-09T19:39:47  <luke-jr> oh, it's tested in a different place, okay
448 2017-03-09T19:41:48  <achow101> anything else?
449 2017-03-09T19:43:25  <sipa> seems not
450 2017-03-09T19:44:31  <wumpus> I don't think so
451 2017-03-09T19:44:45  <wumpus> #endmeeting
452 2017-03-09T19:44:45  <lightningbot> Meeting ended Thu Mar  9 19:44:45 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
453 2017-03-09T19:44:45  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.html
454 2017-03-09T19:44:45  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.txt
455 2017-03-09T19:44:45  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-03-09-19.00.log.html
456 2017-03-09T19:44:47  <achow101> a reminder that daylight savings time in the US begins this weekend so next week's meeting will be an hour later local time
457 2017-03-09T19:45:23  <jl2012> Oh ended?
458 2017-03-09T19:45:41  <jtimon> do you have a topic?
459 2017-03-09T19:45:53  <jl2012> #9443
460 2017-03-09T19:45:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9443 | Repairing the large-work fork warning system by jl2012 · Pull Request #9443 · bitcoin/bitcoin · GitHub
461 2017-03-09T19:45:55  <wumpus> here starting from march 26
462 2017-03-09T19:46:32  <jl2012> This was tagged 0.14
463 2017-03-09T19:46:46  <jl2012> Want to see any chance for 0.15
464 2017-03-09T19:47:50  <jtimon> for some reason I thought that needed rebase
465 2017-03-09T19:48:22  <jl2012> Rebased already
466 2017-03-09T19:48:42  <jtimon> yeah, I see, thanks for the heads up, will review
467 2017-03-09T19:48:53  *** Guyver2 has joined #bitcoin-core-dev
468 2017-03-09T19:49:25  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/9cea1698132ab68b0d6b204ff5c8d154d9192b19
469 2017-03-09T19:49:26  <bitcoin-git> bitcoin/0.10 9cea169 Wladimir J. van der Laan: net: Disable P2P alert system
470 2017-03-09T19:49:36  <sdaftuar> jl2012: if i understand correctly, that PR would cause us to not ban peers who are on an incompatible chain?
471 2017-03-09T19:50:00  <jl2012> It should ban
472 2017-03-09T19:50:00  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/0bace8307995ac2911885c7c8b8dec19b864eaa3
473 2017-03-09T19:50:00  <bitcoin-git> bitcoin/0.11 0bace83 Wladimir J. van der Laan: net: Disable P2P alert system
474 2017-03-09T19:50:24  <sdaftuar> ah, i will re-read more carefully
475 2017-03-09T19:50:34  <jl2012> It just stirs the header
476 2017-03-09T19:50:49  *** JackH has joined #bitcoin-core-dev
477 2017-03-09T19:50:52  <jl2012> Stores
478 2017-03-09T19:50:53  <achow101> wumpus: coulda just set DEFAULT_ALERTS to false
479 2017-03-09T19:51:14  <wumpus> achow101:did that exist in 0.10 and 0.11?
480 2017-03-09T19:51:17  <achow101> yes
481 2017-03-09T19:51:21  <achow101> 0.11 had it false too
482 2017-03-09T19:51:26  <achow101> (but not tagged)
483 2017-03-09T19:51:33  <wumpus> achow101: anyhow, this is complete and clear
484 2017-03-09T19:53:13  <achow101> indeed
485 2017-03-09T19:54:10  <jl2012> sdaftuar: it does not ban for sending header for childs of an invalid block
486 2017-03-09T19:55:11  <wumpus> going to tag v0.11.3 and v0.10.5
487 2017-03-09T19:55:21  <btcdrak> wumpus: ~1
488 2017-03-09T19:55:23  <btcdrak> +1
489 2017-03-09T19:55:23  <sdaftuar> jl2012: ah, ok. right now, banning peers who are on an incompatible chain is used to avoid being partitioned from the peers who share our consensus rules.
490 2017-03-09T19:55:25  <wumpus> no RCs necessary for this, I'd say
491 2017-03-09T19:55:38  <sdaftuar> jl2012: there's some discussion of this in #9530
492 2017-03-09T19:55:39  <gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
493 2017-03-09T19:57:37  <sdaftuar> jl2012: i think we can replace the banning with something else, like rotating outbound connections periodically and try dropping any outbound peers on an incompatible chain in favor of a new outbound peer, but i think we'd need to write that code first before we change the DoS banning behavior we have now
494 2017-03-09T19:57:43  <btcdrak> wumpus: what is the EOL date for 0.12?
495 2017-03-09T19:57:44  <kanzure> if some python-bitcoinlib users want to do some code review, here's a mock for bitcoin.rpc.Proxy-- https://github.com/petertodd/python-bitcoinlib/pull/136
496 2017-03-09T19:57:57  *** chjj has joined #bitcoin-core-dev
497 2017-03-09T19:58:43  <sdaftuar> jl2012: i am hoping to work on the topics in #9530 for 0.15 though, if possible
498 2017-03-09T19:58:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9530 | [brainstorm] DoS protection for blocks · Issue #9530 · bitcoin/bitcoin · GitHub
499 2017-03-09T19:58:56  <wumpus> btcdrak: wouldn't that normally be the 0.14 release date?
500 2017-03-09T19:59:16  <kanzure> oh, i assumed the meeting was over. 'scuse me.
501 2017-03-09T19:59:25  <wumpus> yes, the meeting is closed
502 2017-03-09T19:59:47  <wumpus> kanzure: will take a look
503 2017-03-09T20:00:19  <kanzure> i don't think it's directly usable in bitcoin.git because the rpc tests need to actually use real rpc :) (and also we're not using petertodd/python-bitcoinlib in bitcoin rpc tests anyway)
504 2017-03-09T20:00:19  <jl2012> sdaftuar: maybe giving a score lower than 100 for sending child of invalid block?
505 2017-03-09T20:00:44  <jl2012> Before we have a new DoS system
506 2017-03-09T20:01:30  <sipa> please, no more dos scoring
507 2017-03-09T20:03:49  <jl2012> So the plan is completely removing that?
508 2017-03-09T20:08:54  <sipa> i think so. things are either invalid and expensive, in which case we ban, or not, and we don't ban
509 2017-03-09T20:09:45  <sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion, seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
510 2017-03-09T20:11:56  <morcos> sipa: that wasn't super clear
511 2017-03-09T20:12:08  <morcos> there is expensive to produce and expensive to consume
512 2017-03-09T20:12:12  <morcos> both matter
513 2017-03-09T20:14:30  <sipa> right, ratio between cost to the attacker and cost to us is what matters
514 2017-03-09T20:17:30  <btcdrak> wumpus: yes maintenance end will be when 0.14 is released, but what about EOL.
515 2017-03-09T20:18:06  <wumpus> btcdrak: what did we use for other releases?
516 2017-03-09T20:18:44  <bitcoin-git> [bitcoin] MarcoFalke pushed 10 new commits to master: https://github.com/bitcoin/bitcoin/compare/5703dff0939f...8910b4717e5b
517 2017-03-09T20:18:45  <bitcoin-git> bitcoin/master 0e6d23d John Newbery: Add logging to test_framework.py...
518 2017-03-09T20:18:45  <bitcoin-git> bitcoin/master 553a976 John Newbery: Add logging to p2p-segwit.py
519 2017-03-09T20:18:46  <bitcoin-git> bitcoin/master 6d0e325 John Newbery: Use logging in mininode.py...
520 2017-03-09T20:18:50  <wumpus> I guess it's just maintenance end date + something?
521 2017-03-09T20:19:03  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9768: [qa] Add logging to test_framework.py (master...rpctestlogging) https://github.com/bitcoin/bitcoin/pull/9768
522 2017-03-09T20:19:57  <btcdrak> wumpus: seems to be around ~2 years.
523 2017-03-09T20:21:33  <wumpus> btcdrak: sounds good to me
524 2017-03-09T20:23:38  *** JackH has quit IRC
525 2017-03-09T20:24:00  <btcdrak> wumpus:https://github.com/bitcoin-core/bitcoincore.org/pull/347/files
526 2017-03-09T20:25:40  <wumpus> btcdrak: looks good to me
527 2017-03-09T20:27:29  * luke-jr peers at race conditions not fixed by adding atomic<>
528 2017-03-09T20:27:47  *** wudayoda_ has joined #bitcoin-core-dev
529 2017-03-09T20:27:57  *** wudayoda has quit IRC
530 2017-03-09T20:29:29  <gmaxwell> sipa: we can have another mechenism unrelated to DOS to make sure peers on incompatible chains aren't wasiting our slots and contributing to partioning us. Bans are a dumb way to accomplish that.
531 2017-03-09T20:30:03  <wumpus> just kicking is usually enough
532 2017-03-09T20:30:17  <sipa> gmaxwell: that's exactly what i said
533 2017-03-09T20:30:23  <sipa> 12:09:44 < sipa> and independently there is a mechanism for keeping good peers around (which can use relay speed, first to relay blocks/txn, resource comsumpion,
534 2017-03-09T20:30:26  <sipa>                  seemingly on the same chain, ...) as a low-frequency kicking (but not banning)
535 2017-03-09T20:30:32  <wumpus> only spy nodes are persistent enough to keep reconnecting to the same nodes
536 2017-03-09T20:30:40  <gmaxwell> ah I missed the 'seemingly on the same chain'.
537 2017-03-09T20:32:38  <gmaxwell> e.g. we can easily tell when a peer is on a chain we consider recently invalid. (if they advertise a block to us, we'll fetch back its headers, and eventually find it as a child of a block we rejected as invalid)
538 2017-03-09T20:32:50  <gmaxwell> at that point he should be ranked as first to get dropped.
539 2017-03-09T20:33:34  <sipa> right
540 2017-03-09T20:34:55  <gmaxwell> can just be a flag, that gets set when we see he's on an invalid chain, unset if we get a valid block from him. and connection rotation could strictly prefer to punt ... all obvious.
541 2017-03-09T20:43:42  <luke-jr> tfw you rebase something just to realise you forgot to pull master
542 2017-03-09T20:48:43  <wumpus> 'well, that was easy!' 'oh no...'
543 2017-03-09T21:11:26  *** CubicEarth has joined #bitcoin-core-dev
544 2017-03-09T21:15:42  *** CubicEarth has quit IRC
545 2017-03-09T21:18:25  *** CubicEarth has joined #bitcoin-core-dev
546 2017-03-09T21:32:39  *** CubicEarth has quit IRC
547 2017-03-09T21:35:02  *** CubicEarth has joined #bitcoin-core-dev
548 2017-03-09T21:37:43  *** CubicEarth has quit IRC
549 2017-03-09T21:44:26  *** MarcoFalke has left #bitcoin-core-dev
550 2017-03-09T22:18:36  <luke-jr> I think #8694 needs fresh re-reviews :x
551 2017-03-09T22:18:37  <gribble> https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
552 2017-03-09T22:19:19  *** randy-waterhouse has joined #bitcoin-core-dev
553 2017-03-09T22:19:24  <bitcoin-git> [bitcoin] jnewbery opened pull request #9966: Control mempool persistence using a command line parameter (master...mempoolpersistenceoption) https://github.com/bitcoin/bitcoin/pull/9966
554 2017-03-09T22:19:37  *** randy-waterhouse has quit IRC
555 2017-03-09T22:19:37  *** randy-waterhouse has joined #bitcoin-core-dev
556 2017-03-09T22:46:26  *** Guyver2 has quit IRC
557 2017-03-09T22:46:53  *** gribble has quit IRC
558 2017-03-09T23:01:33  *** wasi has quit IRC
559 2017-03-09T23:01:58  *** wasi has joined #bitcoin-core-dev
560 2017-03-09T23:29:00  *** gribble has joined #bitcoin-core-dev
561 2017-03-09T23:30:48  <gmaxwell> apparently the latest electrum nags you to opt into RBF if you tell it to pay a low fee.
562 2017-03-09T23:31:44  <dcousens_> gmaxwell: suprising,  I'd of thought CPFP would be the easier route
563 2017-03-09T23:32:09  <dcousens_> aka, UX escape hatch
564 2017-03-09T23:33:05  <gmaxwell> dcousens_: CPFP is not that useful.
565 2017-03-09T23:33:14  <gmaxwell> Requires that you have change, and involves 2x the transaction data.
566 2017-03-09T23:33:21  <gmaxwell> I mean, it's useful, but RBF is more useful.
567 2017-03-09T23:33:35  <dcousens_> gmaxwell: true,  just remembered as you wrote that it would require the change
568 2017-03-09T23:33:49  <gmaxwell> Think: you were trying to pay low fees and now you have to pay twice a high fee. .. and you don't even always have the option.
569 2017-03-09T23:35:37  <BlueMatt> gmaxwell: that seems like a reasonable route
570 2017-03-09T23:36:08  <gmaxwell> 15:34 < cbits_> gmaxwell: yep, if you slide the fee slider all the way to the left, the rbf box becomes visible and automatically checked.  :-)
571 2017-03-09T23:36:26  <dcousens_> gmaxwell: so RBF doesn't show unless its low fee?
572 2017-03-09T23:36:29  <luke-jr> CPFP is more useful for the recipient than the sender, really.
573 2017-03-09T23:36:47  <luke-jr> prompting to enable RBF for fallback fee seems like a good idea for Core
574 2017-03-09T23:36:51  <gmaxwell> dcousens_: no, you could set it to default on in the prior version, but few users did until it was too late.
575 2017-03-09T23:39:59  *** cbits_ has joined #bitcoin-core-dev
576 2017-03-09T23:43:14  <cbits_> Electrum uses dynamic fees by default now. The last two slider options for fee preference are within 10 blocks, or within 25 blocks. The within 25 blocks option makes the rbf box visible and sets it on.
577 2017-03-09T23:43:44  *** wudayoda_ has quit IRC
578 2017-03-09T23:44:21  *** wudayoda has joined #bitcoin-core-dev
579 2017-03-09T23:45:22  <luke-jr> cbits_: why isn't it always visible?
580 2017-03-09T23:45:58  *** aalex__ has quit IRC
581 2017-03-09T23:46:08  <cbits_> Not sure, probably to be neutral. Less boxes for users to check or figure out. You can make it always visible in settings.
582 2017-03-09T23:46:44  <luke-jr> i c
583 2017-03-09T23:48:53  *** gribble has quit IRC
584 2017-03-09T23:56:25  <achow101> luke-jr: it can be set to always be visible
585 2017-03-09T23:57:10  *** justanotheruser has quit IRC
586 2017-03-09T23:59:20  *** justanotheruser has joined #bitcoin-core-dev