< 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>
that makes no sense, everyone is 'the bitcoin team'
< 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
< sipa>
you need something like 1.5 or 2 GB to compile bitcoin core, i think
< Victorsueca>
i'm stuck there and can't continue building bitcoin
< 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.
< wumpus>
so, who is volunteering to do 32-bit windows testing for bitcoin core?
< 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
< gmaxwell>
Victorsueca: using bitcoin ia32 should not be considerably more memory efficient.
< Victorsueca>
What about people who has a x64 OS but has low memory and wants to use bitcoin ia32 to save memory?
< gmaxwell>
realistically, most hardware like atoms will be too non-performance to run bitcoin core anymore. :(
< TD-Linux>
gmaxwell, instead of a box in the executable that pops up, you could put it on bitcoin.org
< Victorsueca>
what about the number of downloads from bitcoin.org? that would be a good indicative of x32 usage
< 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
< TD-Linux>
building bitcoin under the Ubuntu for Windows environment is supported now?
< 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
< GitHub105>
bitcoin/master 80a7078 Wladimir J. van der Laan: Merge #8955: doc: update 0.13.0 release note info on linux arm builds...
< GitHub105>
bitcoin/master 83c0f7f mruddy: trivial: update 0.13.0 release note info on linux arm builds
< 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
< GitHub192>
[bitcoin] rebroad opened pull request #8961: Headers announcement for nodes that can do headers. (master...AnnounceUsingHeaders) https://github.com/bitcoin/bitcoin/pull/8961
< 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>
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
< 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.
< wumpus>
michagogo: HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt and HKEY_CURRENT_USER\Software\Bitcoin\Bitcoin-Qt-testnet
< 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
< wumpus>
no, it's one 'directory' named bitcoin-qt or such
< michagogo>
If I run Bitcoin-Qt.exe with a -datadir argument, does it leave traces of itself anywhere but that directory?
< michagogo>
The win64 zip for 0.13.0 from Bitcoin.org has test_bitcoin.exe but not -qt
< 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>
The ones for Bitcoin are downloaded and built by those commands
< 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>
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
< 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
< 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.
< tulip>
TD-Linux: you're right, bitcoin users wouldn't appreciate that much
< 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.
< 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."
< 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. :)
< 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.
< 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?
< michagogo>
01:17:13 <GitHub81> bitcoin/0.13 a5cef7b Wladimir J. van der Laan: Bump version to 0.13.1
< GitHub89>
[bitcoin] gmaxwell opened pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
< GitHub152>
bitcoin/0.13 bf86073 David A. Harding: Release notes: correct segwit signalling period start conditions...
< GitHub152>
bitcoin/0.13 2de93f0 David A. Harding: Relase notes: correct segwit activation point
< GitHub152>
bitcoin/0.13 5f9c7b0 David A. Harding: Release notes: add info about segwit and null dummy soft forks...
< GitHub47>
[bitcoin] laanwj closed pull request #8943: Release notes: add info about segwit and null dummy soft forks (0.13...notable-change-segwit) https://github.com/bitcoin/bitcoin/pull/8943
< GitHub131>
[bitcoin] Michagogo opened pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
< gmaxwell>
uh hm. so another peer that I updated, shows Bitcoin version v0.13.1rc1
< gmaxwell>
why is my 0.13.1rc checkout claiming to be Bitcoin version v0.13.0.0-e1169b0 ? did we not bump the version?
< Lightsword>
btw the btc.com pool software is based off of bitcoin core(an old version 0.8.something)
< wumpus>
the bitcoin-cli API has been kept as close to the RPC API as used by other languages as possible, the only difference is the 'parse this as string or not' bit
< gmaxwell>
Lightsword: there is some risk that some genius is mining using system('bitcoin-cli getblocktemplate').
< Lightsword>
sipa, how do I do that with bitcoin-cli?
< Lightsword>
is there any way to do “bitcoin-cli getblocktemplate” with segwit active?
< BlueMatt>
if they have addnodes in bitcoin.conf they would likely not have
< GitHub67>
[bitcoin] TheBlueMatt opened pull request #8944: Remove bogus assert on number of oubound connections. (master...2016-10-bad-assert) https://github.com/bitcoin/bitcoin/pull/8944
< gmaxwell>
hm. /r/bitcoin could set the automoderator to automatically hide posts from non verified submitters for moderator approval that contain the string "Bitcoin.*Core.*releas"
< achow101>
cobra merged the post about the prefinal alert on bitcoin.org a few minutes after rc1 was tagged
< Lauda>
Alert key warning on Bitcoin.org
< gmaxwell>
achow101: ugh. yea, I didn't want that with a banner up on bitcoin.org
< achow101>
that happens when it goes live on bitcoin.org.
< btcdrak>
achow101: the alert has actually gone live on the bitcoin.org RSS feeds....
< achow101>
gmaxwell: cobra merged the alert announcement to bitcoin.org. The date for the alert is set to tomorrow. Should that still happen or should it be pushed back a bit?
< GitHub161>
[bitcoin] laanwj closed pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
< GitHub190>
bitcoin/master 2449e12 Christian Decker: My DNS seed supports filtering...
< GitHub190>
bitcoin/master ffb4713 Matt Corallo: Add x9 service bit support to dnsseed.bluematt.me
< GitHub190>
bitcoin/master 504c72a Matt Corallo: Comment that most dnsseeds only support some service bits combos
< wumpus>
sipa: I can't find the commit for #8651 (Predeclare PrecomputedTransactionData as struct) in https://github.com/bitcoin/bitcoin/pull/8679 , am I missing something or was it squashed into another one?
< wumpus>
though good point on deanonimization using bitcoin user agents, woudl be something to add as warning to onionscan
< GitHub145>
[bitcoin] TheBlueMatt opened pull request #8940: Add x9 service bit support to dnsseed.bluematt.me (master...2016-10-dnsseed) https://github.com/bitcoin/bitcoin/pull/8940
< GitHub23>
[bitcoin] laanwj closed pull request #8499: Add several policy limits and disable uncompressed keys for segwit scripts (master...badwitnesscheck) https://github.com/bitcoin/bitcoin/pull/8499
< GitHub80>
bitcoin/master 9f0397a Johnson Lau: Make test framework produce lowS signatures
< GitHub80>
bitcoin/master 4c0c25a Johnson Lau: Require compressed keys in segwit as policy and disable signing with uncompressed keys for segwit scripts
< GitHub80>
bitcoin/master 3ade2f6 Johnson Lau: Add standard limits for P2WSH with tests
< wumpus>
cfields_: not a high priority thing though building bitcoin core *on* my phone would be quite awesome
< wumpus>
cfields_: hey, I've been trying something weird: to build bitcoin core in the 'termux' environment on my android phone. This is basically just a arm (64 bit in this case) Linux system, with one catch: there is no shell interpreter, or anything useful for that matter in /bin. All the shell utilities are available in the path though.
< GitHub180>
[bitcoin] pooleja opened pull request #8935: Documentation: Building on Windows with WSL (master...windows_build_docs) https://github.com/bitcoin/bitcoin/pull/8935
< wallet42>
can't join #bitcoin-dev anymore? need +r ?
2016-10-15
< GitHub39>
[bitcoin] TheBlueMatt opened pull request #8930: Move orphan processing to ActivateBestChain (master...net_processing_3) https://github.com/bitcoin/bitcoin/pull/8930
< friendsofbitcoin>
Which Core dev would be willing to review and creat any needed unit test for this in demand pull request - https://github.com/bitcoin/bitcoin/pull/7534 I would be willing to offer a reward of 0.5BTC for efforts pushing this through. I apologize in advance if this question is inappropriate for this venue as Im not familiar with any precedents
< GitHub144>
[bitcoin] TheBlueMatt opened pull request #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis (master...2016-10-fix-segfault) https://github.com/bitcoin/bitcoin/pull/8928
< GitHub17>
[bitcoin] jl2012 opened pull request #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts (master...findanddeletetest) https://github.com/bitcoin/bitcoin/pull/8927
< BlueMatt>
gmaxwell: dunno about debian, but the oldest ubuntu lts which is still supported cant build bitcoin in c++11 mode (despite its version of clang supporting it) because its version of boost doesnt build in C++11 mode
< GitHub184>
[bitcoin] luke-jr opened pull request #8918: Qt: Add "Copy URI" to payment request context menu (master...gui_req_copy_uri) https://github.com/bitcoin/bitcoin/pull/8918
< achow101>
should I submit a PR for the alert or will someone with commit access to bitcoin.org sign and push the commit?
< musalbas>
a black paper would waste lots of ink; you don't want critics to accuse bitcoin of using lots of energy as well as ink now
< kanzure>
was there anyone offering to do the legwork on a bitcoin core whitepaper?
< gmaxwell>
nevermind that it's wrong in a few places, and we've learned _a lot_ about teaching people about Bitcoin since 2008.
< gmaxwell>
so you might not be aware, but cobra proposed putting up an updated whitepaper on bitcoin.org with varrious errata and it started a week long lynchmob thing. OMG YOU CHALLENGED THE HOLY WORD.
< gmaxwell>
(it was fixed around the same time that bitcoin first moved off the minimum difficulty)
< gmaxwell>
Bitcoin's best chain selection is not 'most blocks', it's 'most work'.
< musalbas>
re: checkpointing - is there anything in Bitcoin consensus to prevent someone from going back 2048 blocks to a much lower difficulty, and then doing a 51% attack from there to get the longest chain? I think I must be missing a subtle consensus rule here