1 2016-06-21 00:44:00	0|_anthony_|the CSV fix is in :)
  2 2016-06-21 03:04:59	0|luke-jr|cfields_: https://docs.travis-ci.com/user/ip-addresses/
  3 2016-06-21 04:39:07	0|jl2012|just want to confirm: during bip9 locked_in, blocks with any nVersion >=4 are valid?
  4 2016-06-21 04:45:02	0|btcdrak|jl2012: what do you mean? once lockin is reached signalling is no longer required but recommended.
  5 2016-06-21 04:45:36	0|jl2012|btcdrak: you have answered my question: no longer required
  6 2016-06-21 04:46:01	0|jl2012|i think certains pools are setting their version manually
  7 2016-06-21 04:46:41	0|jl2012|they have to turn it back to 0x20000000 at or before 419328
  8 2016-06-21 04:47:02	0|jl2012|or that may trigger the unknown softfork warning
  9 2016-06-21 04:55:59	0|jl2012|should we ask miners (who are manually setting the version) to change the version to 0x20000000 *at* or *before* 419328?
 10 2016-06-21 04:57:43	0|jl2012|I think it'd be better if they change it before 419328. Otherwise, if they keep signalling 0x20000001 after 419328, Bitcoin Core clients will think there is an unknown softfork
 11 2016-06-21 05:17:47	0|jl2012|},
 12 2016-06-21 05:17:47	0|jl2012|"csv": {
 13 2016-06-21 05:17:47	0|jl2012|"startTime": 1462060800,
 14 2016-06-21 05:17:47	0|jl2012|"status": "locked_in",
 15 2016-06-21 05:17:47	0|jl2012|"timeout": 1493596800
 16 2016-06-21 05:18:55	0|btcdrak|how many 0x20000001 blocks?
 17 2016-06-21 05:18:59	0|jl2012|In the last difficulty round, CSV had 1946/2016 (96.53%)
 18 2016-06-21 05:19:17	0|jl2012|0x20000001 is 1916/2016 (95.04%)
 19 2016-06-21 05:20:13	0|jl2012|so we could have a locked_in just with only standard Bitcoin Core 0.12.1 blocks
 20 2016-06-21 05:23:23	0|gmaxwell|if the signaling goes away now we will panic
 21 2016-06-21 05:23:36	0|gmaxwell|because it will suggest the network state will diverge if a CSV violation is mined.
 22 2016-06-21 05:25:32	0|btcdrak|the spec says should but not must continue to signal during locked in state.
 23 2016-06-21 05:26:08	0|gmaxwell|the purpose of the continued signaling is to let us humans see that the consensus state hasn't changed. it's not enforced by anything, thus not must.
 24 2016-06-21 05:26:43	0|jl2012|after activation of CSV, how many blocks are needed to trigger the unknown softfork warning?
 25 2016-06-21 05:27:39	0|gmaxwell|50 out of 100. is the lower threshold.
 26 2016-06-21 05:28:21	0|jl2012|so they have to react in less than one day if we ask them to change it after it is active
 27 2016-06-21 05:28:59	0|gmaxwell|Since we're now aware of miners manually setting version bits we should start work on a new deployment mechenism and depricate BIP9. :(
 28 2016-06-21 05:29:35	0|gmaxwell|I think BIP9 is too unsafe to use with parties manually setting the bits. The issue is if they have old nodes that don't enforce the consensus rules and they're failing over to them and getting work from them it can split the network, and it would be completely silent.
 29 2016-06-21 05:29:54	0|btcdrak|well it is just f2pool and antpool afaik
 30 2016-06-21 05:30:52	0|gmaxwell|if it's most of the hashpower it means that BIP9 is a currently failed design. The initial switch to signal CSV was _Exactly_ at the starting time, so I felt confident that the version numbers weren't being faked.
 31 2016-06-21 05:30:53	0|jl2012|gmaxwell: the same problem applies to ISM
 32 2016-06-21 05:31:04	0|gmaxwell|I'm really crestfallen to find that it's being faked now.
 33 2016-06-21 05:31:27	0|gmaxwell|jl2012: yes, and we had a failure with ISM, we hoped that the new mechenism which did not orphan non-conforming blocks would not be faked.
 34 2016-06-21 05:32:14	0|gmaxwell|the fact that that failure involved empty blocks is the only thing that prevented there from being large doublespending losses.
 35 2016-06-21 05:33:04	0|gmaxwell|jl2012: in any case, if we know now that they're turning the bit off, we can not freak out when it happens.
 36 2016-06-21 05:33:32	0|gmaxwell|but we should urge them to check very carefully that _all_ of their infrastructure is upgraded and that there are no old nodes that might come back up, e.g. after a power cycle.
 37 2016-06-21 05:33:51	0|btcdrak|i am sure we can solve the problem by talking with them. i think we should advice them to stop signalling before activation
 38 2016-06-21 05:34:44	0|gmaxwell|the problem is likely that version is something exposed to front end mining equipment, and if they are doing 'fake' block generation then they need to have the block version succession logic in their own software, or configure it manually.
 39 2016-06-21 05:34:46	0|btcdrak|the general public just need education
 40 2016-06-21 05:35:23	0|gmaxwell|btcdrak: we can educate around risk people impose on themselves, for risk they impose on others we should strive towards designs that are hard to misconfigure.
 41 2016-06-21 05:35:52	0|gmaxwell|I thought BIP9 got us there, but apparently I was mistaken. An intended feature of the design isn't working.
 42 2016-06-21 05:36:40	0|btcdrak|the website faq advises miners to stop signalling before activation for those manually setting the bit
 43 2016-06-21 05:37:17	0|gmaxwell|...
 44 2016-06-21 05:38:05	0|btcdrak|gmaxwell: i dont see how the issue is any different than ISM. it is better under VB since there is a two week period before enforcement.
 45 2016-06-21 05:38:20	0|gmaxwell|This is seriously fucked up, miners signaling versions inconsistent with the consensus rules they were running already forked the network once and narrowly avoided an incident. BIP9's design was partially motivated in avoiding that. (with no "set version or get orphaned" the beliefe was there would be no reason to fake it.
 46 2016-06-21 05:38:30	0|btcdrak|miners have been manually setting bloxk version long ago
 47 2016-06-21 05:38:50	0|gmaxwell|yes, and it already caused one ~6 block deep chain fork!
 48 2016-06-21 05:40:38	0|btcdrak|right. VB is better because of grace period. but maybe I am not explainimg well. when I talked to ant and fish they said they upgraded first and then changed the version number.
 49 2016-06-21 05:41:26	0|btcdrak|so they are not putting anyone at risk by doing it in that order.
 50 2016-06-21 05:42:12	0|gmaxwell|btcdrak: the grace period doesn't help this issue. The issue is that we don't get any strong, hard to screw up, indication that their upgrades were effective. This depends on their internal monitoring being effective, which it is not historically for many mining operations, and we shouldn't expect it to be because the risk is predominantly not held by them.
 51 2016-06-21 05:42:19	0|gmaxwell|btcdrak: only if they made no errors.
 52 2016-06-21 05:42:48	0|gmaxwell|and it's hard to tell, because the manual setting covers up the indicator.
 53 2016-06-21 05:43:47	0|btcdrak|it is true. they do forget nodes... i dont see how you can get around this problem. miners need to change their habits.
 54 2016-06-21 05:44:08	0|jl2012|Let's assume a miner is not setting manually, and some how fall back to 0.12.0 after activation. What will happen?
 55 2016-06-21 05:45:02	0|gmaxwell|jl2012: won't be detected anymore, the tradeoff for getting the bit back is that you only learn about the status during the month of signaling and grace period.
 56 2016-06-21 05:45:18	0|gmaxwell|But even that is meaningless if manually overridden.
 57 2016-06-21 05:45:21	0|btcdrak|jl2012: they could mine an invalid block.. except their relay policy is unlikely to accept an invalid tx.
 58 2016-06-21 05:45:49	0|gmaxwell|btcdrak: they'll extend an invalid chain when someone else mines an invalid block.
 59 2016-06-21 05:46:02	0|btcdrak|truee
 60 2016-06-21 05:46:51	0|btcdrak|well i dont see a solution other than education. it is why we wrote the FAQ
 61 2016-06-21 05:47:55	0|btcdrak|https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
 62 2016-06-21 05:51:32	0|gmaxwell|jl2012: in theory the mandatory version increase protected against downgrades, but in practice we found it did the opposite, since miners manually set the version to avoid being orphaned... so not only did it not protect against downgrades, it concealed a lack of true enforcement.
 63 2016-06-21 05:52:22	0|gmaxwell|So the expectation with bip9 was that since it was no longer forced there would be no incentive to lie, and at least the measure of upgrade status would be faithful.
 64 2016-06-21 06:00:53	0|jl2012|This could be corrected only with education
 65 2016-06-21 06:01:32	0|btcdrak|jl2012: i agree
 66 2016-06-21 06:01:38	0|gmaxwell|We could introduce signaling elsewhere in the block in locations that miners have not already built infrastructure around faking the values.
 67 2016-06-21 06:01:46	0|jl2012|Some miners didn't really understand bip9
 68 2016-06-21 06:01:48	0|gmaxwell|This would be systematically safe.
 69 2016-06-21 06:02:17	0|jl2012|nlocktime, maybe
 70 2016-06-21 06:02:21	0|gmaxwell|Expecting education to work is a losing fight... because we can educate but the parties will continue to rotate out.
 71 2016-06-21 06:02:36	0|gmaxwell|nlocktime in coinbase txn perhaps, yes.
 72 2016-06-21 06:02:45	0|gmaxwell|(which is where height should have gone, but oh well. :) )
 73 2016-06-21 06:03:01	0|gmaxwell|Not that I don't think that we should educate, of course. But its risky to count on that for safty.
 74 2016-06-21 06:04:18	0|jl2012|But nlocktime is determined by stratum
 75 2016-06-21 06:04:29	0|btcdrak|gmaxwell: in any case for csv miner have upgraded to 0.12.1.
 76 2016-06-21 06:04:31	0|gmaxwell|Then can't use that either.
 77 2016-06-21 06:04:34	0|jl2012|So they will fake it again
 78 2016-06-21 06:05:46	0|gmaxwell|In any case there are many potential places to put it, not something that needs to be figured out now. Any solution would need to be carefully evaluated.
 79 2016-06-21 06:06:29	0|gmaxwell|avoiding interaction with any customized infratructure is one reason why mark advocated the dummy transactions for additional commitments.
 80 2016-06-21 06:07:14	0|btcdrak|yes was about to say use first tx.
 81 2016-06-21 06:08:05	0|gmaxwell|Really the major loss with stratum is that we lost the clean domain of authority layering in the system.  Now there isn't a nice boundary where complex consensus details are hidden behind, and where people who don't care about them don't have to worry about them.
 82 2016-06-21 06:08:39	0|gmaxwell|With getwork nothing that was up for adjustment really mattered much except changes that would just make your block invalid even to SPV nodes.
 83 2016-06-21 06:10:38	0|jl2012|btw, we also need to warn the miners who are using coinbase nSequence as mining nonce
 84 2016-06-21 06:11:04	0|jl2012|they must keep the coinbase nVersion as 1 or the block might be orphaned
 85 2016-06-21 06:17:12	0|sipa|or above 2^31
 86 2016-06-21 06:17:46	0|jl2012|sipa, i.e. negative?
 87 2016-06-21 06:19:10	0|sipa|right
 88 2016-06-21 06:27:23	0|jl2012|we may need a email to miners to tell them what to double check in the coming 2 weeks
 89 2016-06-21 06:28:07	0|jl2012|1. make sure every nodes are upgraded to 0.12.1, and won't somehow fall back to an older version
 90 2016-06-21 06:28:53	0|jl2012|2. make sure they will stop signalling CSV at or before block 419328
 91 2016-06-21 06:29:19	0|jl2012|(if they are doing that manually)
 92 2016-06-21 06:29:41	0|jl2012|3. make sure the coinbase tx compiles with BIP68
 93 2016-06-21 06:30:25	0|jl2012|4. make sure the coinbase tx compiles with BIP113 (in case someone use nLockTime for mining --> unlikely)
 94 2016-06-21 06:30:39	0|jl2012|anymore?
 95 2016-06-21 06:31:28	0|jl2012|s/compiles/complies/
 96 2016-06-21 06:35:03	0|sipa|i don't think 68 applies to coinbase inputs
 97 2016-06-21 06:35:48	0|jl2012|really? let me check the code
 98 2016-06-21 06:36:05	0|sipa|oh, i mean 113
 99 2016-06-21 06:36:37	0|jl2012|nlocktime of coinbase is not checked?
100 2016-06-21 06:37:15	0|sipa|it's not an input
101 2016-06-21 06:37:26	0|sipa|and not validated as one
102 2016-06-21 06:37:30	0|sipa|(i think)
103 2016-06-21 06:38:47	0|jl2012|113 is the median-time-past, not OP_CSV
104 2016-06-21 06:39:56	0|sipa|yes, so 113 does not apply to coinbases
105 2016-06-21 06:40:28	0|jl2012|so i can put whatever value in the nLockTime of coinbase and it is still valid?
106 2016-06-21 06:41:27	0|sipa|i am only half awake and should shut up
107 2016-06-21 06:41:37	0|sipa|i may be confusing things
108 2016-06-21 06:42:12	0|jl2012|that's fine :)
109 2016-06-21 07:31:03	0|jl2012|i think all transactions including coinbase are subject to nLockTime and BIP113 rules
110 2016-06-21 08:10:34	0|GitHub149|[13bitcoin] 15laanwj closed pull request #8230: Fix LogPrint to LogPrintf (060.12...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8230
111 2016-06-21 08:10:34	0|GitHub3|13bitcoin/060.12 14ba61949 15TheLazieR Yip: Fix LogPrint to LogPrintf...
112 2016-06-21 08:10:34	0|GitHub3|[13bitcoin] 15laanwj pushed 2 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/44fdacc19f9f...f3eebcf5158f
113 2016-06-21 08:10:35	0|GitHub3|13bitcoin/060.12 14f3eebcf 15Wladimir J. van der Laan: Merge #8230: Fix LogPrint to LogPrintf...
114 2016-06-21 08:22:04	0|GitHub142|13bitcoin/06master 14bf9c70b 15TheLazieR Yip: Fix LogPrint to LogPrintf...
115 2016-06-21 08:22:04	0|GitHub142|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/bf9c70b1008e1eada462955a6420e79a7d2a8352
116 2016-06-21 08:24:39	0|GitHub112|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bf9c70b1008e...0d41d705c83d
117 2016-06-21 08:24:40	0|GitHub112|13bitcoin/06master 14fa32465 15MarcoFalke: [qa] fundrawtransaction: Create get_unspent()
118 2016-06-21 08:24:40	0|GitHub112|13bitcoin/06master 14fa8ce3b 15MarcoFalke: [qa] assert 'changePosition out of bounds'
119 2016-06-21 08:24:41	0|GitHub112|13bitcoin/06master 14fa3b379 15MarcoFalke: [qa] pull-tester: Fix assertion and check for run_parallel
120 2016-06-21 08:24:44	0|GitHub198|[13bitcoin] 15laanwj closed pull request #8216:  [qa] assert 'changePosition out of bounds'  (06master...06Mf1606-qaFundrawtransaction) 02https://github.com/bitcoin/bitcoin/pull/8216
121 2016-06-21 08:57:42	0|GitHub95|[13bitcoin] 15jonasschnelli opened pull request #8231: [Qt] fix a bug where the SplashScreen will not be hidden during startup (06master...062016/06/qt_min_fix) 02https://github.com/bitcoin/bitcoin/pull/8231
122 2016-06-21 09:13:05	0|MarcoFalke|./boost/config/posix_features.hpp:18:15: fatal error: 'unistd.h' file not found
123 2016-06-21 09:13:10	0|MarcoFalke|https://travis-ci.org/bitcoin/bitcoin/jobs/138877841
124 2016-06-21 09:14:17	0|wumpus|... huh. I didn't change anything there since last time, just re-triggered travis
125 2016-06-21 09:14:59	0|wumpus|looks like they performed a magic trick to make a basic system header disappear
126 2016-06-21 09:15:37	0|jonasschnelli|hmm... could that be related to the OSX SDK 10.11 update?
127 2016-06-21 09:15:59	0|jonasschnelli|I had similar issues when /home/travis/build/bitcoin/bitcoin/depends/SDKs/MacOSX10.11.sdk was not present
128 2016-06-21 09:16:05	0|wumpus|possibly, though it must be an intermittent problem
129 2016-06-21 09:16:40	0|wumpus|there's no error in the log about the sdk
130 2016-06-21 09:17:07	0|jonasschnelli|Wait!
131 2016-06-21 09:17:28	0|wumpus|also: protobuf compiles fine, you'd say it wouldn't get past that without basic C headers
132 2016-06-21 09:17:29	0|jonasschnelli|It tries to access "/home/travis/build/bitcoin/bitcoin/depends/SDKs/MacOSX10.11.sdk" but  export OSX_SDK=10.9?!
133 2016-06-21 09:17:50	0|wumpus|gah
134 2016-06-21 09:18:00	0|jonasschnelli|Why export OSX_SDK10.9?
135 2016-06-21 09:18:03	0|jonasschnelli|Maybe rebase the PR?!
136 2016-06-21 09:18:20	0|wumpus|I don't know, I haven't touched *anything* macosx related
137 2016-06-21 09:18:29	0|wumpus|I don't even change the dependencies, it's a silly test change
138 2016-06-21 09:18:37	0|jonasschnelli|The current master travis file (https://github.com/bitcoin/bitcoin/blob/master/.travis.yml) points clearly to 10.11
139 2016-06-21 09:20:10	0|MarcoFalke|There are issues with travis when .travis.yml changes in master but not in the pull
140 2016-06-21 09:20:15	0|jonasschnelli|wumpus MarcoFalke: I guess it's a temporary issue
141 2016-06-21 09:20:36	0|jonasschnelli|A commit from https://github.com/bitcoin/bitcoin/pull/8227 has a .travis file poining to 10.9 where depends expectes 10.11
142 2016-06-21 09:20:51	0|jonasschnelli|https://github.com/bitcoin/bitcoin/blob/bee60e3bc200be33146699380cbd8f9d9e72c372/.travis.yml
143 2016-06-21 09:21:10	0|jonasschnelli|Rebase should to the thing.
144 2016-06-21 09:21:51	0|MarcoFalke|I guess travis will use the .travis.yml from the pull to set up the vm but uses the cache from master to build
145 2016-06-21 09:22:01	0|GitHub69|[13bitcoin] 15mcccs opened pull request #8232: Add IRC link to README.md (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8232
146 2016-06-21 09:22:42	0|MarcoFalke|or just merge into master :) if we are confident that the pull is what we want
147 2016-06-21 09:22:51	0|MarcoFalke|it is still running for 30 min
148 2016-06-21 09:23:00	0|MarcoFalke|prob communication overhead with wine?
149 2016-06-21 09:23:38	0|MarcoFalke|but when we get rid of java-blocktester, we need to turn on rpc test for windows in any case
150 2016-06-21 09:23:43	0|wumpus|I'm confident it is what we want, but I'm afraid of making travis more flakey that's why I'm testing on the pull insted of in master
151 2016-06-21 09:24:20	0|wumpus|the last thing we want is a flakey travis in the stabilization phase of a release
152 2016-06-21 09:24:23	0|wumpus|so I'd prefer to merge it later
153 2016-06-21 09:24:51	0|wumpus|also with cfields_ not here to solve our build system/travis howlers :-)
154 2016-06-21 09:25:26	0|wumpus|yes, wine clearly has some overhead, it's not clear where and why
155 2016-06-21 09:25:40	0|wumpus|maybe it's just the bitcoind startup overhead, maybe it's some other delay introduced somewhere
156 2016-06-21 09:25:59	0|wumpus|(e.g. a polling loop in the test that either connects immediately, otherwise waits a few seconds before trying again)
157 2016-06-21 09:26:33	0|wumpus|java-blocktester is a worry after the 0.13 release
158 2016-06-21 09:31:07	0|wumpus|re-based the pull to master
159 2016-06-21 12:35:11	0|GitHub137|[13bitcoin] 15laanwj opened pull request #8233: Mention Linux ARM executables in release process and notes (06master...062016_06_release_process_arm) 02https://github.com/bitcoin/bitcoin/pull/8233
160 2016-06-21 12:38:15	0|sipa|wumpus: there is the abcore project, which uses the arch or debian built arm binaries for bitcoin core on android
161 2016-06-21 12:38:42	0|sipa|wumpus: they cheat, by copying the libstc++ and a few more files from those distributions as well
162 2016-06-21 12:39:07	0|sipa|but still, it seems common arm binaries seem to work with such hacks on android
163 2016-06-21 12:39:53	0|wumpus|ok, well we'll have to see, I just want to warn people to not get their hopes up that it will work out of the box with android
164 2016-06-21 12:40:22	0|sipa|yes, warning that it's expiremental is obviously needed
165 2016-06-21 12:40:26	0|wumpus|probably if you 'disguise' your android as a debian box by providing the preerquisite libraries and /etc/ files you can get it to work
166 2016-06-21 12:41:47	0|sipa|right, i'm not suggesting you change the text
167 2016-06-21 12:42:08	0|wumpus|I'm fine with changing the text, just wouldn't know how to incorporate this without making it too technical
168 2016-06-21 12:42:33	0|sipa|but maybe you were unaware of the approach they used
169 2016-06-21 12:42:39	0|sipa|agree
170 2016-06-21 12:42:44	0|sipa|just giving some background
171 2016-06-21 12:43:02	0|wumpus|yes, thanks for the background, I didn't know they emulalated
172 2016-06-21 12:44:13	0|wumpus|"expected to work on Android." -> maybe add as-is in there?
173 2016-06-21 12:44:23	0|wumpus|or "out of the box"
174 2016-06-21 12:44:42	0|sipa|sounds good
175 2016-06-21 13:02:37	0|btcdrak|abcore https://github.com/greenaddress/abcore
176 2016-06-21 13:03:44	0|wumpus|thanks btcdrak
177 2016-06-21 13:14:42	0|wumpus|what is the locale en_US? it is one of the languages being added on transifex, but it lokos like Spanish, that can't be correct
178 2016-06-21 13:15:05	0|instagibbs|US english?
179 2016-06-21 13:15:07	0|pigeons|"american" english.
180 2016-06-21 13:15:35	0|wumpus|https://www.transifex.com/bitcoin/bitcoin/viewstrings/#en_US/qt-translation-013x/86275741
181 2016-06-21 13:16:23	0|wumpus|well it's not English so I'm going to delete it
182 2016-06-21 13:19:42	0|wumpus|wish we had someone with language knowledge actually watching these things
183 2016-06-21 13:31:30	0|GitHub33|[13bitcoin] 15laanwj opened pull request #8234: Periodic transifex update (06master...062016_06_transifex_update) 02https://github.com/bitcoin/bitcoin/pull/8234
184 2016-06-21 13:44:24	0|wumpus|per-function address space randomization, this looks interesting https://github.com/immunant/selfrando
185 2016-06-21 14:27:32	0|wumpus|pretty clever, it just uses compiler's -ffunction-sections to generate the necessary ELF data, then slices the program up at load time based onthat
186 2016-06-21 14:32:43	0|GitHub30|13bitcoin/06master 14e5a680d 15fanquake: [Doc] Update OS X build notes for 10.11 SDK
187 2016-06-21 14:32:43	0|GitHub30|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0d41d705c83d...8ccdac1f5f77
188 2016-06-21 14:32:44	0|GitHub30|13bitcoin/06master 148ccdac1 15Wladimir J. van der Laan: Merge #8229: [Doc] Update OS X build notes for 10.11 SDK...
189 2016-06-21 14:32:53	0|GitHub127|[13bitcoin] 15laanwj closed pull request #8229: [Doc] Update OS X build notes for 10.11 SDK (06master...06osx-build-notes-new) 02https://github.com/bitcoin/bitcoin/pull/8229
190 2016-06-21 18:07:48	0|JackH|!seen maaku
191 2016-06-21 18:07:49	0|gribble|maaku was last seen in #bitcoin-core-dev 6 weeks, 4 days, 1 hour, 19 minutes, and 54 seconds ago: <maaku> yeah but still, we should try not to add to the noise
192 2016-06-21 20:26:50	0|GitHub4|[13bitcoin] 15TheBlueMatt opened pull request #8235: Compact Block Tweaks (06master...06cmpctblock) 02https://github.com/bitcoin/bitcoin/pull/8235