< bitcoin-git>
[bitcoin] laanwj closed pull request #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt) (master...2017/09/qsettings_1) https://github.com/bitcoin/bitcoin/pull/11332
< bitcoin-git>
bitcoin/master 09627b1 Wladimir J. van der Laan: Merge #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (achow101, TheBlueMatt)...
< bitcoin-git>
bitcoin/master cdaf3a1 Matt Corallo: Fix Qt 0.14.2->0.15.0 segfault if "total at least" is selected...
< gmaxwell>
your inside jokes might confuse people. :P fwiw, on an up to date debian testing system, which was QT4 only, you can parallel install QT5, but it seems bitcoin-qt still builds using QT4 even with QT5 'installed'.
< gmaxwell>
Even if notepad is wrong (would be interesting to find out!) that still doesn't excuse bitcoin-- losing notepad is less serious then your wallet. :)
< gmaxwell>
jonasschnelli: I explained before. If you increase your resolution, position there. Shut down bitcoin. Reduce resolution. You will be in this state.
< achow101>
yes, from bitcoin.org
< luke-jr>
bane5000: #bitcoin please
< luke-jr>
bane5000: you mean prune=10000 ? note that user issues should be in #bitcoin though
< bane5000>
i've restarted the bitcoin-qt, however, the old blocks do not seem to be disappearing, as my harddrive space has not been reduced
< bane5000>
so i've enabled pruning on my core wallet (by creating bitcoin.conf in ~/.bitcoin/) and adding pruning=10000
< bitcoin-git>
[bitcoin] achow101 opened pull request #11334: Remove custom fee radio group and remove nCustomFeeRadio setting (master...rm-nCustomFeeRadio) https://github.com/bitcoin/bitcoin/pull/11334
< tloriato>
sipa in which cases does the bitcoin wallet changes the i from the path?
< tloriato>
oh, one more thing, sorry! bitcoin core uses m/0'/0'/k' for derivation path
< tloriato>
Hello! I was looking for how I could import a BIP32 Extended Key into the Bitcoin Core wallet? I've tried the RPC Documentation but got no luck there.
< bitcoin-git>
[bitcoin] danra opened pull request #11333: Use `std::nth_element` instead of `std::sort` to calculate median time past (master...improve/median-time-past) https://github.com/bitcoin/bitcoin/pull/11333
< esotericnonsense>
from #bitcoin: dingus | TYPO at the very top of https://bitcoin.org/en/release/v0.15.0 "14 October 2017" <- It's not October, yet, I hope
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11332: Fix possible crash with invalid nCustomFeeRadio in QSettings (master...2017/09/qsettings_1) https://github.com/bitcoin/bitcoin/pull/11332
< harrymm>
aww. should i have told gdb to load symbols from the symbols downloaded? it says it's reading them from bitcoin-qt (which doesn't have them)
< wumpus>
can you pastebin the output of: <gmaxwell> harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< gmaxwell>
harrymm: can you get a backtrace from it? gdb -c corefile ./path-to/bitcoin-qt then "thread apply all bt full"
< achow101>
if anyone sees any issue remotely like #11171, please get the GUI settings (from windows registry or from ~/.config/Bitcoin/Bitcoin-Qt.conf) before doing -resetguisettings
< bitcoin-git>
[bitcoin] danra opened pull request #11330: Trivial: Fix comments for DEFAULT_WHITELIST[FORCE]RELAY (master...patch-10) https://github.com/bitcoin/bitcoin/pull/11330
< NicolasDorier>
so actually I did not tried https://github.com/bitcoin/bitcoin/pull/11126 yet. But the path of the locks is different from the PR so I guess this is different error.
< bitcoin-git>
bitcoin/master 96d91b7 Wladimir J. van der Laan: contrib: Ignore historical release notes for whitespace check...
< earlz>
How exactly do you debug the bitcoin-qt on 64bit windows? I know the gitian builds produce both the binaries and debug symbols, but not sure what the best way to debug a crash is
< bitcoin-git>
[bitcoin] MeshCollider opened pull request #11326: Fix crash on shutdown with invalid wallet (master...201709_shutdown_crash) https://github.com/bitcoin/bitcoin/pull/11326
< NicolasDorier>
mmh I doubt the bug comes from bitcoin core actually
< NicolasDorier>
Running bitcoin-core-0.15.0/test.rc3 on one of my server, getting "2017-09-14 06:55:48 socket send error The operation completed successfully. (0)" in logs _without_ debug=net. Then the connection drop to the peer. My peer is a NBitcoin peer, and I could not reproduce the error on the same 0.15.0/test.rc3 running on my machine.
< gmaxwell>
(I think expecting them to be well behaved is a bad idea, someone will spin up three pool daemons, they'll run in a fairly tight loop and prevent bitcoin from processing blocks, and wonder why they're getting orphan blocks)
< harding>
BashCo: that's an argument about what it is or is not possible to enforce. I think the important point is about what contributors to the Bitcoin Core project, mainly developers, choose to do regarding interactive communication.
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload (master...Mf1709-qaZap3s) https://github.com/bitcoin/bitcoin/pull/11308
< bitcoin-git>
bitcoin/master 8df48b3 MarcoFalke: Merge #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload...
< bitcoin-git>
bitcoin/master fadd0c1 MarcoFalke: [qa] zapwallettxes: Wait up to 3s for mempool reload
< harding>
BashCo: as I said above, I think the desire is not to get all Bitcoin users on the same platform; merely to get all developers on the same platform.
< BashCo>
gmaxwell's meetup vid covering 0.15 was really popular. a 'sunday talk show' circuit covering various bitcoin media outlets could get a great response, but I understand it has the negative effect of placing devs on pedestals and creating PR spokesmen.
< BashCo>
yeah fair enough. The Bitcoin community also has ambiguously defined boundaries. Lucky for Core, a large contingent of those communities support Core. That's why I think it's short sighted to pressure those communities to disband in favor of inferior platforms.
< luke-jr>
BashCo: I don't agree. The latter is simply the Bitcoin community.
< OdaNobunaga>
It's been suggested (today on the slack) to rebrand the slack into something not connected to core, for example "bitcoincommunity" or something like that (the bitcoin subdomain of slack is already taken)
< BlueMatt>
I absolutely agree there is some value in it, but some active steps should be taken to a) make clear this is not somehow a community related to bitcoin core (the technical project) and b) try to enforce lack of splitbrain
< achow101>
s/the community/any bitcoin related discussion community/
< BlueMatt>
while I understand the migration from Reddit and IRC to some extent, pushing folks towards Slack has, in large part, simply added yet another disconnected venue for Bitcoin discussion, creating yet another fork of the community whcih does not sufficiently communicate with other parts
< BlueMatt>
and the "splitbrain community" issues greg raised are also critical here - as the Bitcoin community grows Bitcoin becomes harder to change, and thats good, but it should not do so needlessly simply because parts of the community do not sufficiently communicate with other parts
< bitcoin-git>
[bitcoin] dooglus opened pull request #11320: Include the wallet name in log messages relating to wallets (master...wallet_name_in_log) https://github.com/bitcoin/bitcoin/pull/11320
< midnightmagic>
He's over in #bitcoin too, last I checked.
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11319: [qa] Fix error introduced into p2p-segwit.py, and prevent future similar errors (master...2017-09-fix-p2p-segwit) https://github.com/bitcoin/bitcoin/pull/11319
< BashCo_>
The 'split communities' (IRC/Slack/Twitter/reddit/etc) are a simple reality that we have to come to terms with. Maybe it's unfortunate that 'Core' is in the Slack team name, but plain 'Bitcoin' is apparently being squatted. Even that would not solve anything since most people will still prefer Slack over IRC. /sorryforflood
< molz>
gmaxwell, what would you suggest? you want to close the core slack and force everyone to join IRC? the only channel they can talk is #bitcoin but even that channel is not for everything one can discuss
< gmaxwell>
molz: that kind of thing doesn't work, there are incredible misconceptions that come from just not talking. As far as never find it... http://webchat.freenode.net/?channels=bitcoin works pretty well for public chat.
< molz>
gmaxwell, the Core slack has bridges to this channel and #bitcoin-dev, many people on the slack read these channels and more informed of what's going on with the development than you know, and if not for the slack, these people would never join IRC or know what's going on with the bitcoin development
< intcat>
meanwhile people like me who prefer connecting to irc over tor so as to not expose IP to anyone lurking in bitcoin-related channels and suffering frequent disconnects as a result cant unfortunately follow all discussion here
< gmaxwell>
Too bad hundreds of people never get to talk to me because they've been siphoned off into a Bitcoin Core chat group that I'm not in.
< gmaxwell>
My interest in Bitcoin is primarily political, the same is true for (I assume) most of the technical contributors.
< gmaxwell>
There are dozens of non-technical bitcoin channels on IRC-- ones that also get participation from many of the longest standing bitcoin users and technical contributors too.
< gmaxwell>
By splitting the community I mean creating a parallel and seperate Bitcoin Core chat community and directing traffic there instead of where the actual bitcoin project people are.
< CodeShark>
using the name was because otherwise what am I promoting? for better or worse, the Bitcoin Core project was where the greatest protocol expertise was concentrated
< CodeShark>
I have invested FAR more of my time promoting Bitcoin Core than Ciphrex in the last two years
< CodeShark>
I'll be totally blunt here - I deeply respect your domain knowledge and breadth of understanding and have learned tremendously from you...but I also strongly disagree with the public relations strategy the Bitcoin Core project had a couple years ago
< CodeShark>
about the best option we had to keep the network together is to help promote the Bitcoin Core project since it is by far the most responsible and most reliable when it comes to avoiding consensus failures
< gmaxwell>
As far as I am concerned: It is the _bitcoin project_. As far as I am concerned there is no bitcoin core project. Bitcoin Core is a piece of software.
< CodeShark>
for better or worse, it all sort of concentrated around the Bitcoin Core project because that's where the best protocol experts were
< CodeShark>
I could have used my company name instead to promote crap - but I wanted to help the Bitcoin Core project. this isn't about me
< gmaxwell>
The software project here is the _bitcoin_ project, Bitcoin core is the name of the reference client, it's not the only thing the project does.
< CodeShark>
but not everyone agrees on what Bitcoin is
< gmaxwell>
OdaNobunaga: the whole thing is the _fking_ bitcoin project, dude. Bitcoin.
< OdaNobunaga>
CodeShark: Perhaps we should come up with a word to refer to the "decentralisation first"/user-driven/cypherpunk movement within bitcoin, and rename the slack after it
< OdaNobunaga>
I agree with gmaxwell, it's hard to see what the slack has to do with bitcoin core
< CodeShark>
I see the Bitcoin Core software project as part of a wider movement
< gmaxwell>
please get bitcoin core's name off it before doing anything else with moderation... so tired of being blamed for moderation actions in stuff we have no control over.
< gmaxwell>
many of the developers are usually in #bitcoin.
< OdaNobunaga>
On the Slack we kind of call that the "user driven" bitcoin (I've seen that being used a few times)
< CodeShark>
I would like to give a name to the movement that favors the conservative approach to consensus rule changes and general avoidance of incompatibilities unless the technical benefits greatly outweigh the costs...and to distinguish it from the Bitcoin Core FOSS project
< OdaNobunaga>
But the I've been surprised to see it being called "the bitcoin core slack" as the discussion there mostly isn't technical, and its biggest contributors aren't core devs
< OdaNobunaga>
I've been following the various the "bitcoin core" slack on a daily basis (mostly its various UASF channels) since last March, and I think that there's a lot of amplification going on, but at the same time the most vocal contributors there are well aware that they're an extreme minority and that they can't possibly have everything go their way; I w
< gmaxwell>
For example, one of your top contributors (who sent me some very nasty remarks) told me that Bitcoin Core was _never_ going to force a segwit activation and so BIP148 was the _only_ option.
< CodeShark>
I just wanted to build good products atop bitcoin and decided to support the Bitcoin Core project however I could because it's the most stable, most reliable, most secure implementation of validation and relay
< CodeShark>
I believe #bitcoin-core-dev should focus more on tech developments and code. we have other channels for things like media strategy
< CodeShark>
I just saw Bitcoin Core viciously attacked a couple years ago and hostile parties form...and did whatever I could to communicate basic principles. it's impossible to get everyone aligned on all the details, but the priority was around trying to at least have a coherent overarching message
< CodeShark>
I try my best to keep abreast of important developments within Bitcoin Core and do my best to communicate them
< sipa>
sure, but why does that need to happen under the "Bitcoin Core" name?
< CodeShark>
I was working on my own Bitcoin implementation and codebase prior to this whole hard forking insanity and decided to volunteer most of my time to help Bitcoin Core instead. prior to that I use to come here more, but I realized that many people still needed basic information
< CodeShark>
and there's a lot more to the Bitcoin Core project than just submitting pull requests and doing code review
< sipa>
i think it's fine for communities to use slack as a medium if they like to do so... i just don't think it should be 'officially' bitcoin core's slack
< gmaxwell>
esotericnonsense: it can't be that without the most active developers involved, and at the time people with admin access there were behaving disrespectfully to these people. (Access is since changed.) None of us have much interest in wheel warring, if a venue has become unproductive for us to use, we won't use it. For something like a bitcoin tech discussion if the most active of the tech peo
< esotericnonsense>
my interpretation was that this channel was for direct work on the bitcoin codebase whilst bitcoin-dev was for general bitcoin-related development e.g. wallets, merchant integration, etc
< gmaxwell>
sipa: I don't think thats fair to say, -- a channel for bitcoin that hardly has any of the most active people isn't much of one.
< gmaxwell>
StopAndDecrypt_: We used to use bitcoin-dev. Then one day Mike Hearn was a real jerk, in particular faulting wumpus for being 'indecisive', wumpus told him to cut it out, mike kept it up. Wumpus banned him. (so much for indecisive). Then out of nowhere jgarzik, who for who knows what reason still had access, unbanned mike hearn. So most of the developers simply left.
< achow101>
it is arguably created by "Bitcoin Core"
< sipa>
#bitcoin-dev is about bitcoin; #bitcoin-core-dev is about development of one specific software project
< StopAndDecrypt_>
gmaxwell, difference between this and #bitcoin-dev ?
< gmaxwell>
17:54:01 < achow101> the slack channel is Bitcoin Core's slack channel.
< achow101>
the slack channel is Bitcoin Core's slack channel. It's mostly for random shit, not development
< achow101>
esotericnonsense: bitcoincore.org is the bitcoin core's website
< bitcoin-git>
[bitcoin] promag opened pull request #11316: [qt] Add use available balance in send coins dialog (master...2017-09-add-use-available-balance) https://github.com/bitcoin/bitcoin/pull/11316
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11308: [qa] zapwallettxes: Wait up to 3s for mempool reload (master...Mf1709-qaZap3s) https://github.com/bitcoin/bitcoin/pull/11308
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11307: wallet: Display non-HD error on first run (master...Mf1709-walletHDfirst) https://github.com/bitcoin/bitcoin/pull/11307
< bitcoin-git>
[bitcoin] danra opened pull request #11306: Refactor: Move core files from src root to src/core and improve inclu… (master...refactor/core-files) https://github.com/bitcoin/bitcoin/pull/11306
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11305: [doc] Update release notes and manpages for 0.16 (master...Mf1709-doc016) https://github.com/bitcoin/bitcoin/pull/11305
< kallewoof>
It's in AbortNode in validation.cpp so seems to be about bitcoin, yeah.
2017-09-11
< bitcoin-git>
[bitcoin] sipa closed pull request #11252: [P2P] When clearing addrman clear mapInfo and mapAddr. (master...recreateaddrman) https://github.com/bitcoin/bitcoin/pull/11252
< bitcoin-git>
bitcoin/master b9bceaf Pieter Wuille: Merge #11252: [P2P] When clearing addrman clear mapInfo and mapAddr....
< bitcoin-git>
bitcoin/master b86a420 Gregory Sanders: when clearing addrman clear mapInfo and mapAddr
< gribble>
https://github.com/bitcoin/bitcoin/issues/11100 | Fix confusing blockmax{size,weight} options, dont default to throwing away money by TheBlueMatt · Pull Request #11100 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] practicalswift closed pull request #11261: scripted-diff: Use <cxxx> instead of deprecated <xxx.h> when including C compatibility headers (master...cinclude) https://github.com/bitcoin/bitcoin/pull/11261
< meshcollider>
wumpus: 21630 failed again with the ~/.bitcoin issue
< bitcoin-git>
[bitcoin] MeshCollider reopened pull request #11297: Make sure ~/.bitcoin doesn't exist before build (master...201709_travis_delete_dir) https://github.com/bitcoin/bitcoin/pull/11297
< earlz>
thanks, I had similar thoughts last time I worked with coindb that it might be more expensive than expected, but not "can break bitcoin" or crash a node. I'll watch the presentation
< morcos>
earlz: you can watch the presentation from breaking bitcoin today, but essentially the fact that the pre-0.15 utxo set stored unspent outputs per transaction meant that a new tx could pull in an input that was 1 of many outputs in a previous transaction
< bitcoin-git>
[bitcoin] MeshCollider closed pull request #11297: Make sure ~/.bitcoin doesn't exist before build (master...201709_travis_delete_dir) https://github.com/bitcoin/bitcoin/pull/11297
< gribble>
https://github.com/bitcoin/bitcoin/issues/10498 | Use static_cast instead of C-style casts for non-fundamental types by practicalswift · Pull Request #10498 · bitcoin/bitcoin · GitHub
< sipa>
oh, perhaps it's due to a cache that existed from before the tests-do-not-touch-.bitcoin issue was merged?
< sipa>
there are random travis failures, where at the end of the test, ~/.bitcoin exists... that PR solving something implies that ~/.bitcoin already exists at the start of the test run
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #11295: doc: Old fee_estimates.dat are discarded by 0.15.0 (0.15...Mf1709-docFeeEst015) https://github.com/bitcoin/bitcoin/pull/11295
< sipa>
bane5000: no need to run as root, forwarding 8333 is perfectly fine but you'll need to configure your external ip address (-externalip=IP on cmdline, or externalip=IP in bitcoin.conf)
< bane5000>
Hey guys, was thinking about running a bitcoin core p2p only headless server on debian. Just had a couple of questions regarding the online documentation... first of all, do you recommend running this as root? Would it be wiser to run the daemon as a separate user/group?
< bitcoin-git>
[bitcoin] jamesob opened pull request #11293: Deduplicate CMerkleBlock construction code, add test coverage (master...dedup-cmerkleblock) https://github.com/bitcoin/bitcoin/pull/11293