< bitcoin-git>
bitcoin/master ee5c1ce Karl-Johan Alm: Bug-fix: listsinceblock: use closest common ancestor when a block hash was provided for a chain that was not the main chain.
< bitcoin-git>
bitcoin/master 7ba0a00 Karl-Johan Alm: Testing: listsinceblock should not use orphan block height.
< bitcoin-git>
bitcoin/master 727a798 Wladimir J. van der Laan: Merge #9516: Bug-fix: listsinceblock: use fork point as reference for blocks in reorg'd chains...
< bitcoin-git>
[bitcoin] laanwj closed pull request #9516: Bug-fix: listsinceblock: use fork point as reference for blocks in reorg'd chains (master...listsinceblock-reorg-fix) https://github.com/bitcoin/bitcoin/pull/9516
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #9613: [wallet] Clarify getbalance help string to explain interaction with bumpfee (master...pr/getbalance-help) https://github.com/bitcoin/bitcoin/pull/9613
< bitcoin-git>
[bitcoin] jnewbery closed pull request #9591: [net] count mempool and extra pool matches correctly in PartiallyDownloadedBlock::InitData() (master...compactmatches) https://github.com/bitcoin/bitcoin/pull/9591
< BlueMatt>
lol, someone might want to remove "Add support for Segregated Witness to Bitcoin Core" from the in-progress projects list....
< BlueMatt>
luke-jr: or gmaxwell might know, otherwise i say close
< BlueMatt>
I'll go do a code pass and see if i see anything surprising anywhere
< MarcoFalke>
BlueMatt: I don't like too much references to GitHub in the commits and stuff. It is already mentioned in one of the commits. No need to put it in the title (i.e. merge commit)
< * sipa>
has a deep philosophical objection to having PR numbers in commits
< sipa>
PR and issues
< BlueMatt>
ok
< BlueMatt>
i mean we fucking trust github for everything else, I'm not sure why thats the line, but ok :p
< sipa>
i still see the commit history as something that exists independently from github
< midnightmagic>
and independently verifiable
< gwillen>
BlueMatt: if github went away tomorrow, everything would be fine and the project would recover and go elsewhere, but all those issue and PR numbers would be permanently rendered nonsense pointers to nowhere.
< midnightmagic>
last I asked, there is someone mirroring all that data via either the github api or otherwise.
< BlueMatt>
yea, I mean I dont really want to copy all the details of an issue into a commitmsg just to reference it
< BlueMatt>
midnightmagic: I know i heard someone doing it...I assume kanzure?
< BlueMatt>
him or petertodd are probably timestamping it, too
< midnightmagic>
I sadly don't recall and would have to check logs.
< gmaxwell>
sipa: what don't you understand? signrawtransaction is pretty eager in returning complete: false in many situations when the transaction is actually complete.
< sipa>
gmaxwell: can you give an example?
< sipa>
ah, i think i see... when there is a pre-existing valid signature for an input, but not the prevout information to validate it?
< gmaxwell>
sipa: I think the issue mentioned one? grab a random transaction out of a block, run signraw on it. complete will be false.
< sipa>
does it also if you pass the prevouts it spends?
< gmaxwell>
there are many different ways to run into it, but I think most of them reduce to not knowing the prevout.
< gmaxwell>
I believe it's still false if you do that, but I'm not sure, brain rot.
< gmaxwell>
what I was trying to say in the PR is that it's okay if we don't return complete true if we don't know... but we shouldn't return false when we don't know either.
< sipa>
i guess we should have made the output an array, which lists the status of each input
< gmaxwell>
I've ended up wasting time while offline multisigning things with people due to it falsely returning false making us think it wasn't working when it was.
< sipa>
complete/incomplete/unknown
< gmaxwell>
(after wasting a bunch of time because "scriptPubkey" is not "scriptPubKey")