Topic: Add user interface to set dust limit and filtered addresses (Read 3677 times)

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.

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.

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.

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 "

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

Yes, it looks reasonable and way more elegant.



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

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

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.

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

+1 this^

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

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.

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.

This! 100% agree.

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.

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.

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.

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?

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

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

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.

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.