add feefilter documentation

[jnewbery]

This PR adds documentation for the feefilter message type, added in Bitcoin Core V0.13.0.

[Mirobit]

Added in protocol version 70013 as described by BIP133.

is a duplicate. Already mentioned on the top.

[jnewbery]

Thanks @Mirobit . You're right. I've removed the dupe.

[Mirobit]

utACK

[harding]

Thanks, @jnewbery !

I just sent @jnewbery some suggested edits in jnewbery#1 . I also previewed the site after those edits and it LGTM. If those edits are merged, I give a tested ACK.

Here's a screenshot of that preview (edit: I just realized that the table looks broken---that's because I reduced the font size to make everything fit on one screen; it looks correct in the original):

[jnewbery]

Looks good to me. Thanks @harding!

[wbnns]

@jnewbery Hello, thanks a bunch for submitting this (@harding thanks for helping!). Could you please rebase and resolve the conflicts? Once you've done this I'll schedule the PR be merged.

[wbnns]

@jnewbery Heya! Just wanted to follow-up again to see if you wouldn't mind rebasing this so we could go ahead and get it on the site.

[jnewbery]

Apologies for the delay on this. Rebased.

[rosser2121]

What does rebased mean? Ross Respond back to connect.

…

On Mar 8, 2017, at 3:07 PM, John Newbery ***@***.***> wrote: Apologies for the delay on this. Rebased. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[wbnns]

@jnewbery Thanks! @rosser2121 Here's more information on what a rebase is.

Unless others object, this will be merged on Sunday, March 12th.

[schildbach]

I think at this point it should be noted that in the case of blocks, feefilter is not additive with bloom filters.

[schildbach]

More specifically, I'd perhaps add "Both block and filtereredblock messages are unaffected by fee filtering."

[jnewbery]

I think you mean "Both block and filteredblockMerkleBlock messages..." (filteredblock is an inv type rather than a message).

If we add this, I think it should be more general, ie "feefilter has no impact on block propagation or responses to getdata messages", since it also won't affect Headers or CompactBlock messages. Thoughts?

[schildbach]

Ah yes, that's what I meant. Your suggestion seems fine to me too.

[jnewbery]

@schildbach I've add a bit more explanation about feefilter interaction with block propagation and responses to getdata requests:

The fee filter is additive with bloom filters. If an SPV client loads a bloom
filter and sends a feefilter message, transactions should only be relayed if
they pass both filters.

Note however that feefilter has no effect on block propagation or responses to
getdata messages. For example, if a node requests a merkleblock from its peer
by sending a getdata message with inv type MSG_FILTERED_BLOCK and it has
previously sent a feefilter to that peer, the peer should respond with a
merkleblock containing all the transactions matching the bloom filter, even
if they are below the feefilter fee rate.

Let me know if you have any comments about that.

@harding @wbnns let me know if you're happy with this addition and I'll squash into a single commit.

[schildbach]

Sounds fine to me.

[wbnns]

@jnewbery Looks good, thanks!

[laanwj]

Thanks for adding this!

[jnewbery]

commits squashed. This is ready for merging.

[wbnns]

@jnewbery Thank you sir - will merge this as soon as tests pass. 👍