7

You're missing the main point: when a selfish miner finds a new block, he keeps it private, does not broadcast it to the network, and starts mining on top of that privately. The rest of the network is still mining on a block that was actually already found, but not broadcast. When the rest of the network finally finds this block, the selfish miner ...


5

Selfish Mining cannot be used to change transactions in any way, therefore, it is impossible to steal funds in such fashion. Also, Selfish Mining is somewhat the opposite of Double-Spending, as double-spending would require you to publish your own blocks as quickly as possible in order to overtake the network, while selfish mining is based on keeping ...


4

The report is not heavily disputed. In the hours following the paper's release, several developers are discussing solutions: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03128.html and http://bitcointalk.org/index.php?topic=324413.0 There has not been any evidence that such an attack is imminent or likely even. And remember,...


3

Selfish mining is based on delaying the propagation of the blocks a selfish miner (or pool) has mined. Following such approach, other miners continue mining on the top of an old block, wasting their time and hash power. There are different situations depending on how many blocks a selfish mining pool is able to mine in a row before any other node mines ...


3

Note that there is a new and better paper about this topic by Aviv Zohar et al. - http://arxiv.org/pdf/1507.06183v1.pdf. None of the solutions suggested have been implemented yet. The attack is significant enough that some solution will need to be found, but that's up to researchers, not developers.


3

I think it's conceivable that this could happen. But under realistic cases, I don't think it actually will. If you don't mine on the longest block, the probability that your block will ever be part of the longest block drops drastically. Unless a block you mine becomes part of the longest chain and stays that way, you never get any fees or reward at all.


2

The interesting thing about that paper is that, if I understood correctly, it doesn't require pools to collude in order to attempt the "selfish miner" strategy - any pool with more than 25% of the total hash power could do it solo - right now there are pools which could do it. And with just slightly more than 33% of total hash power, they could make their ...


2

For the first part: Yes, this is possible, and doesn't require having a high hashrate. No, it is not an attack. It is important to realize that disagreement between nodes on what the last block is is perfectly fine. The protocol specifies that, among branches of the highest length, every node builds on the first one he learned about. In your scenario you ...


2

Is the attack really practical? Eh... maybe. The whitepaper you linked makes two assumptions, and it's not clear how well those hold up in practice. It costs nothing (or close to nothing compared to mining pool revenue) to run a sybil attack. From the paper: Because selfish mining is reactive, and it springs into action only after the honest nodes ...


2

We can make an educated guess about it. We can look at the hashrate that various pools advertise. We can look at what IP address the mined block was first seen at. We can look at the coinbase of the block. (Eligius.st famously embedded bible quotes.) We can also guess at the size of a mining pool by looking at its Alexa rank. But we don't know for sure. ...


2

While FIBRE has done an incredible job in reducing relay times for blocks which are new, many miners additionally have systems by which they relay their own blocks in a single packet and have them queued up to relay on when they start mining the template, not when they find the block. Ultimately, FIBRE's few milliseconds of delay will lose to a single UDP ...


1

Your question seems very similar to the 51% attack vector on the lightning network which I described on the lightning dev mailing list. I am not aware of any protocol to prevent this nor do I see any way of preventing what you and what the mailinglist post describe. The timeouts depend on blockheight and the Bitcoin protocol has the consensus rules that the ...


1

The answer is because among the set of acceptable hashes, every hash is equally likely. See https://bitcoin.stackexchange.com/a/939/60443 There really hasn't been more work done just because the value is greater, as long as it meets the current difficulty. Nickel and diming the work done by comparing block hashes would create many more forks, thus requiring ...


1

This will generally not work, because as you said, if an honest node receives the block, it will propagate it to all of its peers, who will do the same, and so on. Even if the attacker controls a large number of nodes on the network, he/she will have to ban every honest node to have a guarantee of them not receiving the block. If that is done, the attack ...


1

With 51% of the network hashrate the forking attack is theoretically possible. Classically, what you have described is a double spending attack. First, the attacker pays M->B and B releases the goods. Then, the attacker presents a longer valid chain paying M->M instead and the blocks containing M->B are orphaned. It is not simply a matter of presenting an ...


1

Thanks to Murch, I'm answering my own question; Yes! Murch made the point that using BTCDD enables a selfish miner to mine a non-broadcast transaction that spends old coins rather than having to rely on a network propagation advantage. I understand this objection. That advantage is easily removed by excluding from your BTCDD calculation transactions that ...


1

Selfish mining is not related to the three factors you mentioned. The basic idea is that a miner can do one of two things: Shift her mining efforts on top of any new legitimate block she hears about and broadcast to the network any block she finds as soon as she finds it When she finds a block, instead of broadcasting it immediately, keep it to herself ...


1

SPV wallets typically keep track of what the best known block for each of their peers is as well, to make sure they are up to date and can assess the security of their transactions (# of confirmations). The way they do this is to start a counter initialized at the height given in the version message. And then when the node broadcasts a new inv (inventory) ...


1

It is impossible to detect a drop in hashrate working on a chain because foreign hashpower is only evident in the discovery speed of blocks, except if it were deducted from a pool publicly sharing its mining stats. Thus the dropped hashrate would only be evident over sufficient long spans of time. The only indicator of selfish mining would be the actual ...


Only top voted, non community-wiki answers of a minimum length are eligible