Bitcoin Forum
February 27, 2021, 04:38:54 AM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4] 5 »  All
  Print  
Author Topic: Someone is spamming the blockchain  (Read 7664 times)
nottm28
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
July 11, 2013, 10:22:56 PM
 #61

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

donations not accepted
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1614400734
Hero Member
*
Offline Offline

Posts: 1614400734

View Profile Personal Message (Offline)

Ignore
1614400734
Reply with quote  #2

1614400734
Report to moderator
1614400734
Hero Member
*
Offline Offline

Posts: 1614400734

View Profile Personal Message (Offline)

Ignore
1614400734
Reply with quote  #2

1614400734
Report to moderator
WiW
Sr. Member
****
Offline Offline

Activity: 277
Merit: 250


"The public is stupid, hence the public will pay"


View Profile
July 12, 2013, 12:32:44 AM
 #62

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

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
Hero Member
*****
Offline Offline

Activity: 950
Merit: 1001


View Profile
July 12, 2013, 01:07:22 AM
 #63

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

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 🏰
CoinLenders / Inputs.io / CoinChat
VIP
Legendary
*
Offline Offline

Activity: 1218
Merit: 1028

reimbursements closed


View Profile
July 12, 2013, 01:31:54 AM
 #64

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
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1008


Gerald Davis


View Profile
July 12, 2013, 01:38:01 AM
Last edit: July 12, 2013, 01:56:53 AM by DeathAndTaxes
 #65

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1004


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 12, 2013, 01:52:48 AM
 #66

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
SgtSpike
Legendary
*
Offline Offline

Activity: 1386
Merit: 1001



View Profile
July 12, 2013, 02:45:59 AM
 #67

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1004


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 12, 2013, 03:17:21 AM
 #68

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 3332
Merit: 4935



View Profile
July 12, 2013, 03:24:32 AM
 #69

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1004


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 12, 2013, 03:30:21 AM
 #70

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 3332
Merit: 4935



View Profile
July 12, 2013, 03:35:23 AM
 #71

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1004


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 12, 2013, 03:44:03 AM
 #72

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
July 12, 2013, 07:44:34 AM
 #73

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)






Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1004


Ian Knowles - CIYAM Lead Developer


View Profile WWW
July 12, 2013, 07:58:45 AM
 #74

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
derekleong75
Sr. Member
****
Offline Offline

Activity: 243
Merit: 250



View Profile
July 12, 2013, 08:03:25 AM
 #75

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

Activity: 1792
Merit: 1010


View Profile
July 12, 2013, 08:09:19 AM
 #76

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

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
WiW
Sr. Member
****
Offline Offline

Activity: 277
Merit: 250


"The public is stupid, hence the public will pay"


View Profile
July 13, 2013, 09:41:52 AM
 #77

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

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
Sr. Member
****
Offline Offline

Activity: 287
Merit: 250



View Profile
July 13, 2013, 06:47:38 PM
 #78

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
Hero Member
*****
Offline Offline

Activity: 950
Merit: 1001


View Profile
July 13, 2013, 11:01:49 PM
 #79

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

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
Legendary
*
Offline Offline

Activity: 2156
Merit: 1391


You lead and I'll watch you walk away.


View Profile
July 14, 2013, 06:38:24 PM
Last edit: July 14, 2013, 07:58:53 PM by QuestionAuthority
 #80

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?

Pages: « 1 2 3 [4] 5 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!