Someone is spamming the blockchain

[farproc]

https://blockchain.info/address/15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888

300BTC sending back and forth...  

[1715383660]

1715383660

[1715383660]

1715383660

[1715383660]

1715383660

[1715383660]

1715383660

[1715383660]

1715383660

[CIYAM]

I think it's clearer from this address: https://blockchain.info/address/15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888 you can see that each tx is between 1 and 3 blocks after the previous tx.

It is a little surprising that these tx's are being mined without fee (although that is of course up to miners), however as they only each have the one UTXO they are all very small and of course the amount isn't considered as "dust" (maybe it's some sort of a protest?).

[servowire]

So they are using the second/microsecond/etc as a way to encode a message? mmm did not think of that.

Will these transactions get verified? There is no fee included?

[🏰 TradeFortress 🏰]

It matches the free transaction criteria.

Either someone is bored and wrote a script to keep sending the coins back and forth, or it's passing data. I think the latter is more likely.

[CIYAM]

It matches the free transaction criteria.

Either someone is bored and wrote a script to keep sending the coins back and forth, or it's passing data. I think the latter is more likely.

I wonder whether the free tx criteria is too lenient (it could become quite a problem if we end up with 100s or even 1000s of bots doing the same thing).

The possibility of it being a (rather slow) method of sending data (via the timestamp part of the tx) does indeed make some sense - the address that I linked to is constant (it keeps being sent out from and back to that address) so that is also interesting as it may well be possible to work out *who* it is that is doing this.

Of course it is always possible that the computer that this bot is running on might crash and burn with the 300 BTC being lost forever.

[kjj]

The messages are encoded in the time stamps.

Which would make sense, if the sender had some control over the timestamps.

[CIYAM]

Which would make sense, if the sender had some control over the timestamps.

I assume timestamps is referring to what is stored in a tx itself (not the block timestamp as that is provided by the miner).

Note that if you sign the same raw tx multiple times (by repeating the sign command) you end up with a different signed raw tx each time - this is due to a timestamp field in each tx (AFAIA).

[farproc]

Whatever, the downside is obvious: making the block chain data larger than necessary.

[CIYAM]

How do I do this. I want to store my backups with the blockchain.

Hmm... at a rate of a few bytes per 10 minutes (assuming one tx per block which this spammer isn't even achieving btw) I would guess you would not want to be backing up anything very big (unless you are willing to wait years for your backup to complete).

[thehun]

It's not spamming they are passing messages through timestamps

Why don't they just use BitMessage?

[CIYAM]

Why don't they just use BitMessage?

Indeed - if wanting to send information that would make a lot more sense - perhaps it is just an experiment (although using 300 BTC for such fun could be rather expensive if something goes wrong).

[nottm28]

Why don't they just use BitMessage?

Indeed - if wanting to send information that would make a lot more sense - perhaps it is just an experiment (although using 300 BTC for such fun could be rather expensive if something goes wrong).

Curious as to why they would use 300 BTC for an experiment when 5 would do the trick just the same...

[CIYAM]

Curious as to why they would use 300 BTC for an experiment when 5 would do the trick just the same...

It certainly is a lot of BTC to be doing this with - am guessing the owner must have quite a lot of BTC to spare.

[jl2012]

It's not spamming they are passing messages through timestamps

There is no timestamp in transaction

[CIYAM]

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

[VeeMiner]

this can only be prevented by mining pools not adding the no fee transactions to the blockchain. If the sender was to pay a fee he would probably refrain from this behavior

[CIYAM]

If the sender was to pay a fee he would probably refrain from this behavior

Of course - so the question is whether there something wrong with current fee rules that are permitting this?

[nottm28]

If the sender was to pay a fee he would probably refrain from this behavior

Of course - so the question is whether there something wrong with current fee rules that are permitting this?

Indeed. If a malicious person in control of a bot-net started making thousands of these swap transactions per hour then that would take down the network surely.

[jl2012]

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

When signing with ECDSA you need to include a random number, which makes the signature different.

There is no timestamp in transaction. Check the protocol.

[CIYAM]

When signing with ECDSA you need to include a random number, which makes the signature different.

Okay - so random number rather than timestamp - the point is you *can* embed information then (and if random number then easier probably as perhaps if it was a timestamp it might be checked for range).

Of course I assume it is not that big so not much information can be sent with such an approach (yes - too lazy to check the exact details as I don't think it matters very much - if the wish is to send messages then Bitmessage would be a much better option).

[BadBitcoin (James Sutton)]

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.

[jl2012]

When signing with ECDSA you need to include a random number, which makes the signature different.

Okay - so random number rather than timestamp - the point is you *can* embed information then (and if random number then easier probably as perhaps if it was a timestamp it might be checked for range).

Of course I assume it is not that big so not much information can be sent with such an approach (yes - too lazy to check the exact details as I don't think it matters very much - if the wish is to send messages then Bitmessage would be a much better option).

No, the random number is a secret. You can't use it to store information. Revealing the random number will also reveal the private key. http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm

[CIYAM]

No, the random number is a secret. You can't use it to store information. Revealing the random number will also reveal the private key. http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm

Huh - exactly how do you embed a "secret" number when ECDSA just does signing (it does not do encryption)?

[BadBitcoin (James Sutton)]

When signing with ECDSA you need to include a random number, which makes the signature different.

Okay - so random number rather than timestamp - the point is you *can* embed information then (and if random number then easier probably as perhaps if it was a timestamp it might be checked for range).

Of course I assume it is not that big so not much information can be sent with such an approach (yes - too lazy to check the exact details as I don't think it matters very much - if the wish is to send messages then Bitmessage would be a much better option).

the size allotted to script section in bytes has a maximum of 10kb (https://en.bitcoin.it/wiki/Script, scroll down to messages), so in theory you can store a significant amount of text per transaction, that's one thing that satoshi didn't envision and could cause problems if everyone starts using script to store database info, the blockchain bloat will increase in pace.

[bozak]

Why are they using a large amount of coins for this purpose?  Couldn't they just transfer 1 coin back and forth and acheive the same result?

[CIYAM]

Why are they using a large amount of coins for this purpose?  Couldn't they just transfer 1 coin back and forth and acheive the same result?

A good question - does it have something to do with the minimum tx fee algo or maybe the spammer is just "showing off" how much BTC they have?

[🏰 TradeFortress 🏰]

Why are they using a large amount of coins for this purpose?  Couldn't they just transfer 1 coin back and forth and acheive the same result?

A good question - does it have something to do with the minimum tx fee algo or maybe the spammer is just "showing off" how much BTC they have?

The free TX policy has a coin days destroyed. For example, sending 100 BTC around would allow you to get free TX 100x faster than sending 1 BTC around.

[KeyserSoze]

Perhaps someone plans to offer a BTC investment vehicle to potential non-technical investors and wants to provide them other "good data" beyond just exchange pricing. That entity could simply point to the sheer number of bitcoins transferred through the network as an "indicator" of its increased usage, knowing the average person wouldn't investigate the blockchain itself for something like this.

[CIYAM]

The free TX policy has a coin days destroyed. For example, sending 100 BTC around would allow you to get free TX 100x faster than sending 1 BTC around.

Aha - I thought something like that might be the reason - so does the figure of 300 BTC have any "magical property" in regards that it seemingly can get into every new block (despite the UTXO being no older than the last block)?

If they used 100 BTC instead would that not work just as well?

[kjj]

No, the random number is a secret. You can't use it to store information. Revealing the random number will also reveal the private key. http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm

Huh - exactly how do you embed a "secret" number when ECDSA just does signing (it does not do encryption)?

EC math is magic. 

You don't really embed the secret number, you provide the product of the random number * G.  You may recognize that as the same operation that produces your public keys from your private keys.

[CIYAM]

EC math is magic. 

You don't really embed the secret number, you provide the product of the random number * G.  You may recognize that as the same operation that produces your public keys from your private keys.

Oh - well I must admit that to me it is a bit magic - but from what you're saying then the random number being not actually embedded at all would make it pretty useless for storing information then.

In that case we can rule out the "storing information" hypothesis - any other ideas why this spamming is being done (to prove some point perhaps)?

[SgtSpike]

Curious as to why they would use 300 BTC for an experiment when 5 would do the trick just the same...

Because it wouldn't do the trick just the same.  If they are sending transactions just a few blocks apart, then 5 BTC wouldn't be able to be sent without a fee.  Remember that a fee is required whenever Bitcoin * Days is less than 1.  30 minutes * 300 BTC = 6.25 Bitcoin Days, but 30 minutes * 5 BTC = 0.104 Bitcoin Days.

[dirtscience]

https://blockchain.info/address/15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888

300BTC sending back and forth...  

Its not spamming if they are paying fees

[CIYAM]

Because it wouldn't do the trick just the same.  If they are sending transactions just a few blocks apart, then 5 BTC wouldn't be able to be sent without a fee.  Remember that a fee is required whenever Bitcoin * Days is less than 1.  30 minutes * 300 BTC = 6.25 Bitcoin Days, but 30 minutes * 5 BTC = 0.104 Bitcoin Days.

So would 50 BTC be able to be used to do the same thing then?

Its not spamming if they are paying fees

No fees are being paid (check the links to blockchain,info).

[dirtscience]

ITS NOT SPAMMING, totally a normal thing to do.

[CIYAM]

ITS NOT SPAMMING, totally a normal thing to do.

If everyone did this then the blockchain would end up 1000s of times bigger than it is - and how is it totally normal to send your BTC to one address and back to the original address every single block?

[🏰 TradeFortress 🏰]

ITS NOT SPAMMING, totally a normal thing to do.

Please tell me you are trolling

[CIYAM]

Please tell me you are trolling

I am guessing so (shouldn't have bothered replying should I).

[nottm28]

Curious as to why they would use 300 BTC for an experiment when 5 would do the trick just the same...

Because it wouldn't do the trick just the same.  If they are sending transactions just a few blocks apart, then 5 BTC wouldn't be able to be sent without a fee.  Remember that a fee is required whenever Bitcoin * Days is less than 1.  30 minutes * 300 BTC = 6.25 Bitcoin Days, but 30 minutes * 5 BTC = 0.104 Bitcoin Days.

Ah that makes sense as to why 300 BTC then - nicely pointed out

[EDIT] but yeah - why not 50 then?

[SgtSpike]

Curious as to why they would use 300 BTC for an experiment when 5 would do the trick just the same...

Because it wouldn't do the trick just the same.  If they are sending transactions just a few blocks apart, then 5 BTC wouldn't be able to be sent without a fee.  Remember that a fee is required whenever Bitcoin * Days is less than 1.  30 minutes * 300 BTC = 6.25 Bitcoin Days, but 30 minutes * 5 BTC = 0.104 Bitcoin Days.

Ah that makes sense as to why 300 BTC then - nicely pointed out

[EDIT] but yeah - why not 50 then?

If they want to do it every 3 blocks, they might want to make sure the transactions won't have trouble getting through in case 3 blocks are mined rather quickly after each other.  Or, they just had 300 BTC handy that they didn't want to split up.  Or.... ??

[CIYAM]

So in summary (perhaps) if you have 300 BTC you can "spam the blockchain" with such small tx's no worries.

I guess that as not so many people have 300 BTC to do so (or to risk on a bot that may malfunction) then this is not really a pressing issue (just an interesting observation thanks to the OP having noticed it).

[nottm28]

If they want to do it every 3 blocks, they might want to make sure the transactions won't have trouble getting through in case 3 blocks are mined rather quickly after each other.  Or, they just had 300 BTC handy that they didn't want to split up.  Or.... ??

If I sat there using online banking to transfer money from one account to another over and over - my bank would put a hold on my account. I think there should be a way to prevent this. This one person is unlikely to have any effect but if the bot-net dickheads get hold of it...

[meekstav876]

https://blockchain.info/address/15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888

300BTC sending back and forth...  

If hes paying fee's theres nothing wrong with it.

[SgtSpike]

If they want to do it every 3 blocks, they might want to make sure the transactions won't have trouble getting through in case 3 blocks are mined rather quickly after each other.  Or, they just had 300 BTC handy that they didn't want to split up.  Or.... ??

If I sat there using online banking to transfer money from one account to another over and over - my bank would put a hold on my account. I think there should be a way to prevent this. This one person is unlikely to have any effect but if the bot-net dickheads get hold of it...

There is no way to prevent it besides changing the fee structure.  300 BTC is enough that it could be sent in every block without a fee.

[CIYAM]

If hes paying fee's theres nothing wrong with it.

He is not paying fees - otherwise the topic would not even be here.

[2112]

Dear Ian (and TradeFortress)!

Please do us all a favor and stop responding to the spammy one-liners from the accounts that post only to be able to send further spam in private messages.

https://bitcointalk.org/index.php?topic=253190.0

If you see an one-liner just click on the user name and check the last posts of the user before you reply.

Thanks in advance.

If everyone did this then the blockchain would end up 1000s of times bigger than it is - and how is it totally normal to send your BTC to one address and back to the original address every single block?

He is not paying fees - otherwise the topic would not even be here.

[Bacon9504A]

Not spamming!

[Bro]

Perhaps someone plans to offer a BTC investment vehicle to potential non-technical investors and wants to provide them other "good data" beyond just exchange pricing. That entity could simply point to the sheer number of bitcoins transferred through the network as an "indicator" of its increased usage, knowing the average person wouldn't investigate the blockchain itself for something like this.

could be that or just someone holding lots of BTCs trying to make transaction statistics look good

or someone calibrating his script or measuring something in the network (confirmation time vs time)?

[CIYAM]

If you see an one-liner just click on the user name and check the last posts of the user before you reply.

You instructions are duly noted and kindly don't refer to me as "dear" in the future (I am not now nor ever will be "your dear" ).

[WiW]

They're just f***ing with you for the lulz. They're attention whores from 4chan and y'all just eating up the bait.

[ArpFlush]

when you click on the icon next to "one chinese sb which love 8", you get an error message:

ERROR: Address ledger is extremely large. Contact me if you really need the data.

[buysellbitcoin]

when you click on the icon next to "one chinese sb which love 8", you get an error message:

ERROR: Address ledger is extremely large. Contact me if you really need the data.

That is theymos for you

Cheers

[buysellbitcoin]

when you click on the icon next to "one chinese sb which love 8", you get an error message:

ERROR: Address ledger is extremely large. Contact me if you really need the data.

That is theymos for you

Cheers

lol, and when I looked up for sb I got below :

http://www.urbandictionary.com/define.php?term=SB

SB. noun. (pl. same) also,S13 Comes from a Chinese words. Pronounces Sha bi,means "Stupid Bitch".

Cheers

[nottm28]

I googled his payment address and found these:

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

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

and he likes satoshi dice...

http://www.satoshidice.com/full.php?tx=1a11bfc12b103254b582c13d0bd4527dde82908d8e2561b6d6573e9141925db6

http://www.coin500.com/report/active.html


[EDIT] googled for this 15Z4XmorKSN51ndyPrZ2EtL7Nnksb88888

[CIYAM]

SB. noun. (pl. same) also,S13 Comes from a Chinese words. Pronounces Sha bi,means "Stupid Bitch".

Actually "bi" is the term for female genitalia so that is perhaps a more polite translation of the actual meaning (but yes - not to be used in front of strangers if you are in China).

I can see the attraction of using "stupid bitch" though (as it makes more sense to a westerner being SB and is probably the more equivalent expression used in the west).

[SRoulette]

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.

[2112]

You instructions are duly noted and kindly don't refer to me as "dear" in the future (I am not now nor ever will be "your dear" ).

I'm sorry, I didn't mean to offend you in any way. I just wanted to distinguish my post from the other as being a meta-post that is off-topic literally but on-topic morally.

I addressed you because I know you are a native English speaker living in a country where few people speak English. You probably set your linguistic threshold really low before you consider some statement sincere and intelligent.

I'm in an opposite situation and additionally in the past I had an experience of having to instruct first-line sales- and tech-support people in the art of recognizing time-wasters that try to finagle a freebie. Thus my linguistic threshold is diametraly opposite.

We can only guess what is the motivation of somebody moving Bitcoins to and fro.

On the other hand on this forum there's no need to guess, just read the Meta subforum. The moderators and administrators are slowly loosing control of this forum to the slow-spammers that make incisive posts, one-liners or otherwise. That the 3 accounts that posted spam in this thread were not deleted is the proof.

I understand trying to be helpful to newbies, but please administer a passive Turing test on one or two pages of the past posts of an unknown user before posing a reply. It will make our forum more friendly to the regular users and deter the spammers.

[CIYAM]

I'm sorry, I didn't mean to offend you in any way. I just wanted to distinguish my post from the other as being a meta-post that is off-topic literally but on-topic morally.

Your post was more than a touch patronising (to any native English speaker I think) and if you *care to read my post history* then you'll see I have rarely wasted my time posting replies to spammers (and I have never posted for the sake of posting even before the new rating system was introduced).

I did acknowledge to TradeFortress my mistake with the one particular post (I tend to assume that most posts are legit but of course every now and then I can make a mistake as we all do from time to time I would think) - so I think you can just *trust* me to do the right thing rather than give me a lecture thanks all the same.

Also whether I reply or not to a "spam" post for the sake of sending PMs doesn't stop the person from sending PMs (and if their post is reported and removed then they will not be able to send PMs regardless of their post being quoted so I am in no way helping them).

Of course this post is totally OT - so perhaps we could get back to discussing the OP or maybe this topic has run its course (I think I am about ready for the "unwatch" click).

[WiW]

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.

Right, so who gets to decide this? YOU? Why don't you just let the people processing the transactions deal with this, okay?

Or better yet, go mine and decide for yourself which transactions get into blocks and which don't.

Stop bitching.

[SgtSpike]

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.

[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+)

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

[jl2012]

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