1 2016-06-10 07:52:04	0|GitHub113|13bitcoin/06master 14d096d22 15Wladimir J. van der Laan: build: Get rid of `CLIENT_DATE`...
 2 2016-06-10 07:52:04	0|GitHub113|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/32b7294177e5...9201ce8f2f34
 3 2016-06-10 07:52:05	0|GitHub113|13bitcoin/06master 149201ce8 15Wladimir J. van der Laan: Merge #8181: build: Get rid of `CLIENT_DATE`...
 4 2016-06-10 07:52:14	0|GitHub127|[13bitcoin] 15laanwj closed pull request #8181: build: Get rid of `CLIENT_DATE` (06master...062016_06_bye_client_date) 02https://github.com/bitcoin/bitcoin/pull/8181
 5 2016-06-10 08:06:22	0|GitHub14|[13bitcoin] 15laanwj pushed 8 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9201ce8f2f34...fde0ac403c78
 6 2016-06-10 08:06:23	0|GitHub14|13bitcoin/06master 140cb0f26 15Cory Fields: build: out-of-tree fixups...
 7 2016-06-10 08:06:23	0|GitHub14|13bitcoin/06master 14fc4ad0c 15Cory Fields: build: more out-of-tree fixups...
 8 2016-06-10 08:06:24	0|GitHub14|13bitcoin/06master 14ab95d5d 15Cory Fields: build: a few ugly hacks to get the rpc tests working out-of-tree...
 9 2016-06-10 08:06:27	0|GitHub24|[13bitcoin] 15laanwj closed pull request #8133: build: Finish up out-of-tree changes (06master...06out-of-tree-clean) 02https://github.com/bitcoin/bitcoin/pull/8133
10 2016-06-10 08:12:27	0|GitHub163|13bitcoin/06master 14ac8d041 15Wladimir J. van der Laan: qt: translations update
11 2016-06-10 08:12:27	0|GitHub163|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/ac8d0418ed2891311cb786f32d39a54242aa2759
12 2016-06-10 09:29:17	0|GitHub15|[13bitcoin] 15theuni opened pull request #8188: Add armhf/aarch64 gitian builds (06master...06arm-bins) 02https://github.com/bitcoin/bitcoin/pull/8188
13 2016-06-10 09:29:57	0|GitHub143|13bitcoin/06master 14654a211 15Kaz Wesley: developer notes: updates for C++11...
14 2016-06-10 09:29:57	0|GitHub143|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ac8d0418ed28...67db011e1259
15 2016-06-10 09:29:58	0|GitHub143|13bitcoin/06master 1467db011 15Wladimir J. van der Laan: Merge #8177: developer notes: updates for C++11...
16 2016-06-10 09:30:07	0|GitHub177|[13bitcoin] 15laanwj closed pull request #8177: developer notes: updates for C++11 (06master...06no-c-casts) 02https://github.com/bitcoin/bitcoin/pull/8177
17 2016-06-10 10:03:28	0|MarcoFalke|cfields_: I broke the gitian windows build. Not sure how to proceed :/
18 2016-06-10 10:04:19	0|MarcoFalke|If you can't figure out why, I think the best is to revert my recent patch to the gitian descriptors.
19 2016-06-10 10:05:17	0|sipa|which patch broke it?
20 2016-06-10 10:08:30	0|MarcoFalke|pull #7283, I haven't marked it as [WIP], so it got merged even though there was the failure
21 2016-06-10 10:09:41	0|btcdrak|mardown tasklists are better for giving visibility into process and remaining.
22 2016-06-10 10:09:45	0|btcdrak|progress*
23 2016-06-10 10:10:27	0|btcdrak|it also renders in any references, or PR lists.
24 2016-06-10 10:10:37	0|MarcoFalke|log: https://bitcoin.jonasschnelli.ch/nightlybuilds/2016-06-10/build-win.log
25 2016-06-10 10:12:40	0|sipa|are you sure that's the result of your PR, MarcoFalke?
26 2016-06-10 10:13:28	0|MarcoFalke|At least it is the same error I reported here: https://github.com/bitcoin/bitcoin/pull/7283#issuecomment-208076819
27 2016-06-10 11:17:46	0|jonasschnelli|Oh. Is the windows nightly gitian build broken?
28 2016-06-10 11:21:18	0|MarcoFalke|Apparently you can fix it by adding an additional gnu compiler package, but I fail to see why my refactoring triggered this.
29 2016-06-10 11:21:46	0|MarcoFalke|jonasschnelli: I don't think the problem is on your server
30 2016-06-10 13:41:21	0|GitHub66|13bitcoin/06master 142ca8962 15Cory Fields: travis: use slim generic image, and some fixups...
31 2016-06-10 13:41:21	0|GitHub66|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/67db011e1259...3e4cf8fe2644
32 2016-06-10 13:41:22	0|GitHub66|13bitcoin/06master 143e4cf8f 15Wladimir J. van der Laan: Merge #8067: travis: use slim generic image, and some fixups...
33 2016-06-10 13:41:31	0|GitHub145|[13bitcoin] 15laanwj closed pull request #8067: travis: use slim generic image, and some fixups (06master...06travis-generic-image) 02https://github.com/bitcoin/bitcoin/pull/8067
34 2016-06-10 14:08:41	0|cfields_|hmm, I saw some problems with gitian, but didn't test win
35 2016-06-10 14:09:09	0|cfields_|the problem i saw had to do with timestamps and caching. timestamps end up moving backwards and build refuses to continue
36 2016-06-10 14:09:27	0|cfields_|I wasn't sure if the issue was local
37 2016-06-10 14:10:32	0|cfields_|so yea, if 7283 is causing some other issue, i'd say +1 to reverting it for now
38 2016-06-10 14:12:59	0|GitHub135|[13bitcoin] 15instagibbs opened pull request #8189: rename mapAddrCount to mapNetGroupNodes (06master...06mapAddrCounts) 02https://github.com/bitcoin/bitcoin/pull/8189
39 2016-06-10 14:37:48	0|GitHub39|[13bitcoin] 15theuni closed pull request #6526: Move blocksize and related parameters to consensusparams (06master...06blocksize-consensus) 02https://github.com/bitcoin/bitcoin/pull/6526
40 2016-06-10 14:41:31	0|wumpus|cfields_: strange - I had no problems with gitan
41 2016-06-10 14:41:40	0|wumpus|cfields_: maybe pre-7283 caches cause trouble?
42 2016-06-10 14:42:23	0|wumpus|cfields_: yes, I think that's the problem. 7283 sets faketime for the dependencies to a date in 2000, instead of 2006
43 2016-06-10 14:42:29	0|cfields_|wumpus: could be. I didn't look into it at the time, I just nuked the cache and the next build succeeded
44 2016-06-10 14:42:40	0|wumpus|right
45 2016-06-10 14:44:34	0|wumpus|so: if during gitian build you get errors about timestamps, try removing your caches
46 2016-06-10 14:44:54	0|wumpus|if we have to revert 7283 I'd say don't merge it again, it's just not worth it
47 2016-06-10 14:44:56	0|cfields_|wumpus: iirc the issue was that timestamps were in the future. So I assumed that it had something to do with committing a change on my machine and quickly building it inside gitian, where the current time may be slightly behind the committed time
48 2016-06-10 14:46:32	0|cfields_|cory@cory-i7:~/dev/bitcoin(arm-bins)$ date
49 2016-06-10 14:46:32	0|cfields_|Fri Jun 10 10:52:33 EDT 2016
50 2016-06-10 14:46:43	0|cfields_|Fri Jun 10 14:46:03 UTC 2016
51 2016-06-10 14:46:43	0|cfields_|ubuntu@ubuntu:~$ date
52 2016-06-10 14:47:42	0|cfields_|^^ my system clock is indeed apparently skewed. so building a commit within ~6min could've caused me issues i think?
53 2016-06-10 14:48:51	0|cfields_|oh, and those timezones are confusing too :)
54 2016-06-10 15:08:12	0|sipa|http://bitcoin.stackexchange.com/questions/45771/mempool-filled-with-14kb-transactions-tons-of-inputs-0-15-mbtc-fee?noredirect=1#comment53373_45771
55 2016-06-10 15:08:44	0|sipa|our modified txsize calculation is being abused by huge cheap transactions with tons of inputs
56 2016-06-10 15:14:04	0|sipa|i
57 2016-06-10 15:14:07	0|wumpus|ugh
58 2016-06-10 15:14:11	0|sipa|i'm unsure whether this is intended behaviour
59 2016-06-10 15:14:17	0|sipa|it's clearly cleaning up lots of utxos
60 2016-06-10 15:14:31	0|wumpus|large transactions with lots of inputs have always been quite popular
61 2016-06-10 15:14:42	0|sipa|it's certainly suboptimal for miners
62 2016-06-10 15:14:59	0|wumpus|but it getting away with so little fee is curious
63 2016-06-10 15:15:15	0|sipa|well in modified txsize, inputs are free
64 2016-06-10 15:17:11	0|sipa|(unless they have a scriptSig of over 110 bytes)
65 2016-06-10 15:18:12	0|warren|I've always felt that costs should be imposed during creation of each UTXO, but it's too late to change that without upsetting people...
66 2016-06-10 15:21:38	0|sipa|gmaxwell: ^
67 2016-06-10 15:33:40	0|wumpus|having inputs entirely free is a curious decision, although it works to clean up utxos I guess
68 2016-06-10 15:47:20	0|morcos|sipa: i'm not sure what the concern is exactly
69 2016-06-10 15:47:28	0|morcos|modified tx size is only used for priority
70 2016-06-10 15:47:50	0|morcos|these things are still booted from a limited mempool by feerate based on actual tx size
71 2016-06-10 15:48:12	0|sipa|ah, i see
72 2016-06-10 15:49:03	0|morcos|i'm guessing they are just getting in via the free tx rate limiting
73 2016-06-10 15:50:49	0|sipa|morcos: thanks for clearing that up, i forgot it didn't apply everywhere
74 2016-06-10 16:20:44	0|gmaxwell|why pinging me, the modified txsize stuff was only ever used for priority.
75 2016-06-10 16:21:02	0|sipa|ok, false alarm :)
76 2016-06-10 16:21:22	0|sipa|it also explains why they aren't confirming
77 2016-06-10 18:57:58	0|gmaxwell|sipa: thanks for the change to outpoint, thats indeed much better.  Any thoughts on the recursive orphan issue?  I was thinking of just adding the insertion time to the maporphan object and just deleting old orphans from time to time... which is probably an independantly good thing to do.
78 2016-06-10 18:59:03	0|sipa|gmaxwell: i'd go further and make an encapsulated OrphanMap object that just has 'add','delete', 'deleterecursive'
79 2016-06-10 18:59:18	0|sipa|but trying to limit changes now
80 2016-06-10 19:00:21	0|gmaxwell|kind of an annoying thing about just deleting recursively, ... say the orphan was included in a block instead of conflicted, in that case the deletion should not be recursive.
81 2016-06-10 19:01:18	0|sipa|yes, that's why you'd also have a non-recursive delete
82 2016-06-10 19:01:28	0|sipa|it's very similar to the mempool, actually...
83 2016-06-10 21:26:14	0|cfields_|cya everyone, back in a few weeks.
84 2016-06-10 21:26:19	0|helo|o/
85 2016-06-10 21:26:40	0|btcdrak|cfields_ enjoy :)