Usually you'd get that error quicker, but the database needed a lot of time to even gather the counts and basic data. That ledger would have 16,850 rows if it was actually displayed.
One fee method I've been thinking about is charging more for increasing the total block chain size. If these transactions are all 0.01 BTC -> 0.01 BTC, then the spent transactions can be forgotten and there's not much cost to the network. But if it's splitting 100 BTC into 0.01 BTC coins, then fees per transaction should be much higher to reflect the extra storage required by everyone.
Topic: Is this a failure of tx fee scheduling? (Read 980 times)
There was a thread I read about a guy who released a modified client with the transaction fee code taken out. He claims to have tested it at .01 btc, and the nodes still take it.
Maybe that'll point you in the right direction.
Maybe that'll point you in the right direction.
My advanced apologies to Theymos... (I don't mean to DDoS blockexplorer, but I'm posting this anyway...)
I was playing with my blockchain scanning tools. I decided to see what was the most "active" address in the blockchain, by most number of TxOuts. What I found was that there's a pretty big jackass out there executing thousands of pointless transactions. Worst of all, he's doing it without any transaction fees.
I am going to post a few addresses here but I ask for Theymos' sake you don't try searching blockexplorer for them. Click on the links below to see a sample transaction, but don't try to follow them: they have so many tx that I got the following error after waiting a few minutes for the page to load:
This guy perpetually is submitting transactions with 10-50 inputs of 0.01 or 0.1 each between a few addresses. The address with the most activity is 159FTr7Gjs2Qbj4Q5q29cvmchhqymQA7of with 16,850 TxOuts spread out among 8500 transactions. Almost all of them go to 1E29AKE7Lh1xW4ujHotoT4JVDaDdRPJnWu. Here's an example block with this address--about Tx #20.
These coins get juggled between lots of different addresses constantly. For instance, they are linked to another pair of addresses with a ton of activiity:
1AKW1jFcv49EN4g87BN7BdcyztQydihWUG constantly sending dozens of inputs of 0.01 to 1BSTJU32hFj7Uda3qbYCJ9pXXFG6xn9bBX. This block has 8 tx with 10 inputs each of this type - about Tx#20-30.
Clearly, whoever this is, is trying hard to bloat the chain and test the limits of the network. For the first time, I feel better that the flood-defense protocols are strict, because I bet he could be doing a lot more damage without it. But I wonder if there was more the client could be doing to prevent this...? This guy is probably responsible for many tens of MB of space used on my HDD, and it'd be nice if it was costing him something to do this. Until it does, I imagine he's going to continue eating my harddrive space...
I was playing with my blockchain scanning tools. I decided to see what was the most "active" address in the blockchain, by most number of TxOuts. What I found was that there's a pretty big jackass out there executing thousands of pointless transactions. Worst of all, he's doing it without any transaction fees.
I am going to post a few addresses here but I ask for Theymos' sake you don't try searching blockexplorer for them. Click on the links below to see a sample transaction, but don't try to follow them: they have so many tx that I got the following error after waiting a few minutes for the page to load:
Quote
ERROR: Address ledger is extremely large. Contact me if you really need the data.
This guy perpetually is submitting transactions with 10-50 inputs of 0.01 or 0.1 each between a few addresses. The address with the most activity is 159FTr7Gjs2Qbj4Q5q29cvmchhqymQA7of with 16,850 TxOuts spread out among 8500 transactions. Almost all of them go to 1E29AKE7Lh1xW4ujHotoT4JVDaDdRPJnWu. Here's an example block with this address--about Tx #20.
These coins get juggled between lots of different addresses constantly. For instance, they are linked to another pair of addresses with a ton of activiity:
1AKW1jFcv49EN4g87BN7BdcyztQydihWUG constantly sending dozens of inputs of 0.01 to 1BSTJU32hFj7Uda3qbYCJ9pXXFG6xn9bBX. This block has 8 tx with 10 inputs each of this type - about Tx#20-30.
Clearly, whoever this is, is trying hard to bloat the chain and test the limits of the network. For the first time, I feel better that the flood-defense protocols are strict, because I bet he could be doing a lot more damage without it. But I wonder if there was more the client could be doing to prevent this...? This guy is probably responsible for many tens of MB of space used on my HDD, and it'd be nice if it was costing him something to do this. Until it does, I imagine he's going to continue eating my harddrive space...
Jump to: