1 2016-10-26 03:20:52	0|luke-jr|jonasschnelli: are you sure we can get a corrupt db from kill? that would be a pretty serious bug..
  2 2016-10-26 03:21:37	0|luke-jr|I mean, a non-trivial part of the *purpose* of a db engine is to prevent corruption
  3 2016-10-26 03:21:59	0|luke-jr|I know we have had some issues with literal power failures, but it seems absurd for kill to corrupt things
  4 2016-10-26 03:24:23	0|gmaxwell|we shouldn't be, it would be a serious bug.  During IBD unclean poweroffs will pretty reliable corrupt things because we skip syncing, but otherwise it shouldn't.
  5 2016-10-26 03:24:30	0|BlueMatt|sipa: i think i got all your nits on #9014, though some of your comments (from 15 minutes ago) were on outdated code (how did you do that? I pushed many hours ago)
  6 2016-10-26 03:27:16	0|sipa|BlueMatt: i was reviewing commit by commit
  7 2016-10-26 03:27:31	0|BlueMatt|oh, you missed some SQUASHME commits :/
  8 2016-10-26 03:28:04	0|sipa|no, i just wasn't looking at them at the time
  9 2016-10-26 03:28:27	0|BlueMatt|sipa: when you get to a stopping point, i can just squash and force-push...jeremy was happy with where it was and i assume only you and jeremy have looked at it
 10 2016-10-26 03:28:43	0|sipa|BlueMatt: i'm fine with you squashing now
 11 2016-10-26 03:28:47	0|BlueMatt|ok
 12 2016-10-26 03:29:00	0|luke-jr|gmaxwell: context https://github.com/bitcoin/bitcoin/issues/9001 fwiw
 13 2016-10-26 03:29:46	0|luke-jr|inclined to ask him if he can provide remote access for debugging, but not sure there's a need if jonasschnelli has a way to reproduce something similar already
 14 2016-10-26 03:30:22	0|jeremyrubin|I'm happy! A+ BlueMatt!
 15 2016-10-26 03:32:33	0|BlueMatt|ok, force-pushed
 16 2016-10-26 03:33:28	0|BlueMatt|sipa: see https://github.com/bitcoin/bitcoin/pull/9014#discussion_r85034371
 17 2016-10-26 03:33:30	0|BlueMatt|anyway, bedtime for me
 18 2016-10-26 06:41:06	0|gmaxwell|interesting, slushpool just failed to take a pretty attractive CFPF transaction set that my node would have mined.
 19 2016-10-26 07:24:37	0|jonasschnelli|Luke-Jr: my tests showed my that sudden shutdowns (power off situation) will result in corrupt databases (=require for re-sync) during IBD
 20 2016-10-26 07:24:55	0|luke-jr|jonasschnelli: quite different from a kill
 21 2016-10-26 07:25:17	0|jonasschnelli|kill is a flexible term. :)
 22 2016-10-26 07:25:27	0|jonasschnelli|./kill is more specific
 23 2016-10-26 07:26:54	0|jonasschnelli|I ran into different corruptions on Linux/Debian 1) when running out of memory 2) random corruption on USB device, 3) on OSX when force shutdown a process (lldb), 4) Window 10 in VMWare sudden power off
 24 2016-10-26 07:27:11	0|jonasschnelli|All during IBD
 25 2016-10-26 08:06:53	0|GitHub193|13bitcoin/06master 14339c4b6 15Cory Fields: release: bump required osx version to 10.8. Credit jonasschnelli....
 26 2016-10-26 08:06:53	0|GitHub193|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9bdf5269f886...54259370ae93
 27 2016-10-26 08:06:54	0|GitHub193|13bitcoin/06master 145425937 15Wladimir J. van der Laan: Merge #9015: release: bump required osx version to 10.8. (jonasschnelli)...
 28 2016-10-26 08:07:08	0|GitHub90|[13bitcoin] 15laanwj closed pull request #9015: release: bump required osx version to 10.8. (jonasschnelli) (06master...06osx-disable107) 02https://github.com/bitcoin/bitcoin/pull/9015
 29 2016-10-26 08:07:48	0|GitHub60|13bitcoin/060.13 14a32d7c2 15Cory Fields: release: bump required osx version to 10.8. Credit jonasschnelli....
 30 2016-10-26 08:07:48	0|GitHub60|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/a32d7c23fc0eedebe3579edb5d488a4c63b67b70
 31 2016-10-26 08:16:31	0|blur3d|Hey Core. Just a thank you message for your all your work. Keep doing what you guys are doing. Ignore the outside pressures, and keep bitcoin from becoming centeralised. All of the fear mongering ignores the simple fact that the bitcoin network would be near impossible to replicate from scratch. Any transitional periods may have some discomfort, but compromising the network for short term bandaides is for fools.
 32 2016-10-26 08:20:47	0|rabidus_|i'll sign that message also.
 33 2016-10-26 08:45:01	0|midnightmagic|are there any plans to stuff some detached sigs into the repo for v0.13.1rc3..?
 34 2016-10-26 09:02:24	0|btcdrak|blur3d: thank you for saying.
 35 2016-10-26 09:02:51	0|btcdrak|midnightmagic: there are no plans for a binary for 0.13.1rc3
 36 2016-10-26 09:03:07	0|btcdrak|so there is no point building gitian sigs for rc3
 37 2016-10-26 09:04:08	0|gmaxwell|some people build sigs for rc3 to allow comparison, etc.
 38 2016-10-26 09:04:26	0|gmaxwell|I hope in the future we manage to make it so unmodified rc->final doesn't change the gitian sigs.
 39 2016-10-26 09:09:47	0|jonasschnelli|I guess midnightmagic is refering to code-signature detatched sigs (OSX/WIN) these would only be required if there would be binary releases (which we won't do for rc3 IMO)
 40 2016-10-26 09:10:54	0|luke-jr|not sure why rc3 was even tagged :p
 41 2016-10-26 09:16:00	0|gmaxwell|Causes more people to test.
 42 2016-10-26 09:16:05	0|gmaxwell|and update their tests.
 43 2016-10-26 09:16:19	0|timothy|gmaxwell: how? you still have to change the version
 44 2016-10-26 09:16:52	0|gmaxwell|timothy: the version in the software is already 0.13.1. There is only some build automation that inserts the git-tag.
 45 2016-10-26 09:17:06	0|timothy|oh ok
 46 2016-10-26 09:17:20	0|timothy|I tough you still have rc3 in version name
 47 2016-10-26 09:17:24	0|gmaxwell|timothy: but for tagged builds (e.g. releases) we could display the hash of the binary instead of setting the tag, or some hash of the source instead.
 48 2016-10-26 09:17:38	0|gmaxwell|and then the binary would really be identical.
 49 2016-10-26 09:17:51	0|gmaxwell|timothy: we try to change nothing. even really changing the tag implies some small risk.
 50 2016-10-26 09:18:11	0|timothy|I agree :)
 51 2016-10-26 09:18:37	0|wumpus|blur3d: thank you
 52 2016-10-26 09:18:45	0|gmaxwell|(as there are processor design flaws that are alignment sensitive; a different string size could change offsets in the build, and mean that a release could be produced which consistenty crashed on a small set of hardware that tested fine with the rc)
 53 2016-10-26 09:20:02	0|gmaxwell|firefox bug tracker is full of nightmare fuel: https://bugzilla.mozilla.org/show_bug.cgi?id=1281759
 54 2016-10-26 09:20:36	0|gmaxwell|"This adds some 4-byte NOPs to this IC stub on x86 if CPU family is 20 and model is 0-2. According to AMD engineers, limiting the number of branches per cache line might help, so I'm hopeful this will work."
 55 2016-10-26 09:20:51	0|luke-jr|gmaxwell: if we have such issues, I suspect we have bigger problems than changing the version number? :p
 56 2016-10-26 09:21:36	0|wumpus|gmaxwell: that sounds like GPU compiler design :)
 57 2016-10-26 09:21:48	0|wumpus|it doesn't work? add moar nops
 58 2016-10-26 09:22:26	0|gmaxwell|there are a bunch of these -- amd seems to be especially guilty.  branch predictor bugs where under particular sets of instructions it'll just ignore a jmp.
 59 2016-10-26 09:22:52	0|luke-jr|:|
 60 2016-10-26 09:23:06	0|gmaxwell|and then mozilla puts out a new update that does nothing but change the PGO weights around a bit and then the crashes go away.
 61 2016-10-26 09:23:16	0|wumpus|oh yes I'm sure the abuse of branch prediction caches to subvert ASLR (locally) is just the beginning, if people are really going to look into those bugs deeply I'm sure some are exploitable
 62 2016-10-26 09:23:45	0|gmaxwell|then another update to change someting insignificant... and all those hosts are crashing again.
 63 2016-10-26 09:24:10	0|wumpus|(e.g. make it skip the jmp that rejects the authentication)
 64 2016-10-26 09:27:24	0|gmaxwell|hmmm
 65 2016-10-26 09:27:57	0|luke-jr|wumpus: would you entertain support for TQt btw? or is that something I'd need to maintain out of tree?
 66 2016-10-26 09:28:04	0|gmaxwell|Se, Greg ate d witness.
 67 2016-10-26 09:28:33	0|gmaxwell|I never knew I named that after myself.
 68 2016-10-26 09:28:38	0|timothy|gmaxwell: is arm better? :P
 69 2016-10-26 09:28:54	0|wumpus|luke-jr: TQT?
 70 2016-10-26 09:29:02	0|luke-jr|wumpus: Qt3 fork
 71 2016-10-26 09:29:16	0|wumpus|timothy: unfortunately, no, though the specific bugs are different
 72 2016-10-26 09:29:28	0|wumpus|(except for rowhammer, everyone loves rowhammer)
 73 2016-10-26 09:29:33	0|luke-jr|with stuff like thread support, and maintained by TDE
 74 2016-10-26 09:29:58	0|wumpus|luke-jr: why would you fork qt3? that seems ancient
 75 2016-10-26 09:30:00	0|gmaxwell|timothy: no. beyond actual silicon flaws it's hard to find ANY arm board that can handle being run full out without becoming unstable. None of the boards are built for actual usage.
 76 2016-10-26 09:30:29	0|luke-jr|wumpus: originally, because KDE 4 went downhill, and they wanted to maintain KDE 3
 77 2016-10-26 09:30:40	0|gmaxwell|Most reliable I've used has been the novena, though without a active fan on it, the libsecp256k1 tests will still make it hit a thermal emergency cutoff.
 78 2016-10-26 09:31:15	0|timothy|I tried to have a full node on a banana pi. it crashes often :P
 79 2016-10-26 09:31:23	0|wumpus|I've good experiences with cubox-i's, seems they got the cooling right
 80 2016-10-26 09:32:04	0|wumpus|imx6 is also supported in mainline linux + the graphics drivers were partially written by me :)
 81 2016-10-26 09:32:29	0|wumpus|32 bit, though
 82 2016-10-26 09:32:38	0|gmaxwell|imx family ends up in a lot of industrial control stuff too, probably less likely than armcores that are only used in smartphones to be buggy.
 83 2016-10-26 09:33:38	0|wumpus|yes, even in planes, you'd hope they take stabilty seriously :)
 84 2016-10-26 09:34:31	0|luke-jr|I'd kinda hope the planes don't rely on standard CPU stability
 85 2016-10-26 09:35:59	0|wumpus|not only, for any vehicle control system, there's always fallbacks
 86 2016-10-26 09:36:19	0|tulip|luke-jr: there's documentation about plane control out there, they seem to be nominally dual or triple redundant, even going so far as to have quorum between multiple devices. you can commonly get CPUs designed for doing medical control now which do lock stepped ARM cores and a comparator between them.
 87 2016-10-26 09:36:41	0|luke-jr|tulip: yeah, those would be the *non-*standard CPUs :p
 88 2016-10-26 09:37:51	0|wumpus|I'm more worried about cars in that regard
 89 2016-10-26 09:38:42	0|gmaxwell|luke-jr: lockstep cpus are a basically off the shelf part now,  ti hercules, for example. It's inexpensive too, though not very fast.
 90 2016-10-26 09:40:03	0|rabidus_|e
 91 2016-10-26 09:42:16	0|wumpus|luke-jr: but re: qt3, I think it would be a shame to introduce that just now that everything is converging on qt5
 92 2016-10-26 09:42:44	0|luke-jr|Talos ships with TDE? :P
 93 2016-10-26 09:43:11	0|luke-jr|but yeah, I kindof agree
 94 2016-10-26 09:45:33	0|wumpus|and ideally, focusing on a single version means that less effort has to go into compatiblity and more can to improving the experience for users
 95 2016-10-26 09:52:58	0|wumpus|why does Talos ship with TDE?
 96 2016-10-26 09:53:15	0|luke-jr|common lead guy
 97 2016-10-26 09:54:47	0|wumpus|right
 98 2016-10-26 09:57:28	0|luke-jr|☺
 99 2016-10-26 10:03:05	0|GitHub119|[13bitcoin] 15laanwj opened pull request #9020: rpc: Remove invalid explanation from wallet fee message (06master...062016_10_wallet_message) 02https://github.com/bitcoin/bitcoin/pull/9020
100 2016-10-26 10:05:16	0|wumpus|instagibbs: re: #9016 are you sure that problem will always be logged to the debug log when a transaction coming through RPC is rejected? If not, pointing the user to debug.log could result in a wild goose chase
101 2016-10-26 10:05:53	0|wumpus|we did make the transaction validation a lot less noisy in recent versions
102 2016-10-26 10:06:23	0|GitHub64|[13bitcoin] 15gzuser01 opened pull request #9021: zetacoin 0.13 (06master...06gzuser01-patch-1) 02https://github.com/bitcoin/bitcoin/pull/9021
103 2016-10-26 10:06:35	0|gmaxwell|time to close? ^
104 2016-10-26 10:06:36	0|gmaxwell|5
105 2016-10-26 10:06:38	0|gmaxwell|4
106 2016-10-26 10:06:40	0|gmaxwell|3
107 2016-10-26 10:06:42	0|gmaxwell|2
108 2016-10-26 10:06:44	0|gmaxwell|1
109 2016-10-26 10:06:46	0|wumpus|the bot is slow
110 2016-10-26 10:06:48	0|GitHub60|[13bitcoin] 15laanwj closed pull request #9021: zetacoin 0.13 (06master...06gzuser01-patch-1) 02https://github.com/bitcoin/bitcoin/pull/9021
111 2016-10-26 10:06:56	0|gmaxwell|close enough.
112 2016-10-26 10:07:48	0|GitHub197|[13bitcoin] 15fanquake opened pull request #9022: Update release notes to mention dropping OS X 10.7 support (060.13...060-13-1-osx-notes) 02https://github.com/bitcoin/bitcoin/pull/9022
113 2016-10-26 10:45:10	0|gmaxwell|so interesting, last block (by bitclub network) had 866 transactions,  prior blocks (all same max size)-- 1942, 1422, 2215, 2145, 1905..  I wonder why bitclub's transactions were so much larger?
114 2016-10-26 10:45:43	0|gmaxwell|they also collect a lot more fees.
115 2016-10-26 10:48:40	0|gmaxwell|1.239 BTC vs, .513 .839 .723 .689
116 2016-10-26 10:51:46	0|gmaxwell|I see it earlier too. antpool mined a block with .714 btc in fees in 2288 transactions, then bitclub with 1783 transactions but .950 btc in fees.
117 2016-10-26 10:51:51	0|wumpus|interesting, a custom strategy to maximize fees?
118 2016-10-26 10:53:09	0|gmaxwell|well I know that earlier both slush and antpool failed to mine a fairly attractive CPFP (where the parent had ample fees for relay).. the bitclub picked it up.
119 2016-10-26 10:53:19	0|gmaxwell|so it ~might~ be 0.13 vs not.
120 2016-10-26 11:01:14	0|gmaxwell|right now my GBT returns 1.03 btc in fees for a 1MB block.
121 2016-10-26 11:01:51	0|gmaxwell|hm. if it weren't 4am I'd hack update tip to do a gbt and log the total fee amount from the result before processing a block.
122 2016-10-26 11:03:35	0|gmaxwell|in any case if 435976 has less than 1.06 btc in fees, something is up.
123 2016-10-26 11:11:10	0|GitHub58|[13bitcoin] 15jnewbery opened pull request #9023: Add logging to bitcoin-util-test.py (06master...06btutiltestlogging) 02https://github.com/bitcoin/bitcoin/pull/9023
124 2016-10-26 11:11:46	0|gmaxwell|logging now,
125 2016-10-26 11:11:48	0|gmaxwell|Wed Oct 26 11:10:29 UTC 2016 435975 109856937
126 2016-10-26 11:11:58	0|gmaxwell|1477480260 435976 99407716
127 2016-10-26 11:14:46	0|gmaxwell|so 435976 could hav collected 1.09 by my observation, collected 0.953 instead (not that much worse), and immediately after it the next block could connect 0.994 ... pretty good.
128 2016-10-26 11:14:54	0|gmaxwell|Take that mining is unstable people. :P
129 2016-10-26 11:15:16	0|gmaxwell|also bc.i is like seriously behind.
130 2016-10-26 11:15:48	0|gmaxwell|oops I was looking at 435975 there.
131 2016-10-26 11:17:21	0|gmaxwell|also wtf, getblock needs a "true" for its verbose argument, while getrawtransaction needs a "1".
132 2016-10-26 11:17:42	0|gmaxwell|okay 435976 took 1.003 which is pretty close to what I saw right before.
133 2016-10-26 11:20:42	0|GitHub9|13bitcoin/06master 1404c1c15 15Wladimir J. van der Laan: rpc: Remove invalid explanation from wallet fee message
134 2016-10-26 11:20:42	0|GitHub9|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/54259370ae93...86f9e3dbba41
135 2016-10-26 11:20:43	0|GitHub9|13bitcoin/06master 1486f9e3d 15Wladimir J. van der Laan: Merge #9020: rpc: Remove invalid explanation from wallet fee message...
136 2016-10-26 11:20:57	0|GitHub162|[13bitcoin] 15laanwj closed pull request #9020: rpc: Remove invalid explanation from wallet fee message (06master...062016_10_wallet_message) 02https://github.com/bitcoin/bitcoin/pull/9020
137 2016-10-26 11:24:47	0|wumpus|that's slightly curious, maybe getrawtransaction author expected an 'even more verbose' format at some point and pass '2'? it'd have made sense for `getblock` and https://github.com/bitcoin/bitcoin/pull/8704
138 2016-10-26 11:25:35	0|wumpus|getblock \"hash\" ( verbose ) ( extraVerbose )  is a bit silly as APIs go
139 2016-10-26 11:25:44	0|wumpus|but it'd better have been called verbosityLevel then
140 2016-10-26 11:26:52	0|luke-jr|IIRC originally there was a bunch of flags on an Object controlling verbosity
141 2016-10-26 11:27:12	0|wumpus|really? seems like a reversion then
142 2016-10-26 11:27:55	0|wumpus|in any case the RPC could be trivially changed to accept 'true' for '1' too
143 2016-10-26 11:28:18	0|wumpus|(and false for 0)
144 2016-10-26 11:28:22	0|gmaxwell|yea, that might be reasonable.  I've notied this true/1 thing before and thought I was nuts. :)
145 2016-10-26 11:28:25	0|gmaxwell|1477480364 435976 101621240
146 2016-10-26 11:28:28	0|gmaxwell|1477481079 435976 108481648
147 2016-10-26 11:28:30	0|gmaxwell|435977 takes 1.01339 btc in fees.
148 2016-10-26 11:28:33	0|gmaxwell|1477481089 435977 94256908
149 2016-10-26 11:29:41	0|gmaxwell|so either miner at 435977 has 715 seconds of latency from gbt->mining, or their transaction selection is less optimal than 0.13.1 on my desktop with defaults + weight=4m.
150 2016-10-26 11:31:02	0|luke-jr|gmaxwell: or they're being paid out of band as most big pools seem to now
151 2016-10-26 11:31:33	0|gmaxwell|I looked, don't appear to have a wad of free transactions.
152 2016-10-26 11:32:02	0|luke-jr|hm
153 2016-10-26 11:32:24	0|gmaxwell|oh well I know why that miner's selection would be suboptimal.. 0.12.x code (they claim to run BU)
154 2016-10-26 11:40:22	0|luke-jr|XD
155 2016-10-26 11:43:14	0|wumpus|wasn't far of the mark with misconfigured/weird software hypothesis
156 2016-10-26 12:11:48	0|GitHub151|[13bitcoin] 15jnewbery opened pull request #9025: getrawtransaction should take a bool for verbose (06master...06getrawtransbool) 02https://github.com/bitcoin/bitcoin/pull/9025
157 2016-10-26 13:59:39	0|adiabat|Hi, I have an admittedly nit-picky request for the rpc calls
158 2016-10-26 13:59:52	0|adiabat|could we put "weight" in the getrawtransaction return?
159 2016-10-26 14:00:40	0|adiabat|right now getrawtransaction returns "size" and "vsize", while getblock returns "strippedsize", "size", and "weight"
160 2016-10-26 14:09:03	0|adiabat|the "true" vs "1" sillyness in rpc calls just reminded me.  If you want the "weight" of a transaction you have to calculate it from size and vsize.
161 2016-10-26 14:11:26	0|adiabat|also I may be missing something but I don't think verbosity does anything to the getblock command
162 2016-10-26 14:11:34	0|jonasschnelli|adiabat: This would be easy to implement... maybe give it a try?!
163 2016-10-26 14:11:38	0|jonasschnelli|Or open an issue on github
164 2016-10-26 14:11:49	0|jonasschnelli|You need to add a call to GetTransactionWeight()
165 2016-10-26 14:12:06	0|jonasschnelli|somewhere near entry.push_back(Pair("vsize", (int)::GetVirtualTransactionSize(tx)));
166 2016-10-26 14:12:16	0|adiabat|ok, sure
167 2016-10-26 15:30:43	0|sipa|adiabat: originally i wanted weight to be purely an internal thing, and have vsize be the exposed value
168 2016-10-26 16:00:43	0|adiabat|sipa: Hmm ok, should we put vsize in the block info instead?
169 2016-10-26 16:01:37	0|sipa|adiabat: nah, weight is better in any case
170 2016-10-26 16:02:00	0|sipa|i'm just mentioning it to explain why weight isn't in gettransaction
171 2016-10-26 16:02:41	0|adiabat|OK I'll look at putting weight in the getrawtransaction return data
172 2016-10-26 16:03:08	0|adiabat|also the 'verbosity' on getblock, not sure what that does... if it does nothing, maybe can get rid of it
173 2016-10-26 16:03:39	0|sipa|it is about returning 1) just txids 2) full tx info 3) full tx data
174 2016-10-26 16:14:39	0|btcdrak|wumpus: I have found a bug in univalue JSON export, where do I submit the patch?
175 2016-10-26 16:27:29	0|jtimon|quick question on the blocksigning stuff, what flags should I use for block signing (ie #define BLOCK_SIGN_SCRIPT_FLAGS (SCRIPT_VERIFY_P2SH|SCRIPT_VERIFY_WITNESS) is what I have for now)
176 2016-10-26 16:28:09	0|jtimon|some obviously don't make sense like cltv and csv
177 2016-10-26 16:29:21	0|jtimon|for others like SCRIPT_VERIFY_MINIMALIF or SCRIPT_VERIFY_NULLFAIL feels like why not?
178 2016-10-26 16:50:12	0|wumpus|btcdrak: upstream to jgarzik/univalue, and we can merge it to bitcoin-core/univalue if that takes too long / is urgent
179 2016-10-26 17:17:02	0|jtimon|what's the opposite operation of ParseHex() ?
180 2016-10-26 17:19:07	0|sipa|HexStr
181 2016-10-26 17:19:08	0|Chris_Stewart_5|HexStr?
182 2016-10-26 17:20:17	0|jtimon|thanks!
183 2016-10-26 17:21:09	0|jtimon|they were on the same file *hides*
184 2016-10-26 17:25:20	0|sipa|hiding in plain sight, as they say
185 2016-10-26 17:39:17	0|btcdrak|wumpus: well it isnt urgent. Problem is it will need to be merged into Core along at the same time as a tweak of some test cases in the test/data/*.json files.
186 2016-10-26 18:31:13	0|GitHub114|[13bitcoin] 15sdaftuar opened pull request #9026: Fix handling of invalid compact blocks (06master...06fix-invalidcb-handling) 02https://github.com/bitcoin/bitcoin/pull/9026
187 2016-10-26 19:29:31	0|btcdrak|Please review: "Add segwit upgrade guide" https://github.com/bitcoin-core/bitcoincore.org/pull/240
188 2016-10-26 19:48:37	0|michagogo|btcdrak: there seem to be a few things that look like they should be links that are missing the links
189 2016-10-26 19:48:48	0|michagogo|Things like [some text][]
190 2016-10-26 19:49:17	0|michagogo|Is that intentional?
191 2016-10-26 19:49:27	0|michagogo|I don't know enough about markdown
192 2016-10-26 19:53:48	0|btcdrak|michagogo: they are in the references.md include near the top
193 2016-10-26 19:56:58	0|michagogo|btcdrak: I see that for the BIPs
194 2016-10-26 19:57:13	0|michagogo|But it looks like there are two missing
195 2016-10-26 19:57:18	0|michagogo|Or, wait a sec
196 2016-10-26 19:57:25	0|btcdrak|well please comment on the PR
197 2016-10-26 19:57:50	0|michagogo|No, I found them
198 2016-10-26 19:58:23	0|michagogo|Like I said, I'm not really familiar with advanced markdown and didn't want to make a stupid comment :P
199 2016-10-26 19:58:59	0|michagogo|So if there's a reference, you can do [text][] if you want the link text to match the reference?
200 2016-10-26 19:59:15	0|michagogo|[text1][text2] is just if it differs?
201 2016-10-26 20:00:27	0|btcdrak|yes
202 2016-10-26 20:01:25	0|michagogo|I see.
203 2016-10-26 21:27:40	0|gmaxwell|uh revealing errors.
204 2016-10-26 21:27:55	0|gmaxwell|luke-jr: https://btc.com/000000000000000002eb076392586c5b034ba3826ff6adb459bc57db4191943e  reveals that eligius is just hardcoing versions in a dangerous way.
205 2016-10-26 21:44:58	0|gmaxwell|Anyone feel like extracting the amount of fees per block recently?  Here is what the node on my desktop would have made blocks for: http://0bin.net/paste/y4kPmRYLiiuN5gTN#kpX3urA92l6Ggly0MgcThd9VHzNSKP7WZw6ce6bq5rI
206 2016-10-26 21:45:49	0|btcdrak|I extracted this today
207 2016-10-26 21:45:51	0|btcdrak|https://docs.google.com/spreadsheets/d/1JlV5_3q251V7wJM87MH89kT_j8A26b7qM-ThYn2p65g/edit#gid=0
208 2016-10-26 21:49:18	0|morcos|gmaxwell: i actually have a long running node that has been calculating that but only considering txs it actually saw in its mempool.   got to run now.. but can get you the results form that later
209 2016-10-26 21:49:27	0|morcos|don't think its that different, thank goodness
210 2016-10-26 21:54:31	0|gmaxwell|btcdrak: can you merge in my data where it overlaps and show the difference?
211 2016-10-26 21:59:55	0|btcdrak|gmaxwell: done
212 2016-10-26 22:52:43	0|phantomcircuit|btcdrak: the average transaction sizes are really high
213 2016-10-26 23:53:47	0|gmaxwell|wow, gbminers block 436404 failed to collect .246 btc in fees.
214 2016-10-26 23:55:16	0|gmaxwell|bitclub is the only miner that beat my node in these observations
215 2016-10-26 23:55:25	0|gmaxwell|and only slightly
216 2016-10-26 23:59:34	0|gmaxwell|average amount of missed fees by 'block source':
217 2016-10-26 23:59:37	0|gmaxwell|BitClub -0.00241024
218 2016-10-26 23:59:37	0|gmaxwell|BitFury 0.0182999
219 2016-10-26 23:59:37	0|gmaxwell|BTC.com 0.0286225
220 2016-10-26 23:59:37	0|gmaxwell|HaoBTC 0.0291582
221 2016-10-26 23:59:39	0|gmaxwell|SlushPool 0.0402993
222 2016-10-26 23:59:42	0|gmaxwell|BTCC 0.0504893
223 2016-10-26 23:59:44	0|gmaxwell|AntPool 0.0606765
224 2016-10-26 23:59:47	0|gmaxwell|F2Pool 0.080212
225 2016-10-26 23:59:49	0|gmaxwell|ViaBTC 0.0886112
226 2016-10-26 23:59:52	0|gmaxwell|Bitcoin.com 0.106677
227 2016-10-26 23:59:54	0|gmaxwell|BW.COM 0.125634
228 2016-10-26 23:59:57	0|gmaxwell|Unknown 0.166871
229 2016-10-26 23:59:59	0|gmaxwell|GBMiners 0.246336