< GitHub113> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/32b7294177e5...9201ce8f2f34
< GitHub113> bitcoin/master d096d22 Wladimir J. van der Laan: build: Get rid of `CLIENT_DATE`...
< GitHub113> bitcoin/master 9201ce8 Wladimir J. van der Laan: Merge #8181: build: Get rid of `CLIENT_DATE`...
< GitHub127> [bitcoin] laanwj closed pull request #8181: build: Get rid of `CLIENT_DATE` (master...2016_06_bye_client_date) https://github.com/bitcoin/bitcoin/pull/8181
< GitHub14> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/9201ce8f2f34...fde0ac403c78
< GitHub14> bitcoin/master 0cb0f26 Cory Fields: build: out-of-tree fixups...
< GitHub14> bitcoin/master fc4ad0c Cory Fields: build: more out-of-tree fixups...
< GitHub14> bitcoin/master ab95d5d Cory Fields: build: a few ugly hacks to get the rpc tests working out-of-tree...
< GitHub24> [bitcoin] laanwj closed pull request #8133: build: Finish up out-of-tree changes (master...out-of-tree-clean) https://github.com/bitcoin/bitcoin/pull/8133
< GitHub163> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/ac8d0418ed2891311cb786f32d39a54242aa2759
< GitHub163> bitcoin/master ac8d041 Wladimir J. van der Laan: qt: translations update
< GitHub15> [bitcoin] theuni opened pull request #8188: Add armhf/aarch64 gitian builds (master...arm-bins) https://github.com/bitcoin/bitcoin/pull/8188
< GitHub143> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ac8d0418ed28...67db011e1259
< GitHub143> bitcoin/master 654a211 Kaz Wesley: developer notes: updates for C++11...
< GitHub143> bitcoin/master 67db011 Wladimir J. van der Laan: Merge #8177: developer notes: updates for C++11...
< GitHub177> [bitcoin] laanwj closed pull request #8177: developer notes: updates for C++11 (master...no-c-casts) https://github.com/bitcoin/bitcoin/pull/8177
< MarcoFalke> cfields_: I broke the gitian windows build. Not sure how to proceed :/
< MarcoFalke> If you can't figure out why, I think the best is to revert my recent patch to the gitian descriptors.
< sipa> which patch broke it?
< MarcoFalke> pull #7283, I haven't marked it as [WIP], so it got merged even though there was the failure
< btcdrak> mardown tasklists are better for giving visibility into process and remaining.
< btcdrak> progress*
< btcdrak> it also renders in any references, or PR lists.
< sipa> are you sure that's the result of your PR, MarcoFalke?
< MarcoFalke> At least it is the same error I reported here: https://github.com/bitcoin/bitcoin/pull/7283#issuecomment-208076819
< jonasschnelli> Oh. Is the windows nightly gitian build broken?
< MarcoFalke> Apparently you can fix it by adding an additional gnu compiler package, but I fail to see why my refactoring triggered this.
< MarcoFalke> jonasschnelli: I don't think the problem is on your server
< GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67db011e1259...3e4cf8fe2644
< GitHub66> bitcoin/master 2ca8962 Cory Fields: travis: use slim generic image, and some fixups...
< GitHub66> bitcoin/master 3e4cf8f Wladimir J. van der Laan: Merge #8067: travis: use slim generic image, and some fixups...
< GitHub145> [bitcoin] laanwj closed pull request #8067: travis: use slim generic image, and some fixups (master...travis-generic-image) https://github.com/bitcoin/bitcoin/pull/8067
< cfields_> hmm, I saw some problems with gitian, but didn't test win
< cfields_> the problem i saw had to do with timestamps and caching. timestamps end up moving backwards and build refuses to continue
< cfields_> I wasn't sure if the issue was local
< cfields_> so yea, if 7283 is causing some other issue, i'd say +1 to reverting it for now
< GitHub135> [bitcoin] instagibbs opened pull request #8189: rename mapAddrCount to mapNetGroupNodes (master...mapAddrCounts) https://github.com/bitcoin/bitcoin/pull/8189
< GitHub39> [bitcoin] theuni closed pull request #6526: Move blocksize and related parameters to consensusparams (master...blocksize-consensus) https://github.com/bitcoin/bitcoin/pull/6526
< wumpus> cfields_: strange - I had no problems with gitan
< wumpus> cfields_: maybe pre-7283 caches cause trouble?
< wumpus> cfields_: yes, I think that's the problem. 7283 sets faketime for the dependencies to a date in 2000, instead of 2006
< cfields_> wumpus: could be. I didn't look into it at the time, I just nuked the cache and the next build succeeded
< wumpus> right
< wumpus> so: if during gitian build you get errors about timestamps, try removing your caches
< wumpus> if we have to revert 7283 I'd say don't merge it again, it's just not worth it
< 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
< cfields_> cory@cory-i7:~/dev/bitcoin(arm-bins)$ date
< cfields_> Fri Jun 10 10:52:33 EDT 2016
< cfields_> ubuntu@ubuntu:~$ date
< cfields_> Fri Jun 10 14:46:03 UTC 2016
< cfields_> ^^ my system clock is indeed apparently skewed. so building a commit within ~6min could've caused me issues i think?
< cfields_> oh, and those timezones are confusing too :)
< sipa> our modified txsize calculation is being abused by huge cheap transactions with tons of inputs
< sipa> i
< wumpus> ugh
< sipa> i'm unsure whether this is intended behaviour
< sipa> it's clearly cleaning up lots of utxos
< wumpus> large transactions with lots of inputs have always been quite popular
< sipa> it's certainly suboptimal for miners
< wumpus> but it getting away with so little fee is curious
< sipa> well in modified txsize, inputs are free
< sipa> (unless they have a scriptSig of over 110 bytes)
< 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...
< sipa> gmaxwell: ^
< wumpus> having inputs entirely free is a curious decision, although it works to clean up utxos I guess
< morcos> sipa: i'm not sure what the concern is exactly
< morcos> modified tx size is only used for priority
< morcos> these things are still booted from a limited mempool by feerate based on actual tx size
< sipa> ah, i see
< morcos> i'm guessing they are just getting in via the free tx rate limiting
< sipa> morcos: thanks for clearing that up, i forgot it didn't apply everywhere
< gmaxwell> why pinging me, the modified txsize stuff was only ever used for priority.
< sipa> ok, false alarm :)
< sipa> it also explains why they aren't confirming
< 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.
< sipa> gmaxwell: i'd go further and make an encapsulated OrphanMap object that just has 'add','delete', 'deleterecursive'
< sipa> but trying to limit changes now
< 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.
< sipa> yes, that's why you'd also have a non-recursive delete
< sipa> it's very similar to the mempool, actually...
< cfields_> cya everyone, back in a few weeks.
< helo> o/
< btcdrak> cfields_ enjoy :)