< bitcoin-git>
bitcoin/master 1ab49b8 Jon Atack: Add in/out connections to rpc getnetworkinfo
< bitcoin-git>
bitcoin/master d9cc13e Jon Atack: UNIX_EPOCH_TIME fixup in rpc getnettotals
< bitcoin-git>
bitcoin/master 581b343 Jon Atack: Add in/out connections to cli -getinfo
< bitcoin-git>
[bitcoin] laanwj merged pull request #19405: rpc, cli: add network in/out connections to `getnetworkinfo` and `-getinfo` (master...in-and-out-connections) https://github.com/bitcoin/bitcoin/pull/19405
< bitcoin-git>
[bitcoin] ariard opened pull request #19871: Clarify scope of eviction protection of outbound block-relay peers (master...2020-09-clarify-eviction-block-relay) https://github.com/bitcoin/bitcoin/pull/19871
< jnewbery>
oops. I'm just realising that we should have aimed to merge #19606 before #19680 (so they're merged into v0.20 in the same order as in master)
< jnewbery>
merging them in the opposite order just makes the commits a little bit more different from master and the backport a little harder to review
< wumpus>
agree, merging them on the same order in 0.20 would make sense, this is always what i aim for too
< wumpus>
maybe we could revert it for now
< jnewbery>
I've rebased #19606 onto the new 0.20 head. Let's see what reviewers think.
< jnewbery>
it only conflicts in a couple of places, but it's a little fiddly to get those bits right
< sdaftuar>
wumpus: jnewbery: didn't marco propose the opposite order in a meeting a few weeks ago, so that if we cut another release on the 0.20 branch we could delay releasing wtxid-relay before 0.21?
< sdaftuar>
while still getting the other fix out there
< sdaftuar>
that was what i understood at any rate...
< jnewbery>
I said at the time that it didn't matter which order they're merged in (and it doesn't - it's just a bit cleaner if they go in the same order as master)
< sdaftuar>
i'm confused about how you could cut an 0.20.x release without wtxid-relay but with the other mitigation, if wtxid-relay were merged first?
< sdaftuar>
i agree that doing things in the same order as master makes sense by default, just confused about how to reconcile that with marco's suggestion
< jnewbery>
I think marco was saying that we shouldn't ship backported code in a v0.20 minor release before it's been released in master, not specifically that the other mitigation should go in a release first
< jnewbery>
*been released in v0.21
< sdaftuar>
ah, thanks for the clarification
< sipa>
that was my understanding as well
< bitcoin-git>
[bitcoin] luke-jr opened pull request #19873: [WIP] Flush dbcache early if system is under memory pressure (master...mempressure) https://github.com/bitcoin/bitcoin/pull/19873
< bitcoin-git>
[bitcoin] jonatack opened pull request #19874: cli: degrade -getinfo gracefully for older servers (master...getinfo-handle-older-servers-gracefully) https://github.com/bitcoin/bitcoin/pull/19874
< bitcoin-git>
[bitcoin] amitiuttarwar opened pull request #19877: [test] Clarify rpc_net functional test (master...2020-09-rpcnet-fixes) https://github.com/bitcoin/bitcoin/pull/19877
< pinheadmz>
combinerawtransaction doesn't seem to do entirely what I expect. I noticed the help message doesn't seem right (it says the param is an array of tx hashes, but I think it is actually an array of raw hex txs) so I was going to open a PR just for that, and write some tests for bonus points. But it doesn't really fully combine transactions like I'd expect (produce a nex tx with all the ins and outs of all the txs
< pinheadmz>
that are passed to it) -- is this by design / I'm missing something?
< sipa>
it's supposed to merge signatures
< sipa>
not create coinjoins
< pinheadmz>
so it only preserves the outputs of the first tx in the array
< sipa>
the inputs/outputs of all transactions need to match
< sipa>
it's so you can merge signatures for multiple parties for creating a multisig spend
< sipa>
also, use psbt :)
< sipa>
joinpsbts sounds more like what you're looking for
< pinheadmz>
sure yeah - and actually I was going to use it to RBF by adding outputs to an existing TX
< pinheadmz>
not coinjoin
< sipa>
right, sure - combinerawtransaction doesn't do that
< sipa>
all these RPCs are for transactions that are "decided" already, and all you're doing is gathering signatures
< pinheadmz>
ok I'll open this PR just for the help message then
< sipa>
joinpsbts is an exception in that regard
< pinheadmz>
side note - sendmany and createrawtransaction don't like multiple outputs with the same address... is there any raw tx rpc that does?
< sipa>
i don't think so
< bitcoin-git>
[bitcoin] pinheadmz opened pull request #19878: rawtransaction: fix argument in combinerawtransaction help message (master...combinetx1) https://github.com/bitcoin/bitcoin/pull/19878