< luke-jr> we already have something similar for block explorers; but it'd need a URI, not just a key - otherwise nothing will get relayed far
< luke-jr> it occurs to me the revalidation we do when a pre-segwit node upgrades to segwit, is really something we ought to be doing for every softfork :x
< gmaxwell> we do? :(
< gmaxwell> I hope we're not directing people to centeralized block explorers. :(
< gmaxwell> luke-jr: yes, it is. But it was more important for segwit becuase we needed to actually fetch the witness data.
< luke-jr> gmaxwell: there is no default, and the example is example.com
< gmaxwell> where is this?
< luke-jr> Settings->Options->Display->Third party transaction URLs
< gmaxwell> in that case I'm not so worried about the defaults but the idea that you can trust basically any of these websites. I've not seen a single block explorer which has never displayed massively incorrect data at one time or another. Not to mention that the 'balances' model that they all use is a misleading presentation of the system. :(
< luke-jr> for better or worse, it's been there for a while
< morcos> gmaxwell: The aspect of that that I thought about was the ability to do some sort of sanity checking... Like are you paying more than the median fee from the last 10 blocks? But I'm unclear on how worth it it would be...
< morcos> I think that type of sanity checking could be useful for catching when our fee estimation mihgt not be performing at it's best
< morcos> In reality, if you've had your node up and running long enough that you saw a block more than 10 mins after you started... you ought to be able ot at least do something not insane
< bitcoin-git> [bitcoin] practicalswift closed pull request #9557: Prefer (int)a over int(a) (master...avoid-functional-cast-expression) https://github.com/bitcoin/bitcoin/pull/9557
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/af01cd3a3d06...0b96abc35f1a
< bitcoin-git> bitcoin/master afab9f4 practicalswift: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp
< bitcoin-git> bitcoin/master 0b96abc MarcoFalke: Merge #9554: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9554: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp (master...avoid-null-pointer-dereference-in-addrman_tests) https://github.com/bitcoin/bitcoin/pull/9554
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9543: [Trivial] Grammar and typo correction (master...master) https://github.com/bitcoin/bitcoin/pull/9543
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #9610: [Trivial] Grammar and typo correction (laudaa) (master...Mf1701-laudaa) https://github.com/bitcoin/bitcoin/pull/9610
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0b96abc35f1a...ff58b1c3bdff
< bitcoin-git> bitcoin/master 5c66d41 Lauda: [Trivial] Grammar and typo correction...
< bitcoin-git> bitcoin/master ff58b1c MarcoFalke: Merge #9610: [Trivial] Grammar and typo correction (laudaa)...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #9610: [Trivial] Grammar and typo correction (laudaa) (master...Mf1701-laudaa) https://github.com/bitcoin/bitcoin/pull/9610
< afk11> any way to sign a single input with a key/hashtype using bitcoin-tx?
< afk11> this vector uses the same key in different inputs, with different hashtypes, so signrawtransaction doesn't suit this.
< cfields> gmaxwell: sigh, there are so many edge-cases with the handshake, a mutex for a clump of vars may be un-avoidable
< BlueMatt> cfields: why can we not set all these things later in ::VERSION processing?
< BlueMatt> (mostly nVersion and fSuccessfullyConnected)
< BlueMatt> cfields: i mean in your change you're setting those things even above sending a response ::VERSION
< BlueMatt> which might mean you could send other messages before version, right?
< gmaxwell> cfields: I don't think it's that bad... just the verack comment was because you moved the fSuccessfullyConnected above the VERACK... if you hadn't done that, we'd be no worse than we are now.
< Chris_Stewart_5> What does it mean when bitcoin core return an error with insufficient priority? Specifically in a regtest mode
< sipa> Chris_Stewart_5: it means your feerate is too low