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