< achow101>
michagogo: I made an issue here https://github.com/devrandom/gitian-builder/issues/128 about it. There is also a corresponding issue about this in lxc/lxc. Also, if you go back to IRC logs around that same time (end of august), you should be able to find some info I said there about the same problem
< michagogo>
01:17:13 <GitHub81> bitcoin/0.13 a5cef7b Wladimir J. van der Laan: Bump version to 0.13.1
< michagogo>
achow101: hmm. I seem to remember (from quite a while back…) that I tried doing it on Xenial and failed too
< michagogo>
I feel like I might have gotten past the shm thing just to have it fail a different way
< michagogo>
Or maybe I'm misremembering
< michagogo>
Works for me on the Trusty Tahr, though
< * sipa>
realizes that he never knew what the part after 'Trusty' in the ubuntu version name was
< achow101>
Maybe I'll try it in a VM with trusty then. I've been running 16.04 which is what I do the builds on
< achow101>
it previously worked on 15.10 for a while then broke
< achow101>
but it would be great if this could be fixed since multiple people have run into the same problem recently
< achow101>
for some reason I can't do the osx build now
< achow101>
it is failing at installing stuff. the install.log says "E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution)."
< achow101>
well, it isn't just osx apparently, something is broken on my gitian
< achow101>
michagogo:
< michagogo>
But you somehow managed windows and Linux? o_o
< achow101>
I just tried to do windows and linux again and it failed.
< achow101>
I guess it got through them before it broke
< michagogo>
sipa: yep. I wonder if I remember them all
< michagogo>
achow101: odd. I wonder what could have changed
< achow101>
my computer almost crashed during the build since I tried starting a vm. Maybe that corrupted something in memory which corrupted something on disk?
< achow101>
wtf. I just redownloaded and setup gitian and now it's asking me for the password for the vm in order to do stuff
< gmaxwell>
My voice is my passport. Verify me.
< tulip>
achow101: you mustn't have had your pentagon configured correctly.
< michagogo>
achow101: the VM you're running gitian in?
< michagogo>
The same one as before?
< achow101>
the vm that gitian creates
< michagogo>
Hmm.
< michagogo>
It shouldn't be doing that, I think
< tulip>
I managed to find two NODE_SEGWIT peers with #8949 but I don't know if that's luck or not.
< michagogo>
Did you create the previous one the same way?
< achow101>
yes
< michagogo>
🤔
< achow101>
I used my gitian build script with the setup option to setup the gitian environment. the script is in the repo in contrib/
< tulip>
2016-10-18 01:43:35.372446 connect() to [::0.0.255.255]:20720 failed: No route to host (65)
< tulip>
gmaxwell: I guess this means there's only junk in addrman with the NODE_WITNESS service?
< tulip>
no wait, there we go. from a very old node state with no sensible peers to 4 NODE_WITNESS peers in about 6 minutes.
< gmaxwell>
tulip: thats better than I expirenced.
< gmaxwell>
I have one node that after being upgraded, run for three houres, and restart... has no nodewitness peers.
< gmaxwell>
(thus the PR that I opened)
< tulip>
gmaxwell: that's with your patch.
< gmaxwell>
ah okay!
< tulip>
it had no NODE_WITNESS peers beforehand.
< gmaxwell>
yea, with the patch it will be pretty much guarenteed to find some... often 4. :)
< tulip>
curious why we are even trying to connect to nodes with port zero, is anyone really going to be running a privileged port Bitcoin node?
< tulip>
(I assumed 0-1023 would be masked out entirely)
< gmaxwell>
well we only try connecting to non-standard ports if we've been failing to connect for a while, but port 0 is braindamaged.
< gmaxwell>
someone might plausably run a bitcoin node on port 80 or port 443 since it's a little more likely to make it through firewalls.
< gmaxwell>
port 0 is just stupid though. We should probably filter out port 0 from ever going into addrman.
< morcos>
gmaxwell: at the risk of beating a dead horse, can you try again to explain to me the logic behind writing down the mempool every 10 mins?
< gmaxwell>
every ten minutes I care less about than at clean shutdown.
< morcos>
i can somewhat reluctantly accept that it might be useful on shutdown, and could see it being beneficial on demand (maybe via rpc)
< morcos>
but writing it every 10 mins just seems like a way to clog up your node doing useless crap
< gmaxwell>
the 10 minute thing is something sipa added that wasn't in my requirements document. :P
< morcos>
and in particular if somehow some bad tx in your mempool crashed your block creation code, maybe you don't want to reload with that mempool (but i guess you could do that manually)
< gmaxwell>
I don't think we disagree. (The goals in saving it: prevent being utterly cold on newly recieved blocks after you do a simple restart for config changes, to not lose your transaction prioritization, to not reject dependant transactions as orphans which you never recieve, to not needlessly end up mining small blocks for an hour after a boring restart...)
< gmaxwell>
well if you're crashing you can delete the file. I'm not particularly worried about that, and the import path goes through the normal accept logic, it's not just crammed back into the mempool. (meaning a network peer could give you the same garbage)
< morcos>
ok, i guess just making your node to extensive disk access every 10 minutes gives me the heebie jeebies
< gmaxwell>
the lack of the saving/loading also means that all of us spend far too much time messing around with nodes in unrepresentative states, throwing off benchmarking, and risking that we don't see issues that only show up with the mempool nice and fat.
< morcos>
instead of roughly writing 1MB every 10 mins, now you'll write 300
< gmaxwell>
Yea, well, I'm not a fan of the 10 minute thing. I'd be happier if it was on shutdown and had a rpc to trigger, and if you want 10 minutes you can call the rpc yourself. :)
< morcos>
i would be way happier with that
< gmaxwell>
I think the rational for the 10 minute saves is to make it useful across crashes. Which has merit, but-- I'd rather just not crash. :)
< morcos>
looking back at the PR discussion, i think sipa wanted prioritization info to be saved in the event of a crash
< morcos>
but do people actually have nodes that crash?
< morcos>
is that a thing?
< gmaxwell>
horrifyingly, yes. But we don't have to embrace all of reality.
< gmaxwell>
(a main audience for this is miners, some of whom may have custimization that crashes; or be running on mystermeat hardware and not really appricate that it shoud not EVER crash)
< morcos>
ok.. i'll comment on the PR with my thoughts then since they don't seem too objectionable
< gmaxwell>
I'd love to have some crash detection wrapper around bitcoin core that told people "THIS SHOULD NEVER CRASH. IF IT CRASHES WE WANT TO KNOW _NOW_" .. but unfortunately virtually all crashes I've seen from users are bad hardware, and we don't really want to know. :)
< morcos>
heh, i offered one of the industry exec's a 1 BTC bounty for every non hardware caused crash he had on his bitcoinds because he was complaining bitcoind crashes all the time.
< morcos>
that was like a year ago, no claims yet.
< gmaxwell>
:)
< gmaxwell>
I've heard those sorts of claims going around, and wasted a lot of time trying to find ways to make it crash.
< luke-jr>
heh
< luke-jr>
I wonder if the hardware-induced crashes are such that we can detect them with a repeat easily
< luke-jr>
(and then complain to the user that their hardware is certainly faulty)
< gmaxwell>
"Non-determinstic hardware detected (this is bad)"
< luke-jr>
"It's not that we don't like you overclocking, but rather that your overclocking has actually given us the wrong answer to math, which is kinda important to Bitcoin working right."
< TD-Linux>
probably not without crash telemetry, which I think users would be pretty averse to...
< luke-jr>
btw, +1 on RPC trigger to write mempool before exit
< luke-jr>
if someone wants to write every 10 minutes, they can cronjob it
< TD-Linux>
also the existing PR fsync()'s on every write, which is probably fine on exit but is not great for interactive performance, especially on linux
< * luke-jr>
wonders how much performance gain we'd get by using the file-specific fsync calls
< TD-Linux>
luke-jr, it already does, the problem is on Linux other accesses will be queued behind the gigantic write
< tulip>
TD-Linux: manual telemetry can be a thing, sort of. rather than asking users to dig around for things in a debug.log you can make a cohesive blob and a message that says "report this to your handler if you want to".
< luke-jr>
TD-Linux: hmm, some filesystems on Linux seem to have another ioctl for fsyncing a specific file; I guess the normal one does it to a specific fd as well.. not sure what the difference is
< TD-Linux>
(hint: pick the "aggregate on" drop down and choose cpu info)
< gmaxwell>
morcos: more like 150MB of data, fwiw, ... mempool limit is on the in memory form, saving it out currently uses the p2p serilization.
< cfields_>
gitian builders: v0.13.1rc1 detached sigs are pushed
< gmaxwell>
wtf. why does sendtoaddress' help have an actual bitcoin address in the example? O_o we worked hard elsewhere to keep real addresses out of examples.
< gmaxwell>
hmph. a long time ago in fact.
< tulip>
TD-Linux: you're right, bitcoin users wouldn't appreciate that much
< tulip>
yuck, the sentoaddress "example" is even a political one.
< tulip>
well, no political but it's for a "cause" which isn't ideal.
< luke-jr>
there are probably worse causes it could be
< gmaxwell>
yea sure. still. obviously it should be my address there
< btcdrak>
well my laptop with HDD is 314572800 bytes (315 MB) copied, 0.892623 s, 352 MB/s
< btcdrak>
that's only a 5200rpm thing too
< luke-jr>
I did it on btrfs since I expect poorer performance from it
< luke-jr>
but a relatively new drive, so
< TD-Linux>
btcdrak, that's implausibly high for a spinning disk. you're not syncing afterwards
< * luke-jr>
also forgot to sync :x
< luke-jr>
real 0m6.677s
< luke-jr>
so 47 MB/s
< luke-jr>
(sync before starting it too)
< TD-Linux>
right, I'm not so much concerned about speed as the impact on other i/o while that is happening. I think it's probably acceptable, but it's possible to do better
< btcdrak>
why does actual sync matter? Why are we concerned about the background processes of the host computer?
< paveljanik>
btcdrak, it is 300+MB in the default config. And in the typical use case (nonstop, no failure run), we write, write, write and do not use the written data at all.
< paveljanik>
slowly killing the disks...
< luke-jr>
btcdrak: background process I/O is dreadfully annoying
< gmaxwell>
150 MB, not 300.
< gmaxwell>
But creating a 3 second IO stall (luke's example) would be unfortunate. :)
< luke-jr>
gmaxwell: 7 seconds, it turns out
< gmaxwell>
besides, writing the mempool is just wasting SSD write endurance. Bitcoin Core doesn't crash. If you're in some weird enviroment where you care, you can call the rpc yourself.
< luke-jr>
are we locking the mempool while it writes too? :x
< TD-Linux>
luke-jr, the patch does an in-memory copy first to make the lock time minimal
< luke-jr>
ah, ok
< luke-jr>
though that alone might annoy some users
< paveljanik>
in memory copy?
< GitHub141>
[bitcoin] luke-jr opened pull request #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help (master...gbt_help_update) https://github.com/bitcoin/bitcoin/pull/8951
< paveljanik>
So if I have 1G mempool, bitcoind will allocate one more G?
< paveljanik>
hmm
< luke-jr>
^ please tag for backport
< gmaxwell>
paveljanik: No. the transactions themselves are shared pointers.
< btcdrak>
gmaxwell: is 8949 aimed for 0.13.1 backport? (seems like it should be).
< gmaxwell>
Yes, assuming people find it acceptable for master.
< gmaxwell>
I think it's needed.
< gmaxwell>
at least my expirence and tulip's is that absent it, 0.13.1rc1 is prone to not getting any witness peers.
< gmaxwell>
(I somewhat expected this, but we didn't see it on testnet in part because testnet doesn't have that many healthy working peers to begin with)
< btcdrak>
gmaxwell: I can confirm the same problem
< gmaxwell>
In any case, my PR is reported to resolve the issue.
< cdecker>
Checking the hashes produced by gitian I noticed that jl2012 produced different results
< jl2012>
which one?
< cdecker>
The linux hashes
< jl2012>
i didn't check. Let me see
< wumpus>
if you are really masochistic you can try to build bitcoin core with MSVC, most of the hassle is getting eventhing into the build system + setting config.h parameters manually
< wumpus>
I did so in 2012 or so, but that was on my wxp VM which I've nuked by now so don't have any of that anymore
< tulip>
on my unpatched IPv4-only node I'm seeing 2 NODE_WITNESS, but I think that's a function of being in a busy ASN and having a low number of non-junk peers to begin with.
< jl2012>
cdecker: everyone got the same except me? I'll try again
< cdecker>
And I seem to have botched the windows build myself
< cdecker>
:-)
< Victorsueca>
wumpus: yeah, i'm going to do it on a Linux VM, but the curious thing is that when I tried it on windows the failure seemed to be at the directory name characters
< Victorsueca>
i was getting error like directory does not exist or character "|" being unexpected
< luke-jr>
Victorsueca: were you trying to build in a path with spaces?
< tulip>
(lots are fake-looking bitcoinj, and someone who took the time to recompile 0.13.1 with a 0.9 subversion)
< luke-jr>
tulip: AWS BitcoinJ is bogus obviously
< gmaxwell>
tulip: I posted a banlist specifically for those things.
< sipa>
that's to build for windows, not on windows
< Victorsueca>
sipa: i'm trying to build for windows on windows
< sipa>
Victorsueca: good luck
< sipa>
but none of the existing documentation will be of any use
< Victorsueca>
I have a linux VM anyway, but i'm trying to see if it's possible to build on windows without having to edit too much files manually or being a pain in the arse
< luke-jr>
Victorsueca: it might be possible in MSYS, but don't expect anything to just work
< sipa>
Victorsueca: unless you're experienced with developing software using a mingw/msys build environment already, i expect that will take days of work to figure things out
< Victorsueca>
sipa: that sounds like a pain in the arse, i'll just use the linux VM then
< sipa>
yes, building via cross compiling is the only supported mechanism
< michagogo>
Victorsueca: are you on Windows 10?
< Victorsueca>
michagogo: yep
< michagogo>
Because then you could cross compile for windows on Ubuntu on Windows
< michagogo>
No need for a VM
< michagogo>
(It's kinda amusing that you're cross-compiling for Windows on a Windows machine…)
< Victorsueca>
michagogo: yeah lol
< Victorsueca>
but there are no docs for windows compiling AFAIK
< michagogo>
Actually, maybe that was already possible -- does anyone know if anyone's tried cross-compiling for Windows in Cygwin?
< michagogo>
Victorsueca: that's the thing
< michagogo>
If you do it in Ubuntu you just follow the Linux instructions
< Victorsueca>
i'll just use the VM
< jtimon>
Ubuntu on windows to build for windows, hehe
< michagogo>
(I don't think much has changed with the depends/build system since then?)
< michagogo>
Victorsueca: well, doing it in Ubuntu On Windows should be pretty much identical to doing it in the VM AFAIK
< wumpus>
Victorsueca: I pointed you to: https://github.com/bitcoin/bitcoin/pull/8935 right? that adds instructions for building on windows 10 using the built in ubuntu 14.04 subsystem
< wumpus>
would help if someone tested those steps
< Victorsueca>
wumpus: testing required? sure, I'll try it
< wumpus>
it *looks* easy
< sipa>
seriously, who would have believed you if 10 years ago someone told you that a future version of windows would ship with a built-in ubuntu environment...
< sipa>
it still boggles my mind how much changed
< wumpus>
yes. it's extremely surprising to me, even now. I intend to try it out but haven't found the time yet
< wumpus>
indeed
< wumpus>
the list of top OS-es includes a Linux and a BSD derivative, and windows is not doing that well
< wumpus>
no one would have believed that in the 90's, heck not even any science fiction precited it :)
< Victorsueca>
linux on windows feels much like the universe is going to implode
< GitHub192>
[bitcoin] pedrobranco opened pull request #8952: Add selection options to listunspent RPC call (master...enhancement/improve-rpc-listunspent) https://github.com/bitcoin/bitcoin/pull/8952
< michagogo>
14:20:40 <sipa> seriously, who would have believed you if 10 years ago someone told you that a future version of windows would ship with a built-in ubuntu environment...
< michagogo>
AIUI it's more like a built-in, disabled-by-default, hook that can then proceed to download an Ubuntu environment
< michagogo>
i.e. you first need the computer in dev mode, then you go to the "enable/disable optional features" panel - same place you can enable things like built in telnet client, and all kinds of other niche stuff
< michagogo>
Then that installs the "bash" stub that kicks off the install proces
< michagogo>
wumpus: and yeah, from what I've read it seems there shouldn't really be any reason for it not to work
< michagogo>
I mean, it's a full Ubuntu environment, running actual Linux binaries
< michagogo>
And the software build process doesn't exactly involve any exotic syscalls...
< GitHub22>
bitcoin/0.13 3f508ed Wladimir J. van der Laan: rpc: Generate auth cookie in hex instead of base64...
< GitHub22>
bitcoin/0.13 685e4c7 Matt Corallo: Remove bogus assert on number of oubound connections....
< michagogo>
Got WSL up and running, doing what I said before (13:33:46 <michagogo> As of 0.10, this is all you needed to do to cross-compile for Windows: https://www.irccloud.com/pastebin/W6gIBKMf)
< michagogo>
So far so good -- needed to install make
< michagogo>
Depends is running now -- managed to build ccache, so that's good -- downloading boost right now
< achow101>
michagogo: I've been able to compile both linux and windows binaries on WSL
< achow101>
but I haven't gotten gitian to work yet
< * wumpus>
would be really surprised if you get gitian to work as-is. You could try to launch the descriptors without VM (as michagogo said), and build like that, after all it's the same OS as unsed in the internal VM in gitian. But you may have some work getting the same output as others
< michagogo>
wumpus: not what I meant
< michagogo>
I meant, run gitian itself in WSL
< michagogo>
And use VBox
< wumpus>
you can't run gitian in WSL, there's no virtualization support
< * luke-jr>
wonders if WSL can call Windows-build qemu
< michagogo>
No, but maybe it can control native vbox
< michagogo>
Or ^^
< wumpus>
luke-jr: indeed, if you can launch native exes
< wumpus>
windows qemu is strange though
< luke-jr>
at least in the kqemu days, IIRC there was virt support for qemu on windows
< wumpus>
I tried that once, and was unable to get accelerated virtualization to work
< luke-jr>
kqemu is pretty old stuff :p
< luke-jr>
pre-VT-x
< michagogo>
Hrm
< wumpus>
it may need some special driver that needs to be installed as admin, dunno
< michagogo>
Nope, it looks like it's a full environment
< michagogo>
Looks like within WSL it's Linux-only
< michagogo>
I wonder if there's a way to workaround it
< achow101>
wine in wsl ;D
< michagogo>
Hmmmmm
< wumpus>
hahha OSS people aren't happy until they can do a full emualtion roundtrip
< Victorsueca>
would it be possible to do WSL on Wine on WSL.... :P
< Victorsueca>
Inception!
< wumpus>
:')
< wumpus>
shouldn't be to difficult to support the WSL syscalls in wine
< michagogo>
Wine doesn't want to install
< michagogo>
Looks like a bunch of i386 packages not coming in
< wumpus>
I'd expected so
< luke-jr>
wumpus: lol
< michagogo>
I wish apt were better at showing actual cause
< michagogo>
It says winehq-devel : Depends: wine-devel
< timothy>
hi, do you think can be good to add support for rpc to tor?
< timothy>
actually only 8333 is supported
< wumpus>
not just a matter of sudo dpkg --add-architecture i386 ?
< michagogo>
(Unmet dependency)
< michagogo>
wumpus: I did that first
< timothy>
(integrated, I mean. ofc you can use the "standard" tor feature to add rpc port)
< michagogo>
And it says "you have held broken packages", which is misleading
< michagogo>
Anyway, wine-devel then depends on wine-devel-i386
< wumpus>
timothy: if you really want to expose your RPC port on a Tor hidden service that's possible
< michagogo>
And that, in turn, depends on a whole lot of :i386 packages
< wumpus>
timothy: wouldn't advice doing it by default though, a lot of scope to mess up
< timothy>
wumpus: actually I use it only for opentimestamps
< michagogo>
Some say "but it is not going to be installed"
< timothy>
I don't have any wallets here
< michagogo>
But then some say "but it is not installable"
< wumpus>
at the least don't give the onion address to anyone (or link it anywhere public) otherwise it will be picked up and probed by projects like onionscan
< michagogo>
Maybe I could poke at it and figure out what's going on, but a. I don't really care enough
< michagogo>
And b. I doubt I'd be able to figure it out anyway :P
< timothy>
wumpus: ofc it's only for private use and on another port (not 8332)
< wumpus>
if you have no wallet on the node it's certainly safer, though still: RPC is not a public interface, it's not as hardened against DoS and other attacks as the P2P
< michagogo>
Would be nice if depends could multitask
< timothy>
wumpus: so do you suggest me to add another layer like stunnel with client cert?
< wumpus>
timothy: for private use it's fine
< luke-jr>
michagogo: it can't?
< wumpus>
timothy: no need for that, tor has hs security built-in, look into "hidden service authentication"
< wumpus>
with HidServAuth something you can restrict who can connect to your hidden service with certain keys
< michagogo>
luke-jr: I mean, maybe -jx works within a build
< michagogo>
But I mean, for example, download and build different packages in parallel
< timothy>
wumpus: not bad, thank you
< luke-jr>
michagogo: make -jN in depends/?
< michagogo>
luke-jr: I did that
< michagogo>
Maybe each individual compilation job is multitasking
< michagogo>
But it's doing one package at a time
< luke-jr>
weird
< michagogo>
So as OpenSSL.org is feeding me the file at 1000 bytes a second, it's holding up the whole thing
< michagogo>
The ones for Bitcoin are downloaded and built by those commands
< michagogo>
(The cd depends;make HOST...)
< molz>
oh..
< michagogo>
The apt-get command installs everything that the build process needs
< michagogo>
Like I said, if you install WSL completely fresh from scratch (or for that matter, "real" Ubuntu 14.04...), those commands are everything you need to produce Bitcoin-qt.exe
< michagogo>
(And all the others)
< michagogo>
wumpus: what is test_bitcoin-qt.exe supposed to do?
< michagogo>
It seems to just return to the command line immediately
< michagogo>
No output
< sipa>
run the bitcoin-qt unit test
< michagogo>
sipa: is it supposed to output anything, like test_bitcoin.exe does?
< wumpus>
it should print something about Start Testing Finished Testing, normally
< sipa>
unsure
< michagogo>
Doesn't look like it?
< wumpus>
but I've never tried it in windows
< molz>
michagogo, ok i'm not on win10, can the irccloud guide be used on Ubuntu 14.4 VM ?
< michagogo>
I just get the prompt back
< molz>
i'm installing Ubuntu 14.4 on the VM right now
< wumpus>
maybe it's accidentally compiled as a UI subsystem instead of console subsystem executable?
< michagogo>
molz: yeah, those commands should work on a fresh install of 14.04
< sipa>
wumpus: maybe not accidentally... a qt app may need to be gui
< wumpus>
sipa: it doesn't need to be, console will just open a console at startup, it can still use the UI APIs
< sipa>
ah
< wumpus>
(though none of the Qt unit tests does anything with UI)
< michagogo>
We don't seem to ship test_bitcoin-qt.exe
< wumpus>
that's on purpose - it's silly right now
< michagogo>
The win64 zip for 0.13.0 from Bitcoin.org has test_bitcoin.exe but not -qt
< wumpus>
it's a huge executable when statically linking, pulling in much of qt, for no good reason
< michagogo>
So I'm guessing it's not something wrong with this build setup
< wumpus>
yes, test_bitcoin.exe is suposed to be in there
< wumpus>
I'm guessing the same
< michagogo>
If I run Bitcoin-Qt.exe with a -datadir argument, does it leave traces of itself anywhere but that directory?
< sipa>
it shouldn't
< wumpus>
yes - in the registry
< wumpus>
bitcoind.exe shouldn't, though
< michagogo>
Anything outside a simple key named for the app?
< wumpus>
no, it's one 'directory' named bitcoin-qt or such
< wumpus>
with qt settings
< michagogo>
Okay, that's tolerable
< GitHub53>
[bitcoin] mruddy opened pull request #8955: trivial: update 0.13.0 release note info on linux arm builds (master...relnote) https://github.com/bitcoin/bitcoin/pull/8955
< Victorsueca>
cpp not working here
< Victorsueca>
error C++ processort /lib/cpp fails sanity check
< Victorsueca>
processor*
< sipa>
what are you doing
< michagogo>
WSL-built 0.13.1rc1 is running!
< wumpus>
michagogo: HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt and HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt-testnet
< michagogo>
Also: looks like tailf doesn't work in WSL
< michagogo>
(Oh, right -- rc1 still calls itself .0)
< wumpus>
yes
< michagogo>
Victorsueca: did you install g++?
< michagogo>
Pretty sure that was in my paste
< wumpus>
the 0.13.0 ones are rc1, 0.13.1 ones are 0.13 branch, 0.13.99 is master. It checks out
< Victorsueca>
michagogo: I'm not following your paste, i'm using the docs
< Victorsueca>
thanks,i'll try that
< michagogo>
Maybe we should copy my paste to the docs
< wumpus>
sanity check failures in configure 99% of the time mean that the compiler just isn't installed
< michagogo>
(Also, maybe go over and check that that is the absolute minimum)
< wumpus>
(unless you happen to be overriding the compiler to a static analysis tool etc)
< Victorsueca>
seems to be working now
< Victorsueca>
nope, autoconf is missing
< jlopp>
I asked these questions in wizards yesterday; crossposting for more visibility:
< jlopp>
I'm trying to better understand the purpose and future use of checkpoints in Bitcoin. My understanding is that the checkpoints are in place in order to prevent attackers from spamming nodes with low PoW block headers at low chain heights. And that a side effect of checkpoints is a performance speedup in initial block download due to skipping signature verification.
< jlopp>
Though I thought that since libsecp256k1 drastically increases signature validation performance, the speedup is negligible now.
< jlopp>
back in 2013, gmaxwell said "When headers first syncing is merged, just by adding a "must be this tall" minimum sum difficulty check we'll be able to remove checkpoints for all DOS purposes, and we'll also be able to remove them for syncing acceleration (using random sampling for ECDSA in the deeply buried chain)."
< wumpus>
checkpoints really need to go, and are not part of the security model, however they are still used for three of so tasks which haven't been replaced with other implementations
< wumpus>
there's always the -checkpoints=0 option if you can't wait for them to be removed
< jlopp>
Am I correct in stating that it wouldn't be possible to feed any alternative chain of blocks to a full node if that alternative chain's starting point was prior to block 295000? It's also not clear to me why there are 13 checkpoints rather than just the last one at 295000
< BlueMatt>
so....fibre....want more than one group/person to run a public network based on it
< Victorsueca>
the docs don't really explain what libraries you should get
< BlueMatt>
also want to shut down the rn on dec 1
< BlueMatt>
so that leaves....a week or two to get networks up
< sipa>
BlueMatt: maybe someone at dci?
< BlueMatt>
that was suggested, I can reach out to neha and see if there are any students interested in running one
< BlueMatt>
I'm happy to run one, but want to use real servers which implies no longer wanting to pay for it out-of-pocket
< BlueMatt>
(and only if there is an additional one run by someone else)
< neha>
We can probably run one. What are the bw/hard drive/mem/etc requirements?
< BlueMatt>
neha: i mean a network, not node
< BlueMatt>
which means dedicated servers roughly in similar locations as those on the map at http://bitcoinrelaynetwork.org/
< nsh>
cc musalbas
< neha>
a network starts with one node? :) ok let me know what the requirements are and we can talk about it. there probably will be student interest
< BlueMatt>
probably 100-200/mo per server (say, 5 of them + some auxillary stuff) if you're lazy about finding deals, maybe as low as 50
< sipa>
units?
< sipa>
what is a mo
< wumpus>
month
< BlueMatt>
usd/cad/eur/gbp/etc
< BlueMatt>
any of them are valid
< sipa>
ah
< neha>
could we get multiple universities to run nodes as part of one network?
< BlueMatt>
neha: because of the weird trust-all-nodes-in-the-network requirement if you want to run with cut-through on, thats....awkward
< BlueMatt>
neha: i mean could turn off the cut-through and do it
< BlueMatt>
if its on a fast-single-threading server with good peak bw that might be ok
< sipa>
the only issue is that the nodes within the network could dos each other, right?
< BlueMatt>
if you do trusted mode any node can break propagation for a block to the entire network
< wumpus>
so it's mainly miners using this right: aren't any miners/mining pools interested in setting up a network like this?
< neha>
do the nodes need to be geo-distributed?
< neha>
(i need to read more about fibre)
< BlueMatt>
wumpus: i have no idea why miners seemingly only ever provide lip-service to things like this :/
< wumpus>
BlueMatt: I was afraid you were going to say that
< sipa>
wumpus: arguably, it's more in the interest of the network at large that such a network exists, as opposed to miners running their own private setups that are harder to enter as an outsider
< BlueMatt>
wumpus: well, i do know, for many of them it doesnt matter because they just do spy-mining
< BlueMatt>
neha: otherwise how are you propagating around the world? :p
< sipa>
BlueMatt: neutrinos.
< BlueMatt>
oooo bitcoin-over-neutrino
< BlueMatt>
might want to get ip-over-neutrino to work first, though
< neha>
this might be a good thing for a network of universities to do.
< neha>
don't need to worry too much about schools (intentionally) dos'ing each other
< BlueMatt>
neha: indeed, universities tend to have good low-latency bw between each other, too
< Victorsueca>
ip-over-dark-matter is better
< BlueMatt>
neha: well, I think it'd still need to run in non-trusted mode
< BlueMatt>
neha: you do need to worry about someone randomly fucking with one node to screw over block prop. for a given pool at unis
< BlueMatt>
security at uni-hosting places tends to be.......
< Victorsueca>
deficient? is that the word you're searching?
< wumpus>
Victorsueca: ip-over-microwormholes
< sipa>
BlueMatt: can you have two tiers? different orgs running their own nodes, internally cut-through, but not cut-through across orgs
< BlueMatt>
sipa: yes
< Victorsueca>
wumpus: lol
< sipa>
BlueMatt: and then have maybe one org colocate one of their nodes inside or nearby another org's node
< Victorsueca>
wumpus: with that you could recieve data even before it's sent
< BlueMatt>
sipa: not sure how required the second part is...you just end up having a reconstruction-latency on the first hop into an org always
< sipa>
right
< BlueMatt>
sipa: fibre is rather packet-loss-insensitive :)
< sipa>
BlueMatt: well, in any case, it's probably easier to get people interested in this technology and infrastructure if you first ask to run just a node in an exisitng network
< BlueMatt>
sipa: true
< neha>
agree
< neha>
it would be helpful to think about how interested parties at a school could just stand up a node as part of an existing network
< neha>
we have almost "free" access to compute resources, but only locally.
< BlueMatt>
hmm, for that to be useful I think I'd have to run an actual network and let people peer into it
< BlueMatt>
which I'd gladly do, but dont want to funt it myself anymore if I'm gonna stand up a real network
< neha>
bitcoin foundation?
< neha>
or us i suppose depending on costs
< BlueMatt>
they dont have any $$$ left
< neha>
wouldnt your "network" be very small, with most of the resources provided being from people peering?
< michagogo>
Victorsueca: is there something wrong with that last gist?
< michagogo>
And in terms of all the libraries, if you mean the ones that go into Bitcoin Core (OpenSSL, Qt, boost, etc.), the whole beauty of the depends system is that you don't need to know about that
< sipa>
BlueMatt: we'll need a SF to commit to error correction packets :)
< BlueMatt>
sipa: yes, probalem is putting it in the coinbase is expensive, so we need a HF to commit to ECC packets :p
< Victorsueca>
michagogo: no idea, the console seemed to error out, but after spamming the make command a few times it started working
< michagogo>
Victorsueca: what did the consoel look like?
< sipa>
BlueMatt: last tx?
< Victorsueca>
michagogo: lots of error being spammed out, stuff outside of the directory, automake is not available....
< sipa>
BlueMatt: which you require to be small
< BlueMatt>
sipa: just traversing down the merkle tree is non-trivial in byte count when you only have <1500 bytes to play with
< Victorsueca>
I apt-get'd autoconf but still didn't work
< michagogo>
Okay, I just reset my WSL
< michagogo>
Going to figure out what's necessary and sufficient
< Victorsueca>
after spamming the make command a few times and now seems to work tho
< Victorsueca>
now it's doing checks....
< jtimon>
Is nMaxTries in generateBlocks() [rpc/mining.cpp] very used and loved?
< BlueMatt>
one option for a fibre network: be super lazy and spin up servers primarily on softlayer - ~$1500/mo to softlayer and probably another 200 to other providers to bridge the gaps
< achow101>
BlueMatt: I may be able to run a fibre server at my school. It just depends on whether I can figure out how to get one from the school and if they will let me run it
< Victorsueca>
damn, missing pkg-config
< michagogo>
Yep, already got that on the list
< michagogo>
Interesting
< michagogo>
Looks like b2 (boost build tool) is passed -j2 regardless of the depends make -j argument
< michagogo>
(assuming it means the same thing there)
< cfields_>
michagogo: hmm, no reason. Just got left in after testing i guess
< wumpus>
ok. Probably accidental then
< cfields_>
I'm pretty sure you can grab the parallel value from make somehow
< Victorsueca>
I use make with -j4
< michagogo>
Hm, OpenSSL forces -j1
< wumpus>
yes, openssl is broken otherwise
< wumpus>
(the build, not the library)
< cfields_>
yes, that one's on purpose
< michagogo>
ah
< wumpus>
don't know if that's still the case with more recent openssl, but it used to be that there was a race between some parts of the builds (esp. when assembly enabled) preventing paralellel builds
< Victorsueca>
damn, can't reash confdefs.h No such file or directory
< Victorsueca>
read*
< michagogo>
Based on miniupnpc, I'm guessing that it inherits if not specified
< michagogo>
Oh, wait, for boost that doesn't work
< wumpus>
Victorsueca: I'm baffled that michagogo had such an easy time building while you seem to stumble into every possible issue :)
< Victorsueca>
wumpus: yeah, that usually hapens to me when compiling software
< Victorsueca>
lol
< michagogo>
Victorsueca: you're not on insider preview, are you?
< Victorsueca>
nope
< Victorsueca>
just plain windows 10 with aniversary update
< michagogo>
`lsb_release -r` shows 14.04?
< michagogo>
Packages all updated?
< Victorsueca>
yes, it's 14.04
< Victorsueca>
and apt-get upgrade shows everything updated
< michagogo>
Wait a minute, depends builds protobuf _twice_?
< michagogo>
I could have sworn it did that at the beginning
< Victorsueca>
I thought something may be corrupt on the source files and I deleted everything and started over
< Victorsueca>
I use the v0.13.1rc1 zipball from github
< wumpus>
try following exactly what michagogo does in his pastebin
< wumpus>
e.g. check out the tag from git
< michagogo>
I'm working on updating that right now
< Victorsueca>
still compiling here, will see if it works this time
< GitHub117>
[bitcoin] mruddy opened pull request #8960: doc: update 0.13.1 release note info on linux arm builds (0.13...relnote131) https://github.com/bitcoin/bitcoin/pull/8960
< michagogo>
(if you also want to build 32-bit, drop the -x86-64 at the end of l1)
< * wumpus>
wonders if anyone is still using 32-bit windows builds
< Victorsueca>
I was just about to ask if x32 computers are still a thing
< wumpus>
(except by accident on a 64-bit system)
< GitHub192>
[bitcoin] rebroad opened pull request #8961: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/8961
< wumpus>
x86 32-bit is pretty much dead, I think it's still used for some obscure small VPSes, but who would still use it for windows
< wumpus>
this may be something that would make sense to ask on btctalk/reddit though, or maybe twitter
< Victorsueca>
gee, this is taking a eternitiy to build
< michagogo>
Victorsueca: Are you on a spinning disk or ssd?
< michagogo>
Looks like the whole thing including depends took a bit over an hour
< michagogo>
But that includes downloads of packages
< michagogo>
both apt-get, and depedns sources
< molz>
it took me half a day trying to build windows on debian VM and still didn't succeed
< Victorsueca>
michagogo: it finished just now, it's postprocessing ATM
< wumpus>
trying, but will take more than a one-man-army to defend against PR spamming of this scale :)
< Victorsueca>
just wondering.... would it be possible to make a x168 system?
< Victorsueca>
x128*
< Victorsueca>
ohhh shit, 0 FPS, screen went unresponsive while compiling
< wumpus>
possible, sure. 128-bit address bus would make no sense, but for the ALU it might in some cases. E.g. faster bigint arithmetic for cryptographic purposes
< Victorsueca>
what am I supposed to do now? kill it with the power button or wait?
< wumpus>
hm AS/400 apparently did have 128-bit pointers. CHERI (capability-based architecture research project) has 256-bit pointers, even.
< wumpus>
so yes it can always get bigger and crazier :)
< Victorsueca>
wumpus: if I kill it now would it resume the build later?
< wumpus>
Victorsueca: yes
< Victorsueca>
good to know
< Victorsueca>
does it make sense to have such huge pointers other than bigger integers?
< sipa>
zfs internally has a 256-bit hash associated with every "pointer" to a disk location, with a hash off the data record pointed to
< sipa>
arguably that is part of the pointer
< GitHub59>
[bitcoin] laanwj closed pull request #8960: doc: update 0.13.1 release note info on linux arm builds (0.13...relnote131) https://github.com/bitcoin/bitcoin/pull/8960
< GitHub105>
bitcoin/master 83c0f7f mruddy: trivial: update 0.13.0 release note info on linux arm builds
< GitHub105>
bitcoin/master 80a7078 Wladimir J. van der Laan: Merge #8955: doc: update 0.13.0 release note info on linux arm builds...
< GitHub14>
[bitcoin] laanwj closed pull request #8955: doc: update 0.13.0 release note info on linux arm builds (master...relnote) https://github.com/bitcoin/bitcoin/pull/8955
< wumpus>
sipa: right. Would be hard to imagine how the entire disk could work in content-addressable way, at some point there must be a way to map hashes to the the location on the disk where something is stored.
< gmaxwell>
wumpus: perhaps we should do a release for w32 that pops up a box and asks the user to report their usage.
< BlueMatt>
just make a http request to X.onion.to :p
< Victorsueca>
wow netsplit
< Victorsueca>
gee, qt takes a lot to compile
< TD-Linux>
building bitcoin under the Ubuntu for Windows environment is supported now?
< Victorsueca>
TD-Linux: i'm doing it right now lol
< wumpus>
gmaxwell: I'm surprised with how long Microsoft is waiting to deprecate 32-bit windows
< wumpus>
hadn't expected a w10 release for it
< wumpus>
but I have the feeling no one is using it for bitcoin core, and at least up until now responses seem to confirm that
< Victorsueca>
what about the number of downloads from bitcoin.org? that would be a good indicative of x32 usage
< wumpus>
we don't have that information
< wumpus>
also it's very possible that people download the 32-bit version by accident even though they're on 64-bit
< Victorsueca>
doesn't the page detect your OS and arch?
< wumpus>
of the browser
< Victorsueca>
ahh right
< Victorsueca>
the browser could be x32 by accident
< gmaxwell>
that was an issue for fedora for a long time, they recommended 32bit as the main download because it was the most downloaded one... meanwhile the overwhelming majority of users were on 64bit hardware.
< TD-Linux>
Victorsueca, or on purpose. most browser plugins are 32 bit only
< Victorsueca>
gmaxwell: sounds like a loop, it's obviously going to be the most downloaded one if it's the main download
< sipa>
Victorsueca: x32 is not the same as 32-bit x86 :)
< Victorsueca>
sipa: it's ok if I call it ia32?
< Victorsueca>
i'm too lazy to write the word "bit" :P
< wumpus>
TD-Linux: that was the case in 2008 or so, but is that still the case?
< sipa>
as far as i'm concerned you can call it blampowoozie, just making sure you're not saying something that's interpreted different than what you intended
< gmaxwell>
wumpus: other than build costs is 32bit windows a burden on you/us?
< wumpus>
is anyone still using browser plugins in the first place?
< TD-Linux>
wumpus, yes, though the complete death of NPAPI is soon approaching, so once that happens at least firefox is going to do in place 32->64 upgrades
< Victorsueca>
wumpus: I use chrome extensions at most
< wumpus>
gmaxwell: well it goes mainly untested
< wumpus>
gmaxwell: none of the devs uses windows, let alone 32-bit
< wumpus>
Victorsueca: extensions are extensively used and a completely different thing :)
< sipa>
it'd be nice if ubuntu shipped with a built-in windows environment too.
< btcdrak>
fractal OS
< wumpus>
gmaxwell: I just don't think it's used anymore in practice. What was the last 32-bit only CPU?
< TD-Linux>
wumpus, lots of antivirus installs browser plugins (one of the reasons to remove it actually), also realplayer-tier stuff like United's inflight video
< wumpus>
(I mean commonly used intel one, not ARM)
< Victorsueca>
sipa: I think that's called wine, but i don't think it comes pre-installed, you have to apt-get it
< wumpus>
TD-Linux: that doesn't sound like something desirable :)
< wumpus>
"many malware is still 32-bit" hehe
< TD-Linux>
wumpus, indeed, but then you tempt the antivirus vendors to binary patch your executable instead.
< sipa>
wumpus: even windows 10 still supports ia32
< wumpus>
sipa: I know, I was surprised about that a few messages back
< wumpus>
sipa: that doesn't mean anyone is using it though
< wumpus>
I don't really feel like arguing about this though, if everyone here feels that supporting windows 32 bit is still worth it, let's keep doing that, please also help with support if issues come up tho
< Lightsword>
wumpus, doesn’t luke-jr use 32 bit userspace or something strange?
< wumpus>
Lightsword: on linux, yes
< TD-Linux>
likely because they wanted to migrate all windows 7 and 8 installs to 10, and doing an upgrade to a different arch is high risk
< sipa>
wumpus: oh, i'm not arguing - i'm just as curious as you about actual usefulness of 32-bit windows
< wumpus>
linux 32-bit is still used on VPSes with small memory (nano instances and such) so there's a reasonable user base
< Lightsword>
my guess is it might not be all that uncommon for people to want a full node on some ancient systems they have lying around so 32 bit windows might be useful for that
< wumpus>
but we deprecated 32-bit Mac ages ago, and windows really is in the same ballpark as that, an end-user OS
< Lightsword>
as a dedicated box they stick in a closet or something
< Lightsword>
wumpus, yeah but apple deprecated 32-bit mac right?
< wumpus>
let hem install inux, then
< wumpus>
:p
< wumpus>
but *how old* is that anyhow? what and when was the last (commonly used) 32-bit only x86 CPU?
< Lightsword>
wumpus, netbook atoms?
< TD-Linux>
gmaxwell, instead of a box in the executable that pops up, you could put it on bitcoin.org
< gmaxwell>
realistically, most hardware like atoms will be too non-performance to run bitcoin core anymore. :(
< wumpus>
Lightsword: I don't think any of those really caught on, for running windows at least
< Lightsword>
wumpus, I used them at one point with windows 7 32 bit…years ago
< gmaxwell>
I worry more about users on fast hardware that happen to be running 32bit OSes because of ignorance or compatiblity with other things.
< wumpus>
ok, never mind about his
< wumpus>
seems everyone else feels this is still worth supporting, well go ahead :)
< Victorsueca>
What about people who has a x64 OS but has low memory and wants to use bitcoin ia32 to save memory?
< wumpus>
so are there any of those, using windows?
< wumpus>
if you have low memory you probaly shouldn't be using that
< wumpus>
same for small embedded hw
< gmaxwell>
Victorsueca: using bitcoin ia32 should not be considerably more memory efficient.
< sipa>
i think they are
< sipa>
mempool, cpu cache, block index... they're all considerably smaller on 32-bit systems
< sipa>
not a factor 2, but perhaps 20-30%
< Victorsueca>
also you can't use bitcoin x64 on a ia32 os tho even if your system supports x64 you may want to use ia32 OS and that would actually save a lot of memory
< wumpus>
so, who is volunteering to do 32-bit windows testing for bitcoin core?
< gmaxwell>
I can do that.
< Victorsueca>
I could do it, if I ever get to compile the x64 one and get it to work i'll try with the ia32
< wumpus>
great
< wumpus>
you should test on a 32-bit OS then, not a 64-bit one
< Victorsueca>
^ RIP ia32 lol
< Victorsueca>
isn't it the same?
< wumpus>
no, it's not the same
< Victorsueca>
damn
< Victorsueca>
gmaxwell: you're the only hope :D
< Victorsueca>
well, now I think about it... if the main function of the ia32 will be saving memory why don't we just test it in a x64 OS and say there's no support for ia32 OS?
< sipa>
Victorsueca: well gmaxwell points out that people may be running a 32-bit OS, not knowing their hardware supports x86_64
< achow101>
I may be able to help test 32 bit windows, depends on what exactly needs to be done in order to test
< wumpus>
achow101: run a node 24/7 on 32-bit windows at least
< wumpus>
debug when things crash
< wumpus>
maybe try running test_bitcoin and the qa tests on it once in a while. But that's fairly well handled by travis and wine, I think most important is actual usage testing and solving problems that come up
< achow101>
ok. does it matter if it's in a vm?
< wumpus>
no
< achow101>
ok. I'll give it a go
< wumpus>
thanks
< wumpus>
still, not one reply from twitter or #bitcoin from an actual user using the 32-bit windows version though. Only one person who knows someone who uses it on windows 32 bit.
< Victorsueca>
trying to figure out why the heck does my system become unresponsive while compiling qt
< Victorsueca>
i'm stuck there and can't continue building bitcoin
< wumpus>
memory full?
< Victorsueca>
85%
< wumpus>
it's c++ code, if you use too much parallelism it's easy tofill up memory
< Victorsueca>
should I try -j1?
< wumpus>
yes, you could try
< Victorsueca>
I just didn't specify that option, how many threads does qt use by default when compiling?
< sipa>
q
< sipa>
1
< Victorsueca>
1? and still out of memory? wtf?
< sipa>
how much memory do you have?
< Victorsueca>
4GB
< sipa>
how much is available for the linux env?
< sipa>
you need something like 1.5 or 2 GB to compile bitcoin core, i think
< wumpus>
well it could very well be another problem, my observation was just that it's usually a memory/swap issue if the system becomes unresponsive during compilation
< wumpus>
I'm sure there's some way to debug that
< Victorsueca>
is WSL enviroment resource limited?
< Victorsueca>
or it just can use everything windows has available?
< sipa>
you tell us
< wumpus>
yes this is probably not the right place to ask that
< Victorsueca>
hmmm ok, i'll search on google
< achow101>
Victorsueca: WSL should be using everything windows has available. It isn't a vm or emulation
< Victorsueca>
^ +1, google searches seems to agree
< Victorsueca>
so basically I have 4GB - System memory usage
< MarcoFalke>
it is mostly main and init that consume most ram
< Victorsueca>
will try j1 and see if it makes any difference
< Victorsueca>
it has to verify itself that it's a crap enough to meet the M$ crap software standards
< wumpus>
there's really too many PRs open
< Victorsueca>
wumpus: close them all but the ones made by the bitcoin team, if anybody wants to suggest a feature tell them to first search on closed pull requests and reopen if necessary
< wumpus>
that makes no sense, everyone is 'the bitcoin team'
< Victorsueca>
wumpus: I mean that list of people where there are 14 users right now, not sure how's it called
< wumpus>
again, this is not a windows developer troubleshooting channel
< michagogo>
20:36:24 <TD-Linux> building bitcoin under the Ubuntu for Windows environment is supported now? <-- I don't know about Support, but it does seem to work!
< wumpus>
maybe ##windows?
< michagogo>
I mean, it's pretty much a full Ubuntu environment, so it's not so surprising
< Victorsueca>
michagogo: it goes over 85% and a few seconds later it's unresponsive
< wumpus>
I still bet it's swap trashing though
< michagogo>
It's an Ubuntu user space and packages, and while more exotic syscalls aren't supported (so no LXC/KVM, no tail -f, etc.), a cross-compile toolchain runs just fine.
< Victorsueca>
wumpus: how is that suposed to be fixed?
< michagogo>
Victorsueca: most likely with more resources, unfortunately
< Victorsueca>
damn
< wumpus>
I wondered what makes tail -f so exotic, thought it was just a pollign loop, but apparently it uses inotify
< Victorsueca>
i'll have to use my other computer then, didn't want to restart that one because it's hosting stuff
< sipa>
wumpus: maybe tail --follow=name works better?
< wumpus>
sipa: looks like that adds an inotify on both the file *and* the directory it's in :)
< michagogo>
Nobody should ever mix Ubuntu and Debian
< michagogo>
That's a recipe for a broken system
< jonasschnelli>
achow101: is the shutdown at the end intentional?
< achow101>
yes. I shut it down so it wouldn't eat all my data
< GitHub23>
[bitcoin] TheBlueMatt opened pull request #8968: Don't hold cs_main when calling ProcessNewBlock from a cmpctblock (master...cmpctblock) https://github.com/bitcoin/bitcoin/pull/8968
< wumpus>
michagogo: comment that in the pull please
< jonasschnelli>
achow101: It looks like that you have successfully connected to a bunch of nodes in 129.2.207.18
< achow101>
jonasschnelli: that's probably because it's behind the vm nat. That ip address is mine
< achow101>
but I only run one node
< jonasschnelli>
achow101: A right. Confused! 129.2.207.18 is you node..
< jonasschnelli>
maybe try -debug=net and post the debug.log again
< achow101>
I found the problem. If the option is in the bitcoin.conf, it won't work. I have to put it in the command line. Any idea why?
< wumpus>
are you using connect= in your bitcoin.conf or -connect=?
< wumpus>
the former will work, the second will not
< achow101>
connect= in bitcoin.conf
< jonasschnelli>
Should work in bitcoin.conf
< wumpus>
is bitcoin.conf in the right place? does it get parsed at all?
< jonasschnelli>
Doublecheck bitcoin.conf and -datadir (if passed in CLI)
< achow101>
This is my conf: prune=550
< achow101>
connect=172.16.220.1:8333
< jonasschnelli>
what happens if you telnet 172.16.220.1 8333 (nat?)
< achow101>
nevermind. it's a windows problem. It stuck a .txt at the end of the file name!
< michagogo>
Hahaha
< wumpus>
one lousy way to find out if it's parsed is to put junk at the end, e.g. 'fasdjlfaljdfalfjk' then see if bitcoind gives an error at start :p
< jonasschnelli>
heh
< wumpus>
lol okay
< michagogo>
Yeah, first thing I do at any new Windows box/profile
< michagogo>
Folder options -> untick "hide extensions for known file types"
< wumpus>
windows's mysterius hidden extensions and hidden files
< GitHub167>
[bitcoin] jonasschnelli closed pull request #5905: [Qt][WIP] allow possibility to add a comment to a WalletTx (master...2015/03/qt_tx_comment) https://github.com/bitcoin/bitcoin/pull/5905
< GitHub148>
[bitcoin] jonasschnelli closed pull request #7107: Qt: Add network port input box to GUI settings (master...qtnetworkport) https://github.com/bitcoin/bitcoin/pull/7107
< GitHub125>
[bitcoin] jonasschnelli closed pull request #7510: Read/write bitcoin_rw.conf for exposing shared Daemon/GUI options in the GUI (master...rwconf) https://github.com/bitcoin/bitcoin/pull/7510
< GitHub199>
bitcoin/master 7f71a3c Wladimir J. van der Laan: Merge #6996: Add preciousblock RPC...
< michagogo>
Hm, I really hope I find the time to rewrite build-windows.md
< michagogo>
It seems to tell you to install all the unix dependencies
< michagogo>
Which is just wrong
< michagogo>
Or at least, it can be read that way
< wumpus>
it doesn't hurt, but yeah it's overkill
< wumpus>
only the high-level arch-independent build stuff would be necessary, autoconf automake etc
< michagogo>
I mean, molz in #bitcoin was installing all the actual deps, it seems
< GitHub123>
[bitcoin] MarcoFalke closed pull request #8961: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/8961
< michagogo>
OpenSSL, BDB, etc etc
< michagogo>
Which is completely unnecessary
< michagogo>
When you really just need the actual tool chain skeleton
< wumpus>
you don't need those for a depends build on unix either
< jonasschnelli>
wumpus: the preciousblock RPC call needs probably mentioning in the 0.14 releasenots
< jonasschnelli>
*notes
< wumpus>
jonasschnelli: yes
< MarcoFalke>
Yeah, down to 10 pulls
< MarcoFalke>
in base 128
< jonasschnelli>
maybe we should open a issue for RN 0.14
< michagogo>
But the docs don't talk about running a deps build for unix
< wumpus>
michagogo: only the docs in depends do :(
< michagogo>
Build-unix.md walks you through doing a build with system-deps
< wumpus>
michagogo: it's split all over the place, not always over sensible lines
< michagogo>
And build-windows points you at build-unix...
< wumpus>
and build-unix points you at build-openbsd :-)
< michagogo>
When you really just need to install git make pkg-config libtool autoconf g++ g++-mingw-w64-x86-64
< michagogo>
Well, it does for openbsd
< michagogo>
Windows points to unix unconditionally
< wumpus>
I know, that one makes sense
< michagogo>
When all you need is git make pkg-config libtool autoconf g++ g++-mingw-w64-x86-64
< michagogo>
You don't even need all of build-essential
< wumpus>
that's a lot of micromanagement though. I tdoesn't hurt to install one package too many. Though it should be made clear that you don't need to install dependencies if you're going to do a depends build, just the compiler/toolchain
< wumpus>
some of that is documented in depends/, but that's somewhat hidden away
< michagogo>
OTOH, it's just a waste of space to install g++-mingw-w64 when g++-mingw-w64-x86-64 is enough
< michagogo>
(The former basically pulls in the latter, plus -i686)
< michagogo>
And I think some of the packages don't even come with build-essential, you need to install them individually anyway
< wumpus>
I agree, but I think getting the high level understanding clear "depends installs the dependencies for you so you don't need to get them from apt" is more important than whether we mention one package more or less
< michagogo>
In other words, IMHO, there are few enough necessary packages that it's worth just listing them rather than the metapackages that pull in supersets of some of them
< michagogo>
Well, yeah
< michagogo>
I'm hoping to overhaul build-windows on Thursday, if nobody else does it in the meantime
< michagogo>
Also, maybe build-unix should be updated to present depends as an alternative to system deps
< wumpus>
I don't think you need to be afraid anyone else will do so in the meantime, I mean no one did in the last months either :)
< GitHub196>
bitcoin/master 18dacf9 Russell Yanofsky: Add microbenchmarks to profile more code paths....
< GitHub196>
bitcoin/master 74dc388 Wladimir J. van der Laan: Merge #8873: Add microbenchmarks to profile more code paths....
< GitHub52>
[bitcoin] laanwj closed pull request #8873: Add microbenchmarks to profile more code paths. (master...issue-7883-benchmarks) https://github.com/bitcoin/bitcoin/pull/8873
< wumpus>
jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
< wumpus>
I'd prefer keeping around a bit of useless code to that
< wumpus>
OTOH, it's not tested anyway, so if it is safe to remove (no risk of crashes) I'm fine with it
< wumpus>
to be honest I think #8564 is a bit questionable, I'm not convinced it only removed code to do with ip transactions
< wumpus>
#8546, sorry
< BlueMatt>
;;seen cfields_
< gribble>
cfields_ was last seen in #bitcoin-core-dev 4 hours, 55 minutes, and 44 seconds ago: <cfields_> yes, that one's on purpose
< BlueMatt>
;;seen cfields
< gribble>
cfields was last seen in #bitcoin-core-dev 5 days, 0 hours, 12 minutes, and 27 seconds ago: <cfields> gmaxwell: for one in every X connections, we could proxy and route messages together for peer-pairs. Then they'd poison their own stats :p
< wumpus>
we may want to closeit and re-do it at some point, there's no urgency to it
< Anduck>
i think the docs for ubuntu & debian should be separated totally to hilight that they're indeed different distros and have different sw sources etc. i might do this some day when i have more time
< cfields_>
BlueMatt: pong?
< BlueMatt>
cfields_: busy with 13.1? or have you had a chance to review 8865?
< wumpus>
Anduck: all of the apt package names are the same though
< cfields_>
BlueMatt: beating my head against the wall with cgminer. I can take a break to review though.
< wumpus>
unless people mess with software sources, ubuntu and debian can be regarded as having the same build instructions
< Anduck>
what's the "right" way to obtain libdb4.8 (& libdb4.8++) for debian 8.0 jessie, binary or sources?
< wumpus>
no need to duplicate things unnecesarily
< BlueMatt>
cfields_: yea, still ready to split main and have some exciting things planned, but rather blocked on review (story of bitcoin core, i suppose...)
< Anduck>
wumpus: it only builds libdb4.8 but libdb4.8++ is also required
< BlueMatt>
cfields_: I'm happy to trade reviews, if it helps :p
< wumpus>
Anduck: it builds both actually
< wumpus>
Anduck: I've followed the instructions zillions of times, I'm sure it does the right thing
< Anduck>
hmm... i tried it but it complained about libdb4.8++
< Anduck>
alright
< cfields_>
BlueMatt: ack. Will do in a little bit, once I get this test on auto-pilot
< wumpus>
unless something broke anyhow
< wumpus>
these days I don't use bdb 4.8 anymore tbh
< Anduck>
are there any recent/known compatibility issues with newer ones?
< wumpus>
yes, still the same as always
< Anduck>
ok
< wumpus>
bdb 5 wallets won't work in 4.8, bdb 6 wallets won't work in 5 and 4.8
< Anduck>
but it will work perfectly well otherwise?
< Anduck>
--with-incompatible-bdb raises the question if it's not safe to use it at all, or if it's just simply incompatible with other major bdb versions
< wumpus>
and to convert between versions one can do db5.0_dump wallet.dat | db4.8_load wallet.dat.new , still the same as in 2012 :)
< wumpus>
I can't guarantee anything about being safe to use, but I've never heard of any inherent issues
< wumpus>
it's just that different versions' databases are binary incompatible, and if you don't know about that it can be confusing
< Anduck>
alright. good to know
< wumpus>
I guess it'd make sense to document that better
< Victorsueca>
there, back to compiling.... again.....
< wumpus>
but so much stuff to do
< Victorsueca>
this time on a better computer, 16 GB ram
< Victorsueca>
maybe it's an overkill but way we'll know if ram was the problem
< wumpus>
16GB is hardly overkill these days
< Victorsueca>
if it's supposed to be enough with 1.5 or 2....
< wumpus>
that's for the compiler. The other 14GB is for windows.
< Victorsueca>
lol
< Victorsueca>
windows eats at most 4 GB, 2GB usually
< wumpus>
BlueMatt: so I guess you're blocked on 8865?
< BlueMatt>
wumpus: I mean I can open a flurry of prs that all do small changes like that, but I'd rather go one or two at a time
< BlueMatt>
so i guess
< BlueMatt>
yes
< BlueMatt>
wumpus: I also opened #8930 to get some eyes on verifying that orphan processing doesnt have to remain consistent with cs_main
< wumpus>
let's get 8865 merged then
< wumpus>
we kind of failed our goal in Milan to split up main.cpp
< BlueMatt>
this is true, but segwit is more important
< michagogo>
Anduck: honestly, the easiest thing, I think, is to just use the depends system
< wumpus>
michagogo: it is - would be nice if there waa a way to use depends *just* for berkeleydb
< michagogo>
Yeah
< Victorsueca>
i think there is some way to use the system library for some dependency instead f the one specified in depends
< wumpus>
currently you have to either build all dependencies (including qt, which you really don't want to build statically on ubuntu) using depends or none at all
< michagogo>
I mean, can you just run bdb.mk? Or does that only work when called by the main makedile?
< wumpus>
maybe it's possible
< michagogo>
wumpus: can you not make depends NO_QT=1 and point configure at system qt?
< wumpus>
yea, but that'd stlil pull in boost
< wumpus>
it's currently not a practical way to build just berkeleydb