12017-02-28T00:01:15 *** ensign_ has quit IRC
22017-02-28T00:01:57 *** Taek42 has joined #bitcoin-core-dev
32017-02-28T00:02:04 *** trotski2000 has quit IRC
42017-02-28T00:02:30 *** cfields has quit IRC
52017-02-28T00:02:31 *** nsh has quit IRC
62017-02-28T00:02:31 *** Taek has quit IRC
72017-02-28T00:02:59 <gmaxwell> I don't know why we're suddenly talking about this in here. Nothing has changed. We knew that sha1 collisions could be constructed with ~2^64 work, and the prefix that google constructed it for can't (AFAIK) be used to trouble git.
82017-02-28T00:03:26 <gmaxwell> If github were to move to a propritary and incompatible version of git from git itself I would urge we drop github immediately.
92017-02-28T00:04:39 *** trotski2000 has joined #bitcoin-core-dev
102017-02-28T00:05:39 <jeremyrubin> gmaxwell: i would expect it to be FOSS, although it's unclear what you mean by 'propritary'
112017-02-28T00:05:41 *** cfields has joined #bitcoin-core-dev
122017-02-28T00:05:44 *** profall has quit IRC
132017-02-28T00:05:52 <jeremyrubin> my fault for offtopicing
142017-02-28T00:06:21 <sipa> gmaxwell: even if it was FOSS, it would require them to start maintaining a fork of gut
152017-02-28T00:06:25 <sipa> eh
162017-02-28T00:06:31 <sipa> jeremyrubin: even if it was FOSS, it would require them to start maintaining a fork of git
172017-02-28T00:06:46 <sipa> something i don't expect them to be remotely capable of (nor should they)
182017-02-28T00:07:56 <jeremyrubin> I thought they already do that? I think I read a while back they have an internal git implementation, could be wrong
192017-02-28T00:07:58 <gmaxwell> It took weeks of nagging just to get them to not display incorrect authorship information on our reposititory recently. Yet that didn't get 1:10th the conversation in here.
202017-02-28T00:08:26 <jeremyrubin> (could be misinformed there, can't find a link)
212017-02-28T00:10:12 <luke-jr> jeremyrubin: not one every user needs; in any case, unless they actually do it, it doesn't matter
222017-02-28T00:10:12 <sipa> jeremyrubin: i'm sure they have some patches
232017-02-28T00:10:12 <sipa> gmaxwell: not as dramatic :)
242017-02-28T00:10:41 <sipa> jeremyrubin: i don't understand why you think _github_ should be doing anything at all, besides sponsoring git development
252017-02-28T00:10:54 <sipa> (which i hope they're already doing)
262017-02-28T00:11:18 *** ensign_ has joined #bitcoin-core-dev
272017-02-28T00:11:19 *** nsh has joined #bitcoin-core-dev
282017-02-28T00:13:11 <bitcoin-git> [bitcoin] jtimon opened pull request #9882: RPC: Introduce -rpcamountdecimals for the RPC to use other units than BTC (master...0.14.99-rpc-amounts) https://github.com/bitcoin/bitcoin/pull/9882
292017-02-28T00:13:16 *** pindarhk has quit IRC
302017-02-28T00:13:33 <bitcoin-git> [bitcoin] jtimon closed pull request #9855: RPC: Use integer satoshis instead BTC with decimals (master...0.15-rpc-satoshis) https://github.com/bitcoin/bitcoin/pull/9855
312017-02-28T00:14:17 *** pindarhk has joined #bitcoin-core-dev
322017-02-28T00:14:36 <gmaxwell> it just seems odd to me, we had an actual ongoing exploit of the kind that you'd worry about in the abstract from second preimage attack (much less a hash collision). Yet it could be fixed by some simple action on github's part (not a protocol rework)-- and silence. Yet it isn't even clear if the kind of common prefix hash collision construction that people know how to do with sha1 could /ever
332017-02-28T00:14:43 <gmaxwell> / be much of an interesting attack beyond perhaps undermining signed commits, and everyone is talking about it... and now there are suggestions of drastic things like total github lock-in.
342017-02-28T00:14:46 <gmaxwell> This seems cultish.
352017-02-28T00:14:56 <gmaxwell> "omg sha1 is broken. we must do something! this is something! it must be done!"
362017-02-28T00:15:33 <jeremyrubin> jfc you're acting like github making a choice implies total github lock in
372017-02-28T00:15:46 <jeremyrubin> precisely, github is free to offer improvements on the code as they see fit
382017-02-28T00:16:01 <sipa> yes, but why github?
392017-02-28T00:16:15 <jeremyrubin> they are a company that offers git based services
402017-02-28T00:16:16 <sipa> and not say, the linux foundation
412017-02-28T00:16:20 <jeremyrubin> the largest one!
422017-02-28T00:16:47 <jeremyrubin> Does linux foundation offer git services? (honestly not sure? support?)
432017-02-28T00:17:10 <sipa> 15:41:32 < jeremyrubin> Is anyone else kinds surprised that github didn't have a ready to go sha256 <- i find that an incredibly offensive statement
442017-02-28T00:17:31 <jeremyrubin> offensive to who?
452017-02-28T00:17:41 <sipa> it sounds like you're saying "does anyone else think the git maintainers are idiots for ignoring this issue, and that github hasn't decided to fork off"
462017-02-28T00:18:01 <sipa> for something that may never be exploitable
472017-02-28T00:19:33 <BlueMatt> hmmmm, segfault in bitcoin-qt on startup :(
482017-02-28T00:19:57 <jeremyrubin> so it's offensive to... github? or git maintainers?
492017-02-28T00:20:13 <sipa> to me
502017-02-28T00:20:40 <jeremyrubin> Well git is named after a stupid person, so it may be fair to call them idiots :p
512017-02-28T00:20:48 *** sipa has left #bitcoin-core-dev
522017-02-28T00:21:12 <BlueMatt> on a more interesting subject..... https://0bin.net/paste/ECyDDhXzg+BH-92P#NQyXo2b457D6yx+Ezrj+-sVJcLTTFNrk1x36y/avIEA
532017-02-28T00:21:30 <gmaxwell> jeremyrubin: if your question were why hasn't github subbmited some patches upstream to implement it, I would have found it less alarming. But asking about them switching to an incompatible version? They can barely keep their site running competently.
542017-02-28T00:22:00 <gmaxwell> were they to do that it would sound a lot like embrace-extend-extinguish.
552017-02-28T00:22:29 *** sipa has joined #bitcoin-core-dev
562017-02-28T00:22:32 <jeremyrubin> I don't think I ever once said incompatible
572017-02-28T00:22:37 <jeremyrubin> you guys keep injecting that
582017-02-28T00:22:40 <BlueMatt> so, sipa, any thoughts on my segfault?
592017-02-28T00:23:00 <BlueMatt> sipa: you missed the link https://0bin.net/paste/ECyDDhXzg+BH-92P#NQyXo2b457D6yx+Ezrj+-sVJcLTTFNrk1x36y/avIEA
602017-02-28T00:23:20 <sipa> jeremyrubin: i'm offended that you're suggesting github create drama where there is no need for concern
612017-02-28T00:23:54 <sipa> anyway, let's drop the topic
622017-02-28T00:26:23 <BlueMatt> ehh, I'll just file an issue
632017-02-28T00:26:30 <sipa> BlueMatt: ugh
642017-02-28T00:26:38 <sipa> thread 10 is the one that crashed?
652017-02-28T00:26:42 <BlueMatt> no, thread 1
662017-02-28T00:26:47 <BlueMatt> somewhere deep in Qt
672017-02-28T00:27:01 <BlueMatt> thread 10 is just mempool re-acceptance, it looks liek
682017-02-28T00:27:47 * BlueMatt has coredump
692017-02-28T00:27:47 <gmaxwell> #2 0x00007fd6b81ee197 in QTableView::setSortingEnabled(bool) () from /usr/lib/libQt5Widgets.so.5
702017-02-28T00:27:49 <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
712017-02-28T00:27:53 <gmaxwell> #3 0x00005617b3a315ec in TransactionView::setModel (this=0x5617b716bc50, _model=_model@entry=0x5617b6e77530) at qt/transactionview.cpp:205
722017-02-28T00:27:55 <gribble> https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet · Issue #3 · bitcoin/bitcoin · GitHub
732017-02-28T00:29:20 <sipa> BlueMatt: no clue about Qt issues
742017-02-28T00:30:45 <gmaxwell> nothing in the immediate backtrace of that crash appears to have been recently changed.
752017-02-28T00:31:08 <gmaxwell> BlueMatt: I assume this is a build on your system? (not a gitian binary)
762017-02-28T00:31:35 <gmaxwell> BlueMatt: if it's 100% reproducable can you bisect it?
772017-02-28T00:32:02 <BlueMatt> gmaxwell: it is not reproduceable, happened once
782017-02-28T00:32:10 <BlueMatt> i can go restart that thing all day and see.......
792017-02-28T00:32:37 <gmaxwell> BlueMatt: maybe try adding a shutdown shorty after start and leave it going in a loop?
802017-02-28T00:34:05 <BlueMatt> well it crashed in the same place on ~ the 4th try
812017-02-28T00:34:10 <BlueMatt> so its not exactly non-reproduceable
822017-02-28T00:35:55 <gmaxwell> BlueMatt: gitian binary or not.
832017-02-28T00:36:02 <BlueMatt> not
842017-02-28T00:36:09 <BlueMatt> locally-built
852017-02-28T00:36:41 <gmaxwell> can you stick a shutdown right after init completes and see if you can still reproduce it?
862017-02-28T00:36:53 <BlueMatt> lemme see if I can rebuild and still reproduce it first :P
872017-02-28T00:37:12 <gmaxwell> yea, I guess I was also suggesting that.
882017-02-28T00:42:21 <BlueMatt> yes, fresh build crashes in the same way, so thats...good?
892017-02-28T00:45:07 <gmaxwell> The fresh build contains potassium benzoate.
902017-02-28T00:52:19 <BlueMatt> gmaxwell: yay hisenbug :(
912017-02-28T00:53:55 <BlueMatt> yup, just adding a StartShutdown() 30 seconds after start in the middle of the net code appears to fix it
922017-02-28T00:54:53 <cfields> BlueMatt: is there anything in the wallet?
932017-02-28T00:55:20 <BlueMatt> yes, lots 'o things
942017-02-28T00:55:24 <BlueMatt> (nothing unconfirmed, though)
952017-02-28T00:58:01 <BlueMatt> yup, and now even the old binary wont crash
962017-02-28T00:58:02 <BlueMatt> ffs
972017-02-28T01:00:26 *** echonaut has quit IRC
982017-02-28T01:00:28 *** abpa has quit IRC
992017-02-28T01:01:11 *** echonaut has joined #bitcoin-core-dev
1002017-02-28T01:10:34 <cfields> BlueMatt: seems likely to me that re-acceptance is advertising a tx early in the startup process, before the TransactionView is fully setup. So I assume you'd need a sufficiently interesting persisted mempool in order to repro.
1012017-02-28T01:10:52 <cfields> (catching up, not sure if you guys already looked down that path)
1022017-02-28T01:11:29 <BlueMatt> cfields: no one looked down any path
1032017-02-28T01:11:40 <BlueMatt> cfields: strange, there is definitely nothing in mempool which applies to that wallet
1042017-02-28T01:12:44 <cfields> BlueMatt: still reproducible if you disable mempool loading?
1052017-02-28T01:13:09 <cfields> i don't really see where else it'd be coming from, so i assume not
1062017-02-28T01:13:45 <BlueMatt> cfields: well it stoped being reproduceable, so maybe mempool dump changed
1072017-02-28T01:14:20 <cfields> BlueMatt: right. If you repro again, I'd be sure to make a backup
1082017-02-28T01:14:25 <BlueMatt> still, makes no sense as no mempool txn should apply to that wallet
1092017-02-28T01:14:27 <BlueMatt> sure
1102017-02-28T01:15:30 <cfields> i have no idea what gets blasted around, will try to trace the paths
1112017-02-28T01:17:32 *** dodomojo has joined #bitcoin-core-dev
1122017-02-28T01:24:07 *** dodomojo has quit IRC
1132017-02-28T01:27:49 *** dodomojo has joined #bitcoin-core-dev
1142017-02-28T01:28:35 *** wudayoda has joined #bitcoin-core-dev
1152017-02-28T01:29:40 *** CubicEarth has joined #bitcoin-core-dev
1162017-02-28T01:30:36 <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9884: Add Pieter's old signed commits to revsig-commits (master...2017-02-pieter-revsig) https://github.com/bitcoin/bitcoin/pull/9884
1172017-02-28T01:30:47 <BlueMatt> ^ will need to be merged before anything else or travis will barf
1182017-02-28T01:30:57 <BlueMatt> well, travis will barf in an obvious way and only on master, so nbd
1192017-02-28T01:30:59 <BlueMatt> but will barf
1202017-02-28T01:33:10 *** CubicEarth has quit IRC
1212017-02-28T01:54:16 *** Chris_Stewart_5 has quit IRC
1222017-02-28T02:05:02 *** fanquake has joined #bitcoin-core-dev
1232017-02-28T02:11:29 *** profall has joined #bitcoin-core-dev
1242017-02-28T02:16:39 *** fanquake has quit IRC
1252017-02-28T02:19:29 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1262017-02-28T02:42:48 *** Chris_Stewart_5 has quit IRC
1272017-02-28T02:53:28 *** wudayoda has quit IRC
1282017-02-28T02:54:03 *** Ylbam has quit IRC
1292017-02-28T02:54:18 *** wudayoda has joined #bitcoin-core-dev
1302017-02-28T03:16:17 *** Victor_sueca has joined #bitcoin-core-dev
1312017-02-28T03:18:42 *** Victorsueca has quit IRC
1322017-02-28T03:26:29 *** adiabat has joined #bitcoin-core-dev
1332017-02-28T03:37:05 *** jtimon has quit IRC
1342017-02-28T04:02:53 *** Giszmo has quit IRC
1352017-02-28T04:36:24 *** BlueMatt has quit IRC
1362017-02-28T04:41:04 *** wudayoda has quit IRC
1372017-02-28T04:44:34 *** dodomojo has quit IRC
1382017-02-28T04:54:13 *** BlueMatt has joined #bitcoin-core-dev
1392017-02-28T05:02:28 *** d9b4bef9 has quit IRC
1402017-02-28T05:03:07 *** d9b4bef9 has joined #bitcoin-core-dev
1412017-02-28T05:07:43 *** cyphr_ has joined #bitcoin-core-dev
1422017-02-28T05:32:13 <bitcoin-git> [bitcoin] gmaxwell opened pull request #9886: In feerate ties, prefer larger packages first. (master...prefer_bigger_packages) https://github.com/bitcoin/bitcoin/pull/9886
1432017-02-28T06:14:06 *** lclc has joined #bitcoin-core-dev
1442017-02-28T06:15:44 *** cyphr_ has quit IRC
1452017-02-28T06:17:21 *** JackH has quit IRC
1462017-02-28T06:57:55 *** wasi has quit IRC
1472017-02-28T07:04:27 *** wasi has joined #bitcoin-core-dev
1482017-02-28T07:15:48 *** kadoban has quit IRC
1492017-02-28T07:46:21 *** BashCo has quit IRC
1502017-02-28T08:06:05 *** BashCo has joined #bitcoin-core-dev
1512017-02-28T08:15:16 *** Ylbam has joined #bitcoin-core-dev
1522017-02-28T09:09:43 *** kewde[m]1 has quit IRC
1532017-02-28T09:09:45 *** frabrunelle has quit IRC
1542017-02-28T09:10:29 *** Victor_sueca is now known as Victorsueca
1552017-02-28T09:26:32 *** PaulCapestany has quit IRC
1562017-02-28T09:28:06 *** PaulCapestany has joined #bitcoin-core-dev
1572017-02-28T09:32:07 *** jannes has joined #bitcoin-core-dev
1582017-02-28T10:07:39 *** PaulCapestany has quit IRC
1592017-02-28T10:08:39 *** JackH has joined #bitcoin-core-dev
1602017-02-28T10:11:50 *** PaulCapestany has joined #bitcoin-core-dev
1612017-02-28T10:25:11 *** AaronvanW has joined #bitcoin-core-dev
1622017-02-28T10:25:14 <jonasschnelli> Can I still normally merge a PR or did we already witch to the SHA512 merge script?
1632017-02-28T10:28:30 *** BashCo_ has joined #bitcoin-core-dev
1642017-02-28T10:31:27 *** BashCo has quit IRC
1652017-02-28T10:35:38 *** lclc has quit IRC
1662017-02-28T10:36:21 <wumpus> I'm testing the SHA512 merge script, but we haven't merged it yet
1672017-02-28T10:36:25 <wumpus> so feel free to not use it yet
1682017-02-28T10:36:38 *** kewde[m] has joined #bitcoin-core-dev
1692017-02-28T10:36:50 <jonasschnelli> okay... i'll wait until we have merged the SHA512 tree change
1702017-02-28T10:37:17 <wumpus> there's still an open issue about symlinks on that ,but as we (AFAIK) don't have symlinks in bitcoin repo it's somewhat theoretical
1712017-02-28T10:38:11 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/88c2ae3ed2bb...65fdc37ac306
1722017-02-28T10:38:12 <bitcoin-git> bitcoin/master c5f008a Cory Fields: don't throw std::bad_alloc when out of memory. Instead, terminate immediately
1732017-02-28T10:38:12 <bitcoin-git> bitcoin/master d4ee7ba Cory Fields: prevector: assert successful allocation
1742017-02-28T10:38:13 <bitcoin-git> bitcoin/master 65fdc37 Wladimir J. van der Laan: Merge #9856: Terminate immediately when allocation fails...
1752017-02-28T10:38:31 <bitcoin-git> [bitcoin] laanwj closed pull request #9856: Terminate immediately when allocation fails (master...bad_alloc_terminate2) https://github.com/bitcoin/bitcoin/pull/9856
1762017-02-28T10:41:23 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/eddaa6b35d41...775cf54d0e0a
1772017-02-28T10:41:24 <bitcoin-git> bitcoin/0.14 50953c2 Wladimir J. van der Laan: tests: Fix dangling pwalletMain pointer in wallet tests...
1782017-02-28T10:41:25 <bitcoin-git> bitcoin/0.14 69832aa Cory Fields: don't throw std::bad_alloc when out of memory. Instead, terminate immediately...
1792017-02-28T10:41:25 <bitcoin-git> bitcoin/0.14 775cf54 Cory Fields: prevector: assert successful allocation...
1802017-02-28T10:41:43 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/775cf54d0e0a...5aaac4d09e7e
1812017-02-28T10:41:44 <bitcoin-git> bitcoin/0.14 29bae0c Russell Yanofsky: Mention bumpfee in 0.14 release notes.
1822017-02-28T10:41:44 <bitcoin-git> bitcoin/0.14 5aaac4d Wladimir J. van der Laan: Merge #9878: Mention bumpfee in 0.14 release notes....
1832017-02-28T10:42:04 *** AaronvanW has quit IRC
1842017-02-28T10:42:59 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/08e0690f3f3b2f33040916200e8d4444298cf226
1852017-02-28T10:42:59 <bitcoin-git> bitcoin/0.14 08e0690 Russell Yanofsky: Update sendfrom RPC help to correct coin selection misconception...
1862017-02-28T10:44:05 *** MarcoFalke has joined #bitcoin-core-dev
1872017-02-28T10:44:32 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/65fdc37ac306...d75e8cb44def
1882017-02-28T10:44:33 <bitcoin-git> bitcoin/master fe71661 Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation
1892017-02-28T10:44:33 <bitcoin-git> bitcoin/master d75e8cb Wladimir J. van der Laan: Merge #9879: [doc] Update doc/bips.md for BIP90 implementation...
1902017-02-28T10:44:58 <bitcoin-git> [bitcoin] laanwj closed pull request #9879: [doc] Update doc/bips.md for BIP90 implementation (master...2017-02-bips-doc-bip90) https://github.com/bitcoin/bitcoin/pull/9879
1912017-02-28T10:47:21 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/a48b998ff377a827357732b8868b0de10768129d
1922017-02-28T10:47:21 <bitcoin-git> bitcoin/0.14 a48b998 Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation...
1932017-02-28T10:47:43 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to 0.14: https://github.com/bitcoin/bitcoin/compare/a48b998ff377...1f83663bc2c8
1942017-02-28T10:47:44 <bitcoin-git> bitcoin/0.14 50ae5c7 Matt Corallo: Document increase in memory usage due to mempool/dbcache sharing
1952017-02-28T10:47:44 <bitcoin-git> bitcoin/0.14 1f83663 Wladimir J. van der Laan: Merge #9866: Document increase in memory usage due to mempool/dbcache sharing...
1962017-02-28T10:48:05 <wumpus> going to tag rc3 in a moment
1972017-02-28T10:51:00 *** AaronvanW has joined #bitcoin-core-dev
1982017-02-28T10:55:29 *** Victorsueca is now known as LuckyVictor
1992017-02-28T10:55:31 *** n1ce has quit IRC
2002017-02-28T10:56:25 *** n1ce has joined #bitcoin-core-dev
2012017-02-28T10:56:45 *** LuckyVictor is now known as Victorsueca
2022017-02-28T10:58:03 *** frabrunelle has joined #bitcoin-core-dev
2032017-02-28T10:58:13 *** StoBrendo has joined #bitcoin-core-dev
2042017-02-28T10:59:57 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d75e8cb44def...30bdcfca2b7e
2052017-02-28T10:59:58 <bitcoin-git> bitcoin/master 83ac719 Marijn Stollenga: Change bitcoin address in RPC helpaddress to an invalid address, so people don't accidentally send coins there (like I did).
2062017-02-28T10:59:58 <bitcoin-git> bitcoin/master 30bdcfc Wladimir J. van der Laan: Merge #9865: Change bitcoin address in RPC help message...
2072017-02-28T11:00:17 <bitcoin-git> [bitcoin] laanwj closed pull request #9865: Change bitcoin address in RPC help message (master...master) https://github.com/bitcoin/bitcoin/pull/9865
2082017-02-28T11:01:35 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/289204fbe0c188b3cd145dd7b2e271f97a956ba3
2092017-02-28T11:01:35 <bitcoin-git> bitcoin/0.14 289204f Marijn Stollenga: Change bitcoin address in RPC helpaddress to an invalid address, so people don't accidentally send coins there (like I did)....
2102017-02-28T11:03:04 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/30bdcfca2b7e...f5ef8e9dd29c
2112017-02-28T11:03:05 <bitcoin-git> bitcoin/master 0a17714 Wladimir J. van der Laan: uint256: replace sprintf with HexStr and reverse-iterator...
2122017-02-28T11:03:05 <bitcoin-git> bitcoin/master 19cafc6 Wladimir J. van der Laan: test: Replace remaining sprintf with snprintf...
2132017-02-28T11:03:06 <bitcoin-git> bitcoin/master f5ef8e9 Wladimir J. van der Laan: Merge #9867: Replace remaining sprintf with snprintf...
2142017-02-28T11:03:25 <bitcoin-git> [bitcoin] laanwj closed pull request #9867: Replace remaining sprintf with snprintf (master...2017_02_snprintf) https://github.com/bitcoin/bitcoin/pull/9867
2152017-02-28T11:11:15 *** lclc has joined #bitcoin-core-dev
2162017-02-28T11:12:55 *** MarcoFalke has left #bitcoin-core-dev
2172017-02-28T11:22:40 *** Alina-malina has quit IRC
2182017-02-28T11:30:10 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5ef8e9dd29c...c322fa472efa
2192017-02-28T11:30:10 <bitcoin-git> bitcoin/master 467df39 John Newbery: Remove nonsense #undef foreach...
2202017-02-28T11:30:11 <bitcoin-git> bitcoin/master c322fa4 Wladimir J. van der Laan: Merge #9732: [Trivial] Remove nonsense #undef foreach...
2212017-02-28T11:30:31 <bitcoin-git> [bitcoin] laanwj closed pull request #9732: [Trivial] Remove nonsense #undef foreach (master...removeundefforeach) https://github.com/bitcoin/bitcoin/pull/9732
2222017-02-28T11:31:52 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c322fa472efa...b7547fa93e01
2232017-02-28T11:31:52 <bitcoin-git> bitcoin/master 4b183d3 Marko Bencun: Remove block file location upgrade code...
2242017-02-28T11:31:53 <bitcoin-git> bitcoin/master b7547fa Wladimir J. van der Laan: Merge #9822: Remove block file location upgrade code...
2252017-02-28T11:32:15 <bitcoin-git> [bitcoin] laanwj closed pull request #9822: Remove block file location upgrade code (master...appinitmain) https://github.com/bitcoin/bitcoin/pull/9822
2262017-02-28T11:35:06 *** lclc has quit IRC
2272017-02-28T11:48:44 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/1825a03f8144572eaf532b6b3b3acc1a09577d1f
2282017-02-28T11:48:44 <bitcoin-git> bitcoin/0.14 1825a03 Pieter Wuille: Avoid VLA in hash.h...
2292017-02-28T11:50:16 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/8d2d08efaa5fb6b29638fef7fb9bdf051db85f2e
2302017-02-28T11:50:16 <bitcoin-git> bitcoin/0.14 8d2d08e Wladimir J. van der Laan: qt: pre-rc3 translations update
2312017-02-28T11:53:11 *** pindarhk has quit IRC
2322017-02-28T11:54:52 *** pindarhk has joined #bitcoin-core-dev
2332017-02-28T11:56:46 *** MarcoFalke has joined #bitcoin-core-dev
2342017-02-28T12:23:50 *** Alina-malina has joined #bitcoin-core-dev
2352017-02-28T12:25:37 *** lclc has joined #bitcoin-core-dev
2362017-02-28T12:27:53 *** owowo has joined #bitcoin-core-dev
2372017-02-28T12:30:09 *** Alina-malina has quit IRC
2382017-02-28T12:30:09 *** Alina-malina has joined #bitcoin-core-dev
2392017-02-28T12:44:01 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/58800e3556aefbc002b9554b3af5167655fd7943
2402017-02-28T12:44:01 <bitcoin-git> bitcoin/0.14 58800e3 Wladimir J. van der Laan: doc: pre-rc3 changelog update
2412017-02-28T12:50:18 <MarcoFalke> wumpus: Sorry to break the spree, but maybe #9829 should be included in rc3?
2422017-02-28T12:50:20 <gribble> https://github.com/bitcoin/bitcoin/issues/9829 | Fix importmulti returning rescan errors for wrong keys by ryanofsky · Pull Request #9829 · bitcoin/bitcoin · GitHub
2432017-02-28T12:50:32 <wumpus> is that ready now?
2442017-02-28T12:53:13 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b7547fa93e01...7e2a2212ecac
2452017-02-28T12:53:14 <bitcoin-git> bitcoin/master 306bd72 Russell Yanofsky: Fix importmulti returning rescan errors for wrong keys...
2462017-02-28T12:53:14 <bitcoin-git> bitcoin/master 7e2a221 Wladimir J. van der Laan: Merge #9829: Fix importmulti returning rescan errors for wrong keys...
2472017-02-28T12:53:30 <bitcoin-git> [bitcoin] laanwj closed pull request #9829: Fix importmulti returning rescan errors for wrong keys (master...pr/multiinc) https://github.com/bitcoin/bitcoin/pull/9829
2482017-02-28T12:53:53 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/ad24256a65aa4281831e14097a29ac1efe8b5c02
2492017-02-28T12:53:54 <bitcoin-git> bitcoin/0.14 ad24256 Russell Yanofsky: Fix importmulti returning rescan errors for wrong keys...
2502017-02-28T12:54:01 <wumpus> apparently. THanks for mentinoning, I was subliminally ignoring that one for some reason because I assumed it still had nits open
2512017-02-28T12:59:27 <wumpus> * [new tag] v0.14.0rc3 -> v0.14.0rc3
2522017-02-28T13:08:08 *** cysm has quit IRC
2532017-02-28T13:14:32 *** Guyver2 has joined #bitcoin-core-dev
2542017-02-28T13:16:20 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9888: travis: Verify commits only for one target (master...Mf1702-travisCommits) https://github.com/bitcoin/bitcoin/pull/9888
2552017-02-28T13:17:11 *** paveljanik has quit IRC
2562017-02-28T13:20:25 *** cysm has joined #bitcoin-core-dev
2572017-02-28T13:31:44 *** mol has quit IRC
2582017-02-28T13:34:25 *** moli_ has joined #bitcoin-core-dev
2592017-02-28T13:36:26 *** cysm has quit IRC
2602017-02-28T13:42:59 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2612017-02-28T13:45:22 *** Giszmo has joined #bitcoin-core-dev
2622017-02-28T13:59:48 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7e2a2212ecac...36afd4db4442
2632017-02-28T13:59:49 <bitcoin-git> bitcoin/master fa32a16 MarcoFalke: travis: Verify commits only for one target...
2642017-02-28T13:59:49 <bitcoin-git> bitcoin/master 36afd4d MarcoFalke: Merge #9888: travis: Verify commits only for one target...
2652017-02-28T14:00:10 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9888: travis: Verify commits only for one target (master...Mf1702-travisCommits) https://github.com/bitcoin/bitcoin/pull/9888
2662017-02-28T14:18:57 *** lclc has quit IRC
2672017-02-28T14:19:34 *** rubensayshi has quit IRC
2682017-02-28T14:21:32 *** rubensayshi has joined #bitcoin-core-dev
2692017-02-28T14:25:38 *** lclc has joined #bitcoin-core-dev
2702017-02-28T14:27:44 *** cysm has joined #bitcoin-core-dev
2712017-02-28T14:36:29 *** BirneGetreide has joined #bitcoin-core-dev
2722017-02-28T14:37:59 *** BG has joined #bitcoin-core-dev
2732017-02-28T14:38:05 <achow101> whoever finishes osx next, let me know if your hashes match mine: 9b247d80bb79f3b96d49e9d61b1977e07260c788022714e670dc7673a35fbf25 bitcoin-0.14.0-osx-unsigned.dmg
2742017-02-28T14:38:22 <achow101> (I'm guessing it won't)
2752017-02-28T14:38:53 *** BG has quit IRC
2762017-02-28T14:42:58 <cfields> achow101: match :)
2772017-02-28T14:46:42 <achow101> yay
2782017-02-28T15:02:45 <jonasschnelli> cfields, achow101: hmm.. no match: https://bitcoinsrv.jonasschnelli.ch/builds/15/bitcoin-osx-0.14-build.assert
2792017-02-28T15:02:57 <jonasschnelli> But new build setup.. could be on my side.
2802017-02-28T15:03:00 <jonasschnelli> Linux and Windows?
2812017-02-28T15:03:53 <jonasschnelli> db7f17e256c2d832e7eb62f878b74cbd95f3a9af3d0554828b2383a8b25faee3 bitcoin-0.14.0-x86_64-linux-gnu.tar.gz
2822017-02-28T15:03:54 <cfields> ugh
2832017-02-28T15:04:05 <jonasschnelli> 0bf3cae0567d10c9d3cc6ff0125e529c7ee0a336ab6532a2336e4aa7ee394457 bitcoin-0.14.0-win64-setup-unsigned.exe
2842017-02-28T15:04:06 <cfields> jonasschnelli: i'll push all of mine in a min, linux still building
2852017-02-28T15:04:17 <achow101> jonasschnelli: mine is in a pr: https://github.com/bitcoin-core/gitian.sigs/pull/486
2862017-02-28T15:05:17 <cfields> jonasschnelli: match for win64
2872017-02-28T15:05:33 <achow101> jonasschnelli: linux and windows match
2882017-02-28T15:05:38 <jonasschnelli> Yes. Linux and Win matches with achow101
2892017-02-28T15:05:40 <jonasschnelli> But not OSX
2902017-02-28T15:06:05 <jonasschnelli> Same descriptor and SDK
2912017-02-28T15:06:17 <jonasschnelli> source tarball file matches..
2922017-02-28T15:06:22 <jonasschnelli> So.. this is strange
2932017-02-28T15:06:35 <achow101> just like the issue with the last two rcs...
2942017-02-28T15:07:12 <jonasschnelli> ah.. haven't followed that. OSX build of rc1-2 wasn't deterministic?
2952017-02-28T15:07:12 <achow101> are you using kvm or lxc?
2962017-02-28T15:07:16 <jonasschnelli> lxc
2972017-02-28T15:08:26 <achow101> jonasschnelli: yeah, my osx builds for rc1 and 2 did not match everyone elses except under certain circumstances. it was really weird and the cause is unknown
2982017-02-28T15:09:07 <achow101> (rc1 each time I built it alternated between matching and mismatching, rc2 the first build mismatched and all subsequent ones after a new base vm matched)
2992017-02-28T15:09:42 *** wudayoda has joined #bitcoin-core-dev
3002017-02-28T15:11:18 <achow101> jonasschnelli: try remaking with a new base vm?
3012017-02-28T15:11:22 *** wudayoda has joined #bitcoin-core-dev
3022017-02-28T15:11:31 <jonasschnelli> achow101: I made the base vm last week.
3032017-02-28T15:15:37 <achow101> ok, so I just rebuilt and this one matches jonasschnelli's
3042017-02-28T15:15:44 <achow101> :/
3052017-02-28T15:15:59 <jonasschnelli> achow101: okay. Thanks for removing your OSX backdoor. :)
3062017-02-28T15:16:35 <achow101> cfields must have the same backdoor too :D
3072017-02-28T15:16:52 <jonasschnelli> yeah... maybe you are the same person as well. :)
3082017-02-28T15:20:06 <wumpus> did anyone ever compare the executables?
3092017-02-28T15:20:53 <jonasschnelli> Mine is here if someone wants: https://bitcoinsrv.jonasschnelli.ch/builds/15
3102017-02-28T15:20:58 <achow101> wumpus: I think cfields did. IIRC I sent him the osx binaries and all of the compiled object binaries pulled oof of the vm
3112017-02-28T15:21:13 <achow101> s/oof/out/
3122017-02-28T15:21:28 <cfields> wumpus: yes, i compared a ton.
3132017-02-28T15:21:39 <cfields> couldn't track it down to anything. Makes no sense.
3142017-02-28T15:22:27 *** lclc has quit IRC
3152017-02-28T15:22:37 <cfields> wumpus: all object files were the same, only difference is the executables. And They're created with our self-built linker
3162017-02-28T15:23:26 <cfields> only thing i can come up with (and how it looks) is symbol sort order
3172017-02-28T15:23:45 <wumpus> sounds a bit like the issue we had on windows, where some section was left uninitialized
3182017-02-28T15:23:51 <cfields> achow101 / jonasschnelli: mind retrying with 1 build job?
3192017-02-28T15:23:57 <wumpus> a linker map eventually helped me narrow down the issue
3202017-02-28T15:24:23 <wumpus> sort order? hm, a locale issue?
3212017-02-28T15:24:33 <achow101> cfields: sure.
3222017-02-28T15:25:07 <jonasschnelli> cfields: Yes. I can do that.
3232017-02-28T15:25:39 <cfields> wumpus: my only theory so far (based on absolutely nothing) is the $(wildcard) in the osx makefile, which could maybe lead to a different link-order
3242017-02-28T15:25:53 <cfields> wumpus: oh, i left out.. only the osx binary differs
3252017-02-28T15:26:10 <jonasschnelli> cfields, achow101: build started with -j1 https://bitcoinsrv.jonasschnelli.ch/src/build.html?buildid=16
3262017-02-28T15:26:17 <cfields> achow101 / jonasschnelli: thanks :)
3272017-02-28T15:27:12 <wumpus> cfields: that sounds like a good theory to me, various filesystems will return files in different order. May make sense to pass that through a (locale independent) sort as well.
3282017-02-28T15:28:02 <achow101> wumpus: what doesn't make sense is that my build would alternate between two different hashes every time I built
3292017-02-28T15:28:03 <cfields> wumpus: yes
3302017-02-28T15:28:18 <cfields> achow101: hence the -j1 suggestion :)
3312017-02-28T15:28:36 <sipa> 9
3322017-02-28T15:29:15 <wumpus> achow101: it makes perfect sense if it's filesystem non-determinism
3332017-02-28T15:30:00 <achow101> wumpus: how so?
3342017-02-28T15:31:03 <sipa> the filesystem is recreated for each build, no?
3352017-02-28T15:31:38 <wumpus> achow101: there's just no guarantee that the file system is deterministic
3362017-02-28T15:32:43 <wumpus> especially in the presence of multple threads, the order in which things are written, i/o scheduling, etc
3372017-02-28T15:32:47 <achow101> but shouldn't that also effect linux and windows builds?
3382017-02-28T15:33:01 <wumpus> no, in linux and windows builds we don't use any wildcards in the linker AFAIK
3392017-02-28T15:33:35 <achow101> oh
3402017-02-28T15:33:54 <wumpus> also even if they did, they use a different linker which may be sorting things differently, for all we know
3412017-02-28T15:34:09 <wumpus> osx is kind of an odd duck out in the toolchains as it uses the clang-based stuff
3422017-02-28T15:34:44 <sipa> also, any idea why Travis fails on the rebase of #9791 ?
3432017-02-28T15:34:46 <gribble> https://github.com/bitcoin/bitcoin/issues/9791 | Avoid VLA in hash.h by sipa · Pull Request #9791 · bitcoin/bitcoin · GitHub
3442017-02-28T15:34:53 <cfields> fwiw, this is why i get grumpy about wildcard usage in Makefiles. I know it's verbose, but I'd rather always just list explicitly
3452017-02-28T15:34:55 <sipa> there seem to be no actual errors
3462017-02-28T15:35:56 <wumpus> cfields: yes, unless it can be sorted
3472017-02-28T15:36:13 <wumpus> cfields: but for the linker I certainly agree files should simply be enumerated
3482017-02-28T15:36:27 <cfields> sipa: looks like verify-commits.sh fails
3492017-02-28T15:36:28 <wumpus> cfields: for things like documentation + images it can be overly verbose to specify everything
3502017-02-28T15:36:56 <cfields> wumpus: for that stuff, sure. In this case, it's the png's, which get fed to rcc, which get compiled, then linked
3512017-02-28T15:37:11 <cfields> lots of places there for a reordering to have an effect
3522017-02-28T15:37:50 <wumpus> cfields: yep
3532017-02-28T15:37:55 <cfields> (though the object files match, so i'll admit, it's unlikely to be the actual cause here)
3542017-02-28T15:38:36 <wumpus> so it could only be the ordering of the object files
3552017-02-28T15:39:07 <cfields> right
3562017-02-28T15:39:49 <cfields> also, achow's dump was missing the .a's, so i couldn't compare those. Could be ar's fault as well.
3572017-02-28T15:40:00 <cfields> (still rebuilding to get a link map)
3582017-02-28T15:40:19 <wumpus> yes, could be ar's fault too, or the order of objects passed to ar
3592017-02-28T15:40:25 <achow101> cfields: they weren't in the vm image?
3602017-02-28T15:40:46 <wumpus> why is verify-commits failing?
3612017-02-28T15:41:00 <cfields> achow101: no, the gitian script removes 'em
3622017-02-28T15:41:32 <achow101> oh.
3632017-02-28T15:41:38 <cfields> <BlueMatt> ^ will need to be merged before anything else or travis will barf
3642017-02-28T15:41:38 <cfields> <BlueMatt> well, travis will barf in an obvious way and only on master, so nbd
3652017-02-28T15:41:38 <cfields> <BlueMatt> but will barf
3662017-02-28T15:41:47 <cfields> ^ wumpus: unsure if that's solved already?
3672017-02-28T15:42:09 <BlueMatt> its not (see travis failures on master)
3682017-02-28T15:42:12 <achow101> cfields: -j1 build finished with my original hashes
3692017-02-28T15:42:16 <cfields> he was referring to #9884, so i assume no
3702017-02-28T15:42:23 <wumpus> why is that suddenly failing?
3712017-02-28T15:42:24 <gribble> https://github.com/bitcoin/bitcoin/issues/9884 | Add Pieters old signed commits to revsig-commits by TheBlueMatt · Pull Request #9884 · bitcoin/bitcoin · GitHub
3722017-02-28T15:42:43 <sipa> i revoked some of my subkeys and created new ones
3732017-02-28T15:42:51 <cfields> achow101: ok great, let's see if jonasschnelli's matches
3742017-02-28T15:42:59 <sipa> with reason "keys are superseded"
3752017-02-28T15:43:19 <MarcoFalke> sipa: I created fresh signatures for mine
3762017-02-28T15:43:22 <wumpus> and that breaks all verifyies of old signatures? ouch
3772017-02-28T15:43:42 <MarcoFalke> wumpus: Just don't refresh your keys for now :P
3782017-02-28T15:44:16 <jonasschnelli> -j1 asserts file 0.14.0rc3 OSX: https://bitcoinsrv.jonasschnelli.ch/builds/16/bitcoin-osx-0.14-build.assert
3792017-02-28T15:44:24 <wumpus> anyhow going to merge that one
3802017-02-28T15:44:41 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/36afd4db4442...11049f4fe626
3812017-02-28T15:44:41 <bitcoin-git> bitcoin/master a4b02f4 Matt Corallo: Add Pieter's old signed commits to revsig-commits
3822017-02-28T15:44:42 <bitcoin-git> bitcoin/master 11049f4 Wladimir J. van der Laan: Merge #9884: Add Pieter's old signed commits to revsig-commits...
3832017-02-28T15:44:44 <jonasschnelli> different hashes when using -j1
3842017-02-28T15:44:52 <sipa> wumpus: yes, my suggestion to matt would be to check the reason for revocation
3852017-02-28T15:45:05 <sipa> because this will happen again, i guess
3862017-02-28T15:45:05 <bitcoin-git> [bitcoin] laanwj closed pull request #9884: Add Pieter's old signed commits to revsig-commits (master...2017-02-pieter-revsig) https://github.com/bitcoin/bitcoin/pull/9884
3872017-02-28T15:45:25 <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.14: https://github.com/bitcoin/bitcoin/commit/5e709122343e1a336ee8ee21b003a298a65813f3
3882017-02-28T15:45:26 <bitcoin-git> bitcoin/0.14 5e70912 Matt Corallo: Add Pieter's old signed commits to revsig-commits...
3892017-02-28T15:45:36 <cfields> jonasschnelli: woohoo, match
3902017-02-28T15:46:03 <jonasschnelli> cfields: yes. So the build jobs break the determinism
3912017-02-28T15:46:55 <cfields> jonasschnelli: certainly not definitive, but seems very plausible
3922017-02-28T15:47:50 <cfields> jonasschnelli: for rc1/rc2, achow101's builds alternated between 2 outcomes, one of which was a match
3932017-02-28T15:48:40 <wumpus> what should I use to re-sign my subkey?
3942017-02-28T15:48:47 <wumpus> without getting trouble like that
3952017-02-28T15:51:28 <BlueMatt> sipa/wumpus: yea, I mean its not clear to me that keyservers will update their revocation cert for keys which changed from "superceded" to "compromised"
3962017-02-28T15:51:35 <BlueMatt> so I dont want to do that unless there is some assurance there
3972017-02-28T15:51:36 <achow101> cfields: it looks like jonasschnelli's finished: https://bitcoinsrv.jonasschnelli.ch/builds/16/bitcoin-osx-0.14-build.assert
3982017-02-28T15:52:05 <BlueMatt> wumpus: so I dont think anyone figured out how to re-cross-certify using a new hash, so I'm just gonna enforce non-sha1 on new sigs
3992017-02-28T15:52:23 <BlueMatt> wumpus: meaning just create new subs for signing and use those instead of the old ones
4002017-02-28T15:52:37 <BlueMatt> jonasschnelli: may need to do so as well, or needed to as of yesterday
4012017-02-28T15:52:46 <BlueMatt> wumpus: (though your sigs were fine - you werent signing with your subkeys)
4022017-02-28T15:53:10 *** jyap has quit IRC
4032017-02-28T15:53:46 *** sipa has quit IRC
4042017-02-28T15:54:00 <wumpus> BlueMatt: okay, thanks
4052017-02-28T15:54:37 *** sipa has joined #bitcoin-core-dev
4062017-02-28T15:55:10 <jonasschnelli> BlueMatt: I'd like to create a new Ed25519 key (HWW) and add them to my key package under contrib/... would that be a problem?
4072017-02-28T15:55:31 <BlueMatt> jonasschnelli: hmm? do you need new keys or just a new subkey?
4082017-02-28T15:55:32 <MarcoFalke> jonasschnelli: A subkey?
4092017-02-28T15:55:46 <jonasschnelli> BlueMatt: I'd like to do a new key
4102017-02-28T15:55:48 <BlueMatt> you can put a subkey in your key and put it on the keyservers and everything will work without any other updates
4112017-02-28T15:56:08 <BlueMatt> ahh, ok, yea, I mean just put it in contrib/ then, make sure to sign the new key with your old one (and preferably get someone else local to sign)
4122017-02-28T15:56:36 <jonasschnelli> BlueMatt: but I would need to add the new key ID into the verify-git script?
4132017-02-28T15:56:45 <BlueMatt> yes
4142017-02-28T15:56:46 <jonasschnelli> Maybe I just do a subkey for now
4152017-02-28T15:56:59 *** jyap has joined #bitcoin-core-dev
4162017-02-28T15:57:00 *** jyap has joined #bitcoin-core-dev
4172017-02-28T15:57:04 <sipa> note that github doesn't seem to support ed25519 subkeys
4182017-02-28T15:57:21 <jonasschnelli> sipa: hmm.. they support ed25519 "main key" but not sub?
4192017-02-28T15:57:35 <sipa> i don't think so either
4202017-02-28T15:57:44 <sipa> but i didn't try creating a new main key
4212017-02-28T15:58:12 <jonasschnelli> Hmm.. yes. I have only tried git/ssh access keys with Ed25519... this works.. haven't tried the gpg part though
4222017-02-28T16:08:46 *** wudayoda has quit IRC
4232017-02-28T16:10:29 <wumpus> isn't using three braces for a scope a bit overkill? :-) https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1299
4242017-02-28T16:11:29 <jonasschnelli> wumpus: huh? This is in master?!
4252017-02-28T16:11:43 <sipa> hahaha
4262017-02-28T16:11:43 *** wudayoda has joined #bitcoin-core-dev
4272017-02-28T16:12:17 <wumpus> jonasschnelli: yes :)
4282017-02-28T16:12:30 <wumpus> maybe the 64k stack frame needs some extra support, so one brace cannot hold it?
4292017-02-28T16:13:01 <BlueMatt> wumpus: .......
4302017-02-28T16:13:08 <sipa> possibly
4312017-02-28T16:13:21 <BlueMatt> i assume that was cfields trying not to have too large a diff
4322017-02-28T16:13:25 <sipa> subsequent refactorings that removed locks
4332017-02-28T16:13:26 <BlueMatt> or, at least, I blame cfields either way
4342017-02-28T16:13:36 <sipa> i assume
4352017-02-28T16:13:54 <wumpus> I could understand that for one level, but three? anyhow, no big deal, I just had to laugh
4362017-02-28T16:14:14 <cfields> heh yes, i think 3 rounds of scopes have been eliminated now. Got tired of stomping on myself with whitespace :)
4372017-02-28T16:14:58 <cfields> there are a few places like that. It's probably a good time to do a whitespace cleanup on those.
4382017-02-28T16:15:03 <wumpus> I guess all that code is going to be nuked and replaced with libevent anyhow
4392017-02-28T16:15:15 * sipa casually mentions adding ?w=1 to github urls
4402017-02-28T16:16:31 <bsm117532> If anyone knows a way to make github do that by default...I would love you eternally...
4412017-02-28T16:16:33 <cfields> sipa: sure, but towards the end, i can only imagine the initial reaction to "sigh, another +520,-500 diff from cfields" :)
4422017-02-28T16:17:06 <wumpus> bsm117532: get in the habit of diffing locally instead of in gh, or at least that's what I did
4432017-02-28T16:17:23 <bsm117532> Oh I do...but then there's code reviews...
4442017-02-28T16:17:40 <wumpus> I usually review and take notes offline
4452017-02-28T16:17:50 <wumpus> then pester all pulls at once
4462017-02-28T16:19:28 <sipa> offline?
4472017-02-28T16:19:45 <wumpus> well outside-of-the-browser
4482017-02-28T16:20:11 <wumpus> I don't generally go as far as to disconnect my network :p
4492017-02-28T16:20:30 <sipa> i imagine you now printing PRs on a line printer, laying the meters-long paper on the floor, and drawing arrows all over it
4502017-02-28T16:20:42 <wumpus> good idea
4512017-02-28T16:23:02 <cfields> heh
4522017-02-28T16:24:59 *** lclc has joined #bitcoin-core-dev
4532017-02-28T16:29:56 *** StoBrendo has quit IRC
4542017-02-28T16:32:24 <wumpus> outoing connections aren't checked against -whitelist are they?
4552017-02-28T16:32:42 <sipa> i believe not
4562017-02-28T16:33:40 <wumpus> I'm trying to whitelist an outgoing connection (want to push blocks from a node that is not completely up-to-date to a node without any blocks, and trying to get around "Ignoring getheaders from peer=1 because node is in initial block download")
4572017-02-28T16:34:15 <cfields> wumpus: set the ibd date way back
4582017-02-28T16:34:17 <cfields> sec
4592017-02-28T16:35:24 <cfields> wumpus: -maxtipage
4602017-02-28T16:35:31 <wumpus> the node is in a sandbox that cannot make outgoing connections so I can't do it the other way around
4612017-02-28T16:35:38 <wumpus> cfields: thanks! will try that
4622017-02-28T16:36:00 <cfields> (set on the serving node, ofc)
4632017-02-28T16:36:56 <cfields> achow101: if you feel like trying to help nail down the gitian issue: http://pastebin.com/raw/cJzuYPqm
4642017-02-28T16:37:39 <cfields> achow101: It'd be great if you could manage to grab that from a build that differs
4652017-02-28T16:38:28 <cfields> (just edit the descriptor use for building, don't actually commit it)
4662017-02-28T16:40:13 <sipa> i wonder if we should just remove that don't respond to getheaders while in ibd
4672017-02-28T16:42:17 <wumpus> sipa: I wouldn't mind if it was removed
4682017-02-28T16:42:38 * wumpus trying to remember why it was added
4692017-02-28T16:45:01 <wumpus> ah I added the log message in #6971, probably after troubleshooting the same issue why two nodes were not syncing :p
4702017-02-28T16:45:03 <gribble> https://github.com/bitcoin/bitcoin/issues/6971 | Is the InitialBlockDownload() check in getheaders too strict? · Issue #6971 · bitcoin/bitcoin · GitHub
4712017-02-28T16:48:31 *** abpa has joined #bitcoin-core-dev
4722017-02-28T16:48:40 <wumpus> setting maxtipage is not working for some reason, set it to 400000000 which should be enough to put us in 2004, but it still sees it as initial block download. Checking why...
4732017-02-28T16:49:04 <cfields> wumpus: not past a checkpoint yet, maybe?
4742017-02-28T16:49:29 <sipa> i read that as max ti page, and was wondering why we're supporting configuring the page size on ti calculators
4752017-02-28T16:50:54 <cfields> !InitialBlockDownload() added in #6172
4762017-02-28T16:50:55 <gribble> Error: "InitialBlockDownload()" is not a valid command.
4772017-02-28T16:50:57 <sdaftuar> sipa: wumpus: i think because of checkpoints you can partition a node that is syncing off from the honest network by feeding it a forked chain before the last checkpoint
4782017-02-28T16:51:08 <wumpus> hehe, because ti calculators are super fast at ecdsa computations of course!
4792017-02-28T16:51:15 <cfields> er.. #6172
4802017-02-28T16:51:17 <sdaftuar> and then it responds to it's outbound's peers requests with the bogus chain, and gets disconnected
4812017-02-28T16:51:17 <gribble> https://github.com/bitcoin/bitcoin/issues/6172 | Ignore getheaders requests when not synced by sdaftuar · Pull Request #6172 · bitcoin/bitcoin · GitHub
4822017-02-28T16:51:37 <sdaftuar> i think we could just make sure we're past the last checkpoint before responding?
4832017-02-28T16:52:09 * cfields sets his ti-83 graphing mode to secp256k1
4842017-02-28T16:52:14 <wumpus> it's failing the "chainActive.Tip()->nChainWork < UintToArith256(chainParams.GetConsensus().nMinimumChainWork)" check
4852017-02-28T16:53:09 <wumpus> so yes I guess that's the replacement for the checkpoint check
4862017-02-28T16:53:29 <sipa> cfields: http://bitcoin.stackexchange.com/a/21911/208
4872017-02-28T16:54:02 <cfields> sipa: haha
4882017-02-28T16:55:50 <wumpus> didn't we stop using checkpoints for that purpose?
4892017-02-28T16:56:30 <sdaftuar> wumpus: we still lock in the chain once we've gotten to each checkpoint, and will ban nodes that send us an alternate chain after that point
4902017-02-28T16:56:37 <wumpus> anyhow, just going to comment out the check locally
4912017-02-28T16:57:31 <wumpus> sdaftuar: okay
4922017-02-28T16:57:56 <wumpus> sdaftuar: yes in that case it'd make sense to replace that with a checkpoint-based check
4932017-02-28T16:59:11 <bitcoin-git> [bitcoin] RHavar closed pull request #9869: Move comment to right spot (master...comment) https://github.com/bitcoin/bitcoin/pull/9869
4942017-02-28T16:59:52 <wumpus> will look at that
4952017-02-28T17:11:48 *** kewde[m] has quit IRC
4962017-02-28T17:11:59 *** frabrunelle has quit IRC
4972017-02-28T17:13:15 *** rafalcpp has quit IRC
4982017-02-28T17:13:24 <wumpus> I'm not entirely sure I understand this: why would responding to getheaders before the last checkpoint (or during initial block download) cause it to be potentially fed a forked chain?
4992017-02-28T17:16:27 <sipa> because you may be on a forked chain without knowing it
5002017-02-28T17:17:13 <sipa> so a peer asking you for headers, and then downloading them, and then discovering those headers don't align with a checkpoint
5012017-02-28T17:17:20 <bitcoin-git> [bitcoin] ericshawlinux opened pull request #9890: Add a button to open the config file in a text editor (master...master) https://github.com/bitcoin/bitcoin/pull/9890
5022017-02-28T17:17:30 <sipa> (i'm speculating)
5032017-02-28T17:17:47 <wumpus> right, okay, that makes sense
5042017-02-28T17:17:53 <wumpus> why didn't we add a comment for this :/
5052017-02-28T17:18:04 <wumpus> it's not exactly trivial to think though
5062017-02-28T17:18:08 *** jnewbery has quit IRC
5072017-02-28T17:23:46 <gmaxwell> Please no checkpoint based check. Use the work based check.
5082017-02-28T17:24:56 <gmaxwell> also failing to respond to getheaders is a DOS attack against the peer. If we're not going to respond we should disconnect.
5092017-02-28T17:24:56 <wumpus> the point is that the check that causes the ban (on other nodes) uses a checkpoint based check
5102017-02-28T17:25:16 <wumpus> not sending the headers is trying to preempt that
5112017-02-28T17:25:34 <sdaftuar> wumpus: i think gmaxwell is right though -- a work based check is more reasonable long-term and just as effective for this purpose
5122017-02-28T17:25:53 <gmaxwell> The minimum work check has vastly more work than the highest checkpoint deployed. If there is another chain with more work than our minimum work chain that is incompatible with the checkpoints then we have big problems.
5132017-02-28T17:26:07 <wumpus> yes, but what work threshold? if it is that threshold that is updated every version, it's not going to be any better than checking IsInitialBlockDownload
5142017-02-28T17:26:44 <wumpus> (which already checks against that)
5152017-02-28T17:26:47 <gmaxwell> I think checking IsInitialBlockDownload should be fine as is now. It used to be stupid and only check the height against the checkpoints.
5162017-02-28T17:27:04 <sdaftuar> what do you think of allowing nMinimumChainWork to be a hidden command line option? i would find that useful for my testing at least, and sounds like it'd be useful for what wumpus is trying to do as well.
5172017-02-28T17:27:27 <wumpus> it's fine but incredibly annoying if you want to sync blocks from a node that is not up to date to a new node
5182017-02-28T17:27:51 <gmaxwell> Well one downside of IsInitial is that it's not eager enough to turn on.
5192017-02-28T17:28:04 <wumpus> which I apparently do regularly and spend time troubleshooting then realize it's that check again
5202017-02-28T17:28:09 <gmaxwell> Which would be a reason to use a straight work check instead of IsInitial.
5212017-02-28T17:28:47 *** fengling has quit IRC
5222017-02-28T17:28:59 <gmaxwell> sdaftuar: I wouldn't complain about that. But perhaps a switch to more directly change the behavior would be more what you'd want?
5232017-02-28T17:30:40 <sdaftuar> gmaxwell: yeah, that might be called for here. i guess what i often want to do is actually make IBD end sooner (eg for my simulations)
5242017-02-28T17:31:31 <wumpus> sdaftuar: cfields's proposal of using maxtipage was great for that, unfortunately it doesn't work as the fixed work check is before that
5252017-02-28T17:32:49 <wumpus> gmaxwell: it's already possible to avoid the check by whitelisting a node, but in my case I couldn't use that because there's no way to whitelist outgoing connections :)
5262017-02-28T17:34:44 *** rafalcpp has joined #bitcoin-core-dev
5272017-02-28T17:34:57 <gmaxwell> Seperate from the bypass, -- We should probably work to get rid of that ban-on-inconsistent-with-checkpoints behavior.
5282017-02-28T17:40:52 <sdaftuar> gmaxwell: agreed. i also might put getting rid of checkpoints on my list of goals for 0.15.
5292017-02-28T17:44:40 <gmaxwell> I think eliminating them will require a soft-fork to increase the minimum difficulty or something similar.
5302017-02-28T17:45:00 <gmaxwell> (but not the kind of softfork that ever need to get activated, a flag height softfork)
5312017-02-28T17:45:05 *** jnewbery has joined #bitcoin-core-dev
5322017-02-28T17:51:38 *** kewde[m] has joined #bitcoin-core-dev
5332017-02-28T17:53:33 <wumpus> it seems like a lousy reason to ban
5342017-02-28T17:54:16 *** chjj has quit IRC
5352017-02-28T17:54:29 <wumpus> banning should be reserved for things that consume a lot of resources
5362017-02-28T17:54:47 *** wudayoda has quit IRC
5372017-02-28T17:55:57 <gmaxwell> We should have a general mechenism for punting peers that don't agree with our consensus... that should be rather lazy.
5382017-02-28T17:56:45 *** wudayoda has joined #bitcoin-core-dev
5392017-02-28T17:57:47 *** fengling has joined #bitcoin-core-dev
5402017-02-28T17:58:36 *** kadoban has joined #bitcoin-core-dev
5412017-02-28T18:08:15 *** chjj has joined #bitcoin-core-dev
5422017-02-28T18:09:55 <cfields> wumpus: interesting, your osx sigs mismatched as well
5432017-02-28T18:10:08 <cfields> seems we can all flip-flop
5442017-02-28T18:13:58 *** paveljanik has joined #bitcoin-core-dev
5452017-02-28T18:13:58 *** paveljanik has joined #bitcoin-core-dev
5462017-02-28T18:14:02 *** fengling has quit IRC
5472017-02-28T18:14:33 *** frabrunelle has joined #bitcoin-core-dev
5482017-02-28T18:18:28 *** Chris_Stewart_5 has quit IRC
5492017-02-28T18:26:54 *** BashCo_ has quit IRC
5502017-02-28T18:27:31 *** BashCo has joined #bitcoin-core-dev
5512017-02-28T18:29:26 <BlueMatt> lolwtf...someone is trying to connect to the fibre network using a testnet node, connecting to port 8333
5522017-02-28T18:31:02 *** jnewbery has quit IRC
5532017-02-28T18:32:00 *** BashCo has quit IRC
5542017-02-28T18:32:21 <sipa> we need a proxy that forwards connections to one of two bitcoind, based on network magic
5552017-02-28T18:32:37 <BlueMatt> or they could just use the right port.....
5562017-02-28T18:32:46 <BlueMatt> (well, those nodes dont have testnet, so dunno wtf they think they're doing, but whatever)
5572017-02-28T18:33:08 <BlueMatt> suppose its good that at least one miner has a full copy of their configs running on testnet
5582017-02-28T18:34:15 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5592017-02-28T18:36:15 <profall> if I rpcbind to a different address then localhost, when I try to use bitcoin-cli it cannot connect to the server. Before you assume, it's binded to a private IP on a VLAN that only I control.
5602017-02-28T18:37:49 <BlueMatt> profall: i believe there is a rpcconnect option for that case
5612017-02-28T18:38:04 <BlueMatt> (which you would pass into bitcoin-cli to tell it where to connect)
5622017-02-28T18:38:08 <profall> ok
5632017-02-28T18:39:51 *** Chris_Stewart_5 has quit IRC
5642017-02-28T18:39:58 <profall> Figured it out, thanks :)
5652017-02-28T18:41:52 *** fengling has joined #bitcoin-core-dev
5662017-02-28T18:42:25 *** MarcoFalke has left #bitcoin-core-dev
5672017-02-28T18:42:32 *** MarcoFalke has joined #bitcoin-core-dev
5682017-02-28T18:43:22 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5692017-02-28T18:44:27 *** MarcoFalke has joined #bitcoin-core-dev
5702017-02-28T18:47:20 *** lclc has quit IRC
5712017-02-28T18:52:47 *** MarcoFalke has left #bitcoin-core-dev
5722017-02-28T19:00:31 *** MarcoFalke has joined #bitcoin-core-dev
5732017-02-28T19:02:00 *** BashCo has joined #bitcoin-core-dev
5742017-02-28T19:04:01 *** mol has joined #bitcoin-core-dev
5752017-02-28T19:06:31 <gmaxwell> BlueMatt: probably me.... common config for testnet and not.
5762017-02-28T19:06:57 *** moli_ has quit IRC
5772017-02-28T19:08:21 <BlueMatt> gmaxwell: looks like ckpool, maybe
5782017-02-28T19:08:25 *** bityogi has joined #bitcoin-core-dev
5792017-02-28T19:08:54 *** fengling has quit IRC
5802017-02-28T19:09:48 <BlueMatt> sipa: whats the formula for the 15 pointers of size for mapTx? Can we get a comment to describe that?
5812017-02-28T19:10:19 <sipa> 3 pointers per sorted list
5822017-02-28T19:10:24 <sipa> s/list/index/
5832017-02-28T19:10:30 <sipa> i think
5842017-02-28T19:10:40 <sipa> will do
5852017-02-28T19:10:45 <BlueMatt> thanks
5862017-02-28T19:10:51 *** jnewbery has joined #bitcoin-core-dev
5872017-02-28T19:17:49 *** wudayoda has quit IRC
5882017-02-28T19:20:29 *** wudayoda has joined #bitcoin-core-dev
5892017-02-28T19:31:31 *** BGG has joined #bitcoin-core-dev
5902017-02-28T19:37:19 *** fengling has joined #bitcoin-core-dev
5912017-02-28T19:42:38 *** fengling has quit IRC
5922017-02-28T19:58:59 *** fengling has joined #bitcoin-core-dev
5932017-02-28T20:06:28 *** fengling has quit IRC
5942017-02-28T20:10:11 *** dermoth has quit IRC
5952017-02-28T20:11:47 *** dermoth has joined #bitcoin-core-dev
5962017-02-28T20:32:33 *** laurentmt has joined #bitcoin-core-dev
5972017-02-28T20:32:47 *** mol has quit IRC
5982017-02-28T20:34:40 *** fengling has joined #bitcoin-core-dev
5992017-02-28T20:42:06 *** jtimon has joined #bitcoin-core-dev
6002017-02-28T20:43:57 <cfields> ok, I think i nailed down the gitian issue
6012017-02-28T20:45:47 <BlueMatt> nice!
6022017-02-28T20:46:15 <cfields> wumpus: still around, by any chance?
6032017-02-28T20:47:02 <cfields> wumpus: it's not worth a new tag, but i can't sign your osx bin :(
6042017-02-28T20:47:10 *** jtimon has quit IRC
6052017-02-28T20:49:11 <cfields> osx's ld64 uses threads for linking. It then either doesn't sort the output, or produces a graph that can't actually be sorted deterministically. Not sure which.
6062017-02-28T20:50:28 *** fengling has quit IRC
6072017-02-28T20:50:58 <gmaxwell> 0 non-1-bit: Unk=68723 Fails=3170 Total=7144375
6082017-02-28T20:50:58 <gmaxwell> 1 non-1-bit: Unk=11134759 Fails=872220 Total=111452250
6092017-02-28T20:50:58 <gmaxwell> 2 non-1-bit: Unk=219092988 Fails=56230638 Total=579551700
6102017-02-28T20:50:58 <gmaxwell> 3 non-1-bit: Unk=415437342 Fails=382522140 Total=1004556280
6112017-02-28T20:50:58 <gmaxwell> real 673m11.752s
6122017-02-28T20:51:00 <gmaxwell> user 28588m32.263s
6132017-02-28T20:51:03 <gmaxwell> oops wrong window
6142017-02-28T20:51:37 <BlueMatt> lol
6152017-02-28T21:01:03 *** laurentmt has quit IRC
6162017-02-28T21:10:29 *** cyphr_ has joined #bitcoin-core-dev
6172017-02-28T21:13:17 *** laurentmt has joined #bitcoin-core-dev
6182017-02-28T21:13:41 <achow101> cfields: so any idea on how to fix that?
6192017-02-28T21:13:59 <cfields> achow101: yea, PR coming up
6202017-02-28T21:14:29 <achow101> will we have to redo the osx builds?
6212017-02-28T21:16:00 <cfields> yes, but I'm suggesting we just skip
6222017-02-28T21:17:13 *** laurentmt has quit IRC
6232017-02-28T21:17:52 <bitcoin-git> [bitcoin] instagibbs closed pull request #9017: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/9017
6242017-02-28T21:18:44 <achow101> but at least it will be fixed for final
6252017-02-28T21:28:27 *** fengling has joined #bitcoin-core-dev
6262017-02-28T21:29:28 *** MarcoFalke has quit IRC
6272017-02-28T21:41:41 *** Chris_Stewart_5 has quit IRC
6282017-02-28T21:42:47 *** BGG has quit IRC
6292017-02-28T21:43:38 *** fengling has quit IRC
6302017-02-28T21:51:18 *** jtimon has joined #bitcoin-core-dev
6312017-02-28T21:58:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6322017-02-28T21:58:38 <bitcoin-git> [bitcoin] theuni opened pull request #9891: depends: make osx output deterministic (master...fix-osx-link-determinism) https://github.com/bitcoin/bitcoin/pull/9891
6332017-02-28T22:25:32 <achow101> cfields: what hash should we get with the osx patch?
6342017-02-28T22:30:37 *** fengling has joined #bitcoin-core-dev
6352017-02-28T22:31:09 <luke-jr> checking whether to build with support for UPnP⦠configure: error: "UPnP requested but cannot be built. use --without-miniupnpc"
6362017-02-28T22:31:19 <luke-jr> ^ for reference, this means ccache dir is read-only
6372017-02-28T22:31:35 <luke-jr> (or *can* mean it, anyway)
6382017-02-28T22:39:29 *** moli_ has joined #bitcoin-core-dev
6392017-02-28T22:39:44 *** fengling has quit IRC
6402017-02-28T22:42:19 *** MarcoFalke has joined #bitcoin-core-dev
6412017-02-28T22:56:25 *** wudayoda has quit IRC
6422017-02-28T22:57:19 *** wudayoda has joined #bitcoin-core-dev
6432017-02-28T23:01:31 *** wasi has quit IRC
6442017-02-28T23:01:56 *** wasi has joined #bitcoin-core-dev
6452017-02-28T23:02:13 <bitcoin-git> [bitcoin] luke-jr opened pull request #9892: Bugfix: Only install manpages for built programs (master...bugfix_man_onlybuilt) https://github.com/bitcoin/bitcoin/pull/9892
6462017-02-28T23:11:24 *** moli_ has quit IRC
6472017-02-28T23:12:28 *** moli_ has joined #bitcoin-core-dev
6482017-02-28T23:14:46 *** jannes has quit IRC
6492017-02-28T23:16:25 *** str4d has joined #bitcoin-core-dev
6502017-02-28T23:17:39 <cfields> luke-jr: where are you seeing that?
6512017-02-28T23:19:44 *** fengling has joined #bitcoin-core-dev
6522017-02-28T23:21:01 <cfields> luke-jr: ah. We should do a quick compile check.
6532017-02-28T23:22:23 <luke-jr> cfields: Gentoo's build system supports ccache, but apparently doesn't manage permissions correctly (root owns ccache dir)
6542017-02-28T23:22:48 <luke-jr> not normally an issue, but I was testing out an updated ebuild as non-root
6552017-02-28T23:24:07 *** fengling has quit IRC
6562017-02-28T23:24:07 <cfields> luke-jr: ah. There's probably a use flag that's supposed to signal to export a var for the path, then?
6572017-02-28T23:27:11 <luke-jr> ?
6582017-02-28T23:27:38 <cfields> yea: https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Caching_compilation_objects
6592017-02-28T23:27:43 <luke-jr> it's just a bug in Portage, not our problem; the only thing we could do better possibly is make the error clearer
6602017-02-28T23:28:21 <cfields> luke-jr: sure, not suggesting it's our problem. Looks like the dir is set there by portage, you could override locally
6612017-02-28T23:28:29 <cfields> but yes, we should do a compile test
6622017-02-28T23:28:57 <luke-jr> I simply disabled ccache for the test
6632017-02-28T23:33:04 *** Guyver2 has quit IRC
6642017-02-28T23:40:24 *** moli_ has quit IRC
6652017-02-28T23:40:58 *** moli_ has joined #bitcoin-core-dev
6662017-02-28T23:42:24 *** moli_ has quit IRC
6672017-02-28T23:47:32 *** MarcoFalke has quit IRC
6682017-02-28T23:52:01 *** fengling has joined #bitcoin-core-dev
6692017-02-28T23:54:06 *** moli_ has joined #bitcoin-core-dev