1 2017-08-11 00:14:14 0|bitcoin-git|[13bitcoin] 15sipa opened pull request #11028: Avoid masking of difficulty adjustment errors by checkpoints (06master...0620170810_maskpow) 02 https://github.com/bitcoin/bitcoin/pull/11028
2 2017-08-11 03:47:59 0|bitcoin-git|[13bitcoin] 15achow101 closed pull request #10875: BIP 91 deployment parameters (06master...06bip91-dep-params) 02 https://github.com/bitcoin/bitcoin/pull/10875
3 2017-08-11 04:17:41 0|bitcoin-git|[13bitcoin] 15FelixWeis opened pull request #11029: [RPC] trivial: gettxout no longer shows version of tx (06master...06patch-1) 02 https://github.com/bitcoin/bitcoin/pull/11029
4 2017-08-11 13:27:36 0|luke-jr|so what's with "0.15.SW"? Is the plan for the next release to branch off 0.15 rather than master?
5 2017-08-11 13:33:40 0|bitcoin-git|13bitcoin/06master 148627946 15Felix Weis: [RPC] trivial: gettxout no longer shows version of tx...
6 2017-08-11 13:33:40 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/e526ca6284b9...96a63a3e0cef
7 2017-08-11 13:33:41 0|bitcoin-git|13bitcoin/06master 1496a63a3 15MarcoFalke: Merge #11029: [RPC] trivial: gettxout no longer shows version of tx...
8 2017-08-11 13:34:25 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11029: [RPC] trivial: gettxout no longer shows version of tx (06master...06patch-1) 02 https://github.com/bitcoin/bitcoin/pull/11029
9 2017-08-11 14:12:07 0|jonasschnelli|I don't entirely understand that check:
10 2017-08-11 14:12:08 0|jonasschnelli|https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1655
11 2017-08-11 14:12:41 0|jonasschnelli|Why do we check 'pindex->nHeight <= chainActive.Tip()->nHeight - nPrunedBlocksLikelyToHave' during pruning when responsing to GETBLOCKS
12 2017-08-11 14:13:47 0|jonasschnelli|I mean we check for BLOCK_HAVE_DATA, I don't see why we need to check for 'tip - nPrunedBlocksLikelyToHave'
13 2017-08-11 14:14:42 0|luke-jr|maybe to prevent fingerprinting?
14 2017-08-11 14:25:46 0|jonasschnelli|Yes. Maybe.
15 2017-08-11 15:02:04 0|bitcoin-git|13bitcoin/06master 14faa76d1 15MarcoFalke: qa: Fix inv race in example_test
16 2017-08-11 15:02:04 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/96a63a3e0cef...e5d26e47c7a4
17 2017-08-11 15:02:05 0|bitcoin-git|13bitcoin/06master 14e5d26e4 15MarcoFalke: Merge #11025: qa: Fix inv race in example_test...
18 2017-08-11 15:02:39 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11025: qa: Fix inv race in example_test (06master...06Mf1708-qaInvExampleTest) 02 https://github.com/bitcoin/bitcoin/pull/11025
19 2017-08-11 15:15:02 0|sdaftuar|jonasschnelli: i think the comment explains it -- the idea is that we don't want to respond with block hashes that we may be likely to prune in the near future
20 2017-08-11 15:15:42 0|sdaftuar|jonasschnelli: because otherwise the peer might request those blocks from us and we'll stall their block download by ignoring the request
21 2017-08-11 15:33:59 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11031: [rpc] deprecate estimatefee (06master...06deprecate_estimatefee) 02 https://github.com/bitcoin/bitcoin/pull/11031
22 2017-08-11 15:48:10 0|jonasschnelli|sdaftuar: but the check to break the response is: 1 'pindex->nHeight <= chainActive.Tip()->nHeight - nPrunedBlocksLikelyToHave'
23 2017-08-11 15:48:51 0|jonasschnelli|Isn't that that blocks "older@ the 288+6 can then never be relaxed regardless of the prune target?
24 2017-08-11 15:49:14 0|jonasschnelli|s/@/"
25 2017-08-11 15:49:31 0|bitcoin-git|13bitcoin/06master 14c5ebddd 15René Nyffenegger: Tests: address placement should be deterministic by default
26 2017-08-11 15:49:31 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/e5d26e47c7a4...2c811e08db65
27 2017-08-11 15:49:31 0|jonasschnelli|*relayed (dry phone typing)
28 2017-08-11 15:49:32 0|bitcoin-git|13bitcoin/06master 142c811e0 15MarcoFalke: Merge #10765: Tests: address placement should be deterministic by default...
29 2017-08-11 15:49:55 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10765: Tests: address placement should be deterministic by default (06master...06test-addrman) 02 https://github.com/bitcoin/bitcoin/pull/10765
30 2017-08-11 15:50:16 0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11032: [qa] Fix block message processing error in sendheaders.py (06master...062017-08-sendheaders) 02 https://github.com/bitcoin/bitcoin/pull/11032
31 2017-08-11 15:51:16 0|gmaxwell|jonasschnelli: no-- if we offer a block we need to be willing to provide it or we will dos attack our peers.
32 2017-08-11 15:51:49 0|gmaxwell|doesn't matter if its 300 blocks deep or 30000 blocks deep.
33 2017-08-11 15:52:28 0|sdaftuar|also keep in mind that the line of code you're looking at is the getblocks handler, which is no longer really used to sync the chain by anyone (i hope!)
34 2017-08-11 15:54:21 0|jonasschnelli|Hmm... seems harder then I thought to add by-prune-height-fingerprinting protection for NODE_NETWORK_LIMITED
35 2017-08-11 15:55:21 0|sdaftuar|you're concerned about fingerprinting protection for nodes using manual pruning?
36 2017-08-11 15:56:06 0|sdaftuar|i would think that if you support NODE_NETWORK_LIMITED (and not NODE_NETWORK), you just always advertise exactly the last 1008 blocks or whatever that target value is
37 2017-08-11 15:56:30 0|jonasschnelli|I'm concerned introducing a fingerprinting possibility by 1NODE_NETWORK_LIMITED
38 2017-08-11 15:57:06 0|jonasschnelli|Yes. That is what I want. But older messages like getblock must also be covered via that protection
39 2017-08-11 15:58:24 0|sdaftuar|still don't see the fingerprinting issue -- can't all NODE_NETWORK_LIMITED nodes answer the getblocks issue the same way, with only up to the last 1008 block hashes?
40 2017-08-11 16:00:16 0|sdaftuar|nPrunedBlocksLikelyToHave can be calculated differently if you're pruning to a 1-week target versus a 2-day target
41 2017-08-11 16:00:28 0|sdaftuar|which correspond to LIMITED_HIGH and LIMITED_LOW
42 2017-08-11 16:01:02 0|jonasschnelli|Yes. The check we discussed above is kind of a fingerprinting protection.
43 2017-08-11 16:01:50 0|jonasschnelli|(Need to check it in detail when im back on my desk)
44 2017-08-11 16:02:02 0|sdaftuar|i guess! but that's just a coincidence i think, i believe that getblocks handler predates the manual pruning by a lot.
45 2017-08-11 16:02:14 0|sdaftuar|so the concern was taht we might return an inv for blocks that we currently have, but are about to prune
46 2017-08-11 16:02:41 0|sdaftuar|the idea is that pruning only (largely-) guarantees the last 288 blocks, so we're conservative and never advertise more than that
47 2017-08-11 16:03:47 0|sdaftuar|and that happens to also give fingerprinting protection for manual pruners, too. though really it's just a consequence of manual pruners not having any additional guarantees of what they might keep.
48 2017-08-11 16:04:04 0|sdaftuar|eg you could manually prune down to 288 right after you send someone a getblocks response, and then cause problems.
49 2017-08-11 16:07:01 0|sdaftuar|separately i could imagine we could schedule getblocks for deprecation
50 2017-08-11 16:07:12 0|gmaxwell|we should probably just change to only advertise things releated to the last 288 or 1008 (however configured) blocks, whatever is our minimum.
51 2017-08-11 16:07:17 0|jonasschnelli|I see. I guess then increasing that protection up to 8 days of blocks in HIGH mode makes sense
52 2017-08-11 16:07:38 0|gmaxwell|I don't see why.
53 2017-08-11 16:08:06 0|gmaxwell|What we signal should become the minimum we'll prune to, even with manual pruning.
54 2017-08-11 16:08:22 0|gmaxwell|And then we can getblock advertise out to that minimum.
55 2017-08-11 16:12:39 0|jonasschnelli|gmaxwell, sdaftuar: advertise, yes. I see. But I guess we need a protection here: https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L977
56 2017-08-11 16:13:07 0|jonasschnelli|Otherwise one can getdata blocks to fingerprint the prune depth?
57 2017-08-11 16:14:02 0|bitcoin-git|13bitcoin/06master 14cc5d38f 15John Newbery: Add option to attach a python debugger if test fails
58 2017-08-11 16:14:02 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/2c811e08db65...bf74d377fb8e
59 2017-08-11 16:14:03 0|bitcoin-git|13bitcoin/06master 14bf74d37 15MarcoFalke: Merge #11023: [tests] Add option to attach a python debugger if functional test fails...
60 2017-08-11 16:14:37 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11023: [tests] Add option to attach a python debugger if functional test fails (06master...06func_test_pdb) 02 https://github.com/bitcoin/bitcoin/pull/11023
61 2017-08-11 16:17:18 0|gmaxwell|Yes, but it should allow whitelisted peers.
62 2017-08-11 16:21:24 0|sdaftuar|agreed
63 2017-08-11 16:21:49 0|jonasschnelli|ok
64 2017-08-11 20:24:57 0|jnewbery|(not for v0.15) I was thinking of adding 'bestblock' to the output from 'getwalletinfo', so if we implement something where the wallet stops advancing because of keypool deplation, at least there's an indication that your wallet is falling behind
65 2017-08-11 20:26:16 0|jnewbery|But bestblock is only updated when the block index is written to disk (usually once an hour), so I think without description, that might be very confusing for users (bestblock showing as some blocks behind, but transactions from recent blocks shown in wallet)
66 2017-08-11 20:26:27 0|jnewbery|any thoughts/suggestions?
67 2017-08-11 20:28:13 0|luke-jr|can we show the more up-to-date bestblock, but only store the block index as currently done?
68 2017-08-11 20:30:40 0|jnewbery|the wallet doesn't currently store its best block in memory. It only writes bestblock to disk when the node sends it SetBestChain (shutdown and block index flush)
69 2017-08-11 20:31:12 0|jnewbery|I suppose the wallet could store the most recent block connected when it gets BlockConnected. Is that safe?
70 2017-08-11 20:36:33 0|sipa|jnewbery: i think that's what needs to happen anyway, allow the wallet at any time to run behind the node, and make it catch up in the background
71 2017-08-11 20:36:42 0|sipa|so ack on adding bestblock to walletinfo output
72 2017-08-11 20:47:20 0|ryanofsky|#10286 adds CWallet::m_last_block_processed, which is a better name than bestblock imo
73 2017-08-11 20:47:23 0|gribble|https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt ÷ Pull Request #10286 ÷ bitcoin/bitcoin ÷ GitHub
74 2017-08-11 20:47:50 0|jnewbery|sipa : does storing the hash of the most recent BlockConnected seem like the right thing to do?
75 2017-08-11 20:48:47 0|jnewbery|ryanofsky oh great. Thanks
76 2017-08-11 20:49:04 0|ryanofsky|10286 stores it as a cblockindex pointer, but #10973 turns that into a hash, so either way seems fine
77 2017-08-11 20:49:06 0|gribble|https://github.com/bitcoin/bitcoin/issues/10973 | WIP: Add IPC layer between node and wallet by ryanofsky ÷ Pull Request #10973 ÷ bitcoin/bitcoin ÷ GitHub