195.200.253.240 is a real jerk

[BrightAnarchist]

Look at recent transactions... ( https://blockchain.info/ )

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

Maybe TX fee is too low?

[1714183684]

1714183684

[1714183684]

1714183684

[vampire]

Mystery miner ---> https://bitcointalk.org/index.php?topic=67634.0

[FreeMoney]

Look at recent transactions... ( https://blockchain.info/ )

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

Maybe TX fee is too low?

How much faster is he getting it by not including tx?

Indeed, maybe offer something substantial to be a part of his amazingly difficult computations. Or wait for one of the countless generous miners who are willing to do it for free.

[nelisky]

That's CRAZY!!!

That IP is mine, I have a bitcoind running there but not only are the generation addresses not mine but also I have never found a block there that I can remember.

So... what's going on?

[Sukrim]

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

You don't hash any faster if you don't include other transactions from the P2P network. Also only the Merkle Root is part of the header so there is not more work for any miner if he includes 1, 10 or 1 million transactions.

The only explanation I currently have for this behaviour is that this is someone mining with a custom client who didn't bother just for ~1 BTC/block or often even less to (re)implement all that transaction verification stuff. Also it makes communication with minig clients much easier - only notify them of new blocks and if they solve a block, publish it to the network. No need to relay transactions, listen to them, verify them, keep blockchains and account balances and whatnot.
As this would benefit a botnet (low communication overhead), some argue it could be that this miner is a botnet. In fact, noone can know and if the transaction fees were 100 BTC instead of 1 BTC per block, I bet it wouldn't pay off to mine empty blocks.

[alkhdaniel]

That's CRAZY!!!

That IP is mine, I have a bitcoind running there but not only are the generation addresses not mine but also I have never found a block there that I can remember.

So... what's going on?

If it is truly your IP it was probably relayed through you.

AKA the block was sent through his bitcoind to your bitcoind which further sent it to blockchain.info (there might have been people inbetween you and the miner but you were the one who finally sent it to blockchain.info's bitcoind)
(pretty sure this is how blockchain.info gets their ip, kind of weak method)

[payb.tc]

That's CRAZY!!!

That IP is mine, I have a bitcoind running there but not only are the generation addresses not mine but also I have never found a block there that I can remember.

So... what's going on?

If it is truly your IP it was probably relayed through you.

AKA the block was sent through his bitcoind to your bitcoind which further sent it to blockchain.info (there might have been people inbetween you and the miner but you were the one who finally sent it to blockchain.info's bitcoind)
(pretty sure this is how blockchain.info gets their ip, kind of weak method)

or.... his pc has been infected by the botnet.... dun dun dun.

[copumpkin]

(pretty sure this is how blockchain.info gets their ip, kind of weak method)

Unfortunately it's the only one available. The fact that relays exist (because bitcoin is p2p) makes the IP addresses virtually meaningless.

[FreeMoney]

That is interesting nelisky, did you maybe give your IP a long time ago to be one of the IPs to add for people trying to connect without IRC or whatever? That would seem to give credence to the botnet theory as IRC activity might get some attention.

[nelisky]

That is interesting nelisky, did you maybe give your IP a long time ago to be one of the IPs to add for people trying to connect without IRC or whatever? That would seem to give credence to the botnet theory as IRC activity might get some attention.

Not really. It hasn't been up that long, but I guess it is easy for it to get "harvested" into a botnet list of usable IPs, I guess.

[rjk]

That is interesting nelisky, did you maybe give your IP a long time ago to be one of the IPs to add for people trying to connect without IRC or whatever? That would seem to give credence to the botnet theory as IRC activity might get some attention.

Not really. It hasn't been up that long, but I guess it is easy for it to get "harvested" into a botnet list of usable IPs, I guess.

Run Luke-jr's patch to log IPs, perhaps that will give you insight as to where the blocks are coming from.

[Kluge]

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

You don't hash any faster if you don't include other transactions from the P2P network. Also only the Merkle Root is part of the header so there is not more work for any miner if he includes 1, 10 or 1 million transactions.

The only explanation I currently have for this behaviour is that this is someone mining with a custom client who didn't bother just for ~1 BTC/block or often even less to (re)implement all that transaction verification stuff. Also it makes communication with minig clients much easier - only notify them of new blocks and if they solve a block, publish it to the network. No need to relay transactions, listen to them, verify them, keep blockchains and account balances and whatnot.
As this would benefit a botnet (low communication overhead), some argue it could be that this miner is a botnet. In fact, noone can know and if the transaction fees were 100 BTC instead of 1 BTC per block, I bet it wouldn't pay off to mine empty blocks.

Could someone explain this to me? I've read a lot of conflicting reports. Does it take more work to include transactions or not? Rather, does the overall average time to solve a block increase by including transactions? Does the communication overhead impact how quickly (on average) a block is solved?

[ram1]

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

You don't hash any faster if you don't include other transactions from the P2P network. Also only the Merkle Root is part of the header so there is not more work for any miner if he includes 1, 10 or 1 million transactions.

The only explanation I currently have for this behaviour is that this is someone mining with a custom client who didn't bother just for ~1 BTC/block or often even less to (re)implement all that transaction verification stuff. Also it makes communication with minig clients much easier - only notify them of new blocks and if they solve a block, publish it to the network. No need to relay transactions, listen to them, verify them, keep blockchains and account balances and whatnot.
As this would benefit a botnet (low communication overhead), some argue it could be that this miner is a botnet. In fact, noone can know and if the transaction fees were 100 BTC instead of 1 BTC per block, I bet it wouldn't pay off to mine empty blocks.

Could someone explain this to me? I've read a lot of conflicting reports. Does it take more work to include transactions or not? Rather, does the overall average time to solve a block increase by including transactions? Does the communication overhead impact how quickly (on average) a block is solved?

According to the wiki....   "The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions."...   

While there is apparently no additional work involved to do the (indirect) hash of a 10,000 transaction block, there is obviously added work involved in building and processing a 10,000 transaction block.  A miner ignoring transactions would appear have some advantage over a miner including transactions.  With the relatively small number of transactions per block processed currently, the amount of extra work may be negligible, and not produce any practical advantage. 

[payb.tc]

A$$hat is dropping transactions to get the block reward faster

Making more work for legit mining pools

You don't hash any faster if you don't include other transactions from the P2P network. Also only the Merkle Root is part of the header so there is not more work for any miner if he includes 1, 10 or 1 million transactions.

The only explanation I currently have for this behaviour is that this is someone mining with a custom client who didn't bother just for ~1 BTC/block or often even less to (re)implement all that transaction verification stuff. Also it makes communication with minig clients much easier - only notify them of new blocks and if they solve a block, publish it to the network. No need to relay transactions, listen to them, verify them, keep blockchains and account balances and whatnot.
As this would benefit a botnet (low communication overhead), some argue it could be that this miner is a botnet. In fact, noone can know and if the transaction fees were 100 BTC instead of 1 BTC per block, I bet it wouldn't pay off to mine empty blocks.

Could someone explain this to me? I've read a lot of conflicting reports. Does it take more work to include transactions or not? Rather, does the overall average time to solve a block increase by including transactions? Does the communication overhead impact how quickly (on average) a block is solved?

According to the wiki....   "The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions."...   

While there is apparently no additional work involved to do the (indirect) hash of a 10,000 transaction block, there is obviously added work involved in building and processing a 10,000 transaction block.  A miner ignoring transactions would appear have some advantage over a miner including transactions.  With the relatively small number of transactions per block processed currently, the amount of extra work may be negligible, and not produce any practical advantage. 

what about broadcasting the block once you're done with it?

probably negligible too, but the more tx, the more kb you have to send out.

if you're racing against other miners, milliseconds might be the difference between 50 btc and an orphan.

[Steve]

According to the wiki....   "The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of effort as hashing a block with 10,000 transactions."...   

While there is apparently no additional work involved to do the (indirect) hash of a 10,000 transaction block, there is obviously added work involved in building and processing a 10,000 transaction block.  A miner ignoring transactions would appear have some advantage over a miner including transactions.  With the relatively small number of transactions per block processed currently, the amount of extra work may be negligible, and not produce any practical advantage. 

Also, the merkle root hash only has to be computed once (and updated as new, valid transactions arrive)…you aren't seeking a hash that satisfies a difficulty like you are with the block hash, which has to be computed and recomputed many times.  Transaction validation is probably far more significant computation wise, but still far less than finding block hashes that satisfy difficulty.  And, no reason it couldn't be done one the modest CPU of a mining rig instead of using the GPU.  Most like it's someone that simply didn't want to take the time to implement the transaction handling.  Of course, if this becomes more prevalent, the longer confirmation times will start to noticeably diminish the value of bitcoin.  This might get to a point where such miners stop mining due to it no longer being profitable.

[payb.tc]

If this becomes more prevalent, the longer confirmation times will start to noticeably diminish the value of bitcoin. 

but isn't counting confirmations somewhat a placeholder for counting time?

eg. longer wait between blocks = more confidence in each block.

eg2. if blocks came every ~5 minutes, mtgox might wait for 12 confirmations on deposits... if blocks came every 20 minutes, they might only wait for 3.

[MacRohard]

That's CRAZY!!!

That IP is mine, I have a bitcoind running there but not only are the generation addresses not mine but also I have never found a block there that I can remember.

So... what's going on?

The IP address detection thing doesn't really work.. it relies on blockcain.info connecting to every connectable node (and possibly doing some funny business to get as many inbound connections as possible? - are they in dnsseed? anyone know?)

Anyone can relay transactions through anyone else - just do -nolisten -connect=<xxx.xxx.xxx.xxx> when you start bitcoin to make it only connect to one other node and then the transaction will appear to come from that node rather than you when people look on blockchain.info (assuming the node you -connect too is itself connected to blockchain.info and assuming the node you -connect too isn't actually blockchain.info itself).

You could also modify your bitcoin client so that it sends transactions only to certain nodes that have connected to you - that way you could selectively relay through hosts that aren't even listening on port 8333.

[Steve]

If this becomes more prevalent, the longer confirmation times will start to noticeably diminish the value of bitcoin. 

but isn't counting confirmations somewhat a placeholder for counting time?

eg. longer wait between blocks = more confidence in each block.

eg2. if blocks came every ~5 minutes, mtgox might wait for 12 confirmations on deposits... if blocks came every 20 minutes, they might only wait for 3.

Yes, that's true, except that it isn't relevant in this case.  The problem is that if there are lots of these 1 transaction blocks, it will delay a transaction from getting into the block chain.  What matters from a confidence perspective is how deeply a transaction is embedded in the block chain (which is as you say a placeholder for counting time, or more precisely, a placeholder for counting computation power applied to securing the transaction).  If it suddenly starts taking an average of 30 minutes for a transaction to get into a block instead of say 5 minutes, then you've now extended the time you need to wait by 25 minutes on average…regardless of whether you require the transaction to have 3 confirmations or 20 confirmations.

[DeathAndTaxes]

If this becomes more prevalent, the longer confirmation times will start to noticeably diminish the value of bitcoin.

but isn't counting confirmations somewhat a placeholder for counting time?

eg. longer wait between blocks = more confidence in each block.

eg2. if blocks came every ~5 minutes, mtgox might wait for 12 confirmations on deposits... if blocks came every 20 minutes, they might only wait for 3.

No the # of confirmations increases the difficulty of an attacker getting lucky.

Like trying to flipping a coin 6 times and getting 6 heads in a row is harder than getting 1 heads in a row.

Regardless of block times if you want "6 confirms" worth of security you need to wait for 6 confirms.

The larger the % of hashing power an attack may have the more confirms you need to have a given % chance (say 99.99%) that he can't reverse a transaction.  Obviously once attacker has 51% hashing power no amount of confirms provide security.  Satoshi lays out the math at the end of his paper.

[ribuck]

eg. longer wait between blocks = more confidence in each block.

No, that's not how it works. The only things that count are the difficulty and the number of blocks.

Someone might win a block after spending 30 minutes hashing, or they might get lucky and win the block after spending 5 minutes hashing. But the strength of the blocks are the same.

A bad guy rewriting the block chain will still take on average 10 minutes to find a replacement block, no matter how long it took the winner of the original block.