< sipa>
also, none of the people currently involved with bitcoin core development are working for the foundation anymore
< wumpus>
LumberCartel: let's say the bitcoin foundation has a checkered reputation, there's been so much drama about it. But it's off topic here, #bitcoin would be a better place to discuss.
< LumberCartel>
wxss: What's the problem with The Bitcoin Foundation, Inc.?
< wxss>
the Windows binaries are still signed by The Bitcoin Foundation, Inc. -- that is kinda gross
< bitcoin-git>
bitcoin/0.15 2ce9e58 Wladimir J. van der Laan: doc: Fill in 0.15.1 changelog and authors in release notes...
< bitcoin-git>
[bitcoin] fanquake opened pull request #11611: [build] Don't fail when passed --disable-lcov and lcov isn't available (master...dontfaillcov) https://github.com/bitcoin/bitcoin/pull/11611
< Provoostenator>
To answer my own q: once all linux versions finish building, it spits out a summary with hashes. You can compare that with e.g. gitian.sigs/0.15.1rc1-linux/laanwj/bitcoin-linux-0.15-build.assert
< sipa>
bitcoin core tends to stress CPUs far more than usual desktop software
< fobban>
I've got a i7-6700k. Never got these hardware errors before and I only get them once I start bitcoin core again
< fobban>
I'm running (or trying to run) bitcoin-core on arch linux but ever since v0.15 I get a CPU hardware error after a few minutes which causes the computer to reboot. I redownloaded the blockchain but a few seconds after it was complete I got the error again.
< donaloconnor>
I guess it's pow? - I'm not entirely sure... apologies I'm learning. Miners generate the block hash to find one that satisfies the difficulty. I mean, where does bitcoin core check that this hash is actually valid (ie: hashing the block again results int he same hash)
< donaloconnor>
Can anyone point to me where in the code bitcoin core checks if the block hash is valid? - I can see it checks POW in CheckBlockHeader
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #10697: Do not hold cs_vNodes when making ForEachNode Callbacks (master...2017-06-cnodestateaccessors-5) https://github.com/bitcoin/bitcoin/pull/10697
< wumpus>
being stuck with gcc 4.x is one thing, but being stuck with an old bitcoin core version can be actively harmful. It's the same situation that browsers are in.
< wumpus>
NielsvG: yeah the problem is that stable never gets updated, so they end up with age-old releases of bitcoin core, even though it's kind of important to stay up to date because of security updates, network behavior etc
< travis-ci>
TheBlueMatt/bitcoin#674 (2017-10-travis-irc-notifications - f9cd8b4 : Matt Corallo): The build passed.
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11598: Make travis complain on #bitcoin-core-dev when builds fail (master...2017-10-travis-irc-notifications) https://github.com/bitcoin/bitcoin/pull/11598
< bitcoin-git>
[bitcoin] laanwj closed pull request #11560: Connect to a new outbound peer if our tip is stale (master...2017-10-stale-tip-new-peer) https://github.com/bitcoin/bitcoin/pull/11560
< bitcoin-git>
bitcoin/master ac7b37c Suhas Daftuar: Connect to an extra outbound peer if our tip is stale...
< bitcoin-git>
bitcoin/master db32a65 Suhas Daftuar: Track tip update time and last new block announcement from each peer
< bitcoin-git>
bitcoin/master 2d4327d Suhas Daftuar: net: Allow connecting to extra outbound peers
< bitcoin-git>
[bitcoin] kallewoof opened pull request #11597: [trivial] Fix error message & styling for when new fee rate < min mem… (master...171102-feebumper-lowerfeetxt) https://github.com/bitcoin/bitcoin/pull/11597
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11596: Add missing cs_main locks when accessing chainActive (master...chainActive) https://github.com/bitcoin/bitcoin/pull/11596
< ghost43>
I would be interested in the exact semantics of nLockTime and chainActive.Height() here https://github.com/bitcoin/bitcoin/blob/5b059a833eb57a4dd8458f42aedba85265b2bbf3/src/wallet/wallet.cpp#L2661 -- does this line ensure that only the next block contain the tx? should it be height+1? at the same time I just tested and bitcoind rejects transactions with nLockTime for the next block. so does nLockTime mean that the block to contain a tx
< bitcoin-git>
[bitcoin] laanwj closed pull request #11531: Check that new headers are not a descendant of an invalid block (more effeciently) (master...2017-10-cache-invalid-indexes) https://github.com/bitcoin/bitcoin/pull/11531
< bitcoin-git>
bitcoin/master 932f118 Matt Corallo: Accept unrequested blocks with work equal to our tip...
< bitcoin-git>
bitcoin/master 3d9c70c Matt Corallo: Stop always storing blocks from whitelisted peers...
< bitcoin-git>
bitcoin/master 3b4ac43 Matt Corallo: Rewrite p2p-acceptblock in preparation for slight behavior changes...
< bitcoin-git>
[bitcoin] laanwj closed pull request #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false (master...161017_refactor_AppInit) https://github.com/bitcoin/bitcoin/pull/11511
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11591: wallet: Add missing cs_wallet locks in GetAvailableCredit/GetAvailableWatchOnlyCredit/CreateWalletFromFile (master...cs_wallet) https://github.com/bitcoin/bitcoin/pull/11591
< bitcoin-git>
bitcoin/master db2f83e Wladimir J. van der Laan: Merge #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false...
< wumpus>
promag: luke-jr: FWIW javascript of any kind in bitcoin core scares me, even in the GUI, I know this is not like dragging in a browser (it's not html based, nor is it meant as a sandbox for untrusted code) but it's still such a huge exploitable component
< promag>
we could have both bitcoin-qt and bitcoin-quick and later drop support for the first
< bitcoin-git>
[bitcoin] fanquake closed pull request #11587: Fix warnings when building with -Wthread-safety-analysis (master...–Wthread-safety-analysis) https://github.com/bitcoin/bitcoin/pull/11587
< luke-jr>
sure, I just meant that you wrote bitcoin-qt entirely yourself
< wumpus>
bitcoin-qt's gui would be kind of weird on a mobile device
< wumpus>
with your own cross-compile environment you can certainly build bitcoin-qt for ARM
< wumpus>
ARM and QT5 works great, a lot of embedded devices vendors use that combination, the problem (with regard to bitcoin) is that it's not really standardized, so one mgiht be using qt w/ kms backend, the other with wayland, the other with X11, there's no one-size-fits-all static executable
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #11590: [Wallet] always show help-line of wallet encryption calls (master...2017/10/enc_wallet_help) https://github.com/bitcoin/bitcoin/pull/11590
< earlz>
jonasschnelli: not sure how to compile bitcoin-qt to be dynamically linked without building it on device.. and building on device would take days if it's even possible. I got a compiler error that the ARM compiler wasn't supported for building Qt through gitian, so guess I'm just out of luck on it
< earlz>
Is it possible to modify the gitian scripts to cross-compile bitcoin-qt for ARM?
< sipa>
Alkhara: bitcoin.stackexchange.com
< Alkhara>
Anyone willing to answer a question 1:1 that has to do with source code but not directly for the Bitcoin project please DM me. I don't want to off-topic but you guys are probably the best source of information on this.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11587: Fix warnings when building with -Wthread-safety-analysis (master...–Wthread-safety-analysis) https://github.com/bitcoin/bitcoin/pull/11587
< gribble>
https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
< jtimon_>
wasn't there a communicate that bitcoin core will never release non free software somewhere?
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11585: addrman: Add missing lock in Clear() (CAddrMan) (master...missing-lock-in-addrman-clear) https://github.com/bitcoin/bitcoin/pull/11585
2017-10-30
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11583: Do not make it trivial for inbound peers to generate log entries (master...2017-10-no-net-log) https://github.com/bitcoin/bitcoin/pull/11583
< gribble>
https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt · Pull Request #11531 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #11580: Do not send (potentially) invalid headers in response to getheaders (master...2017-10-getheaders-valid-only) https://github.com/bitcoin/bitcoin/pull/11580
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11578: net: Add missing lock in ProcessHeadersMessage(...) (master...ProcessHeadersMessage) https://github.com/bitcoin/bitcoin/pull/11578
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11577: Fix warnings (-Wsign-compare) when building with DEBUG_ADDRMAN (master...DEBUG_ADDRMAN-warnings) https://github.com/bitcoin/bitcoin/pull/11577
< esotericnonsense>
cluelessperson: re your chat in #bitcoin if you actually want to and have time it would be nice to see a benchmark of non-pruning sync time against the same target (e.g. without network node variance)
< sipa>
perhaps you can try bitcoin.stackexchange.com
< Alkhara>
I mean my project isn't even going to be a competing currency, more of a service, and for some reason I am banned from #bitcoin even though I don't think I have ever been there.
< BlueMatt>
Alkhara: please take this to #bitcoin
< Alkhara>
This may not be the right place for this and feel free to tell me if it's not, but is there a reference sheet anywhere that points to the current value locations of Bitcoin's main variables? For example, max_coin_count is located in xxx.cpp. I am looking to fork for a project of mine but C++ skills are slowly coming up from nothing.
< wumpus>
blockchain.info might have changed their site but that's nothing to do with bitcoin core
< Alkhara>
with the current master release of Bitcoin, is the 80 extra bytes OP_Return still available to embed data? or was that removed?
< bitcoin-git>
[bitcoin] laanwj closed pull request #10409: [tests] Add fuzz testing for BlockTransactions and BlockTransactionsRequest (master...fuzz-blocktransactions) https://github.com/bitcoin/bitcoin/pull/10409
< bitcoin-git>
bitcoin/master b5545d8 Wladimir J. van der Laan: Merge #10409: [tests] Add fuzz testing for BlockTransactions and BlockTransactionsRequest...
< bitcoin-git>
bitcoin/master fd3a2f3 practicalswift: [tests] Add fuzz testing for BlockTransactions and BlockTransactionsRequest
< gmaxwell>
BlueMatt: we could also release note this point-- that running -shootmeinthefacekthx will cause your IP to get banned by bitcoin nodes when the fork happens and make it harder to switch back or run both.
< gmaxwell>
luke-jr: also as matt points out, if you don't undermine service flag disconnects you won't get banned by bitcoin 0.15+ peers, so I think that answers your concern/.
< wumpus>
karelb: it could have been resolved with e.g. service bits if 2x was willing, but they're insisting on making this a mess, so we have to do the least harmful thing for the existing bitcoin network
< achow101>
gmaxwell: I think the concern is if someone runs 2x and gets themselves banned, if they switch back to bitcoin they can't connect to the network anymore
< luke-jr>
gmaxwell: right now, we can peers that send invalid blocks, which means their Bitcoin nodes will get rejected from the p2p network too
< gmaxwell>
IniGit: #bitcoin
< IniGit>
I read the whitepaper of ethereum and I have a question (it is the same for bitcoin):
< luke-jr>
morcos: Bitcoin is almost a softfork relative to 2X
< luke-jr>
BlueMatt: it is necessary for people to switch from 2X to Bitcoin, or run them both
< gribble>
https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt · Pull Request #11531 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/11531 | Check that new headers are not a descendant of an invalid block (more effeciently) by TheBlueMatt · Pull Request #11531 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] sdaftuar closed pull request #11534: Evict outbound peers if tip is stale (master...2017-10-stale-tip-eviction) https://github.com/bitcoin/bitcoin/pull/11534
< bitcoin-git>
[bitcoin] theuni opened pull request #11562: bench: use std::chrono rather than gettimeofday (master...bench-clock-chrono) https://github.com/bitcoin/bitcoin/pull/11562
< gmaxwell>
sturles: it can't get anything from the partially sent block because its sent as a large single message. the bitcoin p2p layer deals with messages as big atomic units.
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11560: Connect to a new outbound peer if our tip is stale (master...2017-10-stale-tip-new-peer) https://github.com/bitcoin/bitcoin/pull/11560
< aj>
gmaxwell: i'd give 80% odds it's talking about the qt bugs fixed in 0.15.0.1... i doubt it's anything unknown or unfixed given the "Bitcoin Core project is seeing" them wording
< gmaxwell>
on upstream Bitcoin Core instability.
< gmaxwell>
- ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x
< gmaxwell>
7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing
< bitcoin-git>
[bitcoin] TheBlueMatt closed pull request #11487: Check that new headers are not a descendant of an invalid block (master...2017-10-acceptblock-validity-check) https://github.com/bitcoin/bitcoin/pull/11487
< sipa>
/join #bitcoin
< sipa>
can we move this to #bitcoin ?
< gmaxwell>
So its like importing the same private key into a litecoin and bitcoin wallet. They're still seperate.
< gmaxwell>
it isn't really-- these things are just totally seperate cryptocurrencies where they just happened to also pay everyone that owned bitcoin at a certian time on them.
< gmaxwell>
(and, in fact, your bitcoin transactions are not compatible with them).
< gmaxwell>
Grandpa_: because they are entirely seperate systems that diverged from bitcoin in the past, they will not see your transactions.
< gmaxwell>
When you pay with your bitcoin core wallet, only the bitcoin will move... the Bcash (and presumably bgold) will just stay where they are.
< gmaxwell>
Grandpa_: Bitcoin Cash will not 'replay' your bitcoin transactions. You can send bitcoin without worrying about that. Bitcoin gold doesn't really exist yet, but they claim that when it does it will also not be vulnerable to replay, so again, should be no reason to worry there.
< Grandpa_>
So: Could someone among you PLEASE share some insight as to what to actually do? Since Bitstamp has automatically credited costumer accts with pre-BTCash holdings with one BTCash for each old BTC, do they also automatically do this with BTC that are transferred now? If not, how to go about it from inside Bitcoin Core (with the least possible difficulty and complexity for an aging chap who struggles with the technicalities i
< Grandpa_>
Now I would like to transfer some to Bitstamp (the only place where I have an acct) in case I would like to sell a litle bit. But I would of course also like to NOT LOSE the Bitcoin Cash and Gold coins which now (as far as I am able to discern from media coverage) reside inside the belly of each of my old Bitcoins. I've tried to make sense of Bitstamp's official statements but there isn't really any usable information ther
< Grandpa_>
Hello, - an old lowtech grandpa on the line here - hoping you guys can help me figure out what to do. I have an old Bitcoin Core wallet with some old BTC coins in it. It haven't spent any or even touched the wallet (other than upgrading to Core 0.15.0.1 a few day ago) since May 2017 - prior to the Segwit implementation and the Bitoin Cash and Gold forks that I have been trying to follow through the media.
< bitcoin-git>
[bitcoin] Sjors opened pull request #11557: WIP: Use Sat/WU instead of (μ/m)BTC/kB and show percentage fee (master...fee-sat-per-wu) https://github.com/bitcoin/bitcoin/pull/11557
< jtimon>
are there any other tests that use hardcoded blocks that I can copy from ? I guess the answer is no since https://github.com/bitcoin/bitcoin/pull/8994 which changes the genesis block for all functional tests is passing, but it was recently brought to my attention that hardcoding txs (including coinbases) should be enough even to construct a compatible even with a hf that completely changes the proof of work rules from genesis