Topic: Someone is spamming the blockchain (Read 7813 times)

The SB (shǎbī, http://en.wikipedia.org/wiki/Mandarin_Chinese_profanity#Vagina) has lost all his money in Satoshi Dics 

So is the issue here that someone is making the block chain unnaturally larger or that they are not paying something to make the block chain unnaturally larger?

limitfreerelay=0 wouldn't result in a fork because these nodes would still recognize blocks containing 0-fee txs as valid. One person doing this doesn't make much difference, but enough people doing so would pretty much ban 0-fee txs because miners would never receive them in the first place.

To prevent your private key from being discovered it uses a different number to sign the transaction, there's a whole technical explanation, but basically the private key is multiplied by a different number for each sign.

That's exactly it. If he doesn't like what the miners are doing with the blockchain, he can fork it to whatever he wants.

The 0.00005430 restriction is more aggressive than mine

I think he/she/they just want to be the highest "Total Bitcoins received".

Although a code change would be simple any changing of the fee rules is likely to result in all sorts of "end of the world" topics being created so I somehow doubt this is going to occur any time soon.

After considering this for a while (and noticing the SD *bet* that this *spammer* included) it could actually be an attack *at* SD (as it will presumably always have higher priority than some random SD bet so it is maybe some sort of attempt to *slow down* SD although on its own of course will be rather ineffective).

In any case if all it is doing is taking the place of some SD tx that would otherwise get in the block then it really isn't actually making any difference to your disk usage at all (you would be storing the bytes either for SD or for this SB and in fact as SB txs are tiny then you may actually be benefiting slightly from SB).

It is prunable but the reference client is not pruning and all these craps fill my harddrive.

It will also take more time for initial download.

I hope the core dev will tighten the default fee rules to stop such attack. Just modify the default priority formula from :


to


will slow down such stupid attack a lot, without affecting legitimate use (legitimate users can pay 0.0001 fee if they want fast confirmation)

I guess that these tx's make it in because there is room for them and they are probably actually higher priority then many SD tx's are.

Still a strangely behaving (hmm... sb - hehe) bot.

Ah, I thought you were talking about the party creating 0.001 value txouts to (presumably) deanonymize people. I don't see what your concern is with the 300 BTC party. Their transactions are handled in priority order, and higher priority free transactions still have first dibs on the limited free space.  That they're moving a large amount just means that they meet the minimum threshold after one block— but it doesn't give them a particularly high priority.

The resulting load is all prunable and doesn't hurt the privacy of third parties, so I don't see a reason to be especially concerned by it.

Sorry but I don't get this bit - the party we are talking about has not paid *any* fee to move his 300 BTC around hundreds (or is it thousands) of times.

EDIT: The amount is now only 220 BTC - strangely enough this bot seems to every now and again like to play SD.

This party is willing to pay almost 10 cents US per txout (just in the output value!). I think that strongly suggests that there is _no_ simple way to solve this by dorking with fees/priority/etc: They're willing to pay their way out of any reasonable measure we could employ, as a anti-spam that 'cost' that much per transaction would be not acceptable.

I can think of two things which would address this, and a third that might help a small portion of users:

(1) Strongly de-prioritize transactions which reuse already used addresses. This would improve privacy and fungibility for the system and discourage these sorts of deanonymization attacks.

(2) Deploy P2SH^2: this would inhibit sending to someone merely based on what you saw in the blockchain— you'd need more information than in the chain to send to them.

(3) Better coin control utilities,  including something to opt to let you donate dust away automatically.

I'm not sure if that would address this specific problem (the responsible party would appear to be using a bot that issues raw txs so changing bitcoin-qt wouldn't have any effect at least in a direct fashion).

This problem (if it really is one) would appear to be more about accepting UTXOs (well in this case just the one) that have not been aged (at all) just because the amount in the tx is large enough.

My "fix" is to remove the client-side "mandatory" fee altogether, and instead make suggestions for fees on every transaction.  These fee suggestions would be based on an automated statistical analysis, which calculates how long it takes similar transactions to be confirmed at various fee levels.

"You've got a 1-day old 0.1 BTC with a tx size of 200 bytes that you want to send?  Ok, but it'll probably take 6 hours to be confirmed, based on historical data.  If you pay a 0.0005 BTC fee, it is likely to be confirmed within 1 hour, and if you pay a 0.005 fee, it is likely to be included in the next block."

This puts the power of fee-setting back in the hands of the miners, where it belongs, instead of the miners being mostly forced to go along with whatever the default client-side fees are, else risking losing out on most of the fee income.

The biggest problem with this idea is performing that statistical analysis.  If you don't have your computer on 24/7 with your Bitcoin client running, then you don't see all of the transactions, and you don't know how long it takes until they confirm.  Perhaps it would be possible for a Bitcoin client to check a "first seen" timestamp for each new transaction with multiple peers to ensure accuracy.  If three peers say 2013/07/11 19:44 GMT (+/- a minute or three), one peer says 2013/07/11 13:34 GMT, and four peers haven't heard of it, then it's a safe bet that the true time is 2013/07/11 19:44 GMT.

I think what people are not liking is that it is *just because* it is 300 BTC (although maybe the same thing could be done with less) that he can put this tx into every single block without paying a fee whatsoever.

The critical resource is space in the blockchain.  Fees need to reflect that.  Bitcoin achieves this by having a fee per kb*.  Having a 300 BTC tx which takes 200 bytes cost more (potentially a magnitude more) than a spammy 1 BTC tx which requires 10,000 bytes of space makes no sense.


* Commonly people will say the fee is 0.1 mBTC per KB but this is only the default min mandatory fee for low priority transactions.  Users can pay more or less (even none) but what matters is still the fee per KB.

See this except it's outdated and the fee/kb is 0.0001: http://bitcoinfees.com/

Bitcoin-Qt doesn't just download blocks from miners; it also relays transactions to and from other non-mining nodes. This is why you can see unconfirmed transactions before they've been included in a block. By setting limitfreerelay=0 you will still participate in the main chain, but not pass along any 0-fee transactions which have yet to be mined.
https://en.bitcoin.it/wiki/Transaction_fees#Relaying

Why should anyone be interested? He's just a guy who's using the blockchain. He's about as interesting as you are.



You can reject blocks containing zero fee transactions and you'll have a fork. Good luck finding miners who will mine your fork. Oh right, they're busy using the blockchain everyone is using, making this whole thread and its whining pointless.