Someone is spamming the blockchain

[nottm28]

How come no-one is interested in the guy who is doing this?

https://plus.google.com/communities/111634010372327591643/stream/350db628-910e-45ca-83e3-c01a7f31bdb8

Looks like his name is Kevin Yuan (on google+)

[1714786427]

1714786427

[1714786427]

1714786427

[1714786427]

1714786427

[1714786427]

1714786427

[WiW]

How come no-one is interested in the guy who is doing this?

https://plus.google.com/communities/111634010372327591643/stream/350db628-910e-45ca-83e3-c01a7f31bdb8

Looks like his name is Kevin Yuan (on google+)

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

Bitcoin-Qt shut down, limitfreerelay=0 added to .conf file, Bitcoin-Qt started. Debug.log file now shows quite a lot of messages like one bellow.

Code:

2013-07-11 16:47:08 ERROR: CTxMemPool::accept() : free transaction rejected by rate limiter

Unfortunately, I can't do more than that but it is a nice start. 

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.

[Explodicle]

Bitcoin-Qt shut down, limitfreerelay=0 added to .conf file, Bitcoin-Qt started. Debug.log file now shows quite a lot of messages like one bellow.

Code:

2013-07-11 16:47:08 ERROR: CTxMemPool::accept() : free transaction rejected by rate limiter

Unfortunately, I can't do more than that but it is a nice start.  

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.

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

[🏰 TradeFortress 🏰]

we were going to run into this problem sooner or later, script allows for data to be stored in the blockchain, however since there is currently no incentive to hold the blockchain (fees being paid to hold it), eventually we'll run into serious storage problems enhanced by using the blockchain for storage, my companies design is looking at that seriously and we're currently trying to figure out a method that will keep bloat down to a minimum while maintaining a DDOS proof account ledger.

short answer is no 0 btc fees, which I would happily support.

+1

Zero fee trasactions should be banned. Under all scenarios possible, sending 300 BTC should cost more in transaction fees than sending less BTC.
In real world, we already have fucked-up monetary system that favours rich over poor, do we want the same or similar system online as well? No.

The purpose of fees is to limit spam, not to create an advantage/disadvantage of the rich vs poor.  If you want to "even it out", then simply require a fee that grow linearly with how much room the transaction takes.  Say, 1 satoshi for every byte of room on the blockchain, or something.

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

[DeathAndTaxes]

Under all scenarios possible, sending 300 BTC should cost more in transaction fees than sending less BTC.
In real world, we already have fucked-up monetary system that favours rich over poor, do we want the same or similar system online as well? No.

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.

[CIYAM]

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.

[SgtSpike]

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.

[CIYAM]

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.

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.

[gmaxwell]

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.

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.

[CIYAM]

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.

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.

[gmaxwell]

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.

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.

[CIYAM]

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.

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.

[jl2012]

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.

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.

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 :

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

to

Code:

priority = sum( min(5000000000, input_value_in_base_units) * (input_age - 1))/size_in_bytes

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

[CIYAM]

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

[derekleong75]

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

[jl2012]

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

The 0.00005430 restriction is more aggressive than mine

[WiW]

Bitcoin-Qt shut down, limitfreerelay=0 added to .conf file, Bitcoin-Qt started. Debug.log file now shows quite a lot of messages like one bellow.

Code:

2013-07-11 16:47:08 ERROR: CTxMemPool::accept() : free transaction rejected by rate limiter

Unfortunately, I can't do more than that but it is a nice start.  

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.

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

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.

[mustyoshi]

There is no timestamp in transaction

So what is the thing that makes an identical tx different each time you sign it (I have tested this so I know it to be a fact)?

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.

[Explodicle]

Bitcoin-Qt shut down, limitfreerelay=0 added to .conf file, Bitcoin-Qt started. Debug.log file now shows quite a lot of messages like one bellow.

Code:

2013-07-11 16:47:08 ERROR: CTxMemPool::accept() : free transaction rejected by rate limiter

Unfortunately, I can't do more than that but it is a nice start.  

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.

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

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.

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.

[QuestionAuthority]

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?