1 2017-01-08T00:00:54  <sipa> https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md
  2 2017-01-08T00:01:19  <sipa> it gives an example that include a one-line unbraced indendented conditional
  3 2017-01-08T00:01:24  <sipa> -den
  4 2017-01-08T00:01:30  <BlueMatt> gmaxwell: I thoguht the same, but sipa corrected me
  5 2017-01-08T00:01:43  <BlueMatt> oh, wait, prohibited on single line statements? no
  6 2017-01-08T00:01:45  <BlueMatt> i knew that one
  7 2017-01-08T00:01:58  <BlueMatt> i thought we had a style guide (or someone had a preference) for the open-brace /always/ being on the line after the if
  8 2017-01-08T00:03:16  <gmaxwell> BlueMatt: thank you so much for commenting on #9484
  9 2017-01-08T00:03:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
 10 2017-01-08T00:03:56  <gmaxwell> sipa: yea, I think that should be prohibited. But even if it's just permitted to not do that, I'd be much happier.
 11 2017-01-08T00:05:21  <gmaxwell> I'm fine with "if (!something) return false;" too; but we've accepted patches that do nothing but add line breaks to code like that.
 12 2017-01-08T00:07:01  <gmaxwell> but from working on software with that as a coding style, I recall that there was no way to get any of the existing formatters to enforce that rule.
 13 2017-01-08T00:08:03  *** juscamarena has joined #bitcoin-core-dev
 14 2017-01-08T00:11:02  <gmaxwell> it would be neat if someone made a formater autoconfiguration tool that finds the formater settings that minimize the changes to your code base, then prompts you for all the settings that have no effect.
 15 2017-01-08T00:17:53  <gmaxwell> hm actually clang-format has AllowShortIfStatementsOnASingleLine so it can do that, I was mistaken.
 16 2017-01-08T00:24:34  *** windsok has joined #bitcoin-core-dev
 17 2017-01-08T01:14:30  *** GAit has quit IRC
 18 2017-01-08T01:27:13  *** GAit has joined #bitcoin-core-dev
 19 2017-01-08T01:29:48  *** wvr has quit IRC
 20 2017-01-08T03:07:27  *** Ylbam has quit IRC
 21 2017-01-08T03:17:44  <Chris_Stewart_5> It is possible to have a tx with no outputs right? It would just pay all inputs to miner fees?
 22 2017-01-08T03:18:05  <luke-jr> Chris_Stewart_5: i don't think so
 23 2017-01-08T03:19:28  <Chris_Stewart_5> Trying to get my generators right on #8469 it is important that they allow every possible value
 24 2017-01-08T03:19:30  <gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
 25 2017-01-08T03:22:12  <gmaxwell> it is not possible.
 26 2017-01-08T03:22:13  *** dcousens has joined #bitcoin-core-dev
 27 2017-01-08T03:22:27  <gmaxwell> (I mean you can create such an encoding, but the transaction could never be valid.)
 28 2017-01-08T03:22:58  <Chris_Stewart_5> gmaxwell: Valid in the policy sense?
 29 2017-01-08T03:23:10  <gmaxwell> no, in the consensus rules sense.
 30 2017-01-08T03:23:20  <gmaxwell> the word 'never' should have tipped you off. :)
 31 2017-01-08T03:24:59  <Chris_Stewart_5> gmaxwell: I'm not sure i'm ready to believe you yet, why isn't it valid? Some where in validation.cpp there is a check for vout.size() > 0?
 32 2017-01-08T03:25:26  <gmaxwell> yes.
 33 2017-01-08T03:25:54  <Chris_Stewart_5> like you said, enocding/script wise it should be fine I think
 34 2017-01-08T03:26:36  <Chris_Stewart_5> and is it just a thing satoshi did, or is there an actual attack that would be possible
 35 2017-01-08T03:28:10  <gmaxwell> well it does simplify validation code when it doesn't have to check the count before accessing the first one... but no there isn't any special attack.
 36 2017-01-08T03:28:32  <Chris_Stewart_5> gmaxwell: Thanks for the explanation :-)
 37 2017-01-08T03:35:20  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9488: Parallel ThreadMessageHandler (master...2017-01-parallel-processmessages) https://github.com/bitcoin/bitcoin/pull/9488
 38 2017-01-08T03:41:29  <gmaxwell> #7871 is sometihng I probably should have mentioned for a 0.14 target in the last meeting, it is highly complementary with importmulti.
 39 2017-01-08T03:41:32  <gribble> https://github.com/bitcoin/bitcoin/issues/7871 | Manual block file pruning. by mrbandrews · Pull Request #7871 · bitcoin/bitcoin · GitHub
 40 2017-01-08T03:44:11  <gmaxwell> though the fact that one works based on time and the other based on height is a little awkward.
 41 2017-01-08T03:47:44  <gmaxwell> oh weee. thats a bug.
 42 2017-01-08T03:55:30  *** justanotheruser has joined #bitcoin-core-dev
 43 2017-01-08T03:58:49  *** OfficialLeibniz has quit IRC
 44 2017-01-08T04:19:22  <bitcoin-git> [bitcoin] gmaxwell opened pull request #9489: Make FindLatestBefore use GetMedianTimePast instead of GetBlockTime. (master...fix_find_latest_before) https://github.com/bitcoin/bitcoin/pull/9489
 45 2017-01-08T04:25:52  <luke-jr> Chris_Stewart_5: you *could* have a single output with zero value, note
 46 2017-01-08T04:39:58  <Chris_Stewart_5> luke-jr: Or even negative value
 47 2017-01-08T04:40:02  <Chris_Stewart_5> I think?
 48 2017-01-08T04:40:17  <Chris_Stewart_5> BuildCreditingTransaction uses that inside of transaction_test.cpp any way...
 49 2017-01-08T04:45:40  <sipa> wut?
 50 2017-01-08T04:46:56  <sipa> negative value outputs?
 51 2017-01-08T04:54:40  <bitcoin-git> [bitcoin] gmaxwell closed pull request #9489: Make FindLatestBefore use GetMedianTimePast instead of GetBlockTime. (master...fix_find_latest_before) https://github.com/bitcoin/bitcoin/pull/9489
 52 2017-01-08T04:55:44  <gmaxwell> sipa: will I be hated if I make the entries in CBlockIndex 8 bytes larger? :(
 53 2017-01-08T04:58:47  <gmaxwell> I need a 'highest timestamp seen so far in this chain' for this FindLatestBefore.
 54 2017-01-08T05:00:37  <gmaxwell> obvious way to do that is to just have a maxTime in the CBlockindex which = max(nTime,prev->maxtime). sorry 4 bytes, I guess our time there is only 32bits.
 55 2017-01-08T05:03:17  <luke-jr> Chris_Stewart_5: I am relatively certain that negative value outputs are always invalid.
 56 2017-01-08T05:10:04  *** chosafine has joined #bitcoin-core-dev
 57 2017-01-08T05:53:30  <BlueMatt> gmaxwell: IIRC there are a good chunk more than 8 bytes available in CBlockIndex just from better packing
 58 2017-01-08T05:53:35  <BlueMatt> so.....
 59 2017-01-08T05:58:48  <kallewoof> I always thought bitcoin was supposed to pick the chain with the most work, not the longest chain. I did some testing, and with a split network bitcoin picked the longest chain, even though the shorter-by-one chain had a much lower hash.
 60 2017-01-08T05:59:45  <kallewoof> I.e. (1) 5b6aab3f > 3d697a37 > 4ea2f338. (2) 5b6aab3f > 0000000b. On connecting nodes, result was (1) not (2).
 61 2017-01-08T06:03:08  <kadoban> kallewoof: Wouldn't the difficulty at that point matter, not the actual hashes generated? Or did I make that up?
 62 2017-01-08T06:03:36  <kallewoof> You mean nBits?
 63 2017-01-08T06:04:29  <gmaxwell> kadoban: correct.
 64 2017-01-08T06:04:40  <kadoban> I don't know the block format amazingly well, I only remember some parts at a conceptual level. nBits sounds possibly right though
 65 2017-01-08T06:04:47  <kadoban> Ah good
 66 2017-01-08T06:04:53  <gmaxwell> kadoban: other than sufficiency, the hash value doesn't have anything to do with the work that went into it.
 67 2017-01-08T06:05:24  <gmaxwell> though nbits doesn't tell you the total work, it tells you how much work was required for a particular block.
 68 2017-01-08T06:06:02  <gmaxwell> the total work is represented as nChainWork in the bitcoin codebase, it isn't seralized as part of the block.
 69 2017-01-08T06:06:11  <kallewoof> So what is the point with the whole 'most work not longest chain' talk? Nbits is network-widely defined so there will not be a difference ever, will there?
 70 2017-01-08T06:06:31  <gmaxwell> kallewoof: difficulty changes over time.
 71 2017-01-08T06:06:39  <kallewoof> I mean, it's retargeted, but that's it
 72 2017-01-08T06:06:52  <kallewoof> One client will not have one nbits value while another has a different one, hardly ever.
 73 2017-01-08T06:07:13  <gmaxwell> ...
 74 2017-01-08T06:07:23  <gmaxwell> nbits is a property of the _chain_ not the client.
 75 2017-01-08T06:08:44  <kallewoof> I mean... the work done to a chain is dependent on the accumulated difficulties (which are the nbits values, right?). I just can't think of a case where you would have a shorter chain being chosen due to more work.
 76 2017-01-08T06:09:58  <gmaxwell> kallewoof: I can trivially go fork at block 100,000 and then hand you a chain with way more blocks then the current chain but massively less work.
 77 2017-01-08T06:10:28  <gmaxwell> it's a trivial attack, and utterly devistating to most-blocks.
 78 2017-01-08T06:11:04  <kallewoof> Ahh.. so that's what the whole 'most work' thing is about. I get it. Thanks.
 79 2017-01-08T06:11:24  <gmaxwell> absent attacks, whenever there is a chain fork around a retarget, the two sides can have different amounts of work; which makes a difference though not a terribly critical one.
 80 2017-01-08T06:11:32  <gmaxwell> no problem.
 81 2017-01-08T06:11:55  <gmaxwell> kallewoof: lots of people miss that one, the bitcoin software was originally most blocks.
 82 2017-01-08T06:12:33  <kallewoof> It is super obvious now that you've described it. I wish someone had worded it that way somewhere.
 83 2017-01-08T06:13:01  <gmaxwell> it's the sort of thing that would have been described in the whitepaper, if it were known at the time. :)
 84 2017-01-08T06:14:17  <gmaxwell> also, consider yourself fortunate: the worst position to be in is having never been surprised by anything; from that vantage you can't tell how subtle this stuff is... because it's all obvious when presented clearly.
 85 2017-01-08T06:17:43  <kallewoof> gmaxwell: True enough. :)
 86 2017-01-08T06:21:18  <kallewoof> Here's the log of my fine-but-failed experiment in case anyone wants to see it, btw: https://gist.github.com/kallewoof/9b0e541366941e08e41ab1bf3e03f017
 87 2017-01-08T06:27:17  *** chosafine has left #bitcoin-core-dev
 88 2017-01-08T07:00:08  *** dermoth has quit IRC
 89 2017-01-08T07:00:59  *** dermoth has joined #bitcoin-core-dev
 90 2017-01-08T07:04:02  *** Alopex has quit IRC
 91 2017-01-08T07:05:07  *** Alopex has joined #bitcoin-core-dev
 92 2017-01-08T07:08:20  *** dmrche has joined #bitcoin-core-dev
 93 2017-01-08T07:23:42  <bitcoin-git> [bitcoin] gmaxwell opened pull request #9490: Replace FindLatestBefore used by importmuti with FindEarliestAtLeast. (master...fix_find_latest_before) https://github.com/bitcoin/bitcoin/pull/9490
 94 2017-01-08T07:34:02  *** Alopex has quit IRC
 95 2017-01-08T07:35:07  *** Alopex has joined #bitcoin-core-dev
 96 2017-01-08T07:35:47  *** dcousens has quit IRC
 97 2017-01-08T08:04:38  *** ZhibiaoPan has joined #bitcoin-core-dev
 98 2017-01-08T08:39:07  <gmaxwell> wump: I think #9404 could be merged.
 99 2017-01-08T08:39:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
100 2017-01-08T08:41:52  *** tunafizz has quit IRC
101 2017-01-08T08:42:53  *** tunafizz has joined #bitcoin-core-dev
102 2017-01-08T08:54:34  *** Elysus has joined #bitcoin-core-dev
103 2017-01-08T08:57:04  <gmaxwell> BlueMatt: I with the currently list of network messages in your parallel message handler list-- whats the point?  I also don't see how you can handle a GETBLOCKTXN without cs_main.  Do you intend on making it peek at the message further to decide if it will be able to use the cache?
104 2017-01-08T08:59:04  *** arubi has quit IRC
105 2017-01-08T08:59:19  *** arubi has joined #bitcoin-core-dev
106 2017-01-08T09:07:12  *** Alopex has quit IRC
107 2017-01-08T09:08:17  *** Alopex has joined #bitcoin-core-dev
108 2017-01-08T09:12:18  *** Ylbam has joined #bitcoin-core-dev
109 2017-01-08T09:17:50  *** dmrche has quit IRC
110 2017-01-08T09:23:06  *** Alopex has quit IRC
111 2017-01-08T09:24:12  *** Alopex has joined #bitcoin-core-dev
112 2017-01-08T09:24:51  *** ZhibiaoPan has quit IRC
113 2017-01-08T09:39:54  *** Elysus has quit IRC
114 2017-01-08T09:42:01  *** Alopex has quit IRC
115 2017-01-08T09:43:06  *** Alopex has joined #bitcoin-core-dev
116 2017-01-08T09:56:40  *** juscamarena has quit IRC
117 2017-01-08T10:03:13  *** Victorsueca has joined #bitcoin-core-dev
118 2017-01-08T10:03:32  *** LeMiner2 has joined #bitcoin-core-dev
119 2017-01-08T10:05:39  *** Victor_sueca has quit IRC
120 2017-01-08T10:06:06  *** LeMiner has quit IRC
121 2017-01-08T10:06:06  *** LeMiner2 is now known as LeMiner
122 2017-01-08T10:24:44  *** jtimon has joined #bitcoin-core-dev
123 2017-01-08T10:49:19  *** fanquake has joined #bitcoin-core-dev
124 2017-01-08T11:04:16  *** NicolasDorier has quit IRC
125 2017-01-08T11:24:09  *** pavel_ has quit IRC
126 2017-01-08T11:24:26  *** paveljanik has joined #bitcoin-core-dev
127 2017-01-08T11:24:26  *** paveljanik has joined #bitcoin-core-dev
128 2017-01-08T11:35:10  <fanquake> paveljanik what do you mean by diff-only related changes in 9469? The changes are required to make the patches apply cleanly..
129 2017-01-08T11:35:52  <paveljanik> fanquake, and this was my question :-) So they are to make the diff apply cleanly. OK. Np with that.
130 2017-01-08T11:36:10  <paveljanik> So we somewhere require the patch to apply cleanly?
131 2017-01-08T11:38:22  <fanquake> The patches are applied before building the dependancies, https://github.com/bitcoin/bitcoin/blob/master/depends/packages/libevent.mk#L8. There isn't a hard requirement that they apply perfectly, but it seems logical to update them to do so.
132 2017-01-08T11:39:24  <paveljanik> I do not think so ;-)
133 2017-01-08T11:39:46  <paveljanik> fanquake, ad config.* files - github shows then without final newlines at the end of them...
134 2017-01-08T11:40:55  <fanquake> paveljanik if you look at the source of them, http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess, I can't see any new lines. Maybe I'm missing something?
135 2017-01-08T11:43:56  <paveljanik> wget -O config.sub 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD' && hexdump -C config.sub | tail -2
136 2017-01-08T11:44:04  <paveljanik> shows 0x0a at the end.
137 2017-01-08T11:45:46  <paveljanik> the same for the other file.
138 2017-01-08T11:47:01  <fanquake> heh I can change it back, will investigate the OS X issue.
139 2017-01-08T11:47:57  <fanquake> paveljanik It'd be good if you could also review the contents/changelogs of the dependancy updates/hashes of said updates also.
140 2017-01-08T11:48:14  <paveljanik> I'm in the middle of it ;-)
141 2017-01-08T11:49:10  <fanquake> Newlines will be the least of our worries if we've got a borked boost version etc
142 2017-01-08T11:50:08  *** jtimon has quit IRC
143 2017-01-08T11:50:48  <paveljanik> Hmm, but we should not change the upstream files...
144 2017-01-08T11:51:02  <paveljanik> and these two are upstream files.
145 2017-01-08T11:51:39  <fanquake> paveljanik which files?
146 2017-01-08T11:51:48  <paveljanik> config.sub and config.guess
147 2017-01-08T11:52:17  <fanquake> Why would we not update those?
148 2017-01-08T11:52:31  <paveljanik> we should fetch them and store as-is in the depends, not modify them after fetching.
149 2017-01-08T11:52:35  <paveljanik> update: yes!
150 2017-01-08T11:52:38  <paveljanik> modify: no!
151 2017-01-08T11:52:49  <paveljanik> You updated (good!) and modified (wrong!).
152 2017-01-08T11:53:05  <paveljanik> but maybe the modification was not intentional...
153 2017-01-08T11:53:10  <paveljanik> some tooling or so...
154 2017-01-08T11:53:14  <fanquake> We're not patching/modifying them though?
155 2017-01-08T11:53:33  <fanquake> oh your talking about the newlines? Yes that can be fixed.
156 2017-01-08T11:53:35  <paveljanik> You did modify the file by deleting the final newline!
157 2017-01-08T11:53:39  <paveljanik> yes
158 2017-01-08T11:53:55  <paveljanik> BTW - why don't we fetch them too?
159 2017-01-08T11:55:01  <fanquake> Probably something you'd have to ask theuni.
160 2017-01-08T11:55:46  <fanquake> gmaxwell I think I must be missing something in #9484. Started a -reindex-chainstate with -assumevalid=<default hash>, and it's working far slower than just current master.
161 2017-01-08T11:55:48  <gribble> https://github.com/bitcoin/bitcoin/issues/9484 | Introduce assumevalid setting to skip validation presumed valid scripts. by gmaxwell · Pull Request #9484 · bitcoin/bitcoin · GitHub
162 2017-01-08T12:31:07  *** Alopex has quit IRC
163 2017-01-08T12:31:15  *** fanquake has quit IRC
164 2017-01-08T12:32:12  *** Alopex has joined #bitcoin-core-dev
165 2017-01-08T12:35:48  *** shinobimonkey has quit IRC
166 2017-01-08T12:50:23  *** protomar has joined #bitcoin-core-dev
167 2017-01-08T12:55:43  *** chris2000 has joined #bitcoin-core-dev
168 2017-01-08T13:46:38  *** bachishaman has joined #bitcoin-core-dev
169 2017-01-08T13:51:37  *** AaronvanW has quit IRC
170 2017-01-08T14:11:59  *** AaronvanW has joined #bitcoin-core-dev
171 2017-01-08T14:11:59  *** AaronvanW has joined #bitcoin-core-dev
172 2017-01-08T14:15:13  *** bachishaman has quit IRC
173 2017-01-08T14:50:38  *** Guyver2 has joined #bitcoin-core-dev
174 2017-01-08T15:06:58  *** Cheeseo has joined #bitcoin-core-dev
175 2017-01-08T15:22:05  *** protomar has quit IRC
176 2017-01-08T15:40:26  *** Cheeseo has quit IRC
177 2017-01-08T15:42:19  *** Sosumi has joined #bitcoin-core-dev
178 2017-01-08T16:12:27  <BlueMatt> gmaxwell: I mean it could only respond to getblocktxn if its the top-block (ie cached one)...I'm perfectly ok with it having a chance at blocking if it happens to be a request for the wrong block
179 2017-01-08T16:12:45  <BlueMatt> gmaxwell: in the common case it'll work super well, in the rare case (or if your peer is mean) it might block
180 2017-01-08T16:12:57  <BlueMatt> gmaxwell: in the future we could look deeper at the message to see if we will block
181 2017-01-08T16:13:08  <sipa> gmaxwell: what does 'timestamp seen in a chain' mean?
182 2017-01-08T16:13:24  *** jtimon has joined #bitcoin-core-dev
183 2017-01-08T16:15:04  <BlueMatt> gmaxwell: for 0.15 I may try to push a read/upgrade/write lock model again, which would also make this useful
184 2017-01-08T16:19:56  <BlueMatt> gmaxwell: with real State() fixes, we could also support FILTERLOAD/FILTERADD/FILTERCLEAR/VERACK/ADDR/SENDHEADERS/
185 2017-01-08T16:20:43  <BlueMatt> which, btw, is all of our non-block/tx-download non-version messages
186 2017-01-08T16:20:48  <BlueMatt> and I think we could get version too
187 2017-01-08T16:20:58  <BlueMatt> but it would take a tiny bit more work
188 2017-01-08T16:25:03  <BlueMatt> maybe for 15 we could even get the mempool-can-be-behind-chainActive stuff like we have for wallet now
189 2017-01-08T16:25:18  <BlueMatt> which would make this really awesome
190 2017-01-08T16:50:32  *** murr4y has quit IRC
191 2017-01-08T16:51:09  *** murr4y has joined #bitcoin-core-dev
192 2017-01-08T17:01:56  *** MarcoFalke has joined #bitcoin-core-dev
193 2017-01-08T17:03:32  *** MarcoFalke has left #bitcoin-core-dev
194 2017-01-08T17:41:17  *** justanotheruser has quit IRC
195 2017-01-08T17:47:31  *** justanotheruser has joined #bitcoin-core-dev
196 2017-01-08T17:52:43  <BlueMatt> sipa: you were asking about easy merges? #9480, #9353
197 2017-01-08T17:52:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
198 2017-01-08T17:52:46  <gribble> https://github.com/bitcoin/bitcoin/issues/9353 | Add data() method to CDataStream (and use it) by laanwj · Pull Request #9353 · bitcoin/bitcoin · GitHub
199 2017-01-08T17:56:09  *** CubicEarth has joined #bitcoin-core-dev
200 2017-01-08T18:02:35  *** CubicEarth has quit IRC
201 2017-01-08T18:05:06  *** TomMc has joined #bitcoin-core-dev
202 2017-01-08T18:13:18  *** CubicEarth has joined #bitcoin-core-dev
203 2017-01-08T18:26:55  *** CubicEarth has quit IRC
204 2017-01-08T18:29:23  <BlueMatt> sipa: oh, and the one I actually meant to refer to : #9404
205 2017-01-08T18:29:25  <gribble> https://github.com/bitcoin/bitcoin/issues/9404 | Smarter coordination of change and fee in CreateTransaction. by morcos · Pull Request #9404 · bitcoin/bitcoin · GitHub
206 2017-01-08T18:36:56  *** MarcoFalke has joined #bitcoin-core-dev
207 2017-01-08T18:54:47  *** CubicEarth has joined #bitcoin-core-dev
208 2017-01-08T18:59:14  *** laurentmt has joined #bitcoin-core-dev
209 2017-01-08T19:10:26  *** CubicEarth has quit IRC
210 2017-01-08T19:12:08  *** CubicEarth has joined #bitcoin-core-dev
211 2017-01-08T19:17:33  *** CubicEarth has quit IRC
212 2017-01-08T19:27:31  *** CubicEarth has joined #bitcoin-core-dev
213 2017-01-08T19:29:59  *** CubicEarth has quit IRC
214 2017-01-08T19:31:06  *** CubicEarth has joined #bitcoin-core-dev
215 2017-01-08T19:33:45  *** protomar has joined #bitcoin-core-dev
216 2017-01-08T19:55:24  *** TomMc has quit IRC
217 2017-01-08T19:58:24  *** jm111t has joined #bitcoin-core-dev
218 2017-01-08T19:58:59  <jm111t> just wanted to mention that about 2 months ago I reported  that I could not import a key and then by rebuilding the blockchain it worked again.
219 2017-01-08T19:59:13  <jm111t> well I had the problem again and found out why. The reason is the file system, the problem arises when your drive is formated with msdos.
220 2017-01-08T19:59:43  <jm111t> just in case it might help someone.
221 2017-01-08T20:02:13  *** CubicEarth has quit IRC
222 2017-01-08T20:04:17  *** CubicEarth has joined #bitcoin-core-dev
223 2017-01-08T20:08:29  <luke-jr> BlueMatt: I don't think I can fix most of your nits without amending past commits..
224 2017-01-08T20:09:18  *** CubicEarth has quit IRC
225 2017-01-08T20:09:49  *** PRab has joined #bitcoin-core-dev
226 2017-01-08T20:10:18  <BlueMatt> luke-jr: thats fine...up to you to do that if its required (and no one has published partial reviews)...alternatively you could just add SQUASHME commits on top
227 2017-01-08T20:11:04  *** CubicEarth has joined #bitcoin-core-dev
228 2017-01-08T20:12:24  *** jm111t has quit IRC
229 2017-01-08T20:14:07  <gmaxwell> sipa: I'm not sure of the context of your question, but I presume nTime.
230 2017-01-08T20:14:19  <luke-jr> BlueMatt: that doesn't work for moving changes from commit X to X-1
231 2017-01-08T20:14:35  <BlueMatt> ehh, i dont care if you fix that one
232 2017-01-08T20:14:49  <BlueMatt> but if you get around to doing another rebase, might as well do it then
233 2017-01-08T20:15:48  *** CubicEarth has quit IRC
234 2017-01-08T20:20:09  <luke-jr> BlueMatt: any suggestions for removing the pointer from the debug log? there's kinda nothing else unique..
235 2017-01-08T20:20:48  <luke-jr> maybe it'd be okay with lockwallet(0x%x) instead of a decimal number?
236 2017-01-08T20:21:03  <BlueMatt> yea, I dont have any great insight into that one...what do you use for wallet ids in the final multiwallet pr?
237 2017-01-08T20:21:29  <BlueMatt> no, the point is to not print a pointer into debug.log, since I could contort it into an issue for ASLR
238 2017-01-08T20:24:22  <luke-jr> BlueMatt: final multiwallet gives the wallets names, but there is no strong guarantee they won't have the same name
239 2017-01-08T20:25:57  <luke-jr> I suppose I could use the filename if I move some parts of that into this
240 2017-01-08T20:25:59  <BlueMatt> huh? if they have the same name how would you index them? dont you check name-uniqueness on load?
241 2017-01-08T20:26:25  <luke-jr> they aren't indexed.
242 2017-01-08T20:26:32  <BlueMatt> i mean for this pr you could just have a second id field in the scheduler thinggy that gets appended to the string after print
243 2017-01-08T20:26:41  <BlueMatt> how do you specify the wallet?
244 2017-01-08T20:26:59  <luke-jr> there's a dropdown box in the GUI, and for RPC by filename
245 2017-01-08T20:27:18  <BlueMatt> oh, hum....
246 2017-01-08T20:27:42  <luke-jr> hm, I suppose strWalletFile is already there
247 2017-01-08T20:27:53  <luke-jr> and I guess we don't support files outside of .bitcoin or in subdirs
248 2017-01-08T20:28:19  <BlueMatt> yea, I'd be more comfortable with just using that
249 2017-01-08T20:28:28  *** CubicEarth has joined #bitcoin-core-dev
250 2017-01-08T20:28:30  <luke-jr> it's not a strong guarantee, but maybe good enough
251 2017-01-08T20:28:48  <BlueMatt> well you certainly cant load two wallets with the same name???
252 2017-01-08T20:29:08  <BlueMatt> oh, wait, no, you also cant load two wallets in the same dir, can you?
253 2017-01-08T20:29:11  <BlueMatt> does bdb barf on that?
254 2017-01-08T20:29:41  <luke-jr> you can only load two wallets in the same dir
255 2017-01-08T20:30:00  <BlueMatt> oh? i guess its all the same bdb context thinggy?
256 2017-01-08T20:30:40  <luke-jr> yes
257 2017-01-08T20:30:52  <luke-jr> we don't actually enforce same-dir, but it's going to use the same bdb database dir I think
258 2017-01-08T20:31:29  * luke-jr wonders if we should be enforcing that
259 2017-01-08T20:32:19  <BlueMatt> yes, probably
260 2017-01-08T20:32:27  <BlueMatt> when in doubt, enforce, I'd say here
261 2017-01-08T20:32:33  <BlueMatt> given bdb.........
262 2017-01-08T20:36:22  <luke-jr> not really sure what to do with 989e352f7931f6ab9212e821e2d00e4aa0106635. Someone wanted it. :/
263 2017-01-08T20:36:44  *** CubicEarth has quit IRC
264 2017-01-08T20:37:29  <BlueMatt> i mean the ones inside ifdef ENABLE_WALLET could be moved, and then you could #include inside an ENABLE_WALLET
265 2017-01-08T20:37:47  <BlueMatt> but the include should only be inside an ENABLE_WALLET
266 2017-01-08T20:45:23  *** GAit has quit IRC
267 2017-01-08T20:45:35  *** GAit has joined #bitcoin-core-dev
268 2017-01-08T20:45:35  *** laurentmt has quit IRC
269 2017-01-08T20:46:35  *** CubicEarth has joined #bitcoin-core-dev
270 2017-01-08T20:51:12  *** CubicEarth has quit IRC
271 2017-01-08T21:14:39  *** Sosumi has quit IRC
272 2017-01-08T21:19:01  <luke-jr> BlueMatt: okay, I think I got everything
273 2017-01-08T21:23:36  <luke-jr> oh fun, master doesn't build :x
274 2017-01-08T21:23:50  * luke-jr hopes his rebase went smoothly
275 2017-01-08T21:24:06  <BlueMatt> huh?
276 2017-01-08T21:24:12  <BlueMatt> under what settings?
277 2017-01-08T21:25:17  <luke-jr> test/raii_event_tests.cpp:39:58: error: ‘event_set_mem_functions’ was not declared in this scope
278 2017-01-08T21:26:35  <gmaxwell> fanquake: doesn't bode well for reviewing the constants; when I updated for opening the pull request, I updated the constants, and managed to put a testnet block in the mainnet default. :)
279 2017-01-08T21:26:51  <gmaxwell> fengling: it's fixed now.
280 2017-01-08T21:28:42  *** Guyver2 has quit IRC
281 2017-01-08T21:47:36  *** CubicEarth has joined #bitcoin-core-dev
282 2017-01-08T21:50:13  *** dcousens has joined #bitcoin-core-dev
283 2017-01-08T21:52:05  *** CubicEarth has quit IRC
284 2017-01-08T22:10:04  *** CubicEarth has joined #bitcoin-core-dev
285 2017-01-08T22:25:09  *** AaronvanW has quit IRC
286 2017-01-08T22:30:15  *** trotski2000 has joined #bitcoin-core-dev
287 2017-01-08T22:39:35  *** CubicEarth has quit IRC
288 2017-01-08T22:59:00  *** PRab has quit IRC
289 2017-01-08T23:00:05  *** CubicEarth has joined #bitcoin-core-dev
290 2017-01-08T23:02:47  *** protomar has quit IRC
291 2017-01-08T23:04:24  *** CubicEarth has quit IRC
292 2017-01-08T23:08:00  *** Chris_Stewart_5 has quit IRC
293 2017-01-08T23:23:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
294 2017-01-08T23:31:37  *** MarcoFalke has left #bitcoin-core-dev
295 2017-01-08T23:49:05  *** windsok has quit IRC