12017-01-08T00:00:54  <sipa> https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md
  22017-01-08T00:01:19  <sipa> it gives an example that include a one-line unbraced indendented conditional
  32017-01-08T00:01:24  <sipa> -den
  42017-01-08T00:01:30  <BlueMatt> gmaxwell: I thoguht the same, but sipa corrected me
  52017-01-08T00:01:43  <BlueMatt> oh, wait, prohibited on single line statements? no
  62017-01-08T00:01:45  <BlueMatt> i knew that one
  72017-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
  82017-01-08T00:03:16  <gmaxwell> BlueMatt: thank you so much for commenting on #9484
  92017-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
 102017-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.
 112017-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.
 122017-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.
 132017-01-08T00:08:03  *** juscamarena has joined #bitcoin-core-dev
 142017-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.
 152017-01-08T00:17:53  <gmaxwell> hm actually clang-format has AllowShortIfStatementsOnASingleLine so it can do that, I was mistaken.
 162017-01-08T00:24:34  *** windsok has joined #bitcoin-core-dev
 172017-01-08T01:14:30  *** GAit has quit IRC
 182017-01-08T01:27:13  *** GAit has joined #bitcoin-core-dev
 192017-01-08T01:29:48  *** wvr has quit IRC
 202017-01-08T03:07:27  *** Ylbam has quit IRC
 212017-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?
 222017-01-08T03:18:05  <luke-jr> Chris_Stewart_5: i don't think so
 232017-01-08T03:19:28  <Chris_Stewart_5> Trying to get my generators right on #8469 it is important that they allow every possible value
 242017-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
 252017-01-08T03:22:12  <gmaxwell> it is not possible.
 262017-01-08T03:22:13  *** dcousens has joined #bitcoin-core-dev
 272017-01-08T03:22:27  <gmaxwell> (I mean you can create such an encoding, but the transaction could never be valid.)
 282017-01-08T03:22:58  <Chris_Stewart_5> gmaxwell: Valid in the policy sense?
 292017-01-08T03:23:10  <gmaxwell> no, in the consensus rules sense.
 302017-01-08T03:23:20  <gmaxwell> the word 'never' should have tipped you off. :)
 312017-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?
 322017-01-08T03:25:26  <gmaxwell> yes.
 332017-01-08T03:25:54  <Chris_Stewart_5> like you said, enocding/script wise it should be fine I think
 342017-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
 352017-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.
 362017-01-08T03:28:32  <Chris_Stewart_5> gmaxwell: Thanks for the explanation :-)
 372017-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
 382017-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.
 392017-01-08T03:41:32  <gribble> https://github.com/bitcoin/bitcoin/issues/7871 | Manual block file pruning. by mrbandrews · Pull Request #7871 · bitcoin/bitcoin · GitHub
 402017-01-08T03:44:11  <gmaxwell> though the fact that one works based on time and the other based on height is a little awkward.
 412017-01-08T03:47:44  <gmaxwell> oh weee. thats a bug.
 422017-01-08T03:55:30  *** justanotheruser has joined #bitcoin-core-dev
 432017-01-08T03:58:49  *** OfficialLeibniz has quit IRC
 442017-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
 452017-01-08T04:25:52  <luke-jr> Chris_Stewart_5: you *could* have a single output with zero value, note
 462017-01-08T04:39:58  <Chris_Stewart_5> luke-jr: Or even negative value
 472017-01-08T04:40:02  <Chris_Stewart_5> I think?
 482017-01-08T04:40:17  <Chris_Stewart_5> BuildCreditingTransaction uses that inside of transaction_test.cpp any way...
 492017-01-08T04:45:40  <sipa> wut?
 502017-01-08T04:46:56  <sipa> negative value outputs?
 512017-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
 522017-01-08T04:55:44  <gmaxwell> sipa: will I be hated if I make the entries in CBlockIndex 8 bytes larger? :(
 532017-01-08T04:58:47  <gmaxwell> I need a 'highest timestamp seen so far in this chain' for this FindLatestBefore.
 542017-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.
 552017-01-08T05:03:17  <luke-jr> Chris_Stewart_5: I am relatively certain that negative value outputs are always invalid.
 562017-01-08T05:10:04  *** chosafine has joined #bitcoin-core-dev
 572017-01-08T05:53:30  <BlueMatt> gmaxwell: IIRC there are a good chunk more than 8 bytes available in CBlockIndex just from better packing
 582017-01-08T05:53:35  <BlueMatt> so.....
 592017-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.
 602017-01-08T05:59:45  <kallewoof> I.e. (1) 5b6aab3f > 3d697a37 > 4ea2f338. (2) 5b6aab3f > 0000000b. On connecting nodes, result was (1) not (2).
 612017-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?
 622017-01-08T06:03:36  <kallewoof> You mean nBits?
 632017-01-08T06:04:29  <gmaxwell> kadoban: correct.
 642017-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
 652017-01-08T06:04:47  <kadoban> Ah good
 662017-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.
 672017-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.
 682017-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.
 692017-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?
 702017-01-08T06:06:31  <gmaxwell> kallewoof: difficulty changes over time.
 712017-01-08T06:06:39  <kallewoof> I mean, it's retargeted, but that's it
 722017-01-08T06:06:52  <kallewoof> One client will not have one nbits value while another has a different one, hardly ever.
 732017-01-08T06:07:13  <gmaxwell> ...
 742017-01-08T06:07:23  <gmaxwell> nbits is a property of the _chain_ not the client.
 752017-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.
 762017-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.
 772017-01-08T06:10:28  <gmaxwell> it's a trivial attack, and utterly devistating to most-blocks.
 782017-01-08T06:11:04  <kallewoof> Ahh.. so that's what the whole 'most work' thing is about. I get it. Thanks.
 792017-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.
 802017-01-08T06:11:32  <gmaxwell> no problem.
 812017-01-08T06:11:55  <gmaxwell> kallewoof: lots of people miss that one, the bitcoin software was originally most blocks.
 822017-01-08T06:12:33  <kallewoof> It is super obvious now that you've described it. I wish someone had worded it that way somewhere.
 832017-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. :)
 842017-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.
 852017-01-08T06:17:43  <kallewoof> gmaxwell: True enough. :)
 862017-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
 872017-01-08T06:27:17  *** chosafine has left #bitcoin-core-dev
 882017-01-08T07:00:08  *** dermoth has quit IRC
 892017-01-08T07:00:59  *** dermoth has joined #bitcoin-core-dev
 902017-01-08T07:04:02  *** Alopex has quit IRC
 912017-01-08T07:05:07  *** Alopex has joined #bitcoin-core-dev
 922017-01-08T07:08:20  *** dmrche has joined #bitcoin-core-dev
 932017-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
 942017-01-08T07:34:02  *** Alopex has quit IRC
 952017-01-08T07:35:07  *** Alopex has joined #bitcoin-core-dev
 962017-01-08T07:35:47  *** dcousens has quit IRC
 972017-01-08T08:04:38  *** ZhibiaoPan has joined #bitcoin-core-dev
 982017-01-08T08:39:07  <gmaxwell> wump: I think #9404 could be merged.
 992017-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
1002017-01-08T08:41:52  *** tunafizz has quit IRC
1012017-01-08T08:42:53  *** tunafizz has joined #bitcoin-core-dev
1022017-01-08T08:54:34  *** Elysus has joined #bitcoin-core-dev
1032017-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?
1042017-01-08T08:59:04  *** arubi has quit IRC
1052017-01-08T08:59:19  *** arubi has joined #bitcoin-core-dev
1062017-01-08T09:07:12  *** Alopex has quit IRC
1072017-01-08T09:08:17  *** Alopex has joined #bitcoin-core-dev
1082017-01-08T09:12:18  *** Ylbam has joined #bitcoin-core-dev
1092017-01-08T09:17:50  *** dmrche has quit IRC
1102017-01-08T09:23:06  *** Alopex has quit IRC
1112017-01-08T09:24:12  *** Alopex has joined #bitcoin-core-dev
1122017-01-08T09:24:51  *** ZhibiaoPan has quit IRC
1132017-01-08T09:39:54  *** Elysus has quit IRC
1142017-01-08T09:42:01  *** Alopex has quit IRC
1152017-01-08T09:43:06  *** Alopex has joined #bitcoin-core-dev
1162017-01-08T09:56:40  *** juscamarena has quit IRC
1172017-01-08T10:03:13  *** Victorsueca has joined #bitcoin-core-dev
1182017-01-08T10:03:32  *** LeMiner2 has joined #bitcoin-core-dev
1192017-01-08T10:05:39  *** Victor_sueca has quit IRC
1202017-01-08T10:06:06  *** LeMiner has quit IRC
1212017-01-08T10:06:06  *** LeMiner2 is now known as LeMiner
1222017-01-08T10:24:44  *** jtimon has joined #bitcoin-core-dev
1232017-01-08T10:49:19  *** fanquake has joined #bitcoin-core-dev
1242017-01-08T11:04:16  *** NicolasDorier has quit IRC
1252017-01-08T11:24:09  *** pavel_ has quit IRC
1262017-01-08T11:24:26  *** paveljanik has joined #bitcoin-core-dev
1272017-01-08T11:24:26  *** paveljanik has joined #bitcoin-core-dev
1282017-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..
1292017-01-08T11:35:52  <paveljanik> fanquake, and this was my question :-) So they are to make the diff apply cleanly. OK. Np with that.
1302017-01-08T11:36:10  <paveljanik> So we somewhere require the patch to apply cleanly?
1312017-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.
1322017-01-08T11:39:24  <paveljanik> I do not think so ;-)
1332017-01-08T11:39:46  <paveljanik> fanquake, ad config.* files - github shows then without final newlines at the end of them...
1342017-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?
1352017-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
1362017-01-08T11:44:04  <paveljanik> shows 0x0a at the end.
1372017-01-08T11:45:46  <paveljanik> the same for the other file.
1382017-01-08T11:47:01  <fanquake> heh I can change it back, will investigate the OS X issue.
1392017-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.
1402017-01-08T11:48:14  <paveljanik> I'm in the middle of it ;-)
1412017-01-08T11:49:10  <fanquake> Newlines will be the least of our worries if we've got a borked boost version etc
1422017-01-08T11:50:08  *** jtimon has quit IRC
1432017-01-08T11:50:48  <paveljanik> Hmm, but we should not change the upstream files...
1442017-01-08T11:51:02  <paveljanik> and these two are upstream files.
1452017-01-08T11:51:39  <fanquake> paveljanik which files?
1462017-01-08T11:51:48  <paveljanik> config.sub and config.guess
1472017-01-08T11:52:17  <fanquake> Why would we not update those?
1482017-01-08T11:52:31  <paveljanik> we should fetch them and store as-is in the depends, not modify them after fetching.
1492017-01-08T11:52:35  <paveljanik> update: yes!
1502017-01-08T11:52:38  <paveljanik> modify: no!
1512017-01-08T11:52:49  <paveljanik> You updated (good!) and modified (wrong!).
1522017-01-08T11:53:05  <paveljanik> but maybe the modification was not intentional...
1532017-01-08T11:53:10  <paveljanik> some tooling or so...
1542017-01-08T11:53:14  <fanquake> We're not patching/modifying them though?
1552017-01-08T11:53:33  <fanquake> oh your talking about the newlines? Yes that can be fixed.
1562017-01-08T11:53:35  <paveljanik> You did modify the file by deleting the final newline!
1572017-01-08T11:53:39  <paveljanik> yes
1582017-01-08T11:53:55  <paveljanik> BTW - why don't we fetch them too?
1592017-01-08T11:55:01  <fanquake> Probably something you'd have to ask theuni.
1602017-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.
1612017-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
1622017-01-08T12:31:07  *** Alopex has quit IRC
1632017-01-08T12:31:15  *** fanquake has quit IRC
1642017-01-08T12:32:12  *** Alopex has joined #bitcoin-core-dev
1652017-01-08T12:35:48  *** shinobimonkey has quit IRC
1662017-01-08T12:50:23  *** protomar has joined #bitcoin-core-dev
1672017-01-08T12:55:43  *** chris2000 has joined #bitcoin-core-dev
1682017-01-08T13:46:38  *** bachishaman has joined #bitcoin-core-dev
1692017-01-08T13:51:37  *** AaronvanW has quit IRC
1702017-01-08T14:11:59  *** AaronvanW has joined #bitcoin-core-dev
1712017-01-08T14:11:59  *** AaronvanW has joined #bitcoin-core-dev
1722017-01-08T14:15:13  *** bachishaman has quit IRC
1732017-01-08T14:50:38  *** Guyver2 has joined #bitcoin-core-dev
1742017-01-08T15:06:58  *** Cheeseo has joined #bitcoin-core-dev
1752017-01-08T15:22:05  *** protomar has quit IRC
1762017-01-08T15:40:26  *** Cheeseo has quit IRC
1772017-01-08T15:42:19  *** Sosumi has joined #bitcoin-core-dev
1782017-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
1792017-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
1802017-01-08T16:12:57  <BlueMatt> gmaxwell: in the future we could look deeper at the message to see if we will block
1812017-01-08T16:13:08  <sipa> gmaxwell: what does 'timestamp seen in a chain' mean?
1822017-01-08T16:13:24  *** jtimon has joined #bitcoin-core-dev
1832017-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
1842017-01-08T16:19:56  <BlueMatt> gmaxwell: with real State() fixes, we could also support FILTERLOAD/FILTERADD/FILTERCLEAR/VERACK/ADDR/SENDHEADERS/
1852017-01-08T16:20:43  <BlueMatt> which, btw, is all of our non-block/tx-download non-version messages
1862017-01-08T16:20:48  <BlueMatt> and I think we could get version too
1872017-01-08T16:20:58  <BlueMatt> but it would take a tiny bit more work
1882017-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
1892017-01-08T16:25:18  <BlueMatt> which would make this really awesome
1902017-01-08T16:50:32  *** murr4y has quit IRC
1912017-01-08T16:51:09  *** murr4y has joined #bitcoin-core-dev
1922017-01-08T17:01:56  *** MarcoFalke has joined #bitcoin-core-dev
1932017-01-08T17:03:32  *** MarcoFalke has left #bitcoin-core-dev
1942017-01-08T17:41:17  *** justanotheruser has quit IRC
1952017-01-08T17:47:31  *** justanotheruser has joined #bitcoin-core-dev
1962017-01-08T17:52:43  <BlueMatt> sipa: you were asking about easy merges? #9480, #9353
1972017-01-08T17:52:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9480 | De-duplicate SignatureCacheHasher by JeremyRubin · Pull Request #9480 · bitcoin/bitcoin · GitHub
1982017-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
1992017-01-08T17:56:09  *** CubicEarth has joined #bitcoin-core-dev
2002017-01-08T18:02:35  *** CubicEarth has quit IRC
2012017-01-08T18:05:06  *** TomMc has joined #bitcoin-core-dev
2022017-01-08T18:13:18  *** CubicEarth has joined #bitcoin-core-dev
2032017-01-08T18:26:55  *** CubicEarth has quit IRC
2042017-01-08T18:29:23  <BlueMatt> sipa: oh, and the one I actually meant to refer to : #9404
2052017-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
2062017-01-08T18:36:56  *** MarcoFalke has joined #bitcoin-core-dev
2072017-01-08T18:54:47  *** CubicEarth has joined #bitcoin-core-dev
2082017-01-08T18:59:14  *** laurentmt has joined #bitcoin-core-dev
2092017-01-08T19:10:26  *** CubicEarth has quit IRC
2102017-01-08T19:12:08  *** CubicEarth has joined #bitcoin-core-dev
2112017-01-08T19:17:33  *** CubicEarth has quit IRC
2122017-01-08T19:27:31  *** CubicEarth has joined #bitcoin-core-dev
2132017-01-08T19:29:59  *** CubicEarth has quit IRC
2142017-01-08T19:31:06  *** CubicEarth has joined #bitcoin-core-dev
2152017-01-08T19:33:45  *** protomar has joined #bitcoin-core-dev
2162017-01-08T19:55:24  *** TomMc has quit IRC
2172017-01-08T19:58:24  *** jm111t has joined #bitcoin-core-dev
2182017-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.
2192017-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.
2202017-01-08T19:59:43  <jm111t> just in case it might help someone.
2212017-01-08T20:02:13  *** CubicEarth has quit IRC
2222017-01-08T20:04:17  *** CubicEarth has joined #bitcoin-core-dev
2232017-01-08T20:08:29  <luke-jr> BlueMatt: I don't think I can fix most of your nits without amending past commits..
2242017-01-08T20:09:18  *** CubicEarth has quit IRC
2252017-01-08T20:09:49  *** PRab has joined #bitcoin-core-dev
2262017-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
2272017-01-08T20:11:04  *** CubicEarth has joined #bitcoin-core-dev
2282017-01-08T20:12:24  *** jm111t has quit IRC
2292017-01-08T20:14:07  <gmaxwell> sipa: I'm not sure of the context of your question, but I presume nTime.
2302017-01-08T20:14:19  <luke-jr> BlueMatt: that doesn't work for moving changes from commit X to X-1
2312017-01-08T20:14:35  <BlueMatt> ehh, i dont care if you fix that one
2322017-01-08T20:14:49  <BlueMatt> but if you get around to doing another rebase, might as well do it then
2332017-01-08T20:15:48  *** CubicEarth has quit IRC
2342017-01-08T20:20:09  <luke-jr> BlueMatt: any suggestions for removing the pointer from the debug log? there's kinda nothing else unique..
2352017-01-08T20:20:48  <luke-jr> maybe it'd be okay with lockwallet(0x%x) instead of a decimal number?
2362017-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?
2372017-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
2382017-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
2392017-01-08T20:25:57  <luke-jr> I suppose I could use the filename if I move some parts of that into this
2402017-01-08T20:25:59  <BlueMatt> huh? if they have the same name how would you index them? dont you check name-uniqueness on load?
2412017-01-08T20:26:25  <luke-jr> they aren't indexed.
2422017-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
2432017-01-08T20:26:41  <BlueMatt> how do you specify the wallet?
2442017-01-08T20:26:59  <luke-jr> there's a dropdown box in the GUI, and for RPC by filename
2452017-01-08T20:27:18  <BlueMatt> oh, hum....
2462017-01-08T20:27:42  <luke-jr> hm, I suppose strWalletFile is already there
2472017-01-08T20:27:53  <luke-jr> and I guess we don't support files outside of .bitcoin or in subdirs
2482017-01-08T20:28:19  <BlueMatt> yea, I'd be more comfortable with just using that
2492017-01-08T20:28:28  *** CubicEarth has joined #bitcoin-core-dev
2502017-01-08T20:28:30  <luke-jr> it's not a strong guarantee, but maybe good enough
2512017-01-08T20:28:48  <BlueMatt> well you certainly cant load two wallets with the same name???
2522017-01-08T20:29:08  <BlueMatt> oh, wait, no, you also cant load two wallets in the same dir, can you?
2532017-01-08T20:29:11  <BlueMatt> does bdb barf on that?
2542017-01-08T20:29:41  <luke-jr> you can only load two wallets in the same dir
2552017-01-08T20:30:00  <BlueMatt> oh? i guess its all the same bdb context thinggy?
2562017-01-08T20:30:40  <luke-jr> yes
2572017-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
2582017-01-08T20:31:29  * luke-jr wonders if we should be enforcing that
2592017-01-08T20:32:19  <BlueMatt> yes, probably
2602017-01-08T20:32:27  <BlueMatt> when in doubt, enforce, I'd say here
2612017-01-08T20:32:33  <BlueMatt> given bdb.........
2622017-01-08T20:36:22  <luke-jr> not really sure what to do with 989e352f7931f6ab9212e821e2d00e4aa0106635. Someone wanted it. :/
2632017-01-08T20:36:44  *** CubicEarth has quit IRC
2642017-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
2652017-01-08T20:37:47  <BlueMatt> but the include should only be inside an ENABLE_WALLET
2662017-01-08T20:45:23  *** GAit has quit IRC
2672017-01-08T20:45:35  *** GAit has joined #bitcoin-core-dev
2682017-01-08T20:45:35  *** laurentmt has quit IRC
2692017-01-08T20:46:35  *** CubicEarth has joined #bitcoin-core-dev
2702017-01-08T20:51:12  *** CubicEarth has quit IRC
2712017-01-08T21:14:39  *** Sosumi has quit IRC
2722017-01-08T21:19:01  <luke-jr> BlueMatt: okay, I think I got everything
2732017-01-08T21:23:36  <luke-jr> oh fun, master doesn't build :x
2742017-01-08T21:23:50  * luke-jr hopes his rebase went smoothly
2752017-01-08T21:24:06  <BlueMatt> huh?
2762017-01-08T21:24:12  <BlueMatt> under what settings?
2772017-01-08T21:25:17  <luke-jr> test/raii_event_tests.cpp:39:58: error: ‘event_set_mem_functions’ was not declared in this scope
2782017-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. :)
2792017-01-08T21:26:51  <gmaxwell> fengling: it's fixed now.
2802017-01-08T21:28:42  *** Guyver2 has quit IRC
2812017-01-08T21:47:36  *** CubicEarth has joined #bitcoin-core-dev
2822017-01-08T21:50:13  *** dcousens has joined #bitcoin-core-dev
2832017-01-08T21:52:05  *** CubicEarth has quit IRC
2842017-01-08T22:10:04  *** CubicEarth has joined #bitcoin-core-dev
2852017-01-08T22:25:09  *** AaronvanW has quit IRC
2862017-01-08T22:30:15  *** trotski2000 has joined #bitcoin-core-dev
2872017-01-08T22:39:35  *** CubicEarth has quit IRC
2882017-01-08T22:59:00  *** PRab has quit IRC
2892017-01-08T23:00:05  *** CubicEarth has joined #bitcoin-core-dev
2902017-01-08T23:02:47  *** protomar has quit IRC
2912017-01-08T23:04:24  *** CubicEarth has quit IRC
2922017-01-08T23:08:00  *** Chris_Stewart_5 has quit IRC
2932017-01-08T23:23:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2942017-01-08T23:31:37  *** MarcoFalke has left #bitcoin-core-dev
2952017-01-08T23:49:05  *** windsok has quit IRC