< bitcoin-git>
[bitcoin] murrayn opened pull request #12809: Formatting changes to --help code for increased readability. (master...help_formatting) https://github.com/bitcoin/bitcoin/pull/12809
< bitcoin-git>
[bitcoin] romanz opened pull request #12810: [Tests] Fix a typo at assert_start_raises_init_error() and update its invocation (master...fix-blocksdir-test) https://github.com/bitcoin/bitcoin/pull/12810
< wumpus>
I've added jnewbery to the issue management team: there's now fanquake, meshcollider, cfields and jnewbery that can help with issues and PRs on github, and open/close them
< aj>
wumpus: if you haven't noticed already, #12806 is needed to fix travis failure on master
< bitcoin-git>
bitcoin/master d71bedb MarcoFalke: qa: Fix function names in feature_blocksdir
< bitcoin-git>
bitcoin/master 18606eb Wladimir J. van der Laan: Merge #12806: qa: Fix function names in feature_blocksdir...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12806: qa: Fix function names in feature_blocksdir (master...Mf1803-qaBlocksdirFixup) https://github.com/bitcoin/bitcoin/pull/12806
< bitcoin-git>
[bitcoin] laanwj opened pull request #12811: test: Make summary row bold-red if any test failed (master...2018_03_tests_summaryrow) https://github.com/bitcoin/bitcoin/pull/12811
< aj>
wumpus: if you're making test_runner nicer, might work to just report all the failed tests at the end so they're easy to find. https://github.com/laanwj/bitcoin/pull/6 has sample code
< wumpus>
yes, there's probably a ton of different things that could be done
< wumpus>
I like making the row red though
< wumpus>
though could do what you propose in addition to that, as it saves scrolling to find what failed
< aj>
wumpus: i meant as well, not instead :)
< wumpus>
right :)
< wumpus>
I'll pull in your commit
< aj>
wumpus: feel free to squash it, i didn't write a good commit message :)
< wumpus>
instead of adding a sort_key we change the natural sorting order of the object
< wumpus>
probably want to sort by 1) status, then within that 2) name
< bitcoin-git>
bitcoin/master adc2586 MarcoFalke: doc: Refer to witness reserved value as spec. in the BIP
< bitcoin-git>
bitcoin/master 174d016 Wladimir J. van der Laan: Merge #12798: doc: Refer to witness reserved value as spec. in the BIP...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12798: doc: Refer to witness reserved value as spec. in the BIP (master...Mf1803-docWitnessReservedValue) https://github.com/bitcoin/bitcoin/pull/12798
< provoostenator>
What is bitdb in #11625 ryanofsky?
< bitcoin-git>
bitcoin/master f92541f Wladimir J. van der Laan: test: Make summary row bold-red if any test failed...
< bitcoin-git>
bitcoin/master ffb033a Anthony Towns: test: List any failed tests at the end of test_runner output...
< bitcoin-git>
bitcoin/master 0d8fc8d Wladimir J. van der Laan: Merge #12811: test: Make summary row bold-red if any test failed and show failed tests at end of table...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12811: test: Make summary row bold-red if any test failed and show failed tests at end of table (master...2018_03_tests_summaryrow) https://github.com/bitcoin/bitcoin/pull/12811
< jnewbery>
release-notes.md conflicts are really irritating. Any thoughts on how to make them stop? Perhaps have a separate release-notes file for each PR that requires them, eg release-notes-pr1234.md, and then concatenate/edit them before the release? Release notes need a lot of editing anyway, so might not add too much overhead
< sipa>
jnewbery: that doesn't seem like more overhead than the to-wiki-and-back dance we do already at the end
< BlueMatt>
jimpo: I'd really rather the paralell-txindex stuff not have its own thread
< BlueMatt>
we have too much thread proliferation already, can it not fit cleanly into just running in the scheduler/validationinterface thread(s) (and we can add another thread there when things get too full)
< jimpo>
BlueMatt the thread is just for when the index needs to catch up to the blockchain state from way behind (like behind BlockConnected callbacks).
< jimpo>
Once it gets in sync once, the thread exits and the index is kept in sync by the validation interface.
< BlueMatt>
ah, ok, right, will finish reviewing before I comment more :p
< jimpo>
\o/ Code review is happening!
< MarcoFalke_trave>
wumpus, Are you around for merges? I might send you a list of pulls
< paulg222>
with bitcoin 0.16 in regtest mode I'm seeing that coinbase transactions are not going to a segwit p2sh wrapped address, but to a regular p2pkh address. Is that expected?
< arubi>
paulg222, it's going to a p2pk, not p2pkh. use generatetoaddress
< arubi>
(if you want a different address that is)
< instagibbs>
jnewbery, ive had to rebase a couple PRs a couple times each due to that :/
< BlueMatt>
if thats your concern you should have a git-signing separate primary key
< BlueMatt>
fully-separate them instead of partially combining them
< eklitzke>
maco when you're traveling your nick should be MarcoPolo
< instagibbs>
sdaftuar the `IsDust` use in both relay and wallet policy seems like it makes reasoning about p2sh outputs weird to me. I guess you just pretend the output is p2sh-p2wpkh, and use that for relay dust calculation?
< instagibbs>
(I'm leaving it for now, just thinking aloud)
< sdaftuar>
instagibbs: yeah i was wondering what effect this has on relay policy too -- but figure we might as well just make it right for our wallet at least
< instagibbs>
the functional test already is pretty coarse-grained
< sdaftuar>
so we could just add a way to indicate we want the p2sh-p2wpkh assumption and use that only for our wallet, if we don't want to change relay policy
< instagibbs>
checks that you dump 100 satoshis
< instagibbs>
right
< instagibbs>
or just split the concerns to allow us to move faster with wallet stuff
< sdaftuar>
oh hmm. i guess the reason we have a discard rate in the first place is to be sure that we have a buffer above the prevailing network dust-fee
< sdaftuar>
so splitting might be counter to that a little
< sdaftuar>
in that we might decouple our calculation from the network-wide policy
< sdaftuar>
oh.. so this is unfortunate i guess, in that current network nodes are applying a dust threshold that is "too high" for our p2sh-segwit wallet. good thing we have a discard rate in the first place i guess! but given that it gets capped at the long term fee estimate, i'm not sure what value we're actually using now
< instagibbs>
ill update the test at least to be a bit tighter
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12823: doc: Add .gitattributes file for release-notes.md (master...Mf1803-docGitattributes) https://github.com/bitcoin/bitcoin/pull/12823
< BlueMatt>
#12754 does not look like an "upstream" issue - the reporter indicating some things we should probably do that make upstream behave the proper way
< hkjn0>
hey, maybe I'm just missing something basic here, but I had a tx which sendrawtransaction accepted and returned txid, but getrawtransaction (with txindex=1) still can't find.. how can this happen?
< hkjn0>
I'm assuming that if the fee was lower than minrelaytxfee we'd return an error instead of a txid..
< jnewbery>
hkjn0: #bitcoin please. This channel is for bitcoin core development
< hkjn0>
yup, sorry, realized after writing it was off-topic