Add user interface to set dust limit and filtered addresses

[paraipan]

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.

Needed feature, Bitcoin developers please review.

https://github.com/bitcoin/bitcoin/pull/2383

[1714152695]

1714152695

[1714152695]

1714152695

[grue]

DO WANT

[Herbert]

Dust limit filter: Okay.
Bitcoin address filtering: Never!

[Sukrim]

Do need! This does only mean that transactions fulfilling certain criteria (e.g. dust or containing a certain address) are not getting PROCESSED or RELAYED, not that they cannot be included into blocks.

This solves client side issues, like too high IO from transaction verification. It does not mean that there is any way for non miners to choose what gets into blocks. That would only work if miners only connect to nodes that filter a certain transaction. Even then the person wanting to include the transaction could just send it directly to the miner.

[🏰 TradeFortress 🏰]

Bitcoin address filtering: Never!

0.001 BTC to address A is the same as 0.001 BTC to address B.

This is also trivial to bypass (S.DICE can just gen a new address on page load specific to each visitor but permanently valid)

[Sukrim]

Good luck with their multi gigabyte wallet or huge CPU load to get deterministic keys then. Also it wouldn't be auditable any more, meaning less trust.

This is not specific to SD though, if I choose to run a relatively passive node that checks only few (my) transactions and keeps and distributes the block chain as well as offering bloom filters, it's also already something.

I'd like to have some more warning messages and also a switch to enable expert mode or similar. This should not be too easily changed or set!

[BitcoinAshley]

A dust limit would be nice.

I'd have no use for an address filter, though.

What is the point of blocking SDice addresses if you have a dust limit anyways?

And how do you know the generic 'list of 1000 SDice addresses' that you download from pastebin is even accurate?

I can see no legit. use for an address filter.

[Sukrim]

Well, not for a blacklist. A whitelist  however would for example enable you to run bitcoind on a quite CPU constrained server and use it as a gateway for your SPV client.

Transactions not from one of your addresses would just be ignored and you'd act like a quite passive node in the network. Alternatively you could just relay transactions without any verification - but that opens the door for some attacks, like letting your node pass through some double spends, get choked/banned by other nodes and then maybe even taking over connections that way. Acting as a silent end might be the smarter thing to do.

Even a blacklist can help you right now to reduce background load by quite a bit just by blocking a few busy addresses (SD amongst them at the moment).

[Herbert]

Btw, i thought that the upcoming "bloom filter" technology is somehow related by only handling transactions relevant for "your" wallet. But maybe I totally missed the point here... Is there any pointer available explaining what this bloom filter stuff is doing?

[paraipan]

...

I can see no legit. use for an address filter.

You can't? Just imagine there is a big robbery and all the bitcoins are just sitting in the thief's address, where everyone can see. Wouldn't it be nice to have the bitcoins sit there forever? The thief would not be able to spend his bitcoins because everyone would just reject his transaction, based on previous knowledge about the robbery. If the thief would ever return the bitcoins to it's rightful owner people would already be able to accept only that transaction above all, using their client filters.

I'm puzzled by the control developers exert over all the bitcoin network, and when someone asks them to implement useful features for every individual, they get picky and say is not in their best interest to have more control, Gavin included.

Are you people that dumb? Don't you want authority over your money? The features presented here leave you in control and if you, the majority, decide to raise the bar then SatoshiDice or other entities will have adapt or die. Right now the foundation pays Gavin's salary, so it biases him to develop in foundation businesses interests, including SatoshiDice.

Will stick around Bitcoin 1.0 for a while, but if this goes the way I see it goes then I think 2.0 is just around the corner.

[Sukrim]

Bloom filters help you if you don't have the complete block chain to only return to you some relevant transactions. They take CPU power to calculate and if a node is already busy with verifying for the umpteenth time if a 1 5000 Satoshi output from SD is valid, this can cause delays. Currently for my PC not really, as far as I've seen there is not enough space for transactions in blocks to make my CPU even clock up. In the future this might become a problem though and already now with weaker machines (mine is far from the norm) one can already save quite a bit of power for some actually useful work that you need a full node for.

If a huge portion of load can be avoided just by removing some things that are on one hand redundant, on the other hand have no impact on blocks mined if non-miners apply them is something that's useful and should at least be considered imho.


I don't agree that not relaying transactions is in ANY way useful to make sure these coins will be "blocked" - a single path towards a miner who is allowing the transaction to eb included in one of his/her blocks and the coins can and will be moved. To block stolen coins, one needs to convince miners to not mine transactions with these coins AND to not accept any blocks that contain transactions with these coins, even if that means artificially orphaning a block. Something that might not be impossible, but requires much more than a few nodes not forwarding transactions.

[Herbert]

...

I can see no legit. use for an address filter.

You can't? Just imagine there is a big robbery and all the bitcoins are just sitting in the thief's address, where everyone can see. Wouldn't it be nice to have the bitcoins sit there forever? The thief would not be able to spend his bitcoins because everyone would just reject his transaction, based on previous knowledge about the robbery. If the thief would ever return the bitcoins to it's rightful owner people would already be able to accept only that transaction above all, using their client filters.

No serious robber would be so dumb to move the robbed coins to one address and leave them there for more than 5 seconds. First thing you do is throw them at multiple addresses and mixers as fast as possible to cover up your trail. This reminds me of the "security by obscurity" failure...

[paraipan]

How can I add this patch to my Bitcoin-Qt?

Not easy, some compiling involved 

Basically you clone Git repository "https://github.com/jonls/bitcoin/commits/user-tx-filters", install all dependencies and then compile your own bitcoin-qt. It takes 10 minutes on Linux-Ubuntu, on Windows you should be able to do it with Qt-creator after you install required libraries.

Here is more info:

http://www.rugatu.com/questions/9625/how-to-easily-apply-a-source-patch-to-bitcoin-qt

http://bitcoin.stackexchange.com/questions/587/how-do-i-build-bitcoin-source-in-windows-7

[grue]

A dust limit would be nice.

I'd have no use for an address filter, though.

What is the point of blocking SDice addresses if you have a dust limit anyways?

And how do you know the generic 'list of 1000 SDice addresses' that you download from pastebin is even accurate?

I can see no legit. use for an address filter.

if you don't like it, don't use it. transaction filtering can already be implemented by patching the code, why make it harder for people to do it?

[TraderTimm]

Appreciate having the option since reason seems not to be working with the SD people.

The one thing that really galls me is the "but we're testing the network" - yeah guys, but you should be testing on the TEST blockchain. But then, there would be no profit - so we can see exactly what their agenda is, just like the rest of the "outside world" -- all profit and no ethics.

Oh, and the shut-down during the hard-fork? They didn't want to get any doublespends. That tends to hurt the profit margin.

[ShireSilver]

...

I can see no legit. use for an address filter.

You can't? Just imagine there is a big robbery and all the bitcoins are just sitting in the thief's address, where everyone can see. Wouldn't it be nice to have the bitcoins sit there forever? The thief would not be able to spend his bitcoins because everyone would just reject his transaction, based on previous knowledge about the robbery. If the thief would ever return the bitcoins to it's rightful owner people would already be able to accept only that transaction above all, using their client filters.

No serious robber would be so dumb to move the robbed coins to one address and leave them there for more than 5 seconds. First thing you do is throw them at multiple addresses and mixers as fast as possible to cover up your trail. This reminds me of the "security by obscurity" failure...

Not to mention the possibility of it being abused politically. Imagine if somehow an innocent person gets tagged as a scammer, and everyone jumps on them and blocks their transactions. It could happen to someone who doesn't believe they've done anything wrong so they wouldn't have any reason to hide their coins.

IMHO, this whole madness about dust and SD is more than just an attack on a successful business, but an attack on the validity of bitcoin itself. There's a lot of opportunities being lost here if we do restrict the usage based on some people's opinion of what constitutes value.

[grue]

IMHO, this whole madness about dust and SD is more than just an attack on a successful business, but an attack on the validity of bitcoin itself. There's a lot of opportunities being lost here if we do restrict the usage based on some people's opinion of what constitutes value.

the attack on satoshi dice is NOT because it's successful. the real reason is because SD wastes public resources (blockchain space) for a purpose it's not intended to handle. Bitcoin was never meant for micropayments, nor was intended to record bets.

[Herbert]

...

I can see no legit. use for an address filter.

You can't? Just imagine there is a big robbery and all the bitcoins are just sitting in the thief's address, where everyone can see. Wouldn't it be nice to have the bitcoins sit there forever? The thief would not be able to spend his bitcoins because everyone would just reject his transaction, based on previous knowledge about the robbery. If the thief would ever return the bitcoins to it's rightful owner people would already be able to accept only that transaction above all, using their client filters.

No serious robber would be so dumb to move the robbed coins to one address and leave them there for more than 5 seconds. First thing you do is throw them at multiple addresses and mixers as fast as possible to cover up your trail. This reminds me of the "security by obscurity" failure...

Not to mention the possibility of it being abused politically. Imagine if somehow an innocent person gets tagged as a scammer, and everyone jumps on them and blocks their transactions. It could happen to someone who doesn't believe they've done anything wrong so they wouldn't have any reason to hide their coins.

This! 100% agree.

[Sukrim]

Not relaying or processing some transactions is not the same as making sure these don't get included in blocks...

As already said, this patch has uses beyond playing sheriff and also it would be nice to not again just reiterate all the stuff that was already said in the general forum. There is the fact that this patch is possible and has been written.

Also there is little to no chance that it is even remotely possible to block coins from a robbery  without major commonly accepted centralized structures. That's not very likely imho.

[TraderTimm]

If I was satoshiDICE, I would institute a miner lottery. A daily random transaction fee of some sizable amount of coins in order to provide additional incentive to process my transactions. I'm sure the miners will be more than happy to grow the block chain in order to vie for that lottery.

I'm so glad I found Bitcoin, to give me the freedom to use my money as I see fit. It saddens me to see people who think they know what Bitcoin is "meant to be". Just another group of control freaks I need to watch out for.

If I were SD, I'd act as a force for the common good instead of paying lipservice to the "community" while exploiting the same.

They could craft an out-of-band solution for what they're doing, but they won't. They know, but they just can't seem to get around to it.

All that supposedly beneficial "stress testing"? We have a non-production blockchain they can stress all they want. But they wont - because that doesn't bring in what they really care about -- profit.