1 2017-02-28 00:03:01 0|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.
2 2017-02-28 00:03:28 0|gmaxwell|If github were to move to a propritary and incompatible version of git from git itself I would urge we drop github immediately.
3 2017-02-28 00:05:40 0|jeremyrubin|gmaxwell: i would expect it to be FOSS, although it's unclear what you mean by 'propritary'
4 2017-02-28 00:05:54 0|jeremyrubin|my fault for offtopicing
5 2017-02-28 00:06:23 0|sipa|gmaxwell: even if it was FOSS, it would require them to start maintaining a fork of gut
6 2017-02-28 00:06:26 0|sipa|eh
7 2017-02-28 00:06:32 0|sipa|jeremyrubin: even if it was FOSS, it would require them to start maintaining a fork of git
8 2017-02-28 00:06:47 0|sipa|something i don't expect them to be remotely capable of (nor should they)
9 2017-02-28 00:07:58 0|jeremyrubin|I thought they already do that? I think I read a while back they have an internal git implementation, could be wrong
10 2017-02-28 00:07:59 0|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.
11 2017-02-28 00:08:27 0|jeremyrubin|(could be misinformed there, can't find a link)
12 2017-02-28 00:08:46 0|luke-jr|jeremyrubin: not one every user needs; in any case, unless they actually do it, it doesn't matter
13 2017-02-28 00:09:03 0|sipa|jeremyrubin: i'm sure they have some patches
14 2017-02-28 00:09:31 0|sipa|gmaxwell: not as dramatic :)
15 2017-02-28 00:10:43 0|sipa|jeremyrubin: i don't understand why you think _github_ should be doing anything at all, besides sponsoring git development
16 2017-02-28 00:10:55 0|sipa|(which i hope they're already doing)
17 2017-02-28 00:13:13 0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #9882: RPC: Introduce -rpcamountdecimals for the RPC to use other units than BTC (06master...060.14.99-rpc-amounts) 02https://github.com/bitcoin/bitcoin/pull/9882
18 2017-02-28 00:13:34 0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9855: RPC: Use integer satoshis instead BTC with decimals (06master...060.15-rpc-satoshis) 02https://github.com/bitcoin/bitcoin/pull/9855
19 2017-02-28 00:14:38 0|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
20 2017-02-28 00:14:44 0|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.
21 2017-02-28 00:14:48 0|gmaxwell|This seems cultish.
22 2017-02-28 00:14:58 0|gmaxwell|"omg sha1 is broken. we must do something! this is something! it must be done!"
23 2017-02-28 00:15:35 0|jeremyrubin|jfc you're acting like github making a choice implies total github lock in
24 2017-02-28 00:15:48 0|jeremyrubin|precisely, github is free to offer improvements on the code as they see fit
25 2017-02-28 00:16:02 0|sipa|yes, but why github?
26 2017-02-28 00:16:17 0|jeremyrubin|they are a company that offers git based services
27 2017-02-28 00:16:17 0|sipa|and not say, the linux foundation
28 2017-02-28 00:16:22 0|jeremyrubin|the largest one!
29 2017-02-28 00:16:49 0|jeremyrubin|Does linux foundation offer git services? (honestly not sure? support?)
30 2017-02-28 00:17:11 0|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
31 2017-02-28 00:17:33 0|jeremyrubin|offensive to who?
32 2017-02-28 00:17:43 0|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"
33 2017-02-28 00:18:03 0|sipa|for something that may never be exploitable
34 2017-02-28 00:19:35 0|BlueMatt|hmmmm, segfault in bitcoin-qt on startup :(
35 2017-02-28 00:19:59 0|jeremyrubin|so it's offensive to... github? or git maintainers?
36 2017-02-28 00:20:14 0|sipa|to me
37 2017-02-28 00:20:42 0|jeremyrubin|Well git is named after a stupid person, so it may be fair to call them idiots :p
38 2017-02-28 00:21:14 0|BlueMatt|on a more interesting subject..... https://0bin.net/paste/ECyDDhXzg+BH-92P#NQyXo2b457D6yx+Ezrj+-sVJcLTTFNrk1x36y/avIEA
39 2017-02-28 00:21:31 0|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.
40 2017-02-28 00:22:02 0|gmaxwell|were they to do that it would sound a lot like embrace-extend-extinguish.
41 2017-02-28 00:22:33 0|jeremyrubin|I don't think I ever once said incompatible
42 2017-02-28 00:22:39 0|jeremyrubin|you guys keep injecting that
43 2017-02-28 00:22:41 0|BlueMatt|so, sipa, any thoughts on my segfault?
44 2017-02-28 00:23:02 0|BlueMatt|sipa: you missed the link https://0bin.net/paste/ECyDDhXzg+BH-92P#NQyXo2b457D6yx+Ezrj+-sVJcLTTFNrk1x36y/avIEA
45 2017-02-28 00:23:22 0|sipa|jeremyrubin: i'm offended that you're suggesting github create drama where there is no need for concern
46 2017-02-28 00:23:55 0|sipa|anyway, let's drop the topic
47 2017-02-28 00:26:25 0|BlueMatt|ehh, I'll just file an issue
48 2017-02-28 00:26:32 0|sipa|BlueMatt: ugh
49 2017-02-28 00:26:39 0|sipa|thread 10 is the one that crashed?
50 2017-02-28 00:26:44 0|BlueMatt|no, thread 1
51 2017-02-28 00:26:48 0|BlueMatt|somewhere deep in Qt
52 2017-02-28 00:27:03 0|BlueMatt|thread 10 is just mempool re-acceptance, it looks liek
53 2017-02-28 00:27:49 0|gmaxwell|#2 0x00007fd6b81ee197 in QTableView::setSortingEnabled(bool) () from /usr/lib/libQt5Widgets.so.5
54 2017-02-28 00:27:51 0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value ÷ Issue #2 ÷ bitcoin/bitcoin ÷ GitHub
55 2017-02-28 00:27:55 0|gmaxwell|#3 0x00005617b3a315ec in TransactionView::setModel (this=0x5617b716bc50, _model=_model@entry=0x5617b6e77530) at qt/transactionview.cpp:205
56 2017-02-28 00:27:57 0|gribble|https://github.com/bitcoin/bitcoin/issues/3 | Encrypt wallet ÷ Issue #3 ÷ bitcoin/bitcoin ÷ GitHub
57 2017-02-28 00:29:22 0|sipa|BlueMatt: no clue about Qt issues
58 2017-02-28 00:30:46 0|gmaxwell|nothing in the immediate backtrace of that crash appears to have been recently changed.
59 2017-02-28 00:31:10 0|gmaxwell|BlueMatt: I assume this is a build on your system? (not a gitian binary)
60 2017-02-28 00:31:37 0|gmaxwell|BlueMatt: if it's 100% reproducable can you bisect it?
61 2017-02-28 00:32:03 0|BlueMatt|gmaxwell: it is not reproduceable, happened once
62 2017-02-28 00:32:11 0|BlueMatt|i can go restart that thing all day and see.......
63 2017-02-28 00:32:38 0|gmaxwell|BlueMatt: maybe try adding a shutdown shorty after start and leave it going in a loop?
64 2017-02-28 00:34:07 0|BlueMatt|well it crashed in the same place on ~ the 4th try
65 2017-02-28 00:34:12 0|BlueMatt|so its not exactly non-reproduceable
66 2017-02-28 00:35:57 0|gmaxwell|BlueMatt: gitian binary or not.
67 2017-02-28 00:36:03 0|BlueMatt|not
68 2017-02-28 00:36:05 0|BlueMatt|locally-built
69 2017-02-28 00:36:43 0|gmaxwell|can you stick a shutdown right after init completes and see if you can still reproduce it?
70 2017-02-28 00:36:55 0|BlueMatt|lemme see if I can rebuild and still reproduce it first :P
71 2017-02-28 00:37:13 0|gmaxwell|yea, I guess I was also suggesting that.
72 2017-02-28 00:42:23 0|BlueMatt|yes, fresh build crashes in the same way, so thats...good?
73 2017-02-28 00:45:08 0|gmaxwell|The fresh build contains potassium benzoate.
74 2017-02-28 00:52:21 0|BlueMatt|gmaxwell: yay hisenbug :(
75 2017-02-28 00:53:57 0|BlueMatt|yup, just adding a StartShutdown() 30 seconds after start in the middle of the net code appears to fix it
76 2017-02-28 00:54:55 0|cfields|BlueMatt: is there anything in the wallet?
77 2017-02-28 00:55:22 0|BlueMatt|yes, lots 'o things
78 2017-02-28 00:55:25 0|BlueMatt|(nothing unconfirmed, though)
79 2017-02-28 00:58:03 0|BlueMatt|yup, and now even the old binary wont crash
80 2017-02-28 00:58:04 0|BlueMatt|ffs
81 2017-02-28 01:10:36 0|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.
82 2017-02-28 01:10:54 0|cfields|(catching up, not sure if you guys already looked down that path)
83 2017-02-28 01:11:31 0|BlueMatt|cfields: no one looked down any path
84 2017-02-28 01:11:42 0|BlueMatt|cfields: strange, there is definitely nothing in mempool which applies to that wallet
85 2017-02-28 01:12:45 0|cfields|BlueMatt: still reproducible if you disable mempool loading?
86 2017-02-28 01:13:10 0|cfields|i don't really see where else it'd be coming from, so i assume not
87 2017-02-28 01:13:46 0|BlueMatt|cfields: well it stoped being reproduceable, so maybe mempool dump changed
88 2017-02-28 01:14:21 0|cfields|BlueMatt: right. If you repro again, I'd be sure to make a backup
89 2017-02-28 01:14:27 0|BlueMatt|still, makes no sense as no mempool txn should apply to that wallet
90 2017-02-28 01:14:29 0|BlueMatt|sure
91 2017-02-28 01:15:04 0|cfields|i have no idea what gets blasted around, will try to trace the paths
92 2017-02-28 01:30:37 0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9884: Add Pieter's old signed commits to revsig-commits (06master...062017-02-pieter-revsig) 02https://github.com/bitcoin/bitcoin/pull/9884
93 2017-02-28 01:30:49 0|BlueMatt|^ will need to be merged before anything else or travis will barf
94 2017-02-28 01:30:58 0|BlueMatt|well, travis will barf in an obvious way and only on master, so nbd
95 2017-02-28 01:31:01 0|BlueMatt|but will barf
96 2017-02-28 05:32:15 0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #9886: In feerate ties, prefer larger packages first. (06master...06prefer_bigger_packages) 02https://github.com/bitcoin/bitcoin/pull/9886
97 2017-02-28 10:25:16 0|jonasschnelli|Can I still normally merge a PR or did we already witch to the SHA512 merge script?
98 2017-02-28 10:36:23 0|wumpus|I'm testing the SHA512 merge script, but we haven't merged it yet
99 2017-02-28 10:36:27 0|wumpus|so feel free to not use it yet
100 2017-02-28 10:36:52 0|jonasschnelli|okay... i'll wait until we have merged the SHA512 tree change
101 2017-02-28 10:37:18 0|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
102 2017-02-28 10:38:13 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/88c2ae3ed2bb...65fdc37ac306
103 2017-02-28 10:38:14 0|bitcoin-git|13bitcoin/06master 14c5f008a 15Cory Fields: don't throw std::bad_alloc when out of memory. Instead, terminate immediately
104 2017-02-28 10:38:14 0|bitcoin-git|13bitcoin/06master 14d4ee7ba 15Cory Fields: prevector: assert successful allocation
105 2017-02-28 10:38:15 0|bitcoin-git|13bitcoin/06master 1465fdc37 15Wladimir J. van der Laan: Merge #9856: Terminate immediately when allocation fails...
106 2017-02-28 10:38:33 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9856: Terminate immediately when allocation fails (06master...06bad_alloc_terminate2) 02https://github.com/bitcoin/bitcoin/pull/9856
107 2017-02-28 10:41:25 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/eddaa6b35d41...775cf54d0e0a
108 2017-02-28 10:41:26 0|bitcoin-git|13bitcoin/060.14 1450953c2 15Wladimir J. van der Laan: tests: Fix dangling pwalletMain pointer in wallet tests...
109 2017-02-28 10:41:26 0|bitcoin-git|13bitcoin/060.14 1469832aa 15Cory Fields: don't throw std::bad_alloc when out of memory. Instead, terminate immediately...
110 2017-02-28 10:41:27 0|bitcoin-git|13bitcoin/060.14 14775cf54 15Cory Fields: prevector: assert successful allocation...
111 2017-02-28 10:41:45 0|bitcoin-git|13bitcoin/060.14 1429bae0c 15Russell Yanofsky: Mention bumpfee in 0.14 release notes.
112 2017-02-28 10:41:45 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/775cf54d0e0a...5aaac4d09e7e
113 2017-02-28 10:41:46 0|bitcoin-git|13bitcoin/060.14 145aaac4d 15Wladimir J. van der Laan: Merge #9878: Mention bumpfee in 0.14 release notes....
114 2017-02-28 10:43:00 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/08e0690f3f3b2f33040916200e8d4444298cf226
115 2017-02-28 10:43:01 0|bitcoin-git|13bitcoin/060.14 1408e0690 15Russell Yanofsky: Update sendfrom RPC help to correct coin selection misconception...
116 2017-02-28 10:44:34 0|bitcoin-git|13bitcoin/06master 14fe71661 15Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation
117 2017-02-28 10:44:34 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/65fdc37ac306...d75e8cb44def
118 2017-02-28 10:44:35 0|bitcoin-git|13bitcoin/06master 14d75e8cb 15Wladimir J. van der Laan: Merge #9879: [doc] Update doc/bips.md for BIP90 implementation...
119 2017-02-28 10:45:00 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9879: [doc] Update doc/bips.md for BIP90 implementation (06master...062017-02-bips-doc-bip90) 02https://github.com/bitcoin/bitcoin/pull/9879
120 2017-02-28 10:47:23 0|bitcoin-git|13bitcoin/060.14 14a48b998 15Suhas Daftuar: [doc] Update doc/bips.md for BIP90 implementation...
121 2017-02-28 10:47:23 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/a48b998ff377a827357732b8868b0de10768129d
122 2017-02-28 10:47:45 0|bitcoin-git|13bitcoin/060.14 1450ae5c7 15Matt Corallo: Document increase in memory usage due to mempool/dbcache sharing
123 2017-02-28 10:47:45 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/a48b998ff377...1f83663bc2c8
124 2017-02-28 10:47:46 0|bitcoin-git|13bitcoin/060.14 141f83663 15Wladimir J. van der Laan: Merge #9866: Document increase in memory usage due to mempool/dbcache sharing...
125 2017-02-28 10:48:06 0|wumpus|going to tag rc3 in a moment
126 2017-02-28 10:59:59 0|bitcoin-git|13bitcoin/06master 1483ac719 15Marijn Stollenga: Change bitcoin address in RPC helpaddress to an invalid address, so people don't accidentally send coins there (like I did).
127 2017-02-28 10:59:59 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d75e8cb44def...30bdcfca2b7e
128 2017-02-28 11:00:00 0|bitcoin-git|13bitcoin/06master 1430bdcfc 15Wladimir J. van der Laan: Merge #9865: Change bitcoin address in RPC help message...
129 2017-02-28 11:00:19 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9865: Change bitcoin address in RPC help message (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9865
130 2017-02-28 11:01:37 0|bitcoin-git|13bitcoin/060.14 14289204f 15Marijn Stollenga: Change bitcoin address in RPC helpaddress to an invalid address, so people don't accidentally send coins there (like I did)....
131 2017-02-28 11:01:37 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/289204fbe0c188b3cd145dd7b2e271f97a956ba3
132 2017-02-28 11:03:06 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/30bdcfca2b7e...f5ef8e9dd29c
133 2017-02-28 11:03:07 0|bitcoin-git|13bitcoin/06master 140a17714 15Wladimir J. van der Laan: uint256: replace sprintf with HexStr and reverse-iterator...
134 2017-02-28 11:03:07 0|bitcoin-git|13bitcoin/06master 1419cafc6 15Wladimir J. van der Laan: test: Replace remaining sprintf with snprintf...
135 2017-02-28 11:03:08 0|bitcoin-git|13bitcoin/06master 14f5ef8e9 15Wladimir J. van der Laan: Merge #9867: Replace remaining sprintf with snprintf...
136 2017-02-28 11:03:26 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9867: Replace remaining sprintf with snprintf (06master...062017_02_snprintf) 02https://github.com/bitcoin/bitcoin/pull/9867
137 2017-02-28 11:30:11 0|bitcoin-git|13bitcoin/06master 14467df39 15John Newbery: Remove nonsense #undef foreach...
138 2017-02-28 11:30:11 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f5ef8e9dd29c...c322fa472efa
139 2017-02-28 11:30:12 0|bitcoin-git|13bitcoin/06master 14c322fa4 15Wladimir J. van der Laan: Merge #9732: [Trivial] Remove nonsense #undef foreach...
140 2017-02-28 11:30:32 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9732: [Trivial] Remove nonsense #undef foreach (06master...06removeundefforeach) 02https://github.com/bitcoin/bitcoin/pull/9732
141 2017-02-28 11:31:54 0|bitcoin-git|13bitcoin/06master 144b183d3 15Marko Bencun: Remove block file location upgrade code...
142 2017-02-28 11:31:54 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c322fa472efa...b7547fa93e01
143 2017-02-28 11:31:55 0|bitcoin-git|13bitcoin/06master 14b7547fa 15Wladimir J. van der Laan: Merge #9822: Remove block file location upgrade code...
144 2017-02-28 11:32:16 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9822: Remove block file location upgrade code (06master...06appinitmain) 02https://github.com/bitcoin/bitcoin/pull/9822
145 2017-02-28 11:48:45 0|bitcoin-git|13bitcoin/060.14 141825a03 15Pieter Wuille: Avoid VLA in hash.h...
146 2017-02-28 11:48:45 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/1825a03f8144572eaf532b6b3b3acc1a09577d1f
147 2017-02-28 11:50:17 0|bitcoin-git|13bitcoin/060.14 148d2d08e 15Wladimir J. van der Laan: qt: pre-rc3 translations update
148 2017-02-28 11:50:17 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/8d2d08efaa5fb6b29638fef7fb9bdf051db85f2e
149 2017-02-28 12:44:03 0|bitcoin-git|13bitcoin/060.14 1458800e3 15Wladimir J. van der Laan: doc: pre-rc3 changelog update
150 2017-02-28 12:44:03 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/58800e3556aefbc002b9554b3af5167655fd7943
151 2017-02-28 12:50:19 0|MarcoFalke|wumpus: Sorry to break the spree, but maybe #9829 should be included in rc3?
152 2017-02-28 12:50:21 0|gribble|https://github.com/bitcoin/bitcoin/issues/9829 | Fix importmulti returning rescan errors for wrong keys by ryanofsky ÷ Pull Request #9829 ÷ bitcoin/bitcoin ÷ GitHub
153 2017-02-28 12:50:33 0|wumpus|is that ready now?
154 2017-02-28 12:53:15 0|bitcoin-git|13bitcoin/06master 14306bd72 15Russell Yanofsky: Fix importmulti returning rescan errors for wrong keys...
155 2017-02-28 12:53:15 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b7547fa93e01...7e2a2212ecac
156 2017-02-28 12:53:16 0|bitcoin-git|13bitcoin/06master 147e2a221 15Wladimir J. van der Laan: Merge #9829: Fix importmulti returning rescan errors for wrong keys...
157 2017-02-28 12:53:32 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9829: Fix importmulti returning rescan errors for wrong keys (06master...06pr/multiinc) 02https://github.com/bitcoin/bitcoin/pull/9829
158 2017-02-28 12:53:55 0|bitcoin-git|13bitcoin/060.14 14ad24256 15Russell Yanofsky: Fix importmulti returning rescan errors for wrong keys...
159 2017-02-28 12:53:55 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/ad24256a65aa4281831e14097a29ac1efe8b5c02
160 2017-02-28 12:54:03 0|wumpus|apparently. THanks for mentinoning, I was subliminally ignoring that one for some reason because I assumed it still had nits open
161 2017-02-28 12:59:28 0|wumpus|* [new tag] v0.14.0rc3 -> v0.14.0rc3
162 2017-02-28 13:16:21 0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9888: travis: Verify commits only for one target (06master...06Mf1702-travisCommits) 02https://github.com/bitcoin/bitcoin/pull/9888
163 2017-02-28 13:59:50 0|bitcoin-git|13bitcoin/06master 14fa32a16 15MarcoFalke: travis: Verify commits only for one target...
164 2017-02-28 13:59:50 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7e2a2212ecac...36afd4db4442
165 2017-02-28 13:59:51 0|bitcoin-git|13bitcoin/06master 1436afd4d 15MarcoFalke: Merge #9888: travis: Verify commits only for one target...
166 2017-02-28 14:00:12 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9888: travis: Verify commits only for one target (06master...06Mf1702-travisCommits) 02https://github.com/bitcoin/bitcoin/pull/9888
167 2017-02-28 14:38:06 0|achow101|whoever finishes osx next, let me know if your hashes match mine: 9b247d80bb79f3b96d49e9d61b1977e07260c788022714e670dc7673a35fbf25 bitcoin-0.14.0-osx-unsigned.dmg
168 2017-02-28 14:38:23 0|achow101|(I'm guessing it won't)
169 2017-02-28 14:43:00 0|cfields|achow101: match :)
170 2017-02-28 14:46:44 0|achow101|yay
171 2017-02-28 15:02:46 0|jonasschnelli|cfields, achow101: hmm.. no match: https://bitcoinsrv.jonasschnelli.ch/builds/15/bitcoin-osx-0.14-build.assert
172 2017-02-28 15:02:58 0|jonasschnelli|But new build setup.. could be on my side.
173 2017-02-28 15:03:02 0|jonasschnelli|Linux and Windows?
174 2017-02-28 15:03:55 0|cfields|ugh
175 2017-02-28 15:03:55 0|jonasschnelli|db7f17e256c2d832e7eb62f878b74cbd95f3a9af3d0554828b2383a8b25faee3 bitcoin-0.14.0-x86_64-linux-gnu.tar.gz
176 2017-02-28 15:04:07 0|cfields|jonasschnelli: i'll push all of mine in a min, linux still building
177 2017-02-28 15:04:07 0|jonasschnelli|0bf3cae0567d10c9d3cc6ff0125e529c7ee0a336ab6532a2336e4aa7ee394457 bitcoin-0.14.0-win64-setup-unsigned.exe
178 2017-02-28 15:04:19 0|achow101|jonasschnelli: mine is in a pr: https://github.com/bitcoin-core/gitian.sigs/pull/486
179 2017-02-28 15:05:18 0|cfields|jonasschnelli: match for win64
180 2017-02-28 15:05:34 0|achow101|jonasschnelli: linux and windows match
181 2017-02-28 15:05:39 0|jonasschnelli|Yes. Linux and Win matches with achow101
182 2017-02-28 15:05:41 0|jonasschnelli|But not OSX
183 2017-02-28 15:06:07 0|jonasschnelli|Same descriptor and SDK
184 2017-02-28 15:06:19 0|jonasschnelli|source tarball file matches..
185 2017-02-28 15:06:23 0|jonasschnelli|So.. this is strange
186 2017-02-28 15:06:37 0|achow101|just like the issue with the last two rcs...
187 2017-02-28 15:07:13 0|achow101|are you using kvm or lxc?
188 2017-02-28 15:07:13 0|jonasschnelli|ah.. haven't followed that. OSX build of rc1-2 wasn't deterministic?
189 2017-02-28 15:07:17 0|jonasschnelli|lxc
190 2017-02-28 15:08:28 0|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
191 2017-02-28 15:09:09 0|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)
192 2017-02-28 15:11:20 0|achow101|jonasschnelli: try remaking with a new base vm?
193 2017-02-28 15:11:32 0|jonasschnelli|achow101: I made the base vm last week.
194 2017-02-28 15:15:38 0|achow101|ok, so I just rebuilt and this one matches jonasschnelli's
195 2017-02-28 15:15:46 0|achow101|:/
196 2017-02-28 15:16:00 0|jonasschnelli|achow101: okay. Thanks for removing your OSX backdoor. :)
197 2017-02-28 15:16:36 0|achow101|cfields must have the same backdoor too :D
198 2017-02-28 15:16:53 0|jonasschnelli|yeah... maybe you are the same person as well. :)
199 2017-02-28 15:20:08 0|wumpus|did anyone ever compare the executables?
200 2017-02-28 15:20:54 0|jonasschnelli|Mine is here if someone wants: https://bitcoinsrv.jonasschnelli.ch/builds/15
201 2017-02-28 15:20:59 0|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
202 2017-02-28 15:21:14 0|achow101|s/oof/out/
203 2017-02-28 15:21:30 0|cfields|wumpus: yes, i compared a ton.
204 2017-02-28 15:21:40 0|cfields|couldn't track it down to anything. Makes no sense.
205 2017-02-28 15:22:38 0|cfields|wumpus: all object files were the same, only difference is the executables. And They're created with our self-built linker
206 2017-02-28 15:23:28 0|cfields|only thing i can come up with (and how it looks) is symbol sort order
207 2017-02-28 15:23:47 0|wumpus|sounds a bit like the issue we had on windows, where some section was left uninitialized
208 2017-02-28 15:23:53 0|cfields|achow101 / jonasschnelli: mind retrying with 1 build job?
209 2017-02-28 15:23:59 0|wumpus|a linker map eventually helped me narrow down the issue
210 2017-02-28 15:24:24 0|wumpus|sort order? hm, a locale issue?
211 2017-02-28 15:24:35 0|achow101|cfields: sure.
212 2017-02-28 15:25:09 0|jonasschnelli|cfields: Yes. I can do that.
213 2017-02-28 15:25:40 0|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
214 2017-02-28 15:25:54 0|cfields|wumpus: oh, i left out.. only the osx binary differs
215 2017-02-28 15:26:11 0|jonasschnelli|cfields, achow101: build started with -j1 https://bitcoinsrv.jonasschnelli.ch/src/build.html?buildid=16
216 2017-02-28 15:26:19 0|cfields|achow101 / jonasschnelli: thanks :)
217 2017-02-28 15:27:13 0|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.
218 2017-02-28 15:28:04 0|achow101|wumpus: what doesn't make sense is that my build would alternate between two different hashes every time I built
219 2017-02-28 15:28:04 0|cfields|wumpus: yes
220 2017-02-28 15:28:20 0|cfields|achow101: hence the -j1 suggestion :)
221 2017-02-28 15:28:37 0|sipa|9
222 2017-02-28 15:29:17 0|wumpus|achow101: it makes perfect sense if it's filesystem non-determinism
223 2017-02-28 15:30:01 0|achow101|wumpus: how so?
224 2017-02-28 15:31:04 0|sipa|the filesystem is recreated for each build, no?
225 2017-02-28 15:31:40 0|wumpus|achow101: there's just no guarantee that the file system is deterministic
226 2017-02-28 15:32:45 0|wumpus|especially in the presence of multple threads, the order in which things are written, i/o scheduling, etc
227 2017-02-28 15:32:48 0|achow101|but shouldn't that also effect linux and windows builds?
228 2017-02-28 15:33:02 0|wumpus|no, in linux and windows builds we don't use any wildcards in the linker AFAIK
229 2017-02-28 15:33:36 0|achow101|oh
230 2017-02-28 15:33:56 0|wumpus|also even if they did, they use a different linker which may be sorting things differently, for all we know
231 2017-02-28 15:34:11 0|wumpus|osx is kind of an odd duck out in the toolchains as it uses the clang-based stuff
232 2017-02-28 15:34:45 0|sipa|also, any idea why Travis fails on the rebase of #9791 ?
233 2017-02-28 15:34:47 0|gribble|https://github.com/bitcoin/bitcoin/issues/9791 | Avoid VLA in hash.h by sipa ÷ Pull Request #9791 ÷ bitcoin/bitcoin ÷ GitHub
234 2017-02-28 15:34:54 0|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
235 2017-02-28 15:34:56 0|sipa|there seem to be no actual errors
236 2017-02-28 15:35:58 0|wumpus|cfields: yes, unless it can be sorted
237 2017-02-28 15:36:14 0|wumpus|cfields: but for the linker I certainly agree files should simply be enumerated
238 2017-02-28 15:36:28 0|cfields|sipa: looks like verify-commits.sh fails
239 2017-02-28 15:36:30 0|wumpus|cfields: for things like documentation + images it can be overly verbose to specify everything
240 2017-02-28 15:36:57 0|cfields|wumpus: for that stuff, sure. In this case, it's the png's, which get fed to rcc, which get compiled, then linked
241 2017-02-28 15:37:12 0|cfields|lots of places there for a reordering to have an effect
242 2017-02-28 15:37:52 0|wumpus|cfields: yep
243 2017-02-28 15:37:56 0|cfields|(though the object files match, so i'll admit, it's unlikely to be the actual cause here)
244 2017-02-28 15:38:37 0|wumpus|so it could only be the ordering of the object files
245 2017-02-28 15:39:08 0|cfields|right
246 2017-02-28 15:39:50 0|cfields|also, achow's dump was missing the .a's, so i couldn't compare those. Could be ar's fault as well.
247 2017-02-28 15:40:02 0|cfields|(still rebuilding to get a link map)
248 2017-02-28 15:40:21 0|wumpus|yes, could be ar's fault too, or the order of objects passed to ar
249 2017-02-28 15:40:26 0|achow101|cfields: they weren't in the vm image?
250 2017-02-28 15:40:47 0|wumpus|why is verify-commits failing?
251 2017-02-28 15:41:02 0|cfields|achow101: no, the gitian script removes 'em
252 2017-02-28 15:41:33 0|achow101|oh.
253 2017-02-28 15:41:39 0|cfields|<BlueMatt> but will barf
254 2017-02-28 15:41:39 0|cfields|<BlueMatt> well, travis will barf in an obvious way and only on master, so nbd
255 2017-02-28 15:41:39 0|cfields|<BlueMatt> ^ will need to be merged before anything else or travis will barf
256 2017-02-28 15:41:49 0|cfields|^ wumpus: unsure if that's solved already?
257 2017-02-28 15:42:10 0|BlueMatt|its not (see travis failures on master)
258 2017-02-28 15:42:14 0|achow101|cfields: -j1 build finished with my original hashes
259 2017-02-28 15:42:18 0|cfields|he was referring to #9884, so i assume no
260 2017-02-28 15:42:25 0|gribble|https://github.com/bitcoin/bitcoin/issues/9884 | Add Pieters old signed commits to revsig-commits by TheBlueMatt ÷ Pull Request #9884 ÷ bitcoin/bitcoin ÷ GitHub
261 2017-02-28 15:42:25 0|wumpus|why is that suddenly failing?
262 2017-02-28 15:42:44 0|sipa|i revoked some of my subkeys and created new ones
263 2017-02-28 15:42:53 0|cfields|achow101: ok great, let's see if jonasschnelli's matches
264 2017-02-28 15:43:00 0|sipa|with reason "keys are superseded"
265 2017-02-28 15:43:20 0|MarcoFalke|sipa: I created fresh signatures for mine
266 2017-02-28 15:43:24 0|wumpus|and that breaks all verifyies of old signatures? ouch
267 2017-02-28 15:43:43 0|MarcoFalke|wumpus: Just don't refresh your keys for now :P
268 2017-02-28 15:44:18 0|jonasschnelli|-j1 asserts file 0.14.0rc3 OSX: https://bitcoinsrv.jonasschnelli.ch/builds/16/bitcoin-osx-0.14-build.assert
269 2017-02-28 15:44:26 0|wumpus|anyhow going to merge that one
270 2017-02-28 15:44:43 0|bitcoin-git|13bitcoin/06master 14a4b02f4 15Matt Corallo: Add Pieter's old signed commits to revsig-commits
271 2017-02-28 15:44:43 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/36afd4db4442...11049f4fe626
272 2017-02-28 15:44:44 0|bitcoin-git|13bitcoin/06master 1411049f4 15Wladimir J. van der Laan: Merge #9884: Add Pieter's old signed commits to revsig-commits...
273 2017-02-28 15:44:45 0|jonasschnelli|different hashes when using -j1
274 2017-02-28 15:44:54 0|sipa|wumpus: yes, my suggestion to matt would be to check the reason for revocation
275 2017-02-28 15:45:07 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9884: Add Pieter's old signed commits to revsig-commits (06master...062017-02-pieter-revsig) 02https://github.com/bitcoin/bitcoin/pull/9884
276 2017-02-28 15:45:07 0|sipa|because this will happen again, i guess
277 2017-02-28 15:45:27 0|bitcoin-git|13bitcoin/060.14 145e70912 15Matt Corallo: Add Pieter's old signed commits to revsig-commits...
278 2017-02-28 15:45:27 0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.14: 02https://github.com/bitcoin/bitcoin/commit/5e709122343e1a336ee8ee21b003a298a65813f3
279 2017-02-28 15:45:37 0|cfields|jonasschnelli: woohoo, match
280 2017-02-28 15:46:04 0|jonasschnelli|cfields: yes. So the build jobs break the determinism
281 2017-02-28 15:46:57 0|cfields|jonasschnelli: certainly not definitive, but seems very plausible
282 2017-02-28 15:47:52 0|cfields|jonasschnelli: for rc1/rc2, achow101's builds alternated between 2 outcomes, one of which was a match
283 2017-02-28 15:48:42 0|wumpus|what should I use to re-sign my subkey?
284 2017-02-28 15:48:48 0|wumpus|without getting trouble like that
285 2017-02-28 15:51:29 0|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"
286 2017-02-28 15:51:37 0|BlueMatt|so I dont want to do that unless there is some assurance there
287 2017-02-28 15:51:38 0|achow101|cfields: it looks like jonasschnelli's finished: https://bitcoinsrv.jonasschnelli.ch/builds/16/bitcoin-osx-0.14-build.assert
288 2017-02-28 15:52:06 0|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
289 2017-02-28 15:52:25 0|BlueMatt|wumpus: meaning just create new subs for signing and use those instead of the old ones
290 2017-02-28 15:52:39 0|BlueMatt|jonasschnelli: may need to do so as well, or needed to as of yesterday
291 2017-02-28 15:52:47 0|BlueMatt|wumpus: (though your sigs were fine - you werent signing with your subkeys)
292 2017-02-28 15:54:01 0|wumpus|BlueMatt: okay, thanks
293 2017-02-28 15:55:12 0|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?
294 2017-02-28 15:55:33 0|BlueMatt|jonasschnelli: hmm? do you need new keys or just a new subkey?
295 2017-02-28 15:55:33 0|MarcoFalke|jonasschnelli: A subkey?
296 2017-02-28 15:55:48 0|jonasschnelli|BlueMatt: I'd like to do a new key
297 2017-02-28 15:55:49 0|BlueMatt|you can put a subkey in your key and put it on the keyservers and everything will work without any other updates
298 2017-02-28 15:56:09 0|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)
299 2017-02-28 15:56:37 0|jonasschnelli|BlueMatt: but I would need to add the new key ID into the verify-git script?
300 2017-02-28 15:56:47 0|BlueMatt|yes
301 2017-02-28 15:56:47 0|jonasschnelli|Maybe I just do a subkey for now
302 2017-02-28 15:57:05 0|sipa|note that github doesn't seem to support ed25519 subkeys
303 2017-02-28 15:57:22 0|jonasschnelli|sipa: hmm.. they support ed25519 "main key" but not sub?
304 2017-02-28 15:57:37 0|sipa|i don't think so either
305 2017-02-28 15:57:46 0|sipa|but i didn't try creating a new main key
306 2017-02-28 15:58:14 0|jonasschnelli|Hmm.. yes. I have only tried git/ssh access keys with Ed25519... this works.. haven't tried the gpg part though
307 2017-02-28 16:10:30 0|wumpus|isn't using three braces for a scope a bit overkill? :-) https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1299
308 2017-02-28 16:11:30 0|jonasschnelli|wumpus: huh? This is in master?!
309 2017-02-28 16:11:44 0|sipa|hahaha
310 2017-02-28 16:12:18 0|wumpus|jonasschnelli: yes :)
311 2017-02-28 16:12:31 0|wumpus|maybe the 64k stack frame needs some extra support, so one brace cannot hold it?
312 2017-02-28 16:13:02 0|BlueMatt|wumpus: .......
313 2017-02-28 16:13:09 0|sipa|possibly
314 2017-02-28 16:13:23 0|BlueMatt|i assume that was cfields trying not to have too large a diff
315 2017-02-28 16:13:27 0|sipa|subsequent refactorings that removed locks
316 2017-02-28 16:13:28 0|BlueMatt|or, at least, I blame cfields either way
317 2017-02-28 16:13:38 0|sipa|i assume
318 2017-02-28 16:13:56 0|wumpus|I could understand that for one level, but three? anyhow, no big deal, I just had to laugh
319 2017-02-28 16:14:15 0|cfields|heh yes, i think 3 rounds of scopes have been eliminated now. Got tired of stomping on myself with whitespace :)
320 2017-02-28 16:14:59 0|cfields|there are a few places like that. It's probably a good time to do a whitespace cleanup on those.
321 2017-02-28 16:15:05 0|wumpus|I guess all that code is going to be nuked and replaced with libevent anyhow
322 2017-02-28 16:16:33 0|bsm117532|If anyone knows a way to make github do that by default...I would love you eternally...
323 2017-02-28 16:16:34 0|cfields|sipa: sure, but towards the end, i can only imagine the initial reaction to "sigh, another +520,-500 diff from cfields" :)
324 2017-02-28 16:17:07 0|wumpus|bsm117532: get in the habit of diffing locally instead of in gh, or at least that's what I did
325 2017-02-28 16:17:24 0|bsm117532|Oh I do...but then there's code reviews...
326 2017-02-28 16:17:42 0|wumpus|I usually review and take notes offline
327 2017-02-28 16:17:51 0|wumpus|then pester all pulls at once
328 2017-02-28 16:19:30 0|sipa|offline?
329 2017-02-28 16:19:47 0|wumpus|well outside-of-the-browser
330 2017-02-28 16:20:12 0|wumpus|I don't generally go as far as to disconnect my network :p
331 2017-02-28 16:20:31 0|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
332 2017-02-28 16:20:43 0|wumpus|good idea
333 2017-02-28 16:23:04 0|cfields|heh
334 2017-02-28 16:32:26 0|wumpus|outoing connections aren't checked against -whitelist are they?
335 2017-02-28 16:32:43 0|sipa|i believe not
336 2017-02-28 16:33:41 0|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")
337 2017-02-28 16:34:16 0|cfields|wumpus: set the ibd date way back
338 2017-02-28 16:34:18 0|cfields|sec
339 2017-02-28 16:35:26 0|cfields|wumpus: -maxtipage
340 2017-02-28 16:35:32 0|wumpus|the node is in a sandbox that cannot make outgoing connections so I can't do it the other way around
341 2017-02-28 16:35:39 0|wumpus|cfields: thanks! will try that
342 2017-02-28 16:36:01 0|cfields|(set on the serving node, ofc)
343 2017-02-28 16:36:58 0|cfields|achow101: if you feel like trying to help nail down the gitian issue: http://pastebin.com/raw/cJzuYPqm
344 2017-02-28 16:37:41 0|cfields|achow101: It'd be great if you could manage to grab that from a build that differs
345 2017-02-28 16:38:29 0|cfields|(just edit the descriptor use for building, don't actually commit it)
346 2017-02-28 16:40:14 0|sipa|i wonder if we should just remove that don't respond to getheaders while in ibd
347 2017-02-28 16:42:18 0|wumpus|sipa: I wouldn't mind if it was removed
348 2017-02-28 16:45:03 0|wumpus|ah I added the log message in #6971, probably after troubleshooting the same issue why two nodes were not syncing :p
349 2017-02-28 16:45:05 0|gribble|https://github.com/bitcoin/bitcoin/issues/6971 | Is the InitialBlockDownload() check in getheaders too strict? ÷ Issue #6971 ÷ bitcoin/bitcoin ÷ GitHub
350 2017-02-28 16:48:41 0|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...
351 2017-02-28 16:49:05 0|cfields|wumpus: not past a checkpoint yet, maybe?
352 2017-02-28 16:49:31 0|sipa|i read that as max ti page, and was wondering why we're supporting configuring the page size on ti calculators
353 2017-02-28 16:50:56 0|cfields|!InitialBlockDownload() added in #6172
354 2017-02-28 16:50:56 0|gribble|Error: "InitialBlockDownload()" is not a valid command.
355 2017-02-28 16:50:58 0|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
356 2017-02-28 16:51:10 0|wumpus|hehe, because ti calculators are super fast at ecdsa computations of course!
357 2017-02-28 16:51:16 0|cfields|er.. #6172
358 2017-02-28 16:51:18 0|sdaftuar|and then it responds to it's outbound's peers requests with the bogus chain, and gets disconnected
359 2017-02-28 16:51:19 0|gribble|https://github.com/bitcoin/bitcoin/issues/6172 | Ignore getheaders requests when not synced by sdaftuar ÷ Pull Request #6172 ÷ bitcoin/bitcoin ÷ GitHub
360 2017-02-28 16:51:38 0|sdaftuar|i think we could just make sure we're past the last checkpoint before responding?
361 2017-02-28 16:52:16 0|wumpus|it's failing the "chainActive.Tip()->nChainWork < UintToArith256(chainParams.GetConsensus().nMinimumChainWork)" check
362 2017-02-28 16:53:10 0|wumpus|so yes I guess that's the replacement for the checkpoint check
363 2017-02-28 16:53:30 0|sipa|cfields: http://bitcoin.stackexchange.com/a/21911/208
364 2017-02-28 16:54:03 0|cfields|sipa: haha
365 2017-02-28 16:55:51 0|wumpus|didn't we stop using checkpoints for that purpose?
366 2017-02-28 16:56:32 0|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
367 2017-02-28 16:56:39 0|wumpus|anyhow, just going to comment out the check locally
368 2017-02-28 16:57:32 0|wumpus|sdaftuar: okay
369 2017-02-28 16:57:58 0|wumpus|sdaftuar: yes in that case it'd make sense to replace that with a checkpoint-based check
370 2017-02-28 16:59:13 0|bitcoin-git|[13bitcoin] 15RHavar closed pull request #9869: Move comment to right spot (06master...06comment) 02https://github.com/bitcoin/bitcoin/pull/9869
371 2017-02-28 16:59:54 0|wumpus|will look at that
372 2017-02-28 17:13:26 0|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?
373 2017-02-28 17:16:28 0|sipa|because you may be on a forked chain without knowing it
374 2017-02-28 17:17:14 0|sipa|so a peer asking you for headers, and then downloading them, and then discovering those headers don't align with a checkpoint
375 2017-02-28 17:17:22 0|bitcoin-git|[13bitcoin] 15ericshawlinux opened pull request #9890: Add a button to open the config file in a text editor (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9890
376 2017-02-28 17:17:31 0|sipa|(i'm speculating)
377 2017-02-28 17:17:49 0|wumpus|right, okay, that makes sense
378 2017-02-28 17:17:55 0|wumpus|why didn't we add a comment for this :/
379 2017-02-28 17:18:05 0|wumpus|it's not exactly trivial to think though
380 2017-02-28 17:23:48 0|gmaxwell|Please no checkpoint based check. Use the work based check.
381 2017-02-28 17:24:57 0|gmaxwell|also failing to respond to getheaders is a DOS attack against the peer. If we're not going to respond we should disconnect.
382 2017-02-28 17:24:58 0|wumpus|the point is that the check that causes the ban (on other nodes) uses a checkpoint based check
383 2017-02-28 17:25:18 0|wumpus|not sending the headers is trying to preempt that
384 2017-02-28 17:25:36 0|sdaftuar|wumpus: i think gmaxwell is right though -- a work based check is more reasonable long-term and just as effective for this purpose
385 2017-02-28 17:25:54 0|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.
386 2017-02-28 17:26:08 0|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
387 2017-02-28 17:26:46 0|wumpus|(which already checks against that)
388 2017-02-28 17:26:49 0|gmaxwell|I think checking IsInitialBlockDownload should be fine as is now. It used to be stupid and only check the height against the checkpoints.
389 2017-02-28 17:27:06 0|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.
390 2017-02-28 17:27:29 0|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
391 2017-02-28 17:27:53 0|gmaxwell|Well one downside of IsInitial is that it's not eager enough to turn on.
392 2017-02-28 17:28:06 0|wumpus|which I apparently do regularly and spend time troubleshooting then realize it's that check again
393 2017-02-28 17:28:10 0|gmaxwell|Which would be a reason to use a straight work check instead of IsInitial.
394 2017-02-28 17:29:00 0|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?
395 2017-02-28 17:30:41 0|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)
396 2017-02-28 17:31:32 0|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
397 2017-02-28 17:32:50 0|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 :)
398 2017-02-28 17:34:59 0|gmaxwell|Seperate from the bypass, -- We should probably work to get rid of that ban-on-inconsistent-with-checkpoints behavior.
399 2017-02-28 17:40:54 0|sdaftuar|gmaxwell: agreed. i also might put getting rid of checkpoints on my list of goals for 0.15.
400 2017-02-28 17:44:42 0|gmaxwell|I think eliminating them will require a soft-fork to increase the minimum difficulty or something similar.
401 2017-02-28 17:45:02 0|gmaxwell|(but not the kind of softfork that ever need to get activated, a flag height softfork)
402 2017-02-28 17:53:34 0|wumpus|it seems like a lousy reason to ban
403 2017-02-28 17:54:31 0|wumpus|banning should be reserved for things that consume a lot of resources
404 2017-02-28 17:55:59 0|gmaxwell|We should have a general mechenism for punting peers that don't agree with our consensus... that should be rather lazy.
405 2017-02-28 18:09:57 0|cfields|wumpus: interesting, your osx sigs mismatched as well
406 2017-02-28 18:10:09 0|cfields|seems we can all flip-flop
407 2017-02-28 18:29:28 0|BlueMatt|lolwtf...someone is trying to connect to the fibre network using a testnet node, connecting to port 8333
408 2017-02-28 18:32:22 0|sipa|we need a proxy that forwards connections to one of two bitcoind, based on network magic
409 2017-02-28 18:32:38 0|BlueMatt|or they could just use the right port.....
410 2017-02-28 18:32:48 0|BlueMatt|(well, those nodes dont have testnet, so dunno wtf they think they're doing, but whatever)
411 2017-02-28 18:33:09 0|BlueMatt|suppose its good that at least one miner has a full copy of their configs running on testnet
412 2017-02-28 18:36:16 0|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.
413 2017-02-28 18:37:50 0|BlueMatt|profall: i believe there is a rpcconnect option for that case
414 2017-02-28 18:38:05 0|BlueMatt|(which you would pass into bitcoin-cli to tell it where to connect)
415 2017-02-28 18:38:10 0|profall|ok
416 2017-02-28 18:39:59 0|profall|Figured it out, thanks :)
417 2017-02-28 19:06:32 0|gmaxwell|BlueMatt: probably me.... common config for testnet and not.
418 2017-02-28 19:08:22 0|BlueMatt|gmaxwell: looks like ckpool, maybe
419 2017-02-28 19:09:49 0|BlueMatt|sipa: whats the formula for the 15 pointers of size for mapTx? Can we get a comment to describe that?
420 2017-02-28 19:10:21 0|sipa|3 pointers per sorted list
421 2017-02-28 19:10:26 0|sipa|s/list/index/
422 2017-02-28 19:10:31 0|sipa|i think
423 2017-02-28 19:10:42 0|sipa|will do
424 2017-02-28 19:10:46 0|BlueMatt|thanks
425 2017-02-28 20:43:59 0|cfields|ok, I think i nailed down the gitian issue
426 2017-02-28 20:45:49 0|BlueMatt|nice!
427 2017-02-28 20:46:17 0|cfields|wumpus: still around, by any chance?
428 2017-02-28 20:47:03 0|cfields|wumpus: it's not worth a new tag, but i can't sign your osx bin :(
429 2017-02-28 20:49:13 0|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.
430 2017-02-28 20:50:59 0|gmaxwell|0 non-1-bit: Unk=68723 Fails=3170 Total=7144375
431 2017-02-28 20:51:00 0|gmaxwell|1 non-1-bit: Unk=11134759 Fails=872220 Total=111452250
432 2017-02-28 20:51:00 0|gmaxwell|2 non-1-bit: Unk=219092988 Fails=56230638 Total=579551700
433 2017-02-28 20:51:00 0|gmaxwell|3 non-1-bit: Unk=415437342 Fails=382522140 Total=1004556280
434 2017-02-28 20:51:00 0|gmaxwell|real 673m11.752s
435 2017-02-28 20:51:02 0|gmaxwell|user 28588m32.263s
436 2017-02-28 20:51:04 0|gmaxwell|oops wrong window
437 2017-02-28 20:51:39 0|BlueMatt|lol
438 2017-02-28 21:13:43 0|achow101|cfields: so any idea on how to fix that?
439 2017-02-28 21:14:00 0|cfields|achow101: yea, PR coming up
440 2017-02-28 21:14:30 0|achow101|will we have to redo the osx builds?
441 2017-02-28 21:16:01 0|cfields|yes, but I'm suggesting we just skip
442 2017-02-28 21:17:54 0|bitcoin-git|[13bitcoin] 15instagibbs closed pull request #9017: Enable various p2sh-p2wpkh functionality (06master...06p2shp2wpkhstuff) 02https://github.com/bitcoin/bitcoin/pull/9017
443 2017-02-28 21:18:46 0|achow101|but at least it will be fixed for final
444 2017-02-28 21:58:39 0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9891: depends: make osx output deterministic (06master...06fix-osx-link-determinism) 02https://github.com/bitcoin/bitcoin/pull/9891
445 2017-02-28 22:25:33 0|achow101|cfields: what hash should we get with the osx patch?
446 2017-02-28 22:31:11 0|luke-jr|checking whether to build with support for UPnPââ¬Â¦ configure: error: "UPnP requested but cannot be built. use --without-miniupnpc"
447 2017-02-28 22:31:21 0|luke-jr|^ for reference, this means ccache dir is read-only
448 2017-02-28 22:31:37 0|luke-jr|(or *can* mean it, anyway)
449 2017-02-28 23:02:15 0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9892: Bugfix: Only install manpages for built programs (06master...06bugfix_man_onlybuilt) 02https://github.com/bitcoin/bitcoin/pull/9892
450 2017-02-28 23:17:41 0|cfields|luke-jr: where are you seeing that?
451 2017-02-28 23:21:03 0|cfields|luke-jr: ah. We should do a quick compile check.
452 2017-02-28 23:22:24 0|luke-jr|cfields: Gentoo's build system supports ccache, but apparently doesn't manage permissions correctly (root owns ccache dir)
453 2017-02-28 23:22:49 0|luke-jr|not normally an issue, but I was testing out an updated ebuild as non-root
454 2017-02-28 23:24:08 0|cfields|luke-jr: ah. There's probably a use flag that's supposed to signal to export a var for the path, then?
455 2017-02-28 23:27:12 0|luke-jr|?
456 2017-02-28 23:27:39 0|cfields|yea: https://wiki.gentoo.org/wiki/Handbook:AMD64/Working/Features#Caching_compilation_objects
457 2017-02-28 23:27:44 0|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
458 2017-02-28 23:28:23 0|cfields|luke-jr: sure, not suggesting it's our problem. Looks like the dir is set there by portage, you could override locally
459 2017-02-28 23:28:31 0|cfields|but yes, we should do a compile test
460 2017-02-28 23:28:59 0|luke-jr|I simply disabled ccache for the test