1 2017-11-13 00:26:03	0|ZSky|Hi
  2 2017-11-13 00:27:17	0|ZSky|How popular is the idea of moving from hashcash to another one (not requiring ASICs) in Bitcoin core (not a fork but the real one)?
  3 2017-11-13 01:24:48	0|achow101|what's the reason for shutting down after encrypting the wallet?
  4 2017-11-13 01:24:58	0|achow101|Is it not sufficient to just close and reopen the wallet?
  5 2017-11-13 01:26:02	0|sipa|closing and flushing and snapshotting would be enough
  6 2017-11-13 01:26:18	0|sipa|but at the tike encryption was added, there was no multiwallet
  7 2017-11-13 01:26:28	0|sipa|so the only way to close the wallet was to shut down
  8 2017-11-13 01:27:29	0|achow101|ah, ok. I was thinking that it should be enough to just all StopWallets, CloseWallets, and then OpenWallets after encrypting a wallet
  9 2017-11-13 01:27:52	0|achow101|AFAICT that should close, flush everything, remove keys from memory, and then open again
 10 2017-11-13 01:28:51	0|sipa|probably
 11 2017-11-13 02:44:30	0|roconnor|Hi, are there gitian build logs of the build tty output somewhere that I can puruse?
 12 2017-11-13 02:48:37	0|fanquake|rconnor gitian-builder/var/
 13 2017-11-13 02:48:44	0|fanquake|should be build.log and install.log
 14 2017-11-13 02:55:51	0|roconnor|fanquake: is it available online somewhere?
 15 2017-11-13 03:17:51	0|fanquake|rconnor logs for your own build? I'd hope nope, gitian building is contained to the vm you've setup to build with. Or do you mean gitian build logs for an official release?
 16 2017-11-13 03:18:01	0|fanquake|*roconnor
 17 2017-11-13 03:19:15	0|fanquake|roconnor The signatures used to create the final release are available from https://github.com/bitcoin-core/gitian.sigs . There is no way to get the various build.logs from each of the individual builders.
 18 2017-11-13 03:50:26	0|roconnor|ok ty
 19 2017-11-13 03:50:57	0|achow101|besides deadlock, is there any reason that a lock is not able to be acquired?
 20 2017-11-13 03:51:04	0|roconnor|I suppose I just wanted to double check if ccache is being used in the gitian builds.  It seems it is, but I'm presuming to no advantage.
 21 2017-11-13 03:53:06	0|achow101|roconnor: why would there be no advantage?
 22 2017-11-13 03:53:50	0|roconnor|Maybe I don't understand what ccache does.  I thought it avoid recompiling object files that have been compiled before.
 23 2017-11-13 03:55:11	0|achow101|roconnor: yes, it does
 24 2017-11-13 03:55:31	0|achow101|gitian builds multiple binaries for each OS target
 25 2017-11-13 03:55:48	0|achow101|well, just the linux one actually
 26 2017-11-13 03:56:24	0|roconnor|different OS targets?  can you give an example?
 27 2017-11-13 03:57:36	0|achow101|the linux build does 4 different builds, one for each list: HOSTS="i686-pc-linux-gnu x86_64-linux-gnu arm-linux-gnueabihf aarch64-linux-gnu"
 28 2017-11-13 03:58:02	0|achow101|Windows does the same: HOSTS="i686-w64-mingw32 x86_64-w64-mingw32"
 29 2017-11-13 03:58:09	0|achow101|osx technically does the same, but only has one host
 30 2017-11-13 03:58:29	0|roconnor|how can it do x86 and arm and yet share object files?
 31 2017-11-13 04:00:21	0|achow101|oh right, hmmm
 32 2017-11-13 04:01:15	0|roconnor|If the ccache offers no advantage, perhaps it should be removed from the gitian builds.
 33 2017-11-13 04:33:59	0|sipa|achow101: if something elwe holds the lock already, that does not necessarily imply a deadlock
 34 2017-11-13 06:35:29	0|wumpus|roconnor: ccache is not used in the gitian builds at all, just for travis
 35 2017-11-13 06:36:36	0|wumpus|together with travis' caching it makes PRs and new commits compile faster
 36 2017-11-13 06:38:17	0|wumpus|it just happens that ccache is part of the depends system so it gets built automatically, it builds quickly enough that adding a NO_CCACHE option to depends likely isn't worth the extra complexity
 37 2017-11-13 07:30:03	0|wumpus|intermittent error in sendheaders.py test_null_locators, assert_equal(test_node.check_last_announcement(headers=[tip_hash]), True)
 38 2017-11-13 07:42:49	0|meshcollider|wumpus: yep I've seen that one before
 39 2017-11-13 07:42:55	0|meshcollider|Locally
 40 2017-11-13 07:43:26	0|wumpus|indeed, this was locally too
 41 2017-11-13 07:43:36	0|wumpus|will create an issue
 42 2017-11-13 07:43:46	0|meshcollider|Encountered it yesterday while working on 11667
 43 2017-11-13 07:46:51	0|wumpus|https://github.com/bitcoin/bitcoin/issues/11673
 44 2017-11-13 07:47:14	0|wumpus|I've seen it on 11651, but makes no sense that it would be caused by that change
 45 2017-11-13 07:59:51	0|Lauda|Does 0.15.0 have any bugs that makes the software crash?
 46 2017-11-13 08:00:00	0|Lauda|Any known*.
 47 2017-11-13 08:02:53	0|meshcollider|Lauda: 0.15.0 or 0.15.0.1?
 48 2017-11-13 08:03:02	0|Lauda|0.15.0
 49 2017-11-13 08:03:12	0|Lauda|Mine crashed several times with "Error eading from database"
 50 2017-11-13 08:03:28	0|Lauda|over the last few days. Runs okay for a while and just crashes
 51 2017-11-13 08:03:36	0|Lauda|updating to 0.15.0.1 right now to compare
 52 2017-11-13 08:03:46	0|wumpus|0.15.0 can crash due to corrupt peers.dat, but apart from that, no
 53 2017-11-13 08:04:06	0|wumpus|this was solved in 0.15.1 (not 0.15.0.1)
 54 2017-11-13 08:04:10	0|Lauda|Interesting. I wonder what could be causing this.
 55 2017-11-13 08:04:17	0|Lauda|Erm, sorry. Updating to 0.15.1
 56 2017-11-13 08:04:48	0|wumpus|without further context it sounds like a hardware issue of some kind
 57 2017-11-13 08:06:29	0|wumpus|most of the time database corruptions, if they happen a lot on a single computer, tend to be hw issues (cpu overheat, memory corruption, disk corruption, sometimes due to PSU issues,...)
 58 2017-11-13 08:07:55	0|wumpus|you could try to debug it if you think it's a sw issue, but the few times I've spend lots of time chasing such an issue I ended up with a faulty component
 59 2017-11-13 08:08:31	0|wumpus|most amusing was the USB stick that randomly toggles bits on heavy usage
 60 2017-11-13 08:10:07	0|wumpus|can you pastebin the detailed error?
 61 2017-11-13 08:13:56	0|Lauda|Yeah, I had a flaky USB slot back when I had Core on a external HDD which led to a lot of reindexing. I'll try 0.15.1 first and hope that solves. it
 62 2017-11-13 08:14:05	0|Lauda|From the debug log?
 63 2017-11-13 08:14:12	0|wumpus|yes
 64 2017-11-13 08:21:26	0|wumpus|we really need to add a filename to the leveldb checksum mismatch errors, so people can send to file to be analyzed
 65 2017-11-13 08:21:40	0|Lauda|^
 66 2017-11-13 08:22:09	0|wumpus|I did that locally a long time ago but don't think I still have it
 67 2017-11-13 08:24:12	0|Lauda|Shouldn't be too hard?
 68 2017-11-13 08:26:38	0|wumpus|depends on whether that context is known at the place the exception is thrown
 69 2017-11-13 08:39:06	0|wumpus|oh this seems to be easy
 70 2017-11-13 08:41:08	0|wumpus|but it does need some leveldb changes, e.g. currently RandomAccessFile has no way to get the file name back
 71 2017-11-13 08:51:49	0|wumpus|still easy changes though
 72 2017-11-13 08:53:37	0|wumpus|I'll have a shot at it
 73 2017-11-13 09:21:32	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #11674: leveldb: Add filename to corruption errors (06master...062017_11_leveldb_report_errors) 02https://github.com/bitcoin/bitcoin/pull/11674
 74 2017-11-13 09:24:28	0|helloBits|Good day chappies
 75 2017-11-13 09:28:19	0|Lauda|\o/ wumpus
 76 2017-11-13 11:49:35	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2adbddb03840...7fbf3c638f3f
 77 2017-11-13 11:49:36	0|bitcoin-git|13bitcoin/06master 14e0fc4a7 15Aaron Clauson: Updated Windows build doc for WSL/Xenial workarounds.
 78 2017-11-13 11:49:37	0|bitcoin-git|13bitcoin/06master 147383d77 15Aaron Clauson: Updated instructions for Windows 10 Fall Creators Update.
 79 2017-11-13 11:49:37	0|bitcoin-git|13bitcoin/06master 147fbf3c6 15Wladimir J. van der Laan: Merge #11438: Updated Windows build doc for WSL/Xenial workaround...
 80 2017-11-13 11:50:00	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11438: Updated Windows build doc for WSL/Xenial workaround (06master...06wslbuilddoc) 02https://github.com/bitcoin/bitcoin/pull/11438
 81 2017-11-13 12:22:44	0|Victorsueca|trying to build bitcoin core on WSL, when building the depends it tells me automake is not installed, however it is and both the automake and autoconf commands work when writing them on the terminal
 82 2017-11-13 12:22:53	0|Victorsueca|any clue of what's going wrong?
 83 2017-11-13 12:24:43	0|wumpus|isn't WSL an ever enduring source of issues, just use a real linux or BSD already :)
 84 2017-11-13 12:25:31	0|Victorsueca|welp, I used to compile it succesfully on WSL with ubuntu 14
 85 2017-11-13 12:26:01	0|wumpus|yes I'm just kidding, it should work, it's just that there's so many problems reported with it all over the place
 86 2017-11-13 12:26:16	0|wumpus|so many "fixes" to that doc
 87 2017-11-13 12:26:19	0|Victorsueca|yeah, totally agree, WSL is just a pain in the arse
 88 2017-11-13 12:27:10	0|Victorsueca|I still have the Ubuntu 14 WSL on another machine and I can use that to build it
 89 2017-11-13 12:27:17	0|wumpus|in theory it's simply a ubuntu "VM", that's how it started and worked fine w/ 14.04, but they started injecting the environment from windows in it
 90 2017-11-13 12:27:57	0|wumpus|the more it mutates into some hybrid monster
 91 2017-11-13 12:28:23	0|Victorsueca|Basically, getting something that already exists and doing exactly the same but in incompatible ways
 92 2017-11-13 12:28:34	0|Victorsueca|has Microsoft ever done anything other than that? ;)
 93 2017-11-13 12:28:37	0|wumpus|embrace and extinguish (tm)
 94 2017-11-13 12:30:57	0|Victorsueca|Currently building 0.15.1 on the old WSL, works fine as always
 95 2017-11-13 12:31:15	0|Victorsueca|but I'd like to get the new one working for damn once
 96 2017-11-13 12:32:30	0|Victorsueca|So, more specifically, it's asking for automake-1.14
 97 2017-11-13 12:32:58	0|Victorsueca|but the distro repositories only have automake-1.11 and automake-1.15
 98 2017-11-13 12:33:06	0|Victorsueca|could it be just a version missmatch?
 99 2017-11-13 12:33:06	0|wumpus|it shouldn't require a specific automake version. Did you perhaps upgrade something, without cleaning your tree?
100 2017-11-13 12:33:33	0|wumpus|sometimes there are leftovers from scripts generated from old versions in the way
101 2017-11-13 12:33:44	0|Victorsueca|nope, it's a fresh WSL, just ran the commands stated on the windows build doc
102 2017-11-13 12:34:11	0|Victorsueca|except the Xenial workaround
103 2017-11-13 12:34:20	0|Victorsueca|which I did later today when the doc updated
104 2017-11-13 12:37:27	0|wumpus|the xenial workaround changes to some newer versions using backported packages, that's exactly the change that can result in what I said
105 2017-11-13 12:38:23	0|Victorsueca|thought so, it was worth mentioning that
106 2017-11-13 12:38:35	0|Victorsueca|so, now how do I clean this?
107 2017-11-13 12:39:44	0|wumpus|I'd move away the depends/sources directory, than git clean -f -x -d, move it back, and start over
108 2017-11-13 12:47:00	0|Victorsueca|wumpus: done, still same problem
109 2017-11-13 12:47:23	0|wumpus|ok... no clue in that case
110 2017-11-13 12:47:56	0|Victorsueca|I think it's worth mentioning also that I tried to make the depends before the xenial workaround, and got the same issue
111 2017-11-13 12:48:09	0|Victorsueca|I hoped that the workaround would fix it
112 2017-11-13 12:48:48	0|wumpus|the workaround is for generating broken executables
113 2017-11-13 12:48:58	0|wumpus|it should still build...
114 2017-11-13 12:53:15	0|Victorsueca|hmmm
115 2017-11-13 13:02:09	0|Victorsueca|just noticed that ccache built successfully
116 2017-11-13 13:02:31	0|Victorsueca|it fails when it tries to build native_protobuf
117 2017-11-13 13:04:15	0|Victorsueca|wumpus: I think I found the problem
118 2017-11-13 13:05:57	0|Victorsueca|/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-38b82cbb6fc on line 81
119 2017-11-13 13:06:28	0|Victorsueca|it's trying to run automake-1.14
120 2017-11-13 13:07:11	0|wumpus|can you pastebin the file plesae?
121 2017-11-13 13:07:27	0|Victorsueca|on the way
122 2017-11-13 13:10:04	0|wumpus|that's a strange file name, are you sure it's called like that, without an extension?
123 2017-11-13 13:10:29	0|Victorsueca|nope, it's a dir, I think the file is Makefile.in
124 2017-11-13 13:11:23	0|Victorsueca|I'll just pastebin the console so you can tell me for sure which file should I send
125 2017-11-13 13:13:11	0|Victorsueca|wumpus: https://0bin.net/paste/NCCZM8Etb52NvGhW#BdyXYVQzaGTwy+xcK75FLDyCA6NOBcwl2BxpwhL6i1D
126 2017-11-13 13:14:39	0|wumpus|"missing" is a generated file
127 2017-11-13 13:14:50	0|wumpus|are you sure cleaning the tree actually cleaned up all that?
128 2017-11-13 13:15:39	0|wumpus|hrm, I think I know the issue
129 2017-11-13 13:15:52	0|wumpus|Victorsueca: you should build from the linux fs, not the mounted windows fs
130 2017-11-13 13:16:17	0|Victorsueca|ok, trying that now
131 2017-11-13 13:16:22	0|wumpus|the windows fs emulation botches timestamps, which makes protobuf think it needs to rebuild its configure scripts
132 2017-11-13 13:16:48	0|wumpus|.... another thing that should be mentionined in that infamous doc
133 2017-11-13 13:21:57	0|Victorsueca|nice, seems like it's working
134 2017-11-13 13:22:15	0|Victorsueca|gone past protobuf, now building boost
135 2017-11-13 14:01:12	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7fbf3c638f3f...927e5280bdba
136 2017-11-13 14:01:13	0|bitcoin-git|13bitcoin/06master 144a426d8 15practicalswift: Add note about Valgrind suppressions file in developer-notes.md
137 2017-11-13 14:01:13	0|bitcoin-git|13bitcoin/06master 1484e2462 15practicalswift: contrib: Add Valgrind suppressions file...
138 2017-11-13 14:01:14	0|bitcoin-git|13bitcoin/06master 14927e528 15Wladimir J. van der Laan: Merge #11035: [contrib] Add Valgrind suppressions file...
139 2017-11-13 14:01:33	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11035: [contrib] Add Valgrind suppressions file (06master...06valgrind-suppressions) 02https://github.com/bitcoin/bitcoin/pull/11035
140 2017-11-13 14:09:59	0|roconnor|wumpus: thanks for the info regarding ccache and gitian.
141 2017-11-13 15:04:37	0|ryanofsky|eck: re "multi-process bitcoin core" see https://eklitzke.org/multiprocess-bitcoin and prs 10102, 10244, 10973
142 2017-11-13 16:18:03	0|ossifrage|I just noticed that somehow ~0.15.1 some how managed to drop a label (it now reads "(no label)") that was present last night via listtransactions
143 2017-11-13 16:19:24	0|ossifrage|It seems that 3 of my segwit addresses all have lost their labels
144 2017-11-13 16:20:30	0|ossifrage|It looks like maybe 'addsegwitaddress' for an address that already has a segwit address will clobber the existing label
145 2017-11-13 16:31:21	0|sipa|ossifrage: it shouldn't touch the original address
146 2017-11-13 16:31:36	0|sipa|but the witness address returned by addwitnessaddress won't have a label
147 2017-11-13 16:32:41	0|ossifrage|sipa, I couldn't figure out how to extract the private key for a segwit address, so I walked throught he candidate keys doing an 'addwitnessaddress' until I got a hit
148 2017-11-13 16:36:26	0|achow101|could someone help me debug some locks on https://github.com/achow101/bitcoin/tree/encrypt-no-restart? That branch is for encrypting wallets without restarting, and something in the GUI part is holding cs_KeyStore causing the GUI to freeze
149 2017-11-13 16:37:31	0|sipa|ossifrage: yes, how is that related to the labels
150 2017-11-13 16:38:01	0|sipa|addwitnessaddress does not support labels
151 2017-11-13 16:38:54	0|achow101|sipa: presumably he called addwitnessaddress a bunch of times to make witness addresses that already existed in the wallet. so then addwitnessaddress overwrote whatever label had already been given to that address?
152 2017-11-13 16:39:30	0|sipa|addresses created by addwitnessaddress never have a label, so i don't think that situation is even possible
153 2017-11-13 16:40:40	0|achow101|sipa: pwallet->SetAddressBook(w.result, "", "receive");
154 2017-11-13 16:40:49	0|achow101|I think that's the problem
155 2017-11-13 16:41:25	0|sipa|yes, but there's no way the address would have had another label before the call, i think?
156 2017-11-13 16:41:38	0|sipa|or is there some account related call to modify a label after creation
157 2017-11-13 16:42:00	0|achow101|sipa: he added a label himself using some other call
158 2017-11-13 16:44:12	0|achow101|setaccount will let you re-label an address. It can also be done in the GUI, but I don't know if witness addresses will show up there
159 2017-11-13 16:44:40	0|sipa|ah
160 2017-11-13 16:44:46	0|sipa|that's what i was missing
161 2017-11-13 16:53:10	0|ossifrage|sipa, I gave them a label after I initially created them... then that label was clobbered by doing an addwitnessaddress a second time
162 2017-11-13 16:53:44	0|ossifrage|I added the label in the UI by double clicking on the label text and changing it.
163 2017-11-13 16:56:06	0|sipa|right, addwitnessaddress sets it to ""
164 2017-11-13 16:56:15	0|sipa|you could change it back, i guess
165 2017-11-13 16:56:33	0|ossifrage|I did, it just was a bit confusing
166 2017-11-13 17:19:15	0|achow101|so I'm experiencing some lock contention in the branch I mentioned earlier, and I can't figure out why. nothing is holding cs_KeyStore but the line that is blocking can't acquire it for some reason
167 2017-11-13 19:59:53	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11663: [trivial] doc: Add getreceivedbyaddress release notes (06master...06Mf1711-docReleaseNotes16) 02https://github.com/bitcoin/bitcoin/pull/11663
168 2017-11-13 21:23:14	0|eck|why is it that when you look at debug.log, you see the cache size growing and growing until it periodically "resets" to some much smaller value?
169 2017-11-13 21:23:29	0|BlueMatt|eck: thats when the cache flushes..........
170 2017-11-13 21:23:48	0|eck|i see, thanks
171 2017-11-13 21:24:04	0|sipa|it's both a cache and a buffer
172 2017-11-13 21:24:24	0|gmaxwell|it's mostly a buffer. :) the performance elements of the caching aren't that significant.
173 2017-11-13 21:24:49	0|LumberCartel|A cache is strategically managed buffers.
174 2017-11-13 21:25:02	0|LumberCartel|At least that's how I've always understood it.
175 2017-11-13 21:33:58	0|eck|so if you kill -9 bitcoind, does that mean you have to potentially resync all the data that had been in the in-memory cache/buffer at the time that it was killed?
176 2017-11-13 21:34:26	0|gmaxwell|yes.
177 2017-11-13 21:34:38	0|gmaxwell|it will flush once a day if not earlier due to size
178 2017-11-13 22:03:45	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/41aa9c4a801a...5e468994fbb3
179 2017-11-13 22:03:46	0|bitcoin-git|13bitcoin/06master 142f041f0 15Luke Dashjr: contrib/init: Update openrc-run filename...
180 2017-11-13 22:03:46	0|bitcoin-git|13bitcoin/06master 145e46899 15MarcoFalke: Merge #11676: contrib/init: Update openrc-run filename...
181 2017-11-13 22:04:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11676: contrib/init: Update openrc-run filename (06master...06openrc-run) 02https://github.com/bitcoin/bitcoin/pull/11676
182 2017-11-13 22:47:42	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11677: qa: Remove unused NodeConn members (06master...06Mf1711-qaMininodeUnused) 02https://github.com/bitcoin/bitcoin/pull/11677
183 2017-11-13 23:13:00	0|karelb|I will probably ask here - is there a rule how often to reset testnet chains? Shouldn't testnet be reset more often? It is too big now for effective testing
184 2017-11-13 23:14:50	0|karelb|Is it good idea to make an "informal" rule - that testnet will be reset once it has a certain size in the next release? (For example, once it has 100.000 blocks, then in the next core release)
185 2017-11-13 23:17:54	0|karelb|Well seems I am not the first one to want to reset it - #4416 :)
186 2017-11-13 23:17:55	0|gribble|https://github.com/bitcoin/bitcoin/issues/4416 | testnet4 · Issue #4416 · bitcoin/bitcoin · GitHub
187 2017-11-13 23:28:02	0|achow101|karelb: there's no rule. it's only reset when it is super problematic or people start trading testnet coins for money
188 2017-11-13 23:29:06	0|karelb|hm, it's 10GB right now... that is not *super* problematic, but also not small