Skip to content

[Bip 133] Fix typos #348

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
luke-jr merged 2 commits into from
Mar 7, 2016
Merged

[Bip 133] Fix typos #348

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b3a93c4
Update bip-0133.mediawiki
Mar 6, 2016
fa02af6
bip 133: remove implementation detail
Mar 7, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions bip-0133.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,17 +28,17 @@ After receiving a feefilter message, a node can know before sending an inv that
# Feature discovery is enabled by checking protocol version >= 70013

==Considerations==
The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to your mempool are not relayed and the funcionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited.
The propagation efficiency of transactions across the network should not be adversely affected by this change. In general, transactions which are not accepted to a node's mempool are not relayed by this node and the functionality implemented with this message is meant only to filter those transactions. There could be a small number of edge cases where a node's mempool min fee is actually less than the filter value a peer is aware of and transactions with fee rates between these values will now be newly inhibited.

Feefilter messages are not sent to whitelisted peers if the "-whitelistforcerelay" option is set. In that case, transactions are intended to be relayed even if they are not accepted to the mempool.

There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementaion quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.
There are privacy concerns with deanonymizing a node by the fact that it is broadcasting identifying information about its mempool min fee. To help ameliorate this concern, the implementation quantizes the filter value broadcast with a small amount of randomness, in addition, the messages are broadcast to different peers at individually randomly distributed times.

If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider setting "-nofeefilter" to make sure it is exposed to all possible txid's.
If a node is using prioritisetransaction to accept transactions whose actual fee rates might fall below the node's mempool min fee, it may want to consider disabling the fee filter to make sure it is exposed to all possible txid's.
Copy link
Copy Markdown
Contributor

@morcos morcos Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh, i like "-nofeefilter" better! in fact i tried to make the option called "-nofeefilter" but it was broken because of the negation logic.

Copy link
Copy Markdown
Member

@luke-jr luke-jr Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"-no*" is for backward compatibility, not intended behaviour.

But in any case, I disagree with implementation-specific details being in a BIP like this.

Copy link
Copy Markdown
Member Author

@maflcko maflcko Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is another Bitcoin Core specific detail in the section below disabled by unsetting the "-feefilter" option.

I am happy to change that as well, if @morcos agrees.

Copy link
Copy Markdown
Contributor

@morcos morcos Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense to me. Do you agree with just changing it to generic discussion of disabling it or not using it? I think the fact that it is optional and you should be able to do that is relevant.

Copy link
Copy Markdown
Member Author

@maflcko maflcko Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is useful to mention that a node does not have to send a feefilter msg.

Copy link
Copy Markdown
Member Author

@maflcko maflcko Mar 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you check my most recent commit?


==Backward compatibility==

Older clients remain fully compatible and interoperable after this change. The sending of feefilter messages can be disabled by unsetting the "-feefilter" option.
Older clients remain fully compatible and interoperable after this change. Also, clients implementing this BIP can choose to not send any feefilter messages.

==Implementation==

Expand Down