< 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)?
< achow101>
what's the reason for shutting down after encrypting the wallet?
< achow101>
Is it not sufficient to just close and reopen the wallet?
< sipa>
closing and flushing and snapshotting would be enough
< sipa>
but at the tike encryption was added, there was no multiwallet
< sipa>
so the only way to close the wallet was to shut down
< achow101>
ah, ok. I was thinking that it should be enough to just all StopWallets, CloseWallets, and then OpenWallets after encrypting a wallet
< achow101>
AFAICT that should close, flush everything, remove keys from memory, and then open again
< sipa>
probably
< roconnor>
Hi, are there gitian build logs of the build tty output somewhere that I can puruse?
< fanquake>
rconnor gitian-builder/var/
< fanquake>
should be build.log and install.log
< roconnor>
fanquake: is it available online somewhere?
< 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?
< fanquake>
*roconnor
< 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.
< roconnor>
ok ty
< achow101>
besides deadlock, is there any reason that a lock is not able to be acquired?
< 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.
< achow101>
roconnor: why would there be no advantage?
< roconnor>
Maybe I don't understand what ccache does. I thought it avoid recompiling object files that have been compiled before.
< achow101>
roconnor: yes, it does
< achow101>
gitian builds multiple binaries for each OS target
< achow101>
well, just the linux one actually
< roconnor>
different OS targets? can you give an example?
< 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"
< achow101>
Windows does the same: HOSTS="i686-w64-mingw32 x86_64-w64-mingw32"
< achow101>
osx technically does the same, but only has one host
< roconnor>
how can it do x86 and arm and yet share object files?
< achow101>
oh right, hmmm
< roconnor>
If the ccache offers no advantage, perhaps it should be removed from the gitian builds.
< sipa>
achow101: if something elwe holds the lock already, that does not necessarily imply a deadlock
< wumpus>
roconnor: ccache is not used in the gitian builds at all, just for travis
< wumpus>
together with travis' caching it makes PRs and new commits compile faster
< 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
< wumpus>
intermittent error in sendheaders.py test_null_locators, assert_equal(test_node.check_last_announcement(headers=[tip_hash]), True)
< meshcollider>
wumpus: yep I've seen that one before
< meshcollider>
Locally
< wumpus>
indeed, this was locally too
< wumpus>
will create an issue
< meshcollider>
Encountered it yesterday while working on 11667
< wumpus>
I've seen it on 11651, but makes no sense that it would be caused by that change
< Lauda>
Does 0.15.0 have any bugs that makes the software crash?
< Lauda>
Any known*.
< meshcollider>
Lauda: 0.15.0 or 0.15.0.1?
< Lauda>
0.15.0
< Lauda>
Mine crashed several times with "Error eading from database"
< Lauda>
over the last few days. Runs okay for a while and just crashes
< Lauda>
updating to 0.15.0.1 right now to compare
< wumpus>
0.15.0 can crash due to corrupt peers.dat, but apart from that, no
< wumpus>
this was solved in 0.15.1 (not 0.15.0.1)
< Lauda>
Interesting. I wonder what could be causing this.
< Lauda>
Erm, sorry. Updating to 0.15.1
< wumpus>
without further context it sounds like a hardware issue of some kind
< 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,...)
< 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
< wumpus>
most amusing was the USB stick that randomly toggles bits on heavy usage
< wumpus>
can you pastebin the detailed error?
< 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
< Lauda>
From the debug log?
< wumpus>
yes
< wumpus>
we really need to add a filename to the leveldb checksum mismatch errors, so people can send to file to be analyzed
< Lauda>
^
< wumpus>
I did that locally a long time ago but don't think I still have it
< Lauda>
Shouldn't be too hard?
< wumpus>
depends on whether that context is known at the place the exception is thrown
< wumpus>
oh this seems to be easy
< wumpus>
but it does need some leveldb changes, e.g. currently RandomAccessFile has no way to get the file name back
< wumpus>
still easy changes though
< wumpus>
I'll have a shot at it
< bitcoin-git>
[bitcoin] laanwj opened pull request #11674: leveldb: Add filename to corruption errors (master...2017_11_leveldb_report_errors) https://github.com/bitcoin/bitcoin/pull/11674
< bitcoin-git>
bitcoin/master e0fc4a7 Aaron Clauson: Updated Windows build doc for WSL/Xenial workarounds.
< bitcoin-git>
bitcoin/master 7383d77 Aaron Clauson: Updated instructions for Windows 10 Fall Creators Update.
< bitcoin-git>
bitcoin/master 7fbf3c6 Wladimir J. van der Laan: Merge #11438: Updated Windows build doc for WSL/Xenial workaround...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11438: Updated Windows build doc for WSL/Xenial workaround (master...wslbuilddoc) https://github.com/bitcoin/bitcoin/pull/11438
< 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
< Victorsueca>
any clue of what's going wrong?
< wumpus>
isn't WSL an ever enduring source of issues, just use a real linux or BSD already :)
< Victorsueca>
welp, I used to compile it succesfully on WSL with ubuntu 14
< 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
< wumpus>
so many "fixes" to that doc
< Victorsueca>
yeah, totally agree, WSL is just a pain in the arse
< Victorsueca>
I still have the Ubuntu 14 WSL on another machine and I can use that to build it
< 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
< wumpus>
the more it mutates into some hybrid monster
< Victorsueca>
Basically, getting something that already exists and doing exactly the same but in incompatible ways
< Victorsueca>
has Microsoft ever done anything other than that? ;)
< wumpus>
embrace and extinguish (tm)
< Victorsueca>
Currently building 0.15.1 on the old WSL, works fine as always
< Victorsueca>
but I'd like to get the new one working for damn once
< Victorsueca>
So, more specifically, it's asking for automake-1.14
< Victorsueca>
but the distro repositories only have automake-1.11 and automake-1.15
< wumpus>
it shouldn't require a specific automake version. Did you perhaps upgrade something, without cleaning your tree?
< Victorsueca>
could it be just a version missmatch?
< wumpus>
sometimes there are leftovers from scripts generated from old versions in the way
< Victorsueca>
nope, it's a fresh WSL, just ran the commands stated on the windows build doc
< Victorsueca>
except the Xenial workaround
< Victorsueca>
which I did later today when the doc updated
< wumpus>
the xenial workaround changes to some newer versions using backported packages, that's exactly the change that can result in what I said
< Victorsueca>
thought so, it was worth mentioning that
< Victorsueca>
so, now how do I clean this?
< wumpus>
I'd move away the depends/sources directory, than git clean -f -x -d, move it back, and start over
< Victorsueca>
wumpus: done, still same problem
< wumpus>
ok... no clue in that case
< Victorsueca>
I think it's worth mentioning also that I tried to make the depends before the xenial workaround, and got the same issue
< Victorsueca>
I hoped that the workaround would fix it
< wumpus>
the workaround is for generating broken executables
< wumpus>
it should still build...
< Victorsueca>
hmmm
< Victorsueca>
just noticed that ccache built successfully
< Victorsueca>
it fails when it tries to build native_protobuf
< Victorsueca>
wumpus: I think I found the problem
< Victorsueca>
/depends/work/build/x86_64-w64-mingw32/native_protobuf/2.6.1-38b82cbb6fc on line 81
< Victorsueca>
it's trying to run automake-1.14
< wumpus>
can you pastebin the file plesae?
< Victorsueca>
on the way
< wumpus>
that's a strange file name, are you sure it's called like that, without an extension?
< Victorsueca>
nope, it's a dir, I think the file is Makefile.in
< Victorsueca>
I'll just pastebin the console so you can tell me for sure which file should I send
< 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
< ossifrage>
It seems that 3 of my segwit addresses all have lost their labels
< ossifrage>
It looks like maybe 'addsegwitaddress' for an address that already has a segwit address will clobber the existing label
< sipa>
ossifrage: it shouldn't touch the original address
< sipa>
but the witness address returned by addwitnessaddress won't have a label
< 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
< 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
< sipa>
ossifrage: yes, how is that related to the labels
< sipa>
addwitnessaddress does not support labels
< 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?
< sipa>
addresses created by addwitnessaddress never have a label, so i don't think that situation is even possible
< sipa>
yes, but there's no way the address would have had another label before the call, i think?
< sipa>
or is there some account related call to modify a label after creation
< achow101>
sipa: he added a label himself using some other call
< 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
< sipa>
ah
< sipa>
that's what i was missing
< ossifrage>
sipa, I gave them a label after I initially created them... then that label was clobbered by doing an addwitnessaddress a second time
< ossifrage>
I added the label in the UI by double clicking on the label text and changing it.
< sipa>
right, addwitnessaddress sets it to ""
< sipa>
you could change it back, i guess
< ossifrage>
I did, it just was a bit confusing
< 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
< 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?
< BlueMatt>
eck: thats when the cache flushes..........
< eck>
i see, thanks
< sipa>
it's both a cache and a buffer
< gmaxwell>
it's mostly a buffer. :) the performance elements of the caching aren't that significant.
< LumberCartel>
A cache is strategically managed buffers.
< LumberCartel>
At least that's how I've always understood it.
< 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?
< gmaxwell>
yes.
< gmaxwell>
it will flush once a day if not earlier due to size
< 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
< 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)
< karelb>
Well seems I am not the first one to want to reset it - #4416 :)