Add user interface to set dust limit and filtered addresses #2383
Conversation
Accept only transactions for which all output values are above a minimum amount (dust limit). The mimimum defaults to zero (everything above zero is accepted). Added QT interface options pane called "Advanced" to set this value.
Transactions destined for these addresses will not be accepted by this node. Added a field in the "Advanced" options pane to set the list of filtered addresses.
|
Needed feature, Bitcoin developers please review. |
|
DO WANT even if we need to make it a .conf option, this will be much better than manually patching the client with each build. |
|
I love you! No homo. |
|
NAK Don't encourage censorship based on where Bitcoins are going rather than the technical details about how they are being transferred. My https://github.com/petertodd/bitcoin/tree/block-uneconomic-utxo-creation patch is an example of a way to approach the issue based on politically neutral technical metrics rather than singling out any particular entity. A "dust limit" is fine. Building ways to block specific addresses into the client itself isn't. Additionally any "dust limit" should be written in a way that the behavior is predictable; end users are harmed when they don't have any idea what the dust limit might be set to. |
|
Address filtering is a DEFINITE no. Do not forget that addresses are disposable. |
|
Looks good visually and functionality-wise. I'll have a look at the code when I get home. |
|
Definitely needed as part of the client! |
|
@petertodd @gladoscc I don't see what's wrong with giving people a choice to ignore transactions. Anyone can implement their own address filtering by editing the source code, so what do we gain by adding a technical barrier? |
|
Including such a mechanism in the official Bitcoin reference client implies we support censorship; an obvious extension of this patch is supporting automated blacklists. |
|
@Gruez "Anyone sufficiently motivated could build a chemical weapon, what do we gain by not equipping every adult with one?" Having to modify the software gives people enough friction to think over their change. Not just "I should do this because some website said to click here for awesomeness". ... though my level of horror at this pull request is somewhat tempered by the fact that it's easily avoided by someone using Bitcoin properly (not reusing addresses). Still, NAK. It's also worth noting that inconsistent forwarding rules created by the dust setting makes it much harder to write reliable wallet software... since the software doesn't actually know when its peers are going to forward the transaction or not (and your peers don't tell you when they don't). Ultimately wallets will need to deal with that, but they don't currently. I'd prefer to see a pull request that depriortizes all address reuse, as that will allow reusers with standing relationships to opt into lower priority handling and it encourages blacklisting resistant behavior in our ecosystem. |
|
GUI looks good. But NAK on the filtering. This is a censorship measure, and an ineffective one at that. |
|
I beg to differ @laanwj, I don't understand your point in not letting me control my own resources. Did someone put you there to decide over what bitcoiners have to have in their client software? |
|
Let's see what the community has to say about this https://bitcointalk.org/index.php?topic=160785 |
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/427dcfb215a5892c8108bc76b40fe9bab9eacb24 for binaries and test log. |
|
We won't be adding any blacklisting functionality at this time. There are some other active pull requests on dust relay limiting which should generally address the rest of the concerns here. Thanks to all involved to actually putting code on paper and making a concrete proposal. |
|
This patch is a potential solution to MAX_BLOCK_SIZE limit give it permits Bitcoin users to ignore spam transactions under set limits. |
This patch adds a new "Advanced" pane to the options box where the dust limit for accepted transactions can be set, and where a filter on output addresses can be specified. CTxMemPool::accept() will drop any transaction with outputs below the dust limit, or with an output address corresponding to an address specified in the filter.