< 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
< 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>
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 :)
< 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.
< 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
< 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] 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>
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
< 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/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