1 2016-03-15 08:19:55	0|GitHub126|[13bitcoin] 15laanwj closed pull request #7682: [0.11.3] Fix "Unclear error when starting Bitcoin Core" (060.11...06Mf1603-011wallet) 02https://github.com/bitcoin/bitcoin/pull/7682
 2 2016-03-15 08:21:51	0|GitHub138|[13bitcoin] 15laanwj closed pull request #5949: Replace openssl aes encryption/decryption/key creation implementations with our own (06master...06aes-keys) 02https://github.com/bitcoin/bitcoin/pull/5949
 3 2016-03-15 08:27:37	0|jonasschnelli|sipa, wumpus: Why is https://github.com/bitcoin/bitcoin/pull/7689 labeled with prio high?
 4 2016-03-15 08:28:06	0|jonasschnelli|Side channel attacks? Or did I miss a openssl CVS?
 5 2016-03-15 08:29:47	0|midnightmagic|when was the planned date for that CVE release anyway?
 6 2016-03-15 08:30:04	0|jonasschnelli|SPV Info: during the last 12h, one of my nodes (where I collecting stats), served 4.5 GB of filtered blocks (12h!).
 7 2016-03-15 08:30:17	0|GitHub62|13bitcoin/06master 140040118 15mrbandrews: Fixes ZMQ startup with bad arguments.
 8 2016-03-15 08:30:17	0|GitHub62|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/48f39058315c...a6a860796a44
 9 2016-03-15 08:30:18	0|GitHub62|13bitcoin/06master 14a6a8607 15Wladimir J. van der Laan: Merge #7621: Fixes ZMQ startup with bad arguments....
10 2016-03-15 08:30:22	0|GitHub34|[13bitcoin] 15laanwj closed pull request #7621: Fixes ZMQ startup with bad arguments. (06master...06ba-fix-zmq) 02https://github.com/bitcoin/bitcoin/pull/7621
11 2016-03-15 08:30:53	0|jonasschnelli|And during the same 12h, the node got 5688 filtered mempool requests
12 2016-03-15 08:31:38	0|jonasschnelli|Which took: 73min to process (in total)?! can that be possible?
13 2016-03-15 09:35:46	0|GitHub139|[13bitcoin] 15jonasschnelli opened pull request #7691: [Wallet] refactor wallet/init interaction (06master...062016/03/wallet_mod) 02https://github.com/bitcoin/bitcoin/pull/7691
14 2016-03-15 09:45:43	0|GitHub69|[13bitcoin] 15btcdrak opened pull request #7692: Remove p2p alert system (06master...06remove_alert) 02https://github.com/bitcoin/bitcoin/pull/7692
15 2016-03-15 10:15:24	0|MarcoFalke|btcdrak, there is an issue with the recent cherry-pick: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
16 2016-03-15 10:16:13	0|btcdrak|weird, fixing.
17 2016-03-15 11:08:35	0|MarcoFalke|jonasschnelli, blame qtcreator for the 104px. ;) I assume the program did this because I removed the widget.
18 2016-03-15 11:09:10	0|MarcoFalke|There were other changes introduced by qtcreator but I was unsure what to do with them
19 2016-03-15 11:09:53	0|jonasschnelli|MarcoFalke: Yes. But it might be good to rearrange that height. Maybe 70 or 80px.
20 2016-03-15 11:13:13	0|MarcoFalke|-                    <string>total at least</string>
21 2016-03-15 11:13:14	0|MarcoFalke|Right, we want to make sure the default size can still hold all widgets when expanded ( https://github.com/bitcoin/bitcoin/issues/6601#issuecomment-196464704 )
22 2016-03-15 11:13:42	0|MarcoFalke|(sry for junk, I should get a proper IRC client)
23 2016-03-15 11:17:04	0|MarcoFalke|The only issue with this pull is probably when someone has "-sendfreetransactions" set in their conf.
24 2016-03-15 11:17:27	0|MarcoFalke|IIRC this will "overwrite" the GUI settings done at run time.
25 2016-03-15 11:56:56	0|sipa|jonasschnelli: cory's pull request was also priority high
26 2016-03-15 12:12:05	0|MarcoFalke|jonasschenlli, 7691 looks really neat.
27 2016-03-15 12:12:23	0|MarcoFalke|But it seems you forgot to remove parameter interaction from init?
28 2016-03-15 12:33:51	0|morcos|sipa: ping
29 2016-03-15 12:45:42	0|morcos|sipa: I'm just trying to reason through whether your new warning logic is sufficient or not for BIP 9.
30 2016-03-15 12:46:23	0|morcos|It's unclear what should be fixed in this PR and what should be fixed in a separate PR which cleans up alert logic (for instance making sure the RPC getinfo returns the warnings probably belongs there)
31 2016-03-15 12:47:38	0|morcos|But part of what concerns me about your PR is the if (!fWarned) guard, it seems like its too easy to accidentally miss whatever warning has happened, especially due to the buggy alert logic where strMiscWarning could be overwritten by too many blocks than expected or something silly
32 2016-03-15 12:48:42	0|morcos|What do you think it is that we are trying to avoid happening more than once with that guard?  The Notify?  perhaps we should just guard that.
33 2016-03-15 12:49:24	0|morcos|I'd like to make sure that before we release this code we have something in place such that 0.12.1 code with this released won't accidentally miss future upgrades of either known or unknown type if the user isn't paying very close attention.
34 2016-03-15 12:49:30	0|morcos|I'm not sure we're quite there yet.
35 2016-03-15 12:52:02	0|sipa|morcos: i tried to leave as much of the way warnings are issued untouched
36 2016-03-15 12:52:56	0|morcos|sipa: yeah, but i think the fact that the elegant way your warnings checker doesn't need to run during IBD (which i'd missed before) is a bit hampered by that !fWarned guard.
37 2016-03-15 12:53:37	0|morcos|which might be a problem with the existing code honestly
38 2016-03-15 12:58:11	0|sipa|morcos: and i missed that that fWarned flag was a static, so i had removed it in an earlier version
39 2016-03-15 12:59:04	0|sipa|i think the whole warning system is broken (not visible enough, no way to have multiple parallel warnings, not having transient warnings, ...)
40 2016-03-15 12:59:33	0|sipa|but i don't feel that should be fixed in this PR
41 2016-03-15 12:59:56	0|sipa|maybe it does need fixing separately before we release any bip9 code
42 2016-03-15 13:00:15	0|morcos|sipa: yeah i was just looking at that
43 2016-03-15 13:00:19	0|morcos|thats what i think
44 2016-03-15 13:00:28	0|morcos|i don't think it has to be that hard
45 2016-03-15 13:00:42	0|morcos|but i'm just a bit hesitant b/c i'm not familiar with the statusBar/GUI stuff
46 2016-03-15 13:00:56	0|morcos|but for the RPC warnings, it seems we could just concatenate any active warnings
47 2016-03-15 13:01:16	0|morcos|but i think its worth fixing at least to some degree before release
48 2016-03-15 13:01:26	0|morcos|but if you dont' want to do that, i'd say an alternative
49 2016-03-15 13:01:37	0|sipa|i think you want warnings to be a set of strings, that is constructed by merging the warning sets computed by different subsystems
50 2016-03-15 13:01:55	0|morcos|is to put the !fWarned guard on Notify and strMiscWarning, but keep logprintf's happening period
51 2016-03-15 13:01:58	0|sipa|each subsystem is responsible for caching its own warnings for as long as they are applicable
52 2016-03-15 13:02:12	0|morcos|so then at the very least the debug log will be constantly telling you if your version is out of date
53 2016-03-15 13:02:20	0|morcos|sipa: yes agree
54 2016-03-15 13:02:41	0|morcos|the problem is do we want to back port all those changes to .11 and .12?
55 2016-03-15 13:04:36	0|morcos|It seems like its the case now that anybody running .11.2 or .12.0 might miss warnings of the upgrade to BIP9 right?  they'll have that warning set once, but then it might be wiped out by one of the frivolous warnings
56 2016-03-15 13:06:04	0|morcos|brb
57 2016-03-15 13:37:29	0|morcos|sipa: heh, shows how much i know.  that strRPC is only for determining whether safeMode is required for RPC commands.  strStatusBar is what is returned by RPC commands, so that does get updated.
58 2016-03-15 13:37:50	0|morcos|but we still have the problem of transient warnings
59 2016-03-15 13:45:34	0|dgenr8|morcos: is it silly to warn the user if some miner breaks sha256 and starts issuing a block per 10s?
60 2016-03-15 13:46:06	0|morcos|dgenr8: i called them silly because they happen all the time as false positives now, not that the idea is silly
61 2016-03-15 13:46:51	0|morcos|although maybe that just got fixed?
62 2016-03-15 13:52:11	0|dgenr8|oh ok.  i think #7568 fixes it
63 2016-03-15 14:00:33	0|morcos|sipa: i think we should just do the quick and dirty fix for backports.  which in my mind is only use the !fWarned guard on calling Notify.
64 2016-03-15 14:00:56	0|morcos|This means that unknown block versions will always overwrite partition checks
65 2016-03-15 14:01:23	0|morcos|But LargeWorkForks will overwrite either of those
66 2016-03-15 14:02:05	0|morcos|Then we can clean up the Alert system for 0.13 properly, but right now there is no locking around any of these variables used in alerts and it seems a bit invasive to do it properly
67 2016-03-15 14:02:09	0|morcos|thoughts?
68 2016-03-15 14:03:07	0|sipa|seems reasonable
69 2016-03-15 14:21:49	0|GitHub2|[13bitcoin] 15btcdrak closed pull request #7544: Backport BIP112 implementation for 0.12 (060.12...06dot12_backport_bip112) 02https://github.com/bitcoin/bitcoin/pull/7544
70 2016-03-15 18:53:41	0|GitHub85|[13bitcoin] 15btcdrak closed pull request #7561: IsSuperMajority() softfork for BIPs 68,112 and 113 (06master...06softfork) 02https://github.com/bitcoin/bitcoin/pull/7561
71 2016-03-15 19:38:36	0|GitHub97|[13bitcoin] 15btcdrak opened pull request #7693: [0.11 backport] BIP112 CHECKSEQUENCEVERIFY mempool-only (060.11...06bip112-backport-0.11) 02https://github.com/bitcoin/bitcoin/pull/7693
72 2016-03-15 20:23:59	0|GitHub175|[13bitcoin] 15pstratem opened pull request #7694: Rename AcceptBlock/AcceptBlockHeader to StoreBlock/StoreBlockHeader (06master...062016-03-15-naming) 02https://github.com/bitcoin/bitcoin/pull/7694
73 2016-03-15 21:11:07	0|GitHub72|[13bitcoin] 15morcos opened pull request #7695: [0.11] Backport BIP 68 mempool only (060.11...0668backport) 02https://github.com/bitcoin/bitcoin/pull/7695
74 2016-03-15 21:33:21	0|Luke-Jr|http://seclists.org/oss-sec/2016/q1/645