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

[1715691126]

1715691126

[1715691126]

1715691126

[1715691126]

1715691126

[1715691126]

1715691126

[1715691126]

1715691126

[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.

[grue]

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.

This also applies to MY computing resources: I can use MY processor as I see fit.

[paraipan]

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.

This also applies to MY computing resources: I can use MY processor as I see fit.

+1 this^

[grue]

is it possible for someone to make a windows build? (like with the "no forced fee" or "coin control" releases)

[gmaxwell]

Would people who support this also support an alternative which strongly de-prioritized repeated address use? e.g. only relaying one to a few transactions per address in the mempool.

Blacklisting has some enormous systemic risks for the community— but if people behave in ways which make blacklisting effective then it is inevitable, if not because of this this user than eventually some other user.  Since privacy and fungibility are in all of our interests the system should operate in a way that gives people incentives to not behave in ways that damage those (e.g. use fresh addresses).  Plus it creates more fair load-balancing of the available resources: if someone voluntarily discloses that two transactions are theirs, why shouldn't we prevent them from using more than their share of the available capacity?

I ran a patch like this on my own nodes for some time— long before SD existed, though it has since bitrotted due to other changes.  I haven't promoted it because I believed that people who didn't understand it would think I was trying to single out a particular user... which is not the case, the purpose of such a change would be to protect everyone from the damage to the system being caused by singling out people by making singling out less effective against common behavior.

[deepceleron]

To me, the motivation for this patch is not to affect what gets relayed or included in the blockchain, but instead to be able to easily ignore dust that may be sent to your own wallet addresses or to be able to ignore abandoned addresses filled with dust, dust that is too expensive to spend because it would cost more in transaction fees per KB to send it than the value of the payment.

We all know where this comes from - the "loser dust" of SatoshiDice, where they fill up user's wallets with payments of 0.0000001 - 0.00005000, simply as messages to say "you lost".

These payments-as-messages are bad for Bitcoin. This patch is also bad for Bitcoin. Future clients can and will allow the recovering of disk space and the removal of spent transactions. However, if you play SatoshiDice and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".

[paraipan]

Would people who support this also support an alternative which strongly de-prioritized repeated address use? e.g. only relaying one to a few transactions per address in the mempool.

...

Yes, it looks reasonable and way more elegant.

However, if you play SatoshiDice and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".

I think most people here want Bitcoin to be a huge success. An enormous success even. If it does happen, at some point, these "dust" transactions will no longer be dust.

...

Hope we pass the growing pains and "satoshis" get passed around like full bitcoins today.

[gmaxwell]

these "dust" transactions will no longer be dust.

Are you really anticipating an increase in valuation of 2000x (thats whats required to make a 1e-8 output worth what $0.01 is today) before people have long since lost the relevant keys?

I've considered asking many times, but haven't bothered, does anyone have a figure on the theoretical maximum size of a pruned block chain?

Infinite, unless we add a rule to reject 0 value outputs. If we do the theoretical maximum size is about 44 petabytes.

and also wantonly ignore and never spend the dust, you are saying "I don't give a fuck about the health of Bitcoin, nodes can store my discarded garbage forever".

The ignoring in this patch, fwiw, doesn't appear to change wallet behavior. Once those txn are mined they'll show up in the wallet. Litecoin carries a patch that ignores things in the wallet.

[Peter Todd]

I didn't know 0 value outputs exist. What purpose do they serve?

There are only two legit use for them that I know of. The first is if you want to make a transaction that pays 100% of the funds going in to the transaction to fees. Although such a transaction output should use the OP_RETURN provably unspendable scriptPubKey, because spending the zero-value output makes no sense. The second is if you need to attach some data to a transaction, and don't want to pollute the UTXO set with that data; for that you use the scriptPubKey "OP_RETURN <data>"

[gmaxwell]

That's 2200TB. Which is 37 of the best 2016 HDDs.
[...]
Would it be outlandish to say that in 2016, using improved technology which exists today, a node will require less than $10000 [...] Is dust as really as big of a problem as people make it out to be?

Uh. Your 2200TB of storage would, using the most cost effective hardware currently available, cost $130,992 today.  No doubt this will improve substantially in a few years 2016... but "less than $10,000" sounds a bit ambitious (even relative to past storage scaling)... and you've not justified your random division by 20.

But hey, just take that and run with it—   At $10,000-and-growing in hardware costs just to store the data needed to check the validity of blocks efficiently, costs that have no direct income generation, would Bitcoin be a decenteralized system?  I don't believe that it would be.  It would be a distributed system, yes, but one with some dozen of major players and large mining pools in complete control of the system, subject to easy influence by regulators and organized crime, and with everyone else is stuck with them.

That might be the eventual outcome of Bitcoin— just as it seems the eventual outcome of originally-asset-backed government promissory notes was to become today's current unbacked currencies. But even if it is inevitable I'd like to see that outcome forestalled: A Bitcoin who's only selling part is a different set of cronies-in-charge is not especially attractive to the systems of central banks, and not especially attractive compared to payment systems with lower hardware cost and faster confirmations.

Do we need the 0 value outputs? Will pruning exist in the next few years? Will the size of the block chain realistically grow fast enough to reach some of the numbers I've had fun with in this post?

We have pruning now now just no way for nodes to find sources for blocks in order to sync up if real full nodes become sparse, so there is as of yet no knob to delete the old history. It's not used at all now except for reorgs, syncing up new peers, and rescanning restored wallet backups. Validation is against the pruned data.

How long will 13 year old computers be able to run a full node?

You're not talking about excluding just old systems, you're talking about excluding everything that isn't a commercial-scale price-of-a-cheap-car capital investment in dedicated-to-bitcoin hardware-that-doesn't-even-exist-yet. Requiring reasonably modern, even reasonably high end conventional hardware, is probably not great for decentralization but probably doesn't preclude it, but I think that going beyond that does. Fortunately the same scaling laws your arguing will turn $130k  into $10k will also grant the same capabilities inexpensive systems in suitable time. Maybe.  And when it does we should make use of it. What we shouldn't do is set ourselves up so our only choice is to toss the decentralization that made the system worth having because we let it bloat faster than the technology could keep up with.