1 2017-11-29 00:01:15	0|promag|my point is that there should be one line for each file
  2 2017-11-29 00:02:39	0|promag|and:
  3 2017-11-29 00:02:48	0|meshcollider|mmm yeah, ok
  4 2017-11-29 00:02:50	0|promag|* wallets/db.log; since 0.16.0 for fresh installs
  5 2017-11-29 00:03:04	0|meshcollider|Yep that sounds sensible
  6 2017-11-29 00:03:05	0|meshcollider|Thanks :)
  7 2017-11-29 00:03:13	0|promag|err, don't know, I'm bad at copy..
  8 2017-11-29 00:03:29	0|promag|np
  9 2017-11-29 00:11:20	0|bitcoin-git|[13bitcoin] 15MoneyMakerLTD opened pull request #11784: Update README.md (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11784
 10 2017-11-29 00:19:08	0|promag|fanquake: 11784 why?
 11 2017-11-29 00:20:03	0|fanquake|progmag it's replacing the readme with one line about some money maker coin?
 12 2017-11-29 00:21:14	0|meshcollider|heh trivial ACK to that, sounds like a necessary upgrade
 13 2017-11-29 00:22:08	0|promag|fanquake: sounds legit
 14 2017-11-29 00:22:47	0|promag|meshcollider: files.md is almost sorted, wallets/* should be on the bottom?
 15 2017-11-29 00:23:55	0|meshcollider|oops that should be database/* not wallets/* lol
 16 2017-11-29 00:23:57	0|meshcollider|nice catch
 17 2017-11-29 00:24:52	0|promag|that too
 18 2017-11-29 00:25:55	0|promag|line 10 should move to line 18?
 19 2017-11-29 00:26:17	0|promag|line 12 too
 20 2017-11-29 00:30:56	0|meshcollider|done
 21 2017-11-29 00:39:40	0|promag|meshcollider: wallets/database/*: BDB database environment; only used for wallet since 0.8.0; since 0.16.0
 22 2017-11-29 00:39:53	0|promag|should be wallets/database/*: BDB database environment; only used for wallet since 0.16.0?
 23 2017-11-29 00:46:52	0|luke-jr|new wallets*
 24 2017-11-29 00:52:31	0|promag|that too
 25 2017-11-29 02:09:01	0|mlz|Hello Core devs, 10000!!! Congratulations and thank you for all your hard work, the price didn't happen without your help! So thank you!  :)
 26 2017-11-29 04:00:08	0|Mahesh|Mahesh/dchsjzumck/web/886659427
 27 2017-11-29 05:26:43	0|bitcoin-git|[13bitcoin] 15vii opened pull request #11785: Prevent file-descriptor exhaustion from RPC layer (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11785
 28 2017-11-29 08:20:52	0|wumpus|jonasschnelli: have tried it on odroid C2, was a bit disappointed at the perfomrance - I don't have a XU4
 29 2017-11-29 08:22:03	0|wumpus|jonasschnelli: do have a i.mx8 evaluation board prototype, which seems to be really fast, but don't really dare run a bitcoind sync on it, afraid it will overheat
 30 2017-11-29 08:28:21	0|wumpus|regarding storage on the odroid C2 there's not that much options, only USB2.0, and no SATA
 31 2017-11-29 08:29:52	0|wumpus|I eventually used network block device and a SSD w/ the 1GB ethernet, but that's kind of cheating, and it still wasn't really fast, I didn't have time to investigate further
 32 2017-11-29 08:30:08	0|wumpus|also the thing overheats like crazy
 33 2017-11-29 08:31:07	0|sipa|the debug.log on my c2 is weird
 34 2017-11-29 08:31:19	0|sipa|it seems like it stopped doing anything for about 8 hours
 35 2017-11-29 08:31:45	0|jonasschnelli|eMMC would perform better?
 36 2017-11-29 08:33:45	0|wumpus|sipa: mine didn't stop for 8 hours but there were lots of unexplained pauses during block validtion
 37 2017-11-29 08:36:02	0|wumpus|jonasschnelli: not sure about eMMC speeds, I don't think they're much higher than general MMC ones
 38 2017-11-29 08:36:36	0|jonasschnelli|wumpus: referring to http://www.hardkernel.com/main/_Files/prdt/2016/201602/201506301616277586.jpg
 39 2017-11-29 08:36:41	0|wumpus|at least it's just a dumb flash card (but embedded) not a real SSD
 40 2017-11-29 08:40:05	0|wumpus|ah yes eMMC5.0 is a lot faster
 41 2017-11-29 08:41:23	0|wumpus|<wumpus> 14763950080 bytes (15 GB, 14 GiB) copied, 127.03 s, 116 MB/s <- read benchmark from a eMMC on i.MX8, don't know the write speed
 42 2017-11-29 08:42:04	0|kallewoof|Does gitian require you to run inside a VM or is it possible to run it directly? I keep having issues with lxc. ("lxc-execute: start.c: lxc_spawn: 1094 Failed to find gateway addresses. / Failed to spawn container "gitian".")
 43 2017-11-29 08:42:44	0|jonasschnelli|kallewoof: I run it directly host -> LXC
 44 2017-11-29 08:42:48	0|wumpus|you don't need to run gitian in a VM but it will always spawn one level of VM at least
 45 2017-11-29 08:43:49	0|kallewoof|OK, great! At least I'm not trying to do the impossible.
 46 2017-11-29 08:45:04	0|wumpus|re: eMMC speed the problem is that this doesn't really tell how it will perform under our typical leveldb load, which is seek-heavy, not linear-write/read heavy
 47 2017-11-29 08:45:18	0|jonasschnelli|wumpus: indeed...
 48 2017-11-29 08:45:34	0|kallewoof|Gitian sidenote: is there a reason why it doesn't have #!/bin/bash at the top? I use zsh, which explodes.
 49 2017-11-29 08:45:41	0|kallewoof|(gitian-build.sh)
 50 2017-11-29 08:46:03	0|kallewoof|Running "bash bitcoin/contrib/gitian-build.sh" works fine so no biggie, just annoying.
 51 2017-11-29 08:46:14	0|wumpus|dunno, feel free to add it, shellscripting always suffers from the many different kinds of shells with slightly different syntax
 52 2017-11-29 08:46:39	0|kallewoof|OK
 53 2017-11-29 08:49:50	0|wumpus|if you use any kind of looping or conditionals please contribute a python script instead, not a shell script, it's always at least 5 iterations of bash-this-syntax-back-to-the-eighties. But anyhow we have this one and it, more or less, works.
 54 2017-11-29 08:55:49	0|gmaxwell|wumpus: imx6 has an internal thermal cut, it'll shut off if you overheat it.  I assume the same for the imx8?  you could put a fan on it
 55 2017-11-29 08:58:35	0|wumpus|gmaxwell: I think so! but as I only have it temporarily (to do reverse-engineering to add GC7000 support to etnaviv) I don't want to take too much risk
 56 2017-11-29 09:01:50	0|Provoostenator|I've been syncing a Xiaomi A1 Android phone using ABCore for the past week or so (with a few interruptions, but I didn't want the battery to explode while I was away). When it's done, I can mail the logs to anyone who's interested.
 57 2017-11-29 09:03:26	0|wumpus|Provoostenator: what SoC does that have?
 58 2017-11-29 09:05:53	0|gmaxwell|wumpus: awesome that you're working on it. imx8 looks pretty exciting.
 59 2017-11-29 09:06:15	0|gmaxwell|I hope someone does a novena like board with imx8, would be a lot more interesting than the original novena.
 60 2017-11-29 09:06:39	0|Provoostenator|It's at height 469K taking about 2 seconds per block. wumpus: https://en.wikipedia.org/wiki/Xiaomi_Mi_A1 (Octa-core (8x2.0GHz Cortex-A53)?)
 61 2017-11-29 09:07:25	0|Provoostenator|I doubt my wifi or home internet is a bottleneck.
 62 2017-11-29 09:08:26	0|wumpus|gmaxwell: it's great hw, it seems really fast, rendering at 4k seems to be around the speed it was with 1080p on i.mx6q
 63 2017-11-29 09:09:54	0|wumpus|Provoostenator: two seconds per block at height 496K is pretty good for ARM
 64 2017-11-29 09:11:29	0|wumpus|gmaxwell: at least solidrun (from cubox) has plans to make a i.mx8 variant, also purism/librem is looking at it for their phone
 65 2017-11-29 09:11:53	0|midnightmagic|i wish linux supported the solid-run stuff more
 66 2017-11-29 09:12:21	0|wumpus|but I think it will be quite popular, I had some link to some other planned board as well but can't find it right now
 67 2017-11-29 09:12:27	0|gmaxwell|wumpus: the fact that its a53 is nice... for a long time I wondered if they'd ever existed.
 68 2017-11-29 09:12:40	0|wumpus|midnightmagic: which one? i.mx6 is fully upstream supported, as one of the few ARM SoCs?
 69 2017-11-29 09:12:57	0|gmaxwell|oh nevermind I'm confused. a57 is the out of order one.
 70 2017-11-29 09:13:28	0|gmaxwell|and imx8 is a72 which is a newer out of order one.
 71 2017-11-29 09:17:07	0|wumpus|midnightmagic: that's the cubox-i variant, I've been running stock debian on mine for years. Their first board was based on Marvell Armada 510, not sure that made it upstream.
 72 2017-11-29 09:20:12	0|midnightmagic|wumpus: The clearfog pro; the ECC version doesn't exist (in spite of saying it's available on their website) but apparently a pile of the onboard interfaces are glitchy under linux for that board.
 73 2017-11-29 09:21:27	0|wumpus|i.MX8 seems to be 4xA53, 2xA72, for the top range model
 74 2017-11-29 09:23:40	0|wumpus|midnightmagic: ah another Armada-based one, yes I wouldn't expect anything but pain :)
 75 2017-11-29 09:24:55	0|midnightmagic|wumpus: due to NDA restrictions on the documentation?
 76 2017-11-29 09:27:18	0|wumpus|midnightmagic: there's that problem, but my experience with their hw is also sort of flakey
 77 2017-11-29 09:28:24	0|wumpus|I also remember a glitchy USB interface on one of their SoCs
 78 2017-11-29 09:29:34	0|wumpus|it's not impossible that it's a driver issue, but their stance toward upstreaming drivers pretty much means you're stuck with the ancient vendor kernel forever
 79 2017-11-29 09:44:42	0|shadow_walker|hi Guys
 80 2017-11-29 09:44:57	0|shadow_walker|I need some help to create a bitcoin web wallet
 81 2017-11-29 09:45:09	0|shadow_walker|I am trying to understand what is the best approach for the same
 82 2017-11-29 09:45:30	0|shadow_walker|should I use the bitcoincore.io or https://github.com/bitcoin/bitcoin
 83 2017-11-29 09:45:39	0|shadow_walker|if any one can suggest ?
 84 2017-11-29 09:47:18	0|wumpus|#bitcoin please
 85 2017-11-29 09:48:54	0|aserc|hi need assistance - was sent some transaction few days ago from  old wallet and transaction is not  visible on explorer. Some cborg here told me to upgrade to new node and now have new node and all blockchain was rescaned or not know what was node doing. That transaction is not visible again now what is best option in node to get back that coins. could click abandon transaction but will coins than be in wallet again?
 86 2017-11-29 09:50:21	0|wumpus|yes, you try abandoning the transaction and re-spending the coins. Likely it was sent with too little fee.
 87 2017-11-29 09:50:32	0|wumpus|but ask in #bitcoin please this is not a help channel
 88 2017-11-29 09:50:38	0|aserc|not cborg but cberg
 89 2017-11-29 09:53:27	0|aserc|hi
 90 2017-11-29 09:53:59	0|aserc|after abandon transaction coins are in wallet no need for assistance for now
 91 2017-11-29 09:54:02	0|aserc|:)
 92 2017-11-29 10:19:20	0|wumpus|great!
 93 2017-11-29 10:59:42	0|bitcoin-git|13bitcoin/06master 14e1a8ec5 15Andras Elso: Fix: Open files read only if requested
 94 2017-11-29 10:59:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/26efc220a13a...e97039605e0d
 95 2017-11-29 10:59:43	0|bitcoin-git|13bitcoin/06master 14e970396 15Wladimir J. van der Laan: Merge #11747: Fix: Open files read only if requested...
 96 2017-11-29 11:02:10	0|wumpus|strange, it looks like commits are still notified here by github but not pulls opening/closing
 97 2017-11-29 11:03:43	0|aj|"<bitcoin-git> [bitcoin] vii opened pull request #11785: ..." came through earlier
 98 2017-11-29 11:03:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/11785 | Prevent file-descriptor exhaustion from RPC layer by vii · Pull Request #11785 · bitcoin/bitcoin · GitHub
 99 2017-11-29 11:05:15	0|wumpus|yes, but not the close for 11747, nor the one I closed before that
100 2017-11-29 11:05:56	0|wumpus|it seems unreliable lately
101 2017-11-29 11:20:13	0|wumpus|just merged two PRs without anything appearing here.
102 2017-11-29 11:20:21	0|bitcoin-git|13bitcoin/06master 148b2c733 15Gregory Sanders: clarify abortrescan rpc use
103 2017-11-29 11:20:21	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/46d1ebfcf854...32c9b570fcea
104 2017-11-29 11:20:22	0|bitcoin-git|13bitcoin/06master 1432c9b57 15Wladimir J. van der Laan: Merge #11753: clarify abortrescan rpc use...
105 2017-11-29 11:20:49	0|wumpus|oh, that one it does, but not the one before it (#11737)
106 2017-11-29 11:20:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/11737 | Document partial validation in ConnectBlock() by sdaftuar · Pull Request #11737 · bitcoin/bitcoin · GitHub
107 2017-11-29 11:23:05	0|fanquake|wumpus clearly someone is playing tricks :p
108 2017-11-29 11:23:46	0|wumpus|or the bot is on strike
109 2017-11-29 11:24:22	0|fanquake|Hopefully it's not that smart just yet
110 2017-11-29 11:24:55	0|fanquake|If someone on Windows could test #9254, that'd be great. It's now fixed up, and ready for review.
111 2017-11-29 11:24:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/9254 | [depends] ZeroMQ 4.2.2 by fanquake · Pull Request #9254 · bitcoin/bitcoin · GitHub
112 2017-11-29 11:26:55	0|wumpus|the chance of someone testing it on windows is much higher if we merge it
113 2017-11-29 11:27:31	0|wumpus|as the risk is limited to zeromq support, I think it's acceptable
114 2017-11-29 11:28:32	0|fanquake|wumpus If the changes look ok to you, then I think that's fine. The one thing I was going to look at was adding --disable-curve-keygen to our build options. But that doesn't really matter if you'd just like to merge it now.
115 2017-11-29 11:29:18	0|wumpus|fanquake: there's no rush, if you still want to make changes I'll wait
116 2017-11-29 11:30:09	0|wumpus|we don't use curve-keygen so disabling it mgiht speed up the build by a little bit
117 2017-11-29 11:30:30	0|fanquake|Yes, that was my thinking. I'll push that change up now.
118 2017-11-29 12:08:24	0|pbase|is there an alternative way to keep the chain synced? it is painfully slow!
119 2017-11-29 14:04:01	0|larafale|Hey folks, is it possible for my `bitcoind` to emit only `unconfirmed` tx via ZMQ? currently I received all tx, and when a block arrive I receive the same tx again. I'd like to filter this at the bitcoind level. thx for the feedback guys
120 2017-11-29 14:19:41	0|promag|larafale: not currently possible
121 2017-11-29 14:20:09	0|larafale|hum, thx :)
122 2017-11-29 14:22:05	0|promag|larafale: you might be interested in #8549
123 2017-11-29 14:22:08	0|gribble|https://github.com/bitcoin/bitcoin/issues/8549 | zmq: mempool notifications by jmcorgan · Pull Request #8549 · bitcoin/bitcoin · GitHub
124 2017-11-29 14:22:39	0|larafale|great, thx
125 2017-11-29 14:22:45	0|promag|wumpus: not int the roadmap right?
126 2017-11-29 14:22:52	0|promag|*in
127 2017-11-29 14:23:58	0|larafale|I also don't get why when I list 2 recent utxo via rpc on my tesnet node, I get one utxo that has a height way above chain height.
128 2017-11-29 14:24:03	0|larafale|bitmap: '11',
129 2017-11-29 14:24:03	0|larafale|{ chainHeight: 1249987,
130 2017-11-29 14:24:03	0|larafale|chaintipHash: '00000000000014a8d77d839efc2221d4956e1a6b755b43b551800a3077e0ee05',
131 2017-11-29 14:24:05	0|larafale|utxos:
132 2017-11-29 14:24:07	0|larafale|[ { height: 1249944, value: 0.08333, scriptPubKey: [Object] },
133 2017-11-29 14:24:09	0|larafale|{ height: 2147483647, value: 0.01839147, scriptPubKey: [Object] } ] }
134 2017-11-29 14:24:49	0|promag|larafale: in the future don't paste stuff here, use pastebin or github gist for instance
135 2017-11-29 14:25:13	0|larafale|ok no prob, I'm new i don't know the rules :)
136 2017-11-29 14:26:57	0|promag|larafale: you mean REST?
137 2017-11-29 14:27:19	0|larafale|no I made the call from rpc
138 2017-11-29 14:27:37	0|promag|what call?
139 2017-11-29 14:28:23	0|larafale|I'm issuing a getUnspentTransactionOutputs command passing 2 tx hash, above is the result i get
140 2017-11-29 14:28:46	0|larafale|but my concern is why one of the returned utxo has a height way above chain tip
141 2017-11-29 14:31:06	0|promag|I guess that coin is not in a block
142 2017-11-29 14:33:08	0|larafale|you are right, now that the tx got included in a block I get a valid height. But how would you explain the height: 2147483647 when it was not included? if it's not included in a block yet what does height represent and how did that number got there?
143 2017-11-29 14:34:24	0|promag|larafale: that value is 31 bits
144 2017-11-29 14:35:10	0|promag|https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L38-L39
145 2017-11-29 14:35:43	0|promag|all nHeight bits are 1
146 2017-11-29 14:36:40	0|promag|so, if height is that value then the corresponding transaction is not in the chain
147 2017-11-29 14:36:57	0|promag|jnewbery: ping
148 2017-11-29 14:37:43	0|larafale|really appreciate the feedback, thanks promag
149 2017-11-29 14:37:53	0|promag|no problem
150 2017-11-29 14:38:02	0|promag|larafale: btw, what client are you using
151 2017-11-29 14:38:19	0|larafale|ZMQ client ?
152 2017-11-29 14:39:18	0|promag|no, I mean, getUnspentTransactionOutputs belongs to which library?
153 2017-11-29 14:39:27	0|larafale|I'm building my own client over bitcoind
154 2017-11-29 14:39:59	0|larafale|https://github.com/ruimarinho/bitcoin-core
155 2017-11-29 14:40:14	0|larafale|and that the client I issue RPC command with
156 2017-11-29 14:41:08	0|promag|ah yes, so you are issuing a REST call
157 2017-11-29 14:41:41	0|promag|https://github.com/ruimarinho/bitcoin-core/blob/6d558a486d783d73bd8087e55d42592ff7a3b3ee/src/index.js#L215-L234
158 2017-11-29 14:43:27	0|larafale|is UnspentTransactionOutputs only available throught REST ? I can also run that command throught bitcoin-cli I guess?
159 2017-11-29 14:43:30	0|larafale|I will try
160 2017-11-29 14:44:33	0|promag|you have RPC listunspents
161 2017-11-29 14:44:51	0|promag|listunspent (singular)
162 2017-11-29 14:45:02	0|larafale|yes ok.
163 2017-11-29 15:32:49	0|jnewbery|promag: no need to ping. What's the question?
164 2017-11-29 15:52:19	0|BlueMatt|sipa: if you get particularly bored, I went down a way-too-deep rabbit hole reading mapBlocksUnlinked and pruning logic, and ended up with a few teaks to help my understanding and fix some tiny edge cases as I go....care to take a look at all but the top commit on https://github.com/TheBlueMatt/bitcoin/commits/2017-11-unlinked-blockx-fixes and tell me if its worth upstreaming?
165 2017-11-29 16:42:02	0|bitcoin-git|[13bitcoin] 15rawodb closed pull request #11787: Support for SegWit addresses, change addresses and UI request payment (06master...06pr/segwit_addresses_master) 02https://github.com/bitcoin/bitcoin/pull/11787
166 2017-11-29 16:56:59	0|promag|jnewbery: how could I test parallel rescans? so that I know they are really parallel executions server side?
167 2017-11-29 16:57:25	0|promag|related to #11281
168 2017-11-29 16:57:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
169 2017-11-29 16:59:38	0|promag|I mean add a test in test/functional
170 2017-11-29 17:20:52	0|erichCompSci|Hello, I was wondering about the following problem.  Miners in bitcoin verify transactions in the blockchain by hashing the previous blocks header, transaction data and a nonce value.  However, the block is only considered a legitimate block
171 2017-11-29 17:21:03	0|erichCompSci|if the final hash
172 2017-11-29 17:21:10	0|erichCompSci|is below a certain threshold
173 2017-11-29 17:21:23	0|erichCompSci|So...when that hash becomes as low as it can go
174 2017-11-29 17:21:38	0|erichCompSci|how do new transactions get verified?
175 2017-11-29 17:21:45	0|erichCompSci|?
176 2017-11-29 17:24:11	0|Murch|That question is better suited for Bitcoin.stackexchange.com than for this channel. However, the difficulty scales on a range of 2^256, so that scenario is pretty far-fetched.
177 2017-11-29 17:28:40	0|erichCompSci|Well, I'll move over there then, but I'm afraid I don't understand.  At some point, it will become nearly impossible to create new blocks, hence miners will be unable to mine new bitcoins...so then how are transactions verified?  After all, miners mine by creating the blocks in the blockchain that also verify transactions...so if miners will eventually be unable to mine new coins they must be unable to create new bloc
178 2017-11-29 17:28:44	0|erichCompSci|I'm asking on the developer forum
179 2017-11-29 17:29:15	0|erichCompSci|someone must be thinking of this...how are you going to do the hashing post mining era so that transactions still only take 10 min
180 2017-11-29 17:29:30	0|erichCompSci|new blocks in the chain only take 10 min
181 2017-11-29 17:29:33	0|erichCompSci|sorry
182 2017-11-29 17:29:42	0|erichCompSci|otherwise you have to revisit other things like
183 2017-11-29 17:30:43	0|erichCompSci|block chain lengths can no longer be used for consensus as the hashes don't have a specific value they have to be under...what will the new rule be?
184 2017-11-29 17:30:44	0|Murch|erichCompSci: The sun will go out before our capacity to increase the difficulty runs out. Also, we could just make the difficulty field bigger.
185 2017-11-29 17:31:25	0|erichCompSci|But then there won't be a fixed amount of bitcoins?
186 2017-11-29 17:31:35	0|erichCompSci|if you increase the difficulty field?
187 2017-11-29 17:31:53	0|Murch|erichCompSci: The difficulty is not related to the reward schedule
188 2017-11-29 17:32:12	0|erichCompSci|Okay, thats something I didn't know...I'll look into that thanks
189 2017-11-29 17:32:13	0|jnewbery|promag: not sure what you mean by parallel executions server side
190 2017-11-29 18:00:19	0|jonasschnelli|promag: wumpus: I'm currently overhauling #11281 ... The parallel rescans can best be tested with an artificial temp. sleep in the inner rescan loop
191 2017-11-29 18:00:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/11281 | Avoid permanent cs_main/cs_wallet lock during RescanFromTime by jonasschnelli · Pull Request #11281 · bitcoin/bitcoin · GitHub
192 2017-11-29 18:00:39	0|jonasschnelli|Need also to rebase because 11281 does not cover "rescanblockchain" (new RPC) yet.
193 2017-11-29 18:00:48	0|bitcoincore-slac|Just wanted to let everyone who has committed code to bitcoin core that there are A LOT of shout-outs and appreciation to all of you the past few days on Slack, Twitter, etc.  We know what you have done and continuing to do and can't thank you enough!
194 2017-11-29 18:10:25	0|instagibbs|can anyone point to where the wallet magic value is in the repo, if any
195 2017-11-29 18:19:07	0|Provoostenator|In case we still want to discuss this tomorrow: Google Summer of Code rules archived from last year: http://web.archive.org/web/20170211133438/https://summerofcode.withgoogle.com/rules/
196 2017-11-29 18:20:04	0|Provoostenator|One issue might be that they seem to require a real organization, with legacy world stuff like someone being able to legally represent it. So sounds like this would have to go through some random related foundation.
197 2017-11-29 18:21:43	0|Varunram|Provoostenator: I think organisation means anything, like even a Github organisation
198 2017-11-29 18:22:08	0|Varunram|Because every year, there are baby orgs that get a chance at SoC
199 2017-11-29 18:23:00	0|Varunram|If we do discuss about this tomorrow, I can pitch in more info if you'd like :)
200 2017-11-29 18:23:50	0|Provoostenator|The terms and conditions are pretty specific about legal representation though.
201 2017-11-29 18:26:14	0|Varunram|Most probably, that's only in place to accept stuff, I'll ask around and come back though
202 2017-11-29 18:32:00	0|aj|the software freedom conservancy seems to be the recommended umbrella org so you don't have to setup your own -- https://developers.google.com/open-source/gsoc/help/org-payments
203 2017-11-29 18:34:05	0|aj|i think software in the public interest also works and is used by debian and others (spi-inc.org)
204 2017-11-29 18:47:16	0|Provoostenator|aj: that might get controversial quickly. A single individual accepting and forwarding payments seems better. Ideally someone in a jurisdiction where this wouldn't have weird tax implications.
205 2017-11-29 18:48:01	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11789: [tests] [travis-ci] Combine logs on failure (06master...06pr11779.2) 02https://github.com/bitcoin/bitcoin/pull/11789
206 2017-11-29 18:52:56	0|phantomcircuit|instagibbs, what magic value?
207 2017-11-29 18:53:28	0|instagibbs|phantomcircuit, was just wondering how Core knows it's reading hte "right" bdb, talking with sipa about it now
208 2017-11-29 18:54:08	0|instagibbs|I want to make a wallet that simply won't open with Core master, or anything in the near future
209 2017-11-29 18:54:37	0|sipa|but still want it to be BDB?
210 2017-11-29 18:55:52	0|instagibbs|yes
211 2017-11-29 18:56:50	0|sipa|yes, use minversion
212 2017-11-29 18:57:27	0|instagibbs|yeah, that's what I did for now, removed the footgun surface until its maxed out
213 2017-11-29 20:44:37	0|jimpo|How do people typically profile/time the code on live nodes? eg. Avg validation time for the past N blocks?
214 2017-11-29 20:44:49	0|BlueMatt|-debug=bench
215 2017-11-29 20:45:15	0|BlueMatt|(and -logtimemicros)
216 2017-11-29 20:45:46	0|jimpo|Ah, cool
217 2017-11-29 21:19:33	0|eck|are there pixmaps for bitcoin testnet? i'd like to create .desktop file for bitcoin-qt -testnet=1 that uses the green logo, instead of the orange one
218 2017-11-29 21:29:37	0|eck|nevermind, I found the code that shifts the hue in src/qt/networkstyle.cpp, I will probably submit a PR seeing if I can get testnet and regtest pixmaps checked in for this purpose
219 2017-11-29 21:30:20	0|sipa|seems reasonable to me
220 2017-11-29 22:01:24	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #11790: Add pixmaps for testnet and regtest (06master...06pixmaps) 02https://github.com/bitcoin/bitcoin/pull/11790
221 2017-11-29 22:17:09	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11791: [tests] Rename NodeConn and NodeConnCB (06master...06rename_node_conn) 02https://github.com/bitcoin/bitcoin/pull/11791
222 2017-11-29 22:33:05	0|jonasschnelli|eck: pixmaps? for the application icons?
223 2017-11-29 22:33:30	0|jonasschnelli|Some years ago we moved from pixmaps to the dynamic generated icons via networkstyle.cpp
224 2017-11-29 22:49:00	0|eck|they're still used on linux (and i imagine on os x and windows) to provide an application icon
225 2017-11-29 22:50:51	0|eck|specifically via the Icon= entry in the .desktop file
226 2017-11-29 22:52:11	0|jonasschnelli|eck: Yes. Windows has that direct link to testnet. That's true.
227 2017-11-29 22:52:18	0|jonasschnelli|Not sure about linux
228 2017-11-29 22:52:29	0|jonasschnelli|Maybe via contrib/
229 2017-11-29 23:17:18	0|jimpo|leveldb docs say that DB is safe for concurrent access by multiple threads: https://github.com/bitcoin/bitcoin/blob/master/src/leveldb/include/leveldb/db.h#L42. Is it assumed that CDBWrapper is as well or no?
230 2017-11-29 23:19:36	0|sipa|i believe so, but i don't think we ever use that
231 2017-11-29 23:19:47	0|sipa|CCoinsCache certainly isn't
232 2017-11-29 23:23:13	0|jimpo|I'm looking into building the tx index in it's own thread instead of ConnectBlock. Do you think 1) it's a bad idea altogether 2) it's safe to keep the txindex data in the blocktree database or 3) the txindex should be rebuilt in its own DB?
233 2017-11-29 23:24:09	0|sipa|i think the txindex should be modified to use the signal mechanism the wallet uses too
234 2017-11-29 23:24:31	0|jimpo|in case 2, multiple threads would most likely access the same CBlockTreeDB, though alternately there could be multiple wrapper objects with a shared pointer to the same underlying leveldb::DB
235 2017-11-29 23:24:35	0|sipa|which afaik matt is moving to support multiple threads
236 2017-11-29 23:24:57	0|sipa|and yes, a separate db sounds right to me - we'd have lower consistency guarantees then, though
237 2017-11-29 23:25:31	0|sipa|which i'm not sure will be acceptable
238 2017-11-29 23:25:51	0|jonasschnelli|Anyone up for a quick review: https://github.com/bitcoin/bitcoin/pull/11616/files?
239 2017-11-29 23:26:03	0|jimpo|consistency for RPC calls? couldn't it just block until the txindex is in sync?
240 2017-11-29 23:26:21	0|jimpo|GetRawTransaction RPC, specifically
241 2017-11-29 23:26:35	0|sipa|jimpo: perhaps
242 2017-11-29 23:27:01	0|bitcoin-git|[13bitcoin] 15aaron-hanson opened pull request #11792: Trivial: fix comments for ZeroMQ bitcoind args (06master...06trivial-zeromq-arguments-comments) 02https://github.com/bitcoin/bitcoin/pull/11792
243 2017-11-29 23:27:07	0|sipa|ideally i'd say there is a separate 'indexing subsystem' which is something you talk to explicitly (perhaps using a separate endpoint like the wallet)
244 2017-11-29 23:27:37	0|sipa|in that case you can easily guarantee consisntency within the subsystem (e.g. you could ask what its best block is, and that would be in sync with its indexing results)
245 2017-11-29 23:28:02	0|sipa|making the rpc block until it's caught up is probably the right approach initially but feels much less clean
246 2017-11-29 23:28:37	0|jimpo|That might make sense for possible future indexes, but would break compatibility for GetRawTransaction, no?
247 2017-11-29 23:33:49	0|jimpo|As far as the separate DB instead of a separate key prefix within the same DB (the current design), it would require a migration, which could be avoided if we were comfortable with concurrent access to CBlockTreeDB.