1 2016-11-01T00:12:17  <instagibbs> BlueMatt in not too long it will be 5 digits...
  2 2016-11-01T00:14:09  <sipa> at which point we'll need a bot even more
  3 2016-11-01T00:17:09  *** echonaut3 has joined #bitcoin-core-dev
  4 2016-11-01T00:18:53  *** echonaut has quit IRC
  5 2016-11-01T00:21:40  *** blkdb has quit IRC
  6 2016-11-01T00:21:47  *** blkdb has joined #bitcoin-core-dev
  7 2016-11-01T00:33:30  <nanotube> BlueMatt: that can be easily arranged.
  8 2016-11-01T00:43:23  *** Chris_Stewart_5 has quit IRC
  9 2016-11-01T00:43:32  <GitHub141> [bitcoin] gmaxwell opened pull request #9052: Use RelevantServices instead of node_network in AttemptToEvict. (master...prefer_relevant2) https://github.com/bitcoin/bitcoin/pull/9052
 10 2016-11-01T00:43:41  *** davec has quit IRC
 11 2016-11-01T00:44:25  *** davec has joined #bitcoin-core-dev
 12 2016-11-01T00:45:32  *** binns has quit IRC
 13 2016-11-01T00:45:42  *** binns has joined #bitcoin-core-dev
 14 2016-11-01T00:47:26  <GitHub58> [bitcoin] gmaxwell opened pull request #9053: IBD using chainwork instead of height and not using header timestamps (master...no_checkpoint_for_ibd) https://github.com/bitcoin/bitcoin/pull/9053
 15 2016-11-01T00:47:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9053 | IBD using chainwork instead of height and not using header timestamps by gmaxwell · Pull Request #9053 · bitcoin/bitcoin · GitHub
 16 2016-11-01T00:47:54  <gmaxwell> haha
 17 2016-11-01T00:47:55  *** binns is now known as wbnns
 18 2016-11-01T00:47:57  <nanotube> haha well... i guess gribble should ignore github >_>
 19 2016-11-01T00:48:00  <gmaxwell> so perhaps it should ignore gitub.
 20 2016-11-01T00:48:12  <nanotube> :)
 21 2016-11-01T00:48:22  <sipa> yay, consensus
 22 2016-11-01T00:48:38  <gmaxwell> I like Red #40 dye.
 23 2016-11-01T00:48:39  <gribble> https://github.com/bitcoin/bitcoin/issues/40 | -rpcssl help text by dooglus · Pull Request #40 · bitcoin/bitcoin · GitHub
 24 2016-11-01T00:49:11  <sipa> roses are #FF0000
 25 2016-11-01T00:50:09  <nanotube> the regex just looks for #\d+
 26 2016-11-01T00:50:34  <achow101> #10000
 27 2016-11-01T00:50:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10000 | HTTP Error 404: Not Found
 28 2016-11-01T00:52:14  <sipa> so what if you refer to two in one line, like how #8708 will conflict with #9039
 29 2016-11-01T00:52:16  <gribble> https://github.com/bitcoin/bitcoin/issues/8708 | net: have CConnman handle message sending by theuni · Pull Request #8708 · bitcoin/bitcoin · GitHub
 30 2016-11-01T00:52:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9039 | Various serialization simplifcations and optimizations by sipa · Pull Request #9039 · bitcoin/bitcoin · GitHub
 31 2016-11-01T00:52:28  <phantomcircuit> gmaxwell: int64_t &nOrderNextPos = nOrderNextPos in CWallet::ReorderTransactions is trying to assign a reference to itself not the member variable
 32 2016-11-01T00:52:34  <nanotube> ^ that happens :)
 33 2016-11-01T00:52:36  <phantomcircuit> i dont get this
 34 2016-11-01T00:52:37  <phantomcircuit> do you?
 35 2016-11-01T00:52:50  <sipa> phantomcircuit: ha
 36 2016-11-01T00:53:06  <sipa> phantomcircuit: yes, variables are defined during their own initializer
 37 2016-11-01T00:53:49  <phantomcircuit> ok then i understand what was wrong with #8828
 38 2016-11-01T00:53:51  <gribble> https://github.com/bitcoin/bitcoin/issues/8828 | Move CWalletDB::ReorderTransactions to CWallet by pstratem · Pull Request #8828 · bitcoin/bitcoin · GitHub
 39 2016-11-01T00:54:02  <sipa> similar to how you can call a function inside that function's body
 40 2016-11-01T00:59:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 41 2016-11-01T01:47:52  *** btcdrak has quit IRC
 42 2016-11-01T01:51:13  <sipa> should we introduce http://en.cppreference.com/w/cpp/language/user_literal for uint256?
 43 2016-11-01T01:52:56  <gmaxwell> sipa: would there be any benefits beyond saving a few bytes of source code for each of the couple uint256 constants we have?
 44 2016-11-01T01:57:31  <sipa> no
 45 2016-11-01T01:58:50  <cfields_> sipa: mm, i coded that up at one point
 46 2016-11-01T01:59:40  <cfields_> gmaxwell: it's especially nice because you can initialize on the stack more quickly (and efficiently)
 47 2016-11-01T02:00:10  <sipa> cfields_: it's just an invocation to a conversion operator, instead of a function
 48 2016-11-01T02:00:20  <cfields_> (you can parse a variadic of hex chars as constexpr, so the parsing is free)
 49 2016-11-01T02:00:20  <sipa> i'm pretty sure there's no difference at runtime
 50 2016-11-01T02:00:28  <sipa> oh!
 51 2016-11-01T02:00:39  <sipa> well we could also make uint256S constexpr then?
 52 2016-11-01T02:00:56  <cfields_> sipa: well, it only works for literals
 53 2016-11-01T02:01:15  <gmaxwell> I think in all cases they get stashed in constants, so it shouldn't really make a runtime difference.
 54 2016-11-01T02:02:23  <cfields_> yea, in reality it's negligible. I just did it to play with the variadics + user literals. But it made chainparams look prettier :)
 55 2016-11-01T02:02:28  <cfields_> i'll see if i can dig it up
 56 2016-11-01T02:07:08  <sipa> cfields_: right, but i guess you could at least have a uint256constS function, which is constexpr and does the same thing as the normal uint256S function
 57 2016-11-01T02:07:22  <sipa> which you could only pass literals or other constexpr strings
 58 2016-11-01T02:07:48  <sipa> and compared to that, a user-defined literal is purely syntactic sugar?
 59 2016-11-01T02:09:45  <cfields_> sipa: sure, i suppose so
 60 2016-11-01T02:11:55  *** notmike has joined #bitcoin-core-dev
 61 2016-11-01T02:28:15  *** notmike has quit IRC
 62 2016-11-01T02:35:29  *** notmike has joined #bitcoin-core-dev
 63 2016-11-01T02:37:48  *** Chris_Stewart_5 has quit IRC
 64 2016-11-01T02:39:31  *** echonaut3 has quit IRC
 65 2016-11-01T02:39:48  *** echonaut has joined #bitcoin-core-dev
 66 2016-11-01T02:48:13  *** notmike is now known as notnick
 67 2016-11-01T02:48:30  *** notnick is now known as notmike
 68 2016-11-01T03:17:53  *** btcdrak has joined #bitcoin-core-dev
 69 2016-11-01T03:40:43  <gmaxwell> https://github.com/bitcoin/bitcoin/pull/9053 < can someone trigger a rerun here? I'm pretty sure this change couldn't make test_bitcoin fail (and it passes locally.)
 70 2016-11-01T03:46:53  <sipa> gmaxwell: chainActive.Tip()->nChainWork may segfault before the genesis block is loaded
 71 2016-11-01T03:47:09  <sipa> almost all platforms fail, that doesn't look like a spurious error
 72 2016-11-01T03:48:01  <gmaxwell> sipa: on #1 fair comment, but they're failing in test_bitcoin prevector tests.
 73 2016-11-01T03:48:03  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 74 2016-11-01T03:48:11  <gmaxwell> die
 75 2016-11-01T03:48:21  <sipa> hahahaha
 76 2016-11-01T03:57:13  <luke-jr> lol
 77 2016-11-01T04:10:23  *** PaulCapestany has quit IRC
 78 2016-11-01T04:11:35  *** PaulCapestany has joined #bitcoin-core-dev
 79 2016-11-01T04:16:04  *** dstadulis has joined #bitcoin-core-dev
 80 2016-11-01T04:16:29  *** PaulCapestany has quit IRC
 81 2016-11-01T04:18:44  *** PaulCapestany has joined #bitcoin-core-dev
 82 2016-11-01T04:23:58  *** fengling has joined #bitcoin-core-dev
 83 2016-11-01T05:08:48  *** dstadulis has quit IRC
 84 2016-11-01T05:40:17  <btcdrak> #2
 85 2016-11-01T05:40:19  <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
 86 2016-11-01T05:40:35  <btcdrak> oh thats going to get annoying
 87 2016-11-01T05:41:08  <gmaxwell> Perhaps we should as nano to change it to PR#xxxx
 88 2016-11-01T05:41:13  <sipa> or we adapt
 89 2016-11-01T05:41:45  <gmaxwell> FWIW, there is a bot that does this in #xiph run by someone no one knows, that just spends all its time banned. esp because it links to some trac instance thats hardly used.
 90 2016-11-01T05:42:15  *** rebroad has joined #bitcoin-core-dev
 91 2016-11-01T05:44:45  *** DigiByteDev has joined #bitcoin-core-dev
 92 2016-11-01T05:48:28  <TD-Linux> gmaxwell, it's not banned sadly
 93 2016-11-01T05:52:14  *** notmike has quit IRC
 94 2016-11-01T06:08:52  *** rebroad has quit IRC
 95 2016-11-01T06:36:14  *** servkolhapur has joined #bitcoin-core-dev
 96 2016-11-01T06:36:58  *** notmike has joined #bitcoin-core-dev
 97 2016-11-01T06:42:06  *** notmike has quit IRC
 98 2016-11-01T06:59:07  *** paveljanik has quit IRC
 99 2016-11-01T07:09:54  *** Evel-Knievel has quit IRC
100 2016-11-01T07:14:00  *** rebroad has joined #bitcoin-core-dev
101 2016-11-01T07:19:51  <jonasschnelli> test #8977
102 2016-11-01T07:19:52  <gribble> https://github.com/bitcoin/bitcoin/issues/8977 | [Wallet] Refactor wallet/init interaction (Reaccept wtx, flush thread) by jonasschnelli · Pull Request #8977 · bitcoin/bitcoin · GitHub
103 2016-11-01T07:20:30  <jonasschnelli> I think this is useful,.. but agree maybe double-hash ##xxx would result in less noise.
104 2016-11-01T07:23:30  <sipa> if we want to modify it to something more strict, i'd prefer PRXXXX (without #), as that's easier to type as well
105 2016-11-01T07:24:37  <jonasschnelli> Yes. That would also work...
106 2016-11-01T07:32:37  *** Evel-Knievel has joined #bitcoin-core-dev
107 2016-11-01T07:33:38  <GitHub103> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3d69ecb4edeb...273bde37d867
108 2016-11-01T07:33:38  <GitHub103> bitcoin/master 3333e5a MarcoFalke: [qt] Return useful error message on ATMP failure
109 2016-11-01T07:33:39  <GitHub103> bitcoin/master 273bde3 Jonas Schnelli: Merge #9043: [qt] Return useful error message on ATMP failure...
110 2016-11-01T07:33:53  <GitHub3> [bitcoin] jonasschnelli closed pull request #9043: [qt] Return useful error message on ATMP failure (master...Mf1611-qtATMPerror) https://github.com/bitcoin/bitcoin/pull/9043
111 2016-11-01T07:39:29  *** echonaut has quit IRC
112 2016-11-01T07:39:30  *** echonaut4 has joined #bitcoin-core-dev
113 2016-11-01T07:46:17  <rebroad> does gribble no longer report pull requests I open?
114 2016-11-01T07:48:31  <rebroad> test #9055
115 2016-11-01T07:48:33  <gribble> https://github.com/bitcoin/bitcoin/issues/9055 | Skip processing of cmpctblocks we have previously downloaded. by rebroad · Pull Request #9055 · bitcoin/bitcoin · GitHub
116 2016-11-01T07:49:02  <rebroad> jonasschnelli, what does the test command do please?
117 2016-11-01T07:49:17  <jonasschnelli> rebroad: a test. :)
118 2016-11-01T07:49:36  <rebroad> jonasschnelli, ah, thank you. most enlightening
119 2016-11-01T07:58:38  *** arubi has quit IRC
120 2016-11-01T07:59:20  *** kadoban has quit IRC
121 2016-11-01T08:07:52  *** btcdrak has quit IRC
122 2016-11-01T08:12:30  *** wasi has joined #bitcoin-core-dev
123 2016-11-01T08:18:39  *** molz has joined #bitcoin-core-dev
124 2016-11-01T08:22:20  *** mol has quit IRC
125 2016-11-01T08:27:37  *** btcdrak has joined #bitcoin-core-dev
126 2016-11-01T08:37:49  *** DigiByteDev has quit IRC
127 2016-11-01T08:38:41  *** DigiByteDev has joined #bitcoin-core-dev
128 2016-11-01T08:51:22  *** notmike has joined #bitcoin-core-dev
129 2016-11-01T08:59:34  *** notmike has quit IRC
130 2016-11-01T09:04:02  <jonasschnelli> sipa: how do we detect nodes delaying (or even not sending) requested blocks? Currently I'm debugging a case where I have a couple of blocks "inflight" but the peer is responding extremely slow...
131 2016-11-01T09:04:24  <jonasschnelli> Is there a max timeout or something similar until we release the block from the mapBlocksInFlight?
132 2016-11-01T09:04:32  <jonasschnelli> and re-request it from a different peer?
133 2016-11-01T09:08:20  <gmaxwell> jonasschnelli: yes, we will eventually hang up on the peer after 10 minutes, see BLOCK_DOWNLOAD_TIMEOUT_BASE
134 2016-11-01T09:08:39  <jonasschnelli> gmaxwell: thanks. Also just stumbled over state->nDownloadingSince
135 2016-11-01T09:09:02  <jonasschnelli> gmaxwell: for my hybrid-SPV-PR this seems to be to long...
136 2016-11-01T09:09:14  *** DigiByteDev has quit IRC
137 2016-11-01T09:09:26  <jonasschnelli> I guess there are no other full-block SPV wallets out there... so hard to say what would be best in a such case...
138 2016-11-01T09:10:14  <gmaxwell> why is that any different for hybrid-spv-pr than normal operation?
139 2016-11-01T09:10:35  <jonasschnelli> Yes. Same for normal operation.
140 2016-11-01T09:11:12  <jonasschnelli> If blocks are dropping in in a ~10min interval, the UX of an SPV mode is almost broken..
141 2016-11-01T09:11:27  <gmaxwell> It should be made adaptive. It cannot just be made shorter without making the software dysfunctional for hosts with a slow connection. (as it will get 95% through transfering, then abort, and start over, ... but even slower because the prior transfer left some incoming traffic...)
142 2016-11-01T09:11:32  <jonasschnelli> I guess during full-validation. people tend to be more patient.
143 2016-11-01T09:11:50  <gmaxwell> jonasschnelli: what?
144 2016-11-01T09:12:12  <gmaxwell> are you forcing in order block processing or something?
145 2016-11-01T09:13:02  <gmaxwell> normally during sync the timeout isn't the mechenism that deals with slow peers, the stalling mechenism is.
146 2016-11-01T09:13:08  <jonasschnelli> gmaxwell: I'm working on an SPV modes where the wallet can specifically request (priorize) a block-sequence
147 2016-11-01T09:13:44  <jonasschnelli> "Normal" IBD interrupts, FindNextBlocksToDownload prefers specific request
148 2016-11-01T09:13:56  <gmaxwell> And it doesn't have any tricky and failure prone hard timeouts, it punts peers that stall the transfer.
149 2016-11-01T09:14:21  <gmaxwell> so the good performance of other peers is the test rather than a static timeout.
150 2016-11-01T09:16:36  <jonasschnelli> The SPV modes works mostly okay, but sometimes I encountered that I have connected to extremely slow peers (block response take up to 5mins), which makes the user-experience really inconvenient.
151 2016-11-01T09:17:29  <gmaxwell> this is handled by the initial block download logic. It fetches blocks out of order, and when a peer is slower than all the others thus stalling things, it gets kicked off.
152 2016-11-01T09:19:22  <jonasschnelli> Haven't fully analyzed "nNow > state.nDownloadingSince + consensusParams.nPowTargetSpacing * (BLOCK_DOWNLOAD_TIMEOUT_BASE + BLOCK_DOWNLOAD_TIMEOUT_PER_PEER * nOtherPeersWithValidatedDownloads)"... but it seems to not trigger a 5 min delayed block around the tip
153 2016-11-01T09:20:26  <gmaxwell> the timeout is 10 minutes. (at the tip, normally we expect things to be transfered via BIP152 high bandwidth mode, which can't stall)
154 2016-11-01T09:21:07  <gmaxwell> (well my recollection is 10 minutes, and if it is set statically less then 10 minutes you will have hosts with enough bandwidth to successfully use the system constant dos attacking themselves.)
155 2016-11-01T09:22:01  <jonasschnelli> Okay. Thanks.
156 2016-11-01T09:22:22  <jonasschnelli> BIP152 doesn't helps in the SPV mode (UTXO set not ready)
157 2016-11-01T09:22:53  <gmaxwell> UTXO set? you mean mempool.
158 2016-11-01T09:23:12  <jonasschnelli> Yes. But no UXTO set no mempool. :)
159 2016-11-01T09:23:39  *** notmike has joined #bitcoin-core-dev
160 2016-11-01T09:24:51  <jonasschnelli> Also not sure, but could it be, that the parallel block download during the time, when we initially sync the headers could slow down the header sync?
161 2016-11-01T09:25:29  <jonasschnelli> As soon as we have the first header batch, we start download those blocks (which is fine in normal operation), but in SPV, I'd prefer to get the headers with priority.
162 2016-11-01T09:25:38  *** rebroad has quit IRC
163 2016-11-01T09:25:49  <gmaxwell> the header sync is very fast, and we do not use much bandwidth early in the sync due to the many round trips needed due to small batches. So I doubt it does.
164 2016-11-01T09:26:47  *** DigiByteDev has joined #bitcoin-core-dev
165 2016-11-01T09:27:49  <gmaxwell> in any case, as I said before... the timeout can be made dynamic. It just needs to start at a safe number like ten minutes, and then when a block transfers faster than 10 minutes, it can be reduced to e.g. 2 sec + 2*(block_time*1m/block_size) or such, and any time it kicks off a peer due to a failure, double again with a max of 10 minutes. This way it will not have a timeout so slow that it will
166 2016-11-01T09:27:55  <gmaxwell>  cause failure, and if the node's bandwidth goes down, it will adapt back after a couple failures.
167 2016-11-01T09:28:35  <gmaxwell> that kind of adaptive threshold just wasn't very important so far because of the combination of other methods.
168 2016-11-01T09:28:48  *** notmike has quit IRC
169 2016-11-01T09:35:29  *** jannes has joined #bitcoin-core-dev
170 2016-11-01T09:45:28  <phantomcircuit> jonasschnelli: hybrid-spv-pr?
171 2016-11-01T09:45:29  <phantomcircuit> wat
172 2016-11-01T10:04:40  *** rebroad has joined #bitcoin-core-dev
173 2016-11-01T10:06:37  *** rebroad has quit IRC
174 2016-11-01T10:10:19  *** fengling has quit IRC
175 2016-11-01T10:12:58  *** Victorsueca has quit IRC
176 2016-11-01T10:21:29  *** rebroad has joined #bitcoin-core-dev
177 2016-11-01T10:24:26  *** murch has joined #bitcoin-core-dev
178 2016-11-01T10:26:37  *** notmike has joined #bitcoin-core-dev
179 2016-11-01T10:31:45  *** notmike has quit IRC
180 2016-11-01T10:37:00  *** rebroad has quit IRC
181 2016-11-01T10:49:55  *** fengling has joined #bitcoin-core-dev
182 2016-11-01T10:54:43  *** fengling has quit IRC
183 2016-11-01T11:12:14  *** Guyver2 has joined #bitcoin-core-dev
184 2016-11-01T11:16:37  *** cryptapus has joined #bitcoin-core-dev
185 2016-11-01T11:16:37  *** cryptapus has joined #bitcoin-core-dev
186 2016-11-01T11:50:56  *** fengling has joined #bitcoin-core-dev
187 2016-11-01T11:55:46  *** fengling has quit IRC
188 2016-11-01T11:57:56  *** rebroad has joined #bitcoin-core-dev
189 2016-11-01T12:15:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
190 2016-11-01T12:18:49  *** wasi has quit IRC
191 2016-11-01T12:20:17  *** Chris_Stewart_5 has quit IRC
192 2016-11-01T12:20:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
193 2016-11-01T12:24:27  *** dermoth_ has joined #bitcoin-core-dev
194 2016-11-01T12:24:53  *** dermoth has quit IRC
195 2016-11-01T12:24:55  *** dermoth_ is now known as dermoth
196 2016-11-01T12:37:51  *** wasi has joined #bitcoin-core-dev
197 2016-11-01T12:44:58  <jl2012> sipa: I got a question from a block explorer dev. How do we want people to present bare segwit on explorers?
198 2016-11-01T12:47:18  <jl2012> I never thought of that. Maybe using the hex?
199 2016-11-01T12:47:49  *** DigiByteDev has quit IRC
200 2016-11-01T12:51:58  *** fengling has joined #bitcoin-core-dev
201 2016-11-01T12:56:49  *** fengling has quit IRC
202 2016-11-01T13:03:26  *** ClockCat has joined #bitcoin-core-dev
203 2016-11-01T13:15:51  <jonasschnelli> phantomcircuit: Yes. Will PR soon. Need to write a RPC test first,... which is non-trivial
204 2016-11-01T13:16:28  <jonasschnelli> I guess you are familiar with the idea of SPV during IBD/sync (= hybrid SPV)
205 2016-11-01T13:20:36  *** laurentmt has joined #bitcoin-core-dev
206 2016-11-01T13:20:42  *** laurentmt has quit IRC
207 2016-11-01T13:37:33  *** Guyver2 has quit IRC
208 2016-11-01T13:40:53  *** Guyver2 has joined #bitcoin-core-dev
209 2016-11-01T13:50:24  *** cryptapus has quit IRC
210 2016-11-01T13:51:16  *** Chris_Stewart_5 has quit IRC
211 2016-11-01T13:53:00  *** fengling has joined #bitcoin-core-dev
212 2016-11-01T13:57:52  *** fengling has quit IRC
213 2016-11-01T14:03:02  *** Guyver2 has quit IRC
214 2016-11-01T14:04:08  *** Guyver2 has joined #bitcoin-core-dev
215 2016-11-01T14:05:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
216 2016-11-01T14:19:01  *** aalex has quit IRC
217 2016-11-01T14:20:37  *** DigiByteDev has joined #bitcoin-core-dev
218 2016-11-01T14:21:43  *** rebroad has quit IRC
219 2016-11-01T14:27:53  *** DigiByteDev has quit IRC
220 2016-11-01T14:53:59  *** fengling has joined #bitcoin-core-dev
221 2016-11-01T14:54:28  <GitHub45> [bitcoin] ryanofsky opened pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (master...fix-8842-sync-timeouts) https://github.com/bitcoin/bitcoin/pull/9058
222 2016-11-01T14:58:55  *** fengling has quit IRC
223 2016-11-01T15:05:11  <phantomcircuit> jonasschnelli: ah yeah
224 2016-11-01T15:05:15  <phantomcircuit> for the wallet only right?
225 2016-11-01T15:07:26  <jl2012> sipa: for block explorer, I think they should display bare segwit with P2SH addresses. Just like how they display P2PK as P2PKH address
226 2016-11-01T15:10:48  *** kadoban has joined #bitcoin-core-dev
227 2016-11-01T15:18:06  *** vdefeo has joined #bitcoin-core-dev
228 2016-11-01T15:27:25  *** cryptapus has joined #bitcoin-core-dev
229 2016-11-01T15:32:14  *** notmike has joined #bitcoin-core-dev
230 2016-11-01T15:33:28  *** vdefeo has quit IRC
231 2016-11-01T15:36:38  *** sanada has quit IRC
232 2016-11-01T15:54:47  *** fengling has joined #bitcoin-core-dev
233 2016-11-01T15:55:12  *** ClockCat has quit IRC
234 2016-11-01T15:58:18  *** aalex has joined #bitcoin-core-dev
235 2016-11-01T15:59:58  *** fengling has quit IRC
236 2016-11-01T16:00:08  *** Ylbam has quit IRC
237 2016-11-01T16:08:26  *** PaulCape_ has joined #bitcoin-core-dev
238 2016-11-01T16:08:53  *** wallet42 has quit IRC
239 2016-11-01T16:10:14  *** wallet42 has joined #bitcoin-core-dev
240 2016-11-01T16:10:45  *** PaulCapestany has quit IRC
241 2016-11-01T16:18:41  <NicolasDorier> jl2012: nop
242 2016-11-01T16:18:46  <NicolasDorier> it confuses new devs
243 2016-11-01T16:19:05  <NicolasDorier> best is just to show 0 <hash>
244 2016-11-01T16:19:22  <jl2012> or just the hex
245 2016-11-01T16:19:29  <NicolasDorier> yeah or just the hex
246 2016-11-01T16:20:24  <NicolasDorier> lost quite a lot of time explaining to noob why the address of the genesis output was not generating the same ScriptPubKey than inside the block
247 2016-11-01T16:38:47  *** sanada has joined #bitcoin-core-dev
248 2016-11-01T16:44:50  *** abpa has joined #bitcoin-core-dev
249 2016-11-01T16:55:59  *** fengling has joined #bitcoin-core-dev
250 2016-11-01T17:01:01  *** fengling has quit IRC
251 2016-11-01T17:16:36  <morcos> cfields_: I got a bit lost trying to follow you, BlueMatt and sipa discussing moving and const members, but I don't think any of that discussion changes the gains I was seeing from your copy-move branch?
252 2016-11-01T17:17:09  <morcos> What do you think about actually PR'ing that.  I've been using it for so long now for all my benching, I'd like to make sure I'm not building my work on a house of cards
253 2016-11-01T17:17:31  <sipa> what does his copy-move branch do?
254 2016-11-01T17:17:38  <gmaxwell> jl2012: showing some other address would cause loss of funds.
255 2016-11-01T17:18:02  <morcos> theuni/bitcoin/copy-move
256 2016-11-01T17:18:30  <gmaxwell> jl2012: people would sends funds to those addresses and because they're not the same, wallets would ignore those payments.
257 2016-11-01T17:18:53  <jl2012> gmaxwell: yes, i think that's not a good idea. But core is still showing P2PK as P2PKH
258 2016-11-01T17:19:21  <sipa> morcos: casting a const field to non-const is undefined behaviour
259 2016-11-01T17:19:27  <gmaxwell> yes, legacy behavior but at least a ubiquitous one.
260 2016-11-01T17:19:27  <morcos> sipa: if i recall cfields was thinking it wouldn't show a big speedup, but it definitely makes a noticeable difference for me.
261 2016-11-01T17:19:38  <jl2012> ok, i told them to use raw hex directly
262 2016-11-01T17:19:45  <sipa> morcos: we currently do it in CTransaction, but I have a PR to get rid of it
263 2016-11-01T17:19:55  <morcos> sipa: you're referring to the move operator for CTransaction (or whatever thats called) in the 2nd commit?
264 2016-11-01T17:20:35  <morcos> i don't think I'm using that though anywhere in the code right.  i didn't make any changes to explicitly use that.  i'm assuming its the other changes that are causing the speedup, so i don't need that part
265 2016-11-01T17:20:59  <morcos> i just briefly tried putting an assert(false) in there and it worked just fine...
266 2016-11-01T17:21:16  <sipa> morcos: oh, making prevector movable is fine!
267 2016-11-01T17:21:25  <sipa> i missed there were two commits
268 2016-11-01T17:21:53  <morcos> it wasn't clear to me if any of the other minor changes in the 2nd commit mattered, i didn't bother trying to track down what was important...
269 2016-11-01T17:22:12  <morcos> pehraps the thing holding cfields_ up from actually PR'ing it is you can't use is_trivially_copyable
270 2016-11-01T17:22:34  <morcos> and maybe he wanted some protection for that
271 2016-11-01T17:25:23  *** Ylbam has joined #bitcoin-core-dev
272 2016-11-01T17:30:51  <sipa> is_trivially_copyable is certainly fine for the current use cases
273 2016-11-01T17:31:23  <morcos> no i mean its not supported everywhere, for instance in gcc 4.8 or whatever i have on ubuntu 14.04
274 2016-11-01T17:32:01  *** notmike has quit IRC
275 2016-11-01T17:33:47  <sipa> that's something you wonder about, or an issue you know?
276 2016-11-01T17:34:05  <morcos> yeah it didn't compile for me until i commented those lines out
277 2016-11-01T17:34:06  <sipa> afaik is_trivially_copyable is just c++11, so every compliant compiler should have it
278 2016-11-01T17:34:39  *** justanotheruser has quit IRC
279 2016-11-01T17:35:13  <gmaxwell> sipa: it's libstdc++ though, not GCC itself.
280 2016-11-01T17:35:22  <morcos> what are those called? traits or attributes or whatever, are the one part of c++11 that gcc 4.8 didn't fully support
281 2016-11-01T17:36:52  <morcos> ehh, type properties.. see https://gcc.gnu.org/onlinedocs/gcc-4.8.4/libstdc++/manual/manual/status.html#status.iso.2011
282 2016-11-01T17:38:59  <sipa> i see
283 2016-11-01T17:41:17  <sipa> well we can temporarily define our own, for just the types we use it for
284 2016-11-01T17:43:07  <morcos> so in your PR to fix CTransaction, you don't define a move constructor right?  would it be benfecial to have one?  or is it useless since the CTransaction it's moving from has all members const?
285 2016-11-01T17:43:22  <morcos> thats where i got lost in yoru conversation the other day
286 2016-11-01T17:43:55  <sipa> right, the move constructor would be identical to the copy constructor
287 2016-11-01T17:44:39  <sipa> and my suggestion is that we solve it at a higher level: if a ctransaction needs to be movable, use a std::unique_ptr or std::shared_ptr around it
288 2016-11-01T17:44:53  <morcos> which is inefficient though huh, since isn't the whole point of the move that you're not going to use the source object any more
289 2016-11-01T17:44:53  <sipa> in particular in CBlock
290 2016-11-01T17:45:12  *** atroxes has quit IRC
291 2016-11-01T17:46:15  <morcos> btw, if you have any brilliant ideas, i've been spending a lot of time trying to figure out how to flush pcoinstip but keep it warm
292 2016-11-01T17:46:30  *** atroxes has joined #bitcoin-core-dev
293 2016-11-01T17:46:46  <morcos> you can do something semi-smart in regular operation by constructing fake blocks (although usually there isn't enough of a mempool backlog for this to be too helpful)
294 2016-11-01T17:47:09  <morcos> but what in the world do you do during startup...
295 2016-11-01T17:50:02  <gmaxwell> oh thats cute... during startup: mempool saving. :) (later: mempool sync)
296 2016-11-01T17:50:42  *** DigiByteDev has joined #bitcoin-core-dev
297 2016-11-01T17:51:50  <morcos> gmaxwell: no i mean when you're in IBD or something (so its not that you don't have a mempool, its that you're connecting blocks from long ago)
298 2016-11-01T17:52:33  <gmaxwell> "don't do it then"
299 2016-11-01T17:53:12  <morcos> it's sad how long HaveInputs takes in a reindex-chainstate or similar operation
300 2016-11-01T17:54:19  <sipa> morcos: even with huge dbcache?
301 2016-11-01T17:54:40  <sipa> because HaveInputs is what triggers the fetch from disk if an entry is not cached
302 2016-11-01T17:54:41  <morcos> sipa: no thats what i mean.  with a reasonable sized one
303 2016-11-01T17:55:09  <morcos> i'm wondering if when you go to flush it, you can be smart about keeping some useful stuff in there...
304 2016-11-01T17:56:11  *** arubi has joined #bitcoin-core-dev
305 2016-11-01T17:56:56  *** fengling has joined #bitcoin-core-dev
306 2016-11-01T18:02:04  *** fengling has quit IRC
307 2016-11-01T18:02:54  <sipa> perhaps we should experiment with per-output caching rather than per-tx
308 2016-11-01T18:05:08  <morcos> sipa: i just worry that without changing the whole database it'll be hard to use that efficiently
309 2016-11-01T18:05:25  <sipa> oh, sure, the database will need to change
310 2016-11-01T18:05:35  <sipa> but it can be converted on startup or so
311 2016-11-01T18:05:56  <morcos> well you could imagine a middle ground.. but yeah i agree, cleaner to just do the whole thing
312 2016-11-01T18:06:34  <sipa> the one thing i'm not clear on is how to deal with the (few) per-tx values
313 2016-11-01T18:08:05  <morcos> well, we should stop storing nVersion
314 2016-11-01T18:08:15  <morcos> i think what we store for that is undefined actually
315 2016-11-01T18:09:01  <sipa> agree, i doubt we'll need it
316 2016-11-01T18:09:02  <morcos> i was trying to trace it yesterday, it looks like we right shift a signed int to store it as a CVarInt which I belive is implementation dependent
317 2016-11-01T18:09:19  <sipa> indeed
318 2016-11-01T18:09:29  <morcos> there is a comment about it not properly handling negative numbers already
319 2016-11-01T18:10:14  <sipa> so if it's just height and coinbaseness, we could perhaps have just coinbaseness stored in every utxo
320 2016-11-01T18:10:27  <sipa> and a separate map with remembered heights of coinbase tn
321 2016-11-01T18:11:01  <morcos> you need the height for more than coinbase though right?
322 2016-11-01T18:11:09  <sipa> do we?
323 2016-11-01T18:11:14  <morcos> bip68?
324 2016-11-01T18:11:19  <sipa> oh, with bip68 we do
325 2016-11-01T18:11:20  <sipa> ok
326 2016-11-01T18:11:34  <sipa> maybe it's easier to not bother with deduplicating the height then
327 2016-11-01T18:12:28  <morcos> certainly easier!
328 2016-11-01T18:13:40  <morcos> so will the txid be duplicated on disk though for each utxo?
329 2016-11-01T18:14:24  <morcos> i assume its easy enough to skip that in memory, but not sure how leveldb works, that can we have two levels of keys?
330 2016-11-01T18:15:58  <sipa> i believe that leveldb efficiently represents may keys with the same prefix
331 2016-11-01T18:16:03  <sipa> *many
332 2016-11-01T18:16:15  <sipa> but i can't find a reference for it
333 2016-11-01T18:19:16  <instagibbs> does the rpc tester eventually time out? It's hanging on me and I can't tell which test is triggering the timeout
334 2016-11-01T18:19:57  <sipa> bigtable (the internal system at google that leveldb is an opensource simplified version of) certainly does that
335 2016-11-01T18:25:06  *** Chris_Stewart_5 has quit IRC
336 2016-11-01T18:26:58  <sipa> morcos: an alternative is two tabbles, where one maps txid to (coinbase,height,id), and id is a 64-bit sequentially incrementing value, which is used in a (id,nout) to (scriptPubkey, amoubt) map
337 2016-11-01T18:27:16  <sipa> downside: twice the number of disk seeks
338 2016-11-01T18:28:44  <morcos> sipa: yeah i 2 disk ops is going to be worse for a lot of disks
339 2016-11-01T18:30:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
340 2016-11-01T18:30:28  *** molz has quit IRC
341 2016-11-01T18:31:15  <sipa> or we can of course leave the disk format intact
342 2016-11-01T18:33:06  *** paveljanik has joined #bitcoin-core-dev
343 2016-11-01T18:41:25  *** DigiByteDev has quit IRC
344 2016-11-01T18:57:46  *** fengling has joined #bitcoin-core-dev
345 2016-11-01T19:03:07  *** fengling has quit IRC
346 2016-11-01T19:12:39  *** BashCo has joined #bitcoin-core-dev
347 2016-11-01T19:21:39  <gmaxwell> So, re. prefinal alert, right now all those old nodes are displaying "Warning: This version is obsolete, upgrade required!".  It would be a bit odd to override that message with something merely saying the alert system is going away.
348 2016-11-01T19:22:10  <BlueMatt> "The Alert System has been deprecated. Please upgrade your client"
349 2016-11-01T19:22:11  <BlueMatt> ?
350 2016-11-01T19:25:07  <gmaxwell> What I wrote before checking to see the language of the current warning was "Alerts are retired and removed in current software."
351 2016-11-01T19:25:27  <gmaxwell> BlueMatt: your suggestion suggests that alerts are the only reason to upgrade.
352 2016-11-01T19:25:29  *** Chris_Stewart_5 has quit IRC
353 2016-11-01T19:25:30  <achow101> How about "Upgrading is strongly recommended" instead of "Please upgrade your client"
354 2016-11-01T19:26:04  <achow101> won't both the alert and the other message be displayed simultaneously?
355 2016-11-01T19:26:07  <gmaxwell> It's weird to override a more serious warning with a less serious one.
356 2016-11-01T19:26:12  <gmaxwell> achow101: no, they can't be.
357 2016-11-01T19:27:02  <gmaxwell> achow101: the messages have a priority and the highest priority active alert is displayed.
358 2016-11-01T19:27:35  <gmaxwell> if this is sent at low priority (which was what I was originally intending before I thought about it) then it just won't be seen by anyone because it would be masked by that upgrade required alert.
359 2016-11-01T19:28:10  <achow101> What about two different messages, one for those who are showing that upgrade required alert, and one not?
360 2016-11-01T19:28:36  *** moli has joined #bitcoin-core-dev
361 2016-11-01T19:29:23  <gmaxwell> AFAIK, there aren't any nodes which display alerts which aren't showing upgrade required. Anything prior to 0.12.2 is displaying upgrade required right now. (and once segwit signaling starts, all 0.13 will also start displaying an upgrade notice)
362 2016-11-01T19:29:42  <BlueMatt> sipa: we're all getting emails about old releases :(
363 2016-11-01T19:29:50  <BlueMatt> bitcoin 0.10.4 released
364 2016-11-01T19:29:58  <sdaftuar> time to upgrade!
365 2016-11-01T19:31:30  <achow101> gmaxwell: so just make the message "Warning: This version is obsolete. The Alert System has been deprecated. Upgrade is strongly recommended. See: https://bitcoin.org/alert-retirement"
366 2016-11-01T19:31:34  <sipa> BlueMatt: oops
367 2016-11-01T19:31:57  <sipa> BlueMatt: i was just adding release notes to tags
368 2016-11-01T19:32:05  <BlueMatt> yea, i figured
369 2016-11-01T19:32:14  <BlueMatt> whatever, one-time cost
370 2016-11-01T19:32:18  <sipa> as they weren't showing up on https://github.com/bitcoin/bitcoin/releases
371 2016-11-01T19:32:29  <arubi> genuinely asking, why not recommend to run with -alerts=0 from now and that's it?
372 2016-11-01T19:32:29  <sipa> i'm done now
373 2016-11-01T19:32:31  <gmaxwell> achow101: makes it sound like the alert system is the only issue, but it's not-- the reason they're saying upgrade required is that they're not current with the current network rules.
374 2016-11-01T19:32:55  <gmaxwell> arubi: uh oh. confusion detected.
375 2016-11-01T19:33:07  <arubi> is that a different alert then?
376 2016-11-01T19:33:15  <gmaxwell> arubi: alert=0 has been the case for many versions, and since 0.13.0 the alert system is gone entirely.
377 2016-11-01T19:33:33  <arubi> yea but you were talking about 0.12.2
378 2016-11-01T19:33:50  <gmaxwell> arubi: that has alert=0 by default.
379 2016-11-01T19:34:09  <arubi> I see, "prior to"
380 2016-11-01T19:34:16  <TD-Linux> gmaxwell, just concatenate the messages? "In addition, the alert system..."
381 2016-11-01T19:34:29  <achow101> how long can the message be? You could make it more explicit that the software is both out of date with consensus rules and that the alert system is deprecated
382 2016-11-01T19:35:11  <gmaxwell> achow101: I think it'll get cut off in the tray of the application in older versions if it's too long. But otherwise there isn't a meaningful limit.
383 2016-11-01T19:36:18  <BlueMatt> http://bitcoinfibre.org/public-network.html
384 2016-11-01T19:37:33  <achow101> so, how about "Warning: Network rules in this version are out of date. Additionally the Alert System has been deprecated. Upgrade is strongly recommended. See https://bitcoin.org/alert-retirement"
385 2016-11-01T19:37:57  <arubi> gmaxwell, to be sure, "upgrade required" is a message invoked locally when rule changes are detected, and "alerts" are simply the messages that come in signed by the alert key?  sorry for getting in the way here
386 2016-11-01T19:38:10  <achow101> maybe have a "due to soft forks" after "rules out of date"
387 2016-11-01T19:38:29  <kanzure> high amounts of meail from recent releases on github
388 2016-11-01T19:38:32  <kanzure> .. email.
389 2016-11-01T19:38:46  <sipa> kanzure: i'm sorry, i didn't know it was mailing people
390 2016-11-01T19:38:51  <kanzure> it's fine. just a heads up.
391 2016-11-01T19:38:55  <sipa> kanzure: they're listed now on https://github.com/bitcoin/bitcoin/releases
392 2016-11-01T19:39:00  <kanzure> ya it is nice
393 2016-11-01T19:44:00  <achow101> gmaxwell: if the message is an issue now, what about when "Alert Key Compromised" is sent?
394 2016-11-01T19:44:15  <gmaxwell> arubi: yes, -- the local message and alerts are handled in exactly the same way.
395 2016-11-01T19:44:39  <gmaxwell> achow101: it's even more urgent though, and also less of an issue since we'll have months of this message being displayed.
396 2016-11-01T19:46:36  <achow101> ok. What do you think about my other suggestion?
397 2016-11-01T19:47:20  <arubi> thanks gmaxwell, I'll have to play around with alerts= with my own mock alert key
398 2016-11-01T19:50:27  <gmaxwell> achow101: sounds fine to me more or less..  Perhaps "Warning: This is outdated and network-inconsistent software. Also, the alert system has been deprecated. Upgrade is strongly recommended. See https://bitcoin.org/alert-retirement"
399 2016-11-01T19:51:11  <achow101> sounds good to me.
400 2016-11-01T19:53:19  <achow101> how do you even send an alert?
401 2016-11-01T19:53:56  <gmaxwell> achow101: using software bitcoin's creator wrote which has never been publically distributed.
402 2016-11-01T19:54:00  <gmaxwell> (AFAIK)
403 2016-11-01T19:54:57  <achow101> does it happen to look like this: https://gist.github.com/laanwj/0e689cfa37b52bcbbb44 ?
404 2016-11-01T19:56:04  <gmaxwell> well then.
405 2016-11-01T19:56:11  <phantomcircuit> gmaxwell: possibly just send the same message
406 2016-11-01T19:56:24  <phantomcircuit> iirc there are very very old versions which wont show that warning
407 2016-11-01T19:56:43  <gmaxwell> yes, though AFAICT all of those are forked off. :)
408 2016-11-01T19:57:10  <gmaxwell> we want to mention the alert system specifically, so that when the alert system compromised message shows up it might be a little less alarming.
409 2016-11-01T19:58:58  *** fengling has joined #bitcoin-core-dev
410 2016-11-01T19:59:28  <cfields_> sipa: https://github.com/theuni/bitcoin/commits/uint-literal
411 2016-11-01T20:04:10  *** fengling has quit IRC
412 2016-11-01T20:04:44  *** cryptapus has quit IRC
413 2016-11-01T20:05:51  <sipa> cfields_: hmm, i would expect something that just uses return (4*(recursive call)+(new digit)) on a uint256
414 2016-11-01T20:08:35  <cfields_> sipa: hmm?
415 2016-11-01T20:10:30  <cfields_> sipa: ah, you mean add an initializer to base_blob that accepts uint64's?
416 2016-11-01T20:11:18  <GitHub32> [bitcoin] Vitaminmm opened pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059
417 2016-11-01T20:12:34  <gmaxwell> oh thats from his master, if we care to replace it with folgers crystals.
418 2016-11-01T20:14:15  <GitHub88> [bitcoin] MarcoFalke closed pull request #9059: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/9059
419 2016-11-01T20:14:15  <sipa> cfields_: no, have a constexpr function that takes a hex string... if the string has length 0, return 0. if not, call recursively, multiply by 16 and add the new hex digit
420 2016-11-01T20:14:34  <sipa> cfields_: oh wait, uint256 no longer has operator* and operator+
421 2016-11-01T20:15:14  <cfields_> sipa: right, just dumb bits
422 2016-11-01T20:16:31  <sipa> cfields_: so ignore what i said
423 2016-11-01T20:17:23  <cfields_> sipa: roger. doing it in 64bit chunks would probably be cleaner, though
424 2016-11-01T20:56:36  *** Victorsueca has joined #bitcoin-core-dev
425 2016-11-01T20:59:58  *** fengling has joined #bitcoin-core-dev
426 2016-11-01T21:01:16  *** molz has joined #bitcoin-core-dev
427 2016-11-01T21:04:34  *** moli has quit IRC
428 2016-11-01T21:05:13  *** fengling has quit IRC
429 2016-11-01T21:29:21  *** molz has quit IRC
430 2016-11-01T21:29:33  *** moli has joined #bitcoin-core-dev
431 2016-11-01T21:57:20  *** justanotheruser has joined #bitcoin-core-dev
432 2016-11-01T22:01:00  *** fengling has joined #bitcoin-core-dev
433 2016-11-01T22:06:16  *** fengling has quit IRC
434 2016-11-01T22:26:17  *** justanotheruser has quit IRC
435 2016-11-01T22:27:16  *** justanotheruser has joined #bitcoin-core-dev
436 2016-11-01T22:28:42  *** Guyver2 has quit IRC
437 2016-11-01T22:48:04  *** Alina-malina has quit IRC
438 2016-11-01T23:02:00  *** fengling has joined #bitcoin-core-dev
439 2016-11-01T23:06:54  <dgenr8> PR#6
440 2016-11-01T23:06:55  <gribble> https://github.com/bitcoin/bitcoin/issues/6 | Treat wallet as a generic keystore · Issue #6 · bitcoin/bitcoin · GitHub
441 2016-11-01T23:06:58  <dgenr8> sorry, meant for apple ][ window
442 2016-11-01T23:07:19  *** fengling has quit IRC
443 2016-11-01T23:12:54  * btcdrak stabs gribble
444 2016-11-01T23:17:54  * achow101 calls an ambulance for gribble
445 2016-11-01T23:27:52  *** owowo has quit IRC
446 2016-11-01T23:33:39  *** owowo has joined #bitcoin-core-dev
447 2016-11-01T23:40:16  *** owowo has quit IRC
448 2016-11-01T23:45:04  *** owowo has joined #bitcoin-core-dev
449 2016-11-01T23:45:05  *** owowo has joined #bitcoin-core-dev
450 2016-11-01T23:45:05  *** owowo has joined #bitcoin-core-dev
451 2016-11-01T23:46:29  *** murch has quit IRC
452 2016-11-01T23:48:18  *** notmike has joined #bitcoin-core-dev
453 2016-11-01T23:59:40  *** notmike has quit IRC