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

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


2

The minting of bitcoins is constant and a 51% miner can't change the supply of it and cause inflation. Changing the supply can only be done by developers, resulting in a chain split, which wouldn't be called Bitcoin (unless it gains the support of various companies and users) You can't just mine loads of coins, double spend them and cash out. To spent the ...


2

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


2

Don't we actually mean stale blocks when talking in context of selfish mining? You always mean stale blocks, never orphan ones. An orphan block is one that you can not connect to your local chain because you are missing a parent, in the current version of the software you can never get into the situation where this happens. When most people are talking ...


1

I understand that in selfish mining a malicious node can "send its entire hidden chain". Exactly how is this done? I know that usually a single block is broadcast-ed right after it is mined, but how does it relay an entire chain? Forks appear naturally, when two miners produce competing blocks approximately simultaneously. Such forks may have ...


1

I do not really understand any of given solutions. Can someone please explain in plain English I also find this stuff difficult to understand however I'm a little skeptical of the idea that complex issues can always be simply explained. There is a reason why people spend decades studying a subject in order to understand something. Selfish mining isn't one ...


1

There's no need to consider the timestamps in order to know the difficulty. The difficulty is stored in the blocks. This is a bit speculative but in the past such threats have been discussed, more along the lines of the hash function being hacked, and I think in such cases there will be a large consensus to hard fork. If the hypothetical threat you're ...


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

When a miner has found a block, he does not broadcast it publicly immediately, but waits until someone else is publishing a solution. He then makes surethat his solution is spreading faster on the network (by using several nodes spread around the globe). That way he selfishly prevents the other miner from getting his reward, gaining a competitive advantage ...


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