< bitcoin-git>
[bitcoin] FelixWeis opened pull request #11029: [RPC] trivial: gettxout no longer shows version of tx (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11029
< luke-jr>
so what's with "0.15.SW"? Is the plan for the next release to branch off 0.15 rather than master?
< jonasschnelli>
Why do we check 'pindex->nHeight <= chainActive.Tip()->nHeight - nPrunedBlocksLikelyToHave' during pruning when responsing to GETBLOCKS
< jonasschnelli>
I mean we check for BLOCK_HAVE_DATA, I don't see why we need to check for 'tip - nPrunedBlocksLikelyToHave'
< 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
< sdaftuar>
jonasschnelli: because otherwise the peer might request those blocks from us and we'll stall their block download by ignoring the request
< bitcoin-git>
bitcoin/master c5ebddd René Nyffenegger: Tests: address placement should be deterministic by default
< jonasschnelli>
*relayed (dry phone typing)
< bitcoin-git>
bitcoin/master 2c811e0 MarcoFalke: Merge #10765: Tests: address placement should be deterministic by default...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #10765: Tests: address placement should be deterministic by default (master...test-addrman) https://github.com/bitcoin/bitcoin/pull/10765
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #11032: [qa] Fix block message processing error in sendheaders.py (master...2017-08-sendheaders) https://github.com/bitcoin/bitcoin/pull/11032
< gmaxwell>
jonasschnelli: no-- if we offer a block we need to be willing to provide it or we will dos attack our peers.
< gmaxwell>
doesn't matter if its 300 blocks deep or 30000 blocks deep.
< 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!)
< jonasschnelli>
Hmm... seems harder then I thought to add by-prune-height-fingerprinting protection for NODE_NETWORK_LIMITED
< sdaftuar>
you're concerned about fingerprinting protection for nodes using manual pruning?
< 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
< jonasschnelli>
I'm concerned introducing a fingerprinting possibility by NODE_NETWORK_LIMITED
< jonasschnelli>
Yes. That is what I want. But older messages like getblock must also be covered via that protection
< 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?
< sdaftuar>
nPrunedBlocksLikelyToHave can be calculated differently if you're pruning to a 1-week target versus a 2-day target
< sdaftuar>
which correspond to LIMITED_HIGH and LIMITED_LOW
< jonasschnelli>
Yes. The check we discussed above is kind of a fingerprinting protection.
< jonasschnelli>
(Need to check it in detail when im back on my desk)
< sdaftuar>
i guess! but that's just a coincidence i think, i believe that getblocks handler predates the manual pruning by a lot.
< sdaftuar>
so the concern was taht we might return an inv for blocks that we currently have, but are about to prune
< sdaftuar>
the idea is that pruning only (largely-) guarantees the last 288 blocks, so we're conservative and never advertise more than that
< 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.
< sdaftuar>
eg you could manually prune down to 288 right after you send someone a getblocks response, and then cause problems.
< sdaftuar>
separately i could imagine we could schedule getblocks for deprecation
< gmaxwell>
we should probably just change to only advertise things releated to the last 288 or 1008 (however configured) blocks, whatever is our minimum.
< jonasschnelli>
I see. I guess then increasing that protection up to 8 days of blocks in HIGH mode makes sense
< gmaxwell>
I don't see why.
< gmaxwell>
What we signal should become the minimum we'll prune to, even with manual pruning.
< gmaxwell>
And then we can getblock advertise out to that minimum.
< bitcoin-git>
bitcoin/master cc5d38f John Newbery: Add option to attach a python debugger if test fails
< bitcoin-git>
bitcoin/master bf74d37 MarcoFalke: Merge #11023: [tests] Add option to attach a python debugger if functional test fails...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11023: [tests] Add option to attach a python debugger if functional test fails (master...func_test_pdb) https://github.com/bitcoin/bitcoin/pull/11023
< gmaxwell>
Yes, but it should allow whitelisted peers.
< sdaftuar>
agreed
< jonasschnelli>
ok
< 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
< 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)
< jnewbery>
any thoughts/suggestions?
< luke-jr>
can we show the more up-to-date bestblock, but only store the block index as currently done?
< 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)
< jnewbery>
I suppose the wallet could store the most recent block connected when it gets BlockConnected. Is that safe?
< 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
< sipa>
so ack on adding bestblock to walletinfo output
< ryanofsky>
#10286 adds CWallet::m_last_block_processed, which is a better name than bestblock imo