1 2017-01-22 00:22:48	0|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
 2 2017-01-22 00:23:40	0|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
 3 2017-01-22 00:25:44	0|gmaxwell|we do? :(
 4 2017-01-22 00:25:58	0|gmaxwell|I hope we're not directing people to centeralized block explorers. :(
 5 2017-01-22 00:26:26	0|gmaxwell|luke-jr: yes, it is. But it was more important for segwit becuase we needed to actually fetch the witness data.
 6 2017-01-22 00:27:03	0|luke-jr|gmaxwell: there is no default, and the example is example.com
 7 2017-01-22 00:27:36	0|gmaxwell|where is this?
 8 2017-01-22 00:28:07	0|luke-jr|Settings->Options->Display->Third party transaction URLs
 9 2017-01-22 00:28:53	0|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. :(
10 2017-01-22 00:31:23	0|luke-jr|for better or worse, it's been there for a while
11 2017-01-22 01:18:06	0|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...
12 2017-01-22 01:18:50	0|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
13 2017-01-22 01:19:56	0|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
14 2017-01-22 09:31:32	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #9557: Prefer (int)a over int(a) (06master...06avoid-functional-cast-expression) 02https://github.com/bitcoin/bitcoin/pull/9557
15 2017-01-22 12:18:17	0|bitcoin-git|13bitcoin/06master 14afab9f4 15practicalswift: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp
16 2017-01-22 12:18:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/af01cd3a3d06...0b96abc35f1a
17 2017-01-22 12:18:18	0|bitcoin-git|13bitcoin/06master 140b96abc 15MarcoFalke: Merge #9554: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp...
18 2017-01-22 12:18:32	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9554: [test] Avoid potential NULL pointer dereference in addrman_tests.cpp (06master...06avoid-null-pointer-dereference-in-addrman_tests) 02https://github.com/bitcoin/bitcoin/pull/9554
19 2017-01-22 12:21:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9543: [Trivial] Grammar and typo correction (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9543
20 2017-01-22 12:27:25	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9610: [Trivial] Grammar and typo correction (laudaa) (06master...06Mf1701-laudaa) 02https://github.com/bitcoin/bitcoin/pull/9610
21 2017-01-22 12:29:10	0|bitcoin-git|13bitcoin/06master 145c66d41 15Lauda: [Trivial] Grammar and typo correction...
22 2017-01-22 12:29:10	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0b96abc35f1a...ff58b1c3bdff
23 2017-01-22 12:29:11	0|bitcoin-git|13bitcoin/06master 14ff58b1c 15MarcoFalke: Merge #9610: [Trivial] Grammar and typo correction (laudaa)...
24 2017-01-22 12:29:28	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9610: [Trivial] Grammar and typo correction (laudaa) (06master...06Mf1701-laudaa) 02https://github.com/bitcoin/bitcoin/pull/9610
25 2017-01-22 12:42:05	0|afk11|any way to sign a single input with a key/hashtype using bitcoin-tx?
26 2017-01-22 12:44:37	0|afk11|this vector uses the same key in different inputs, with different hashtypes, so signrawtransaction doesn't suit this.
27 2017-01-22 18:49:12	0|cfields|gmaxwell: sigh, there are so many edge-cases with the handshake, a mutex for a clump of vars may be un-avoidable
28 2017-01-22 19:42:07	0|BlueMatt|cfields: why can we not set all these things later in ::VERSION processing?
29 2017-01-22 19:42:13	0|BlueMatt|(mostly nVersion and fSuccessfullyConnected)
30 2017-01-22 19:44:49	0|BlueMatt|cfields: i mean in your change you're setting those things even above sending a response ::VERSION
31 2017-01-22 19:45:01	0|BlueMatt|which might mean you could send other messages before version, right?
32 2017-01-22 21:49:08	0|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.
33 2017-01-22 22:37:22	0|Chris_Stewart_5|What does it mean when bitcoin core return an error with insufficient priority? Specifically in a regtest mode
34 2017-01-22 22:38:06	0|sipa|Chris_Stewart_5: it means your feerate is too low