1 2017-09-30 00:48:39	0|m4gdev|o/
 2 2017-09-30 08:01:47	0|meshcollider|ugh irieGhost is spamming comments on random PR
 3 2017-09-30 08:14:34	0|bitcoin-git|13bitcoin/06master 148849130 15MeshCollider: Remove lxcbr0 lines from gitian-build.sh
 4 2017-09-30 08:14:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/38c201f47c0b...763231051596
 5 2017-09-30 08:14:35	0|bitcoin-git|13bitcoin/06master 147632310 15MarcoFalke: Merge #11391: Remove lxcbr0 lines from gitian-build.sh...
 6 2017-09-30 08:15:09	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11391: Remove lxcbr0 lines from gitian-build.sh (06master...06201709_gitian_script_fix) 02https://github.com/bitcoin/bitcoin/pull/11391
 7 2017-09-30 12:17:55	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #11426: BIP90: Make buried deployments slightly more easily extensible (06master...06e16-bip90-extensible) 02https://github.com/bitcoin/bitcoin/pull/11426
 8 2017-09-30 12:44:37	0|jtimon|re https://github.com/bitcoin/bitcoin/pull/11398 I wonder if we should always leave at least the last bip9/bip8 deployment there to make sure we're using the rpc part of bip9
 9 2017-09-30 12:47:46	0|jtimon|I mean, I was about to start the same, but only for csv
10 2017-09-30 13:05:04	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #11427: Optimization: Remove Consensus::Params::BIP34Hash (06master...06e16-bip90-bip30) 02https://github.com/bitcoin/bitcoin/pull/11427
11 2017-09-30 15:54:06	0|bitcoin-git|[13bitcoin] 15wodry opened pull request #11428: Better understandable text for sending transaction option "Request Replace-By-Fee" (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11428
12 2017-09-30 16:11:25	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/763231051596...e542728cde67
13 2017-09-30 16:11:26	0|bitcoin-git|13bitcoin/06master 140b1b914 15Matt Corallo: Remove countMaskInv caching in bench framework...
14 2017-09-30 16:11:26	0|bitcoin-git|13bitcoin/06master 1453a6590 15Matt Corallo: Make float <-> int casts explicit outside of test, qt, CFeeRate
15 2017-09-30 16:11:27	0|bitcoin-git|13bitcoin/06master 141789e46 15Matt Corallo: Force explicit double -> int conversion for CFeeRate constructor...
16 2017-09-30 16:12:04	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11303: Fix estimatesmartfee rounding display issue (06master...062017-09-estimatesmartfee-round) 02https://github.com/bitcoin/bitcoin/pull/11303
17 2017-09-30 17:20:36	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #11430: B16 bip90 bip16 (06master...06b16-bip90-bip16) 02https://github.com/bitcoin/bitcoin/pull/11430
18 2017-09-30 18:19:07	0|jtimon|jl2012: edited https://github.com/bitcoin/bitcoin/pull/11398#issuecomment-333325969
19 2017-09-30 18:20:36	0|jtimon|btw thanks again for https://github.com/bitcoin/bitcoin/pull/11427 I could have looked at it for hours without distinguising < from >
20 2017-09-30 18:23:52	0|jl2012|jtimon: I'm trying to make IsSoftForkEnabled(), so all softforks, buried or bip9, could use that
21 2017-09-30 18:24:01	0|jl2012|not sure if it is a good idea
22 2017-09-30 18:25:10	0|jl2012|So next time when we bury a bip9 softfork, we don't need to edit validation.cpp at all
23 2017-09-30 18:26:34	0|jtimon|jl2012: I saw some simplification/preparation on rpc that looked spot on at a first glance, but will review more
24 2017-09-30 18:27:41	0|jtimon|IIRC you were unifying SoftForkMajorityDesc and SoftForkDesc and preparing it for post-bip9 buried deployments
25 2017-09-30 18:29:15	0|jl2012|I'm trying to combine softforks and bip9_softforks in getblockchaininfo
26 2017-09-30 18:29:15	0|jtimon|that kind of thing should pass all the tests before moving anything from bip9 to buried
27 2017-09-30 18:30:05	0|jl2012|ok. Do you think it should be a separate PR?
28 2017-09-30 18:30:30	0|jtimon|yeah, I think leaving BIP9SoftForkDesc as it is and rewritting SoftForkMajorityDesc/SoftForkDesc as it fits as you were doing looks good
29 2017-09-30 18:32:20	0|jtimon|I think most people won't care about them being separated PRs, I slightly care and maybe some people care in the opposite direction (but they can always ignore the dependency PR and ack the upper one directly)
30 2017-09-30 18:33:41	0|jtimon|just eager to ack the csv part I guess, but probably better to focus on commits than PRs
31 2017-09-30 18:36:07	0|jtimon|I would focus first on a commit that leaves everything prepared on the rpc side but without actually changing anything and thus passing all tests, but just my very opinionated and also criticized modus operandi, don't feel obliged to comply
32 2017-09-30 18:36:28	0|jl2012|jtimon: i think you are right
33 2017-09-30 18:38:42	0|jtimon|I think it will make things easier for you, but just try modifying your thing with an interactive rebase and if you're not convinced, rebase --abort (sorry, being verbose about my customes again)
34 2017-09-30 18:42:05	0|jtimon|forget about a separate PR for now, more separated commits will probably do it even for me, the terror of history bike-shedding
35 2017-09-30 18:43:22	0|jtimon|always remember I may compain about tiny things and there the right answer is probably "thanks, but no" I won't be offended
36 2017-09-30 18:44:56	0|jl2012|it's ok
37 2017-09-30 18:45:30	0|jtimon|cool, happy to help, but also don't want to slow you down
38 2017-09-30 18:45:33	0|jl2012|jtimon: the compiler complains comparing uint with int
39 2017-09-30 18:45:43	0|jtimon|cast ?
40 2017-09-30 18:46:08	0|jtimon|(unint32_t) somewhere probably
41 2017-09-30 18:46:10	0|jl2012|i think you changed buried_deployments from int to uint?
42 2017-09-30 18:49:13	0|jtimon|yep, I did, I was changing a local variable from int to uint32 initially, but I ended up liking luke-jr's casting in https://github.com/BitcoinHardfork/bitcoin/pull/3/files more and I also needed it for https://github.com/bitcoin/bitcoin/pull/11430
43 2017-09-30 18:49:22	0|jtimon|sorry for the incenvenience
44 2017-09-30 18:50:24	0|jtimon|I should have thought about those 2 things before asking you to rebase on top of it, sorry...excitement...impacience...sw is activated!
45 2017-09-30 18:52:50	0|luke-jr|speaking of comparing signed vs unsigned, is it well-defined how it behaves? does it actually compare correctly, or is the warning because of some real bug risk?
46 2017-09-30 18:54:38	0|esotericnonsense|luke-jr: -1 > 1
47 2017-09-30 18:55:59	0|esotericnonsense|my understanding (could be wrong) is that the signed int is cast to unsigned and then compared, so it is well defined, but whether it compares correctly depends on what you mean by correctly :P
48 2017-09-30 18:58:07	0|jtimon|perhaps someone should decide between 64 and 32 (which seems to dominate in consensus code, see primitives/block/CBlockHeader) and do a univeral transparent wrapper for int and unsigned or something
49 2017-09-30 18:59:36	0|esotericnonsense|e.g. https://0bin.net/paste/tytLfw5A072VUD4R#m49We78TgI6LQqcoMAK7Nwe9S2uIv2HFwyJCdawYzpZ
50 2017-09-30 18:59:58	0|esotericnonsense|I don't even get a compiler warning, heh
51 2017-09-30 19:01:38	0|jtimon|yeah, unsigned vs signed is much more dangerous than 32 vs 64
52 2017-09-30 19:01:42	0|luke-jr|esotericnonsense: eck
53 2017-09-30 19:02:07	0|luke-jr|jtimon: since everyone uses 64-bit platforms now, IMO we should make height be uint64_t everywhere
54 2017-09-30 19:02:10	0|jtimon|but in this case I think it should be ok
55 2017-09-30 19:02:21	0|luke-jr|unless we want to support negative heights some places, in which case int64_t is prob fine too
56 2017-09-30 19:03:40	0|jtimon|luke-jr: yeah, makes sense. besides is more forward compatible, we don't want to slow down the rest for miliseconds of performance in inferior platforms, right? I bet they simulate 64 just fine
57 2017-09-30 19:05:14	0|luke-jr|not sure 32-bit is slower on 64-bit platforms, but I don't think we need to support 32-bit performantly.
58 2017-09-30 19:12:14	0|jtimon|jl2012: changed from 32 to 64, mainteined the change to unsigned
59 2017-09-30 19:14:02	0|sipa|converting from signed to unsigned is always well-defined, unsigned to signed is only well-defined if there is no overflow
60 2017-09-30 19:14:14	0|jtimon|no, I was saying probably 64 is slower in 32 platforms, but...not so much slower, that was early optimization
61 2017-09-30 19:15:29	0|jtimon|sipa: thus converting unsigned to signed is never well defined without knowing the input, right?
62 2017-09-30 19:15:36	0|sipa|indeed
63 2017-09-30 19:15:47	0|sipa|(in practice, it works fine, though)
64 2017-09-30 19:15:54	0|sipa|on all platforms we support
65 2017-09-30 19:16:15	0|sipa|64-bit arithmetic is several times slower than 32-bit arithmetic on 32-bit platforms
66 2017-09-30 19:16:26	0|sipa|on 64-bit they're the same speed
67 2017-09-30 19:18:05	0|jtimon|yep, we're discussing edge cases that you just want to be sure about because...consensus code, no? training neural networks this kind of undefined behaviour could be a feature!
68 2017-09-30 19:20:04	0|jtimon|or if not, you probably don't care, whatever the machine does, if the network is not fit for that problem and architecture...just select another one, weights are extremly unlikely to ever get anywhere close to where that matters anyway
69 2017-09-30 20:51:04	0|bitcoin-git|[13bitcoin] 15geohic opened pull request #11431: 0.12 (06master...060.12) 02https://github.com/bitcoin/bitcoin/pull/11431
70 2017-09-30 20:52:59	0|bitcoin-git|[13bitcoin] 15geohic closed pull request #11431: 0.12 (06master...060.12) 02https://github.com/bitcoin/bitcoin/pull/11431
71 2017-09-30 21:55:09	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11432: Remove unused fTry from push_lock (06master...062017-08-clean-push-lock) 02https://github.com/bitcoin/bitcoin/pull/11432
72 2017-09-30 23:55:52	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9717: Pow: Remove fCheckPOW from CheckBlockHeader (06master...06pre-0.14-dont-call-me) 02https://github.com/bitcoin/bitcoin/pull/9717