Bitcoin Forum
December 08, 2016, 06:03:20 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: 195.200.253.240 is a real jerk  (Read 3754 times)
BrightAnarchist
Donator
Legendary
*
Offline Offline

Activity: 853



View Profile
March 22, 2012, 09:31:51 PM
 #1

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

Posts: 1481177000

View Profile Personal Message (Offline)

Ignore
1481177000
Reply with quote  #2

1481177000
Report to moderator
1481177000
Hero Member
*
Offline Offline

Posts: 1481177000

View Profile Personal Message (Offline)

Ignore
1481177000
Reply with quote  #2

1481177000
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481177000
Hero Member
*
Offline Offline

Posts: 1481177000

View Profile Personal Message (Offline)

Ignore
1481177000
Reply with quote  #2

1481177000
Report to moderator
1481177000
Hero Member
*
Offline Offline

Posts: 1481177000

View Profile Personal Message (Offline)

Ignore
1481177000
Reply with quote  #2

1481177000
Report to moderator
vampire
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 22, 2012, 09:33:40 PM
 #2

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

Activity: 1246


Strength in numbers


View Profile WWW
March 22, 2012, 09:41:07 PM
 #3

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 22, 2012, 09:47:08 PM
 #4

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

Activity: 1848


View Profile
March 22, 2012, 09:49:36 PM
 #5

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.

https://bitfinex.com <-- leveraged trading of BTCUSD, LTCUSD and LTCBTC (long and short) - 10% discount on fees for the first 30 days with this refcode: x5K9YtL3Zb
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
alkhdaniel
Member
**
Offline Offline

Activity: 114


View Profile
March 22, 2012, 11:58:37 PM
 #6

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

Activity: 812



View Profile
March 23, 2012, 12:01:12 AM
 #7

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

Activity: 266


I'm actually a pineapple


View Profile
March 23, 2012, 12:15:58 AM
 #8

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

Activity: 1246


Strength in numbers


View Profile WWW
March 23, 2012, 12:21:39 AM
 #9

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 23, 2012, 12:45:05 AM
 #10

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

Activity: 420


1ngldh


View Profile
March 23, 2012, 12:57:21 AM
 #11

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
Kluge
Donator
Legendary
*
Offline Offline

Activity: 1218


Michael, send me some coins before I hitman you


View Profile
March 23, 2012, 01:04:59 AM
 #12

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?

Don't mix your coins someone said isn't legal
ram1
Newbie
*
Offline Offline

Activity: 16



View Profile
March 23, 2012, 02:45:37 AM
 #13

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

Activity: 812



View Profile
March 23, 2012, 02:52:31 AM
 #14

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

Activity: 868



View Profile WWW
March 23, 2012, 03:25:21 AM
 #15

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.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
payb.tc
Hero Member
*****
Offline Offline

Activity: 812



View Profile
March 23, 2012, 03:41:26 AM
 #16

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

Activity: 103


View Profile
March 23, 2012, 11:37:10 AM
 #17

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

Activity: 868



View Profile WWW
March 23, 2012, 12:56:13 PM
 #18

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.

(gasteve on IRC) Does your website accept cash? https://bitpay.com
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 23, 2012, 01:27:57 PM
 #19

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

Activity: 826


View Profile
March 23, 2012, 02:17:54 PM
 #20

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.
Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!