< archaeal> nevermind my last question...hadn't enabled the proper flags on configure
< bitcoin-git> [bitcoin] knoxcard opened pull request #12877: Show correct bitcoin daemon bash commands (master...patch-1) https://github.com/bitcoin/bitcoin/pull/12877
< bitcoin-git> [bitcoin] ajtowns opened pull request #12878: [refactor] Config handling refactoring in preparation for network-specific sections (master...netconf-refactor) https://github.com/bitcoin/bitcoin/pull/12878
< fanquake> Apologies if the labeller has been a bit off target lately. Should be back on track now..
< luke-jr> fanquake: wait, that's automated? XD
< bitcoin-git> [bitcoin] kallewoof opened pull request #12879: [scripted-diff] No extern function declarations (master...scripted-no-extern-functions) https://github.com/bitcoin/bitcoin/pull/12879
< aj> wumpus: i've split #12878 out of #11862 (-sasl/daer] has joined #bitcoin
< gribble> https://github.com/bitcoin/bitcoin/issues/12878 | [refactor] Config handling refactoring in preparation for network-specific sections by ajtowns · Pull Request #12878 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/11862 | Network specific conf sections by ajtowns · Pull Request #11862 · bitcoin/bitcoin · GitHub
< aj> wumpus: ...and can't cut&paste to irc competently apparently. https://github.com/bitcoin/bitcoin/pull/11862#issuecomment-378524308 has rationale. maybe 12878 could be high-pri-for-review?
< bitcoin-git> [bitcoin] murrayn opened pull request #12881: Tighten up bech32::Decode(); add tests. (master...bech32_decode) https://github.com/bitcoin/bitcoin/pull/12881
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ad960f5771dc...1d540046fe47
< bitcoin-git> bitcoin/master 2ebad11 Sjors Provoost: make clean removes src/qt/moc_ files
< bitcoin-git> bitcoin/master 1d54004 Jonas Schnelli: Merge #12870: make clean removes src/qt/moc_ files...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #12870: make clean removes src/qt/moc_ files (master...2018/04/make_clean_qt_moc) https://github.com/bitcoin/bitcoin/pull/12870
< bitcoin-git> [bitcoin] practicalswift opened pull request #12882: tests: Fix lock-order-inversion (potential deadlock) in DoS_tests. Reported by TSAN. (master...lock-order-inversion-in-DoS_tests) https://github.com/bitcoin/bitcoin/pull/12882
< setpill> hi all, im playing around with RBF in regtest, and noticed some weirdness. noticeably, the (undocumented) return value "walletconflicts" of "listtransactions" and "gettransaction" ONLY shows a conflict in the receiving node if a RBF tx is feebumped with that node again as receiving party
< setpill> if node 1 sends a RBF tx to node 2, then RBFs it back to itself, node 2 will not show this conflict in any way even though the new tx (from node 1 to itself) is the one present in node 2's mempool
< setpill> (in fact, even mining a new block with node 2 will mine the tx from node 1 to itself and the tx from node 1 to node 2 THEN disappears from node 2's wallet)
< setpill> is this how it is intended to work?
< provoostenator> setpill: "RBFs it back to itself" means a completely new transaction? If it has fewer bytes for whatever reason, it might violate one of the BIP-125 rules.
< provoostenator> I would suggest testing first with just bumping the fee without changing anything else.
< setpill> provoostenator: BIP 125 says nothing about byte size
< provoostenator> https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki "3. The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
< setpill> sure... that is distinct from bytes
< provoostenator> Yes, it's indirect
< setpill> eh
< setpill> anyway
< provoostenator> But it matters if your new transaction is smaller and the fee rate isn't increased enough to offset that. There's some discussion on the bitcoin-dev mailinglist to relax that particular rule
< setpill> it does get propagated
< setpill> the conflict is just not shown in the wallet rpc output
< provoostenator> I'm not familiar with that part of the RPC, so not sure what's going on there.
< setpill> and in the UI it's only shown VERY indirectly, when opening the transaction details it says "status: [..] not in mempool"
< sdaftuar> setpill: i haven't double checked but what you describe makes some sense to me--
< sdaftuar> setpill: the receiving node's wallet will never even be aware of the second transaction (except indirectly) because the second transaction doesn't involve it at all (no inputs, no outputs belong to the wallet)
< sdaftuar> the receiving node will notice that the original transaction is no longer in the mempool, i think
< sdaftuar> but the "walletconflicts" output from the rpc call only reports other transactions that spend the same inputs
< setpill> no, apparently not
< sdaftuar> this could use some documentation i think if it's missing
< setpill> it only reports other transactions that spend the same inputs AND touch the local wallet
< sdaftuar> setpill: yes, sorry that's what i meant. listtransactions is a wallet rpc call, so the context here is transactions in your wallet
< sdaftuar> not eg transactions in the mempool
< sdaftuar> "walletconflicts"
< setpill> right, yes, but it would be useful to see conflicting txes in the mempool of local wallet txes even if the conflicting txes dont touch the local wallet
< setpill> (actually id be MORE interested in them if they dont touch the local wallet since then it is a doublespend)
< setpill> the receiving tx not being in the mempool might just be due to mempool being full
< jnewbery> archael: I presume you built without wallet. If you run the functional tests through test_runner, it'll check that the wallet was compiled in. If you run the tests directly, I think they'll just fail with confusing messages like you saw
< jnewbery> (generate is a wallet RPC, which is why it returned the Method not found error)
< sdaftuar> setpill: i think it might be pretty straightforward to do what i think you're asking. perhaps open an issue on bitcoin core as a feature request?
< setpill> sdaftuar: will do, just wasnt sure if i was missing something :)
< sdaftuar> setpill: well it's possible i'm missing something too and there's already a good workflow, in which case i expect someone to say as much on the github issue :)
< setpill> 👍
< bitcoin-git> [bitcoin] jamesob closed pull request #12873: [ci] Run functional tests using bitcoin-qt in one Travis job (master...2018-04-03-travis-func-qt) https://github.com/bitcoin/bitcoin/pull/12873
< jnewbery> MarcoFalke , wumpus: any idea why #12873 isn't getting picked up by travis? jamesob has force pushed and close-opened the PR, but it's not getting run on travis.
< gribble> https://github.com/bitcoin/bitcoin/issues/12873 | [ci] Run functional tests using bitcoin-qt in one Travis job by jamesob · Pull Request #12873 · bitcoin/bitcoin · GitHub
< sipa> maybe it's confused by the close/reopen?
< sipa> was there a push in between the close and reopen?
< jnewbery> no - github won't allow you to re-open if there's been a push since close
< jnewbery> I suggested james close-open to try and kick travis, since it wasn't running before
< sipa> weird
< bitcoin-git> [bitcoin] sipa opened pull request #12885: Reduce implementation code inside CScript (master...201803_reducescript) https://github.com/bitcoin/bitcoin/pull/12885
< sipa> why are so many of the win64 travis jobs timing out suddenly?
< sipa> should we temporarily disable testing those?
< sipa> oh, it's the win32 one
< jnewbery> sipa: unit tests are slow in wine
< jnewbery> #12772 was a mitigation to help, but we need to figure out why those tests are so slow and fix
< gribble> https://github.com/bitcoin/bitcoin/issues/12772 | [CI]: bump travis timeout for make check to 50m by jnewbery · Pull Request #12772 · bitcoin/bitcoin · GitHub
< sipa> jnewbery: just unit tests, not functional tests?
< jnewbery> just unit tests I believe. See https://travis-ci.org/bitcoin/bitcoin/jobs/361486215 for example
< bitcoin-git> [bitcoin] jamesob closed pull request #12873: [ci] Run functional tests using bitcoin-qt in one Travis job (master...2018-04-03-travis-func-qt) https://github.com/bitcoin/bitcoin/pull/12873
< jnewbery> that travis job doesn't run functional tests
< jnewbery> wumpus: #12167 may be ready for merge
< gribble> https://github.com/bitcoin/bitcoin/issues/12167 | Make segwit failure due to CLEANSTACK violation return a SCRIPT_ERR_CLEANSTACK error code by maaku · Pull Request #12167 · bitcoin/bitcoin · GitHub
< jamesob> did we document the new procedure for changelog additions anywhere? (i.e. file-per-change to be aggregated at release time, IIRC)
< jnewbery> jamesob: i think the outcome was that the maintainers have no objection to contributors adding per-PR release notes files
< jamesob> jnewbery: any convention on where that lives? (apologies if obvious)
< jnewbery> not yet!
< jimpo_> Am I correct that undo data is only pruned if blocks themselves are pruned?
< sdaftuar> jimpo_: yes
< jimpo_> Seems like there could be an option to prune that after a certain height and leave the block data so it can be served to other nodes?
< sipa> indeed
< sipa> though the undo data is relatively small compared to the block data, so it doesn't gain you all that much
< jimpo_> Eh, it's still 37/196 GB on my machine
< jnewbery> wumpus: #12460 could be ready for merge too
< gribble> https://github.com/bitcoin/bitcoin/issues/12460 | Assert CPubKey::ValidLength to the pubkeys header-relevant size by Empact · Pull Request #12460 · bitcoin/bitcoin · GitHub
< jimpo_> But I see the point that if you're willing to keep 160+ GB, you can afford the extra 37
< sipa> jnewbery: i'll do some merges soon if wumpus is not around
< sipa> jimpo_: yes, i'm not disagreeing with you - pruning undo data more than block data makes sense
< sipa> but given that the reduction ratio of storage isn't all that high i guess it hasn't really been a priority
< sipa> 18:33:58 < sipa> jimpo_: yes, i'm not disagreeing with you - pruning undo data more than block data makes sense
< jimpo> Thx, makes sense
< bitcoin-git> [bitcoin] jamesob reopened pull request #12873: [ci] Run functional tests using bitcoin-qt in one Travis job (master...2018-04-03-travis-func-qt) https://github.com/bitcoin/bitcoin/pull/12873
< bitcoin-git> [bitcoin] sipa opened pull request #12886: Introduce Slice type and use it instead of FLATDATA (master...201803_slice) https://github.com/bitcoin/bitcoin/pull/12886
< bitcoin-git> [bitcoin] jnewbery opened pull request #12887: [trivial] Add newlines to end of log messages. (master...log_messages_newlines) https://github.com/bitcoin/bitcoin/pull/12887
< DrDraake> Hey guys
< DrDraake> This might be a silly question to some. I'm just having a hard time finding the answer. If someone has a Bitcoin Core wallet and I install the Bitcoin Core Wallet on a new PC. Do I need to wait for the entire history of the blockchain to download prior to receiving coins?
< sipa> please go to #bitcoin or https://bitcoin.stackexchange.com
< DrDraake> Got it.
< sipa> there are plenty of answers about questions like that
< bitcoin-git> [bitcoin] jamesob closed pull request #12873: [ci] Run functional tests using bitcoin-qt in one Travis job (master...2018-04-03-travis-func-qt) https://github.com/bitcoin/bitcoin/pull/12873
< bitcoin-git> [bitcoin] jamesob reopened pull request #12873: [ci] Run functional tests using bitcoin-qt in one Travis job (master...2018-04-03-travis-func-qt) https://github.com/bitcoin/bitcoin/pull/12873
< dtnge> JOIN
< jnewbery> wumpus: mind if I take over #7729?
< gribble> https://github.com/bitcoin/bitcoin/issues/7729 | rpc: introduce label API for wallet by laanwj · Pull Request #7729 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d540046fe47...648252e8ae91
< bitcoin-git> bitcoin/master fa6f12a MarcoFalke: travis: Run verify-commits only on cron jobs
< bitcoin-git> bitcoin/master 648252e MarcoFalke: Merge #12851: travis: Run verify-commits only on cron jobs...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12851: travis: Run verify-commits only on cron jobs (master...Mf1804-travisCronVerifyCommits) https://github.com/bitcoin/bitcoin/pull/12851
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12702: [wallet] [rpc] [doc] importprivkey: hint about importmulti (master...importprivkey-importmulti-hint) https://github.com/bitcoin/bitcoin/pull/12702
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dab0d6859b8a...2106c4c64c36
< bitcoin-git> bitcoin/master faace13 MarcoFalke: qa: Match full plain text by default
< bitcoin-git> bitcoin/master 2106c4c MarcoFalke: Merge #12853: qa: Match full plain text by default...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12853: qa: Match full plain text by default (master...Mf1803-qaErrorMatchFullText) https://github.com/bitcoin/bitcoin/pull/12853
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2106c4c64c36...bfaed1ab2ec7
< bitcoin-git> bitcoin/master f8c249a Ben Woosley: Assert CPubKey::ValidLength to the pubkey's header-relevent size...
< bitcoin-git> bitcoin/master bfaed1a MarcoFalke: Merge #12460: Assert CPubKey::ValidLength to the pubkey's header-relevant size...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #12460: Assert CPubKey::ValidLength to the pubkey's header-relevant size (master...key-size-check-header) https://github.com/bitcoin/bitcoin/pull/12460
< aj> jamesob, jnewbery: i did doc/release-nots-pr12823.md fwiw
< aj> notes even
< aj> i noticed that unit tests in gcc seem to take longer than unit tests in clang (2min vs 40s), seems a bit odd? haven't investigated
< sipa> aj: that's dramatic :o