Topic: Solving Selfish/Colluding Mining (Read 662 times)

I see, thanks.  No I didn't realize there was any relevance to BCH vs. BTC here.  My point is just that there is no "selfish miner attack", for any coin, any more than a karate expert need concern himself with a "hit yourself in the eye" attack by his opponent.  Withholding blocks won't have any positive effect for a miner unless the miner is engaging in some 51 percent attack.   

Actually it is not fully my idea. I implemented something similar when being hired to work on an altcoin. I didn't think much of it at the time, but now realize it can help to make mining more competitive. But it is not a silver bullet and I am still pondering whether it will make much of a difference. I think it will help, but I want to see people really demanding this before I work on a pull request for Bitcoin.

Your idea of "peak hashrate" alone is definitely something new POW coins should take a look into...this could completely eliminate the colluding problem, but I guess one could just split his mining rig to beat this.

Sounds like it is enabling powerful individuals to dominate the market...Yet another reason not to use shitcoincash

That plot is from a blog of a Bitcoin Cash (BCH) supporter. He talks about various sophisticated statistical concepts, without showing the math, and even uses "miners will blacklist the IP address of selfish miners" as an argument. I wouldn't assign much credibility to that analysis, though it has some amount of truth, it is not a full, unbiased analysis of the situation. Even if his model is correct, selfish mining isn't the only attack I'm concerned about, as I have mentioned in previous posts of this thread.

Thank you!  This looks correct to me, well put and nice plot. 

Also see:  http://vixra.org/abs/1504.0072

I want to amend some details in my proposal.

The reserved fees shouldn't be paid as transactions back to the users as that would waste too much space on the blockchain, and even if users aggregate all their fees into one address that changes once in a while, it would still waste space and be bad for privacy.

So I think each output in a transaction should be associated with a reserve fee (could be 0), and it would typically be the difference of f and f*h/p, where h and peak are the current and peak hashrates at the time of the transaction, and f is the full fee paid for the transaction divided by the number of outputs. This reserve fee can only be used when the next time the output is used as an input in a transaction (to preserve fungibility of coins), and it's value would fluctuate based on h/p (hashrate to peak hashrate ratio).

Think of it like this: When you send bitcoin to someone currently it is like sending someone a car without wheels. The car (the btc) needs wheels (fees) to get moved, so with this reserve fee associated with each UTXO you are giving the receiver a chance to send the btc with a fee that will fluctuate according to conditions. If hashrate rises, miners will chip away at the reserve fees created within the past 2016 blocks. At the time of spending the UTXO, whatever is left can be used for the mining fee. Yes in the end miners get all the transaction fees, but the ones they get at times of peak hashrate will be "unconditional" as they will not need a transaction associated with those, so they can fill their blocks with more transactions and take more fees. Also note that the "wheels" will be big for users during rough conditions (falling hashrate) and small during good conditions (rising hashrates).

Edit: I think better not to force the reserve fee to only work with the output it came with, because then people will select outputs based on fee preference, and that can be bad for liquidity or anonymity. Just leave the reserve fees as if they were independent UTXOs, except you can't spend from them; you have to use them as fees for transactions. This would increase the size of the UTXO database, but by a maximum factor of 2.

Would be good to see how that pie chart changed before the rise and after (August 25 and August 27)


Merge mining is more useful for altcoins to prevent wild swings in hashrate and to increase the hashrate, which is necessary for security. Actually, it is the honest hashrate that you want to maximize. Honest meaning, a hashrate provided by miners that don't attack. The main attack to worry about is double spending, but also censorship of transactions is an attack a miner can carry out.
The expected value of the honest hashrate is
h * P, where h is the hashrate and P is the probability that any given miner is honest. For native mining (no merge mining), it would make sense that P is greater (the miner is more dependent exclusively on the coin), but if the coin has low value, h will be very small, so not worth it even if P is 1. Also the variance of h and P is probably larger with native mining. For Bitcoin h is large, so it doesn't matter so much if you do merge mining, and h * P may even be greater for native mining because of a larger P. But this can change, and anyway, merge miners still have some degree of loyalty to a coin they are merge mining together with another, and as long as Bitcoin has the dominant market value, the miner is still very dependent on it. The P can also depend on what kind of "rival" coins are out there, as rival miners would just want to damage coin in order to boost another coin.

Sidechains can help by providing other blockchains where miners get paid in Bitcoin, and I think better to not allow merge mining of sidechains simultaneously, only merge mine random other coins, but all Bitcoin sidechains should be independently mined (as well as their sub sidechains), so then you get a whole tree structure of side chains, and no miner can control all chains simultaneously, since they are not merge mineable. Sidechains still needs more work in zero knowledge proofs in order to be a trustless system. The best we can do now is lock coins in a multisig address when sending to a sidechain.

Multi-algo proof of work systems can also help to decentralize mining. If you let miners choose 1 of n algos for mining, then miners will likely want to specialize in one algo, instead of try to be a "jack of all trades", so it will be hard for one miner to attack all algos and thus the chain. Though one thing I like about SHA256 is that it is really simple, so someone can easily build an ASIC at home, or a small company can build it instead of rely on centralized manufacturers. So maybe multi algo with simple algos, not those complex algos designed to prevent ASIC mining, because for those it will be easier to be a "jack of all trades" mining everything with general purpose GPUs.

I think the 2 week block retarget with 4 times max increase/decrease is fine as it helps to prevent sybil attacks, but who knows, a more dynamic algorithm could work also.

As for my proposal to let users create "smart contracts" with miners dependent on hashrate, I think it would be easy to do because as with SegWit, there is an "anyone-can-spend" output that can be used to put extra fees that are dependent on hashrate conditions. The miner would have to add one anyone-can-spend output in his coinbase transaction that stores the reserves. There can be various contracts, but I think the standard contract should work like this: If hashrate keeps rising, then miners keep getting more rewards from those reserved fees, if hashrate drops, then the users who created those smart contracts would start getting their fees back.

The change would require new OP codes added the the script system that check for hashrate and peak hashrate. That wouldn't add much CPU time and we can add a limit of 4 years for the lookback period for the peak hashrate (anyway it would be cached in the blockindex / memory). The feature would be completely voluntary for both users and miners. I think with a chance of users getting some of their fees back, that would incentivize users to create such smart contracts with a larger fee than usual and miners would find them attractive since they can now can get more than usual amount of fees. The only issue is the UTXOs extra transactions needed (possibly increasing costs for users/miners). We want to make sure the UTXO database doesn't grow unnecessarily and any extra transactions don't waste block space. When miners get paid for the rising hashrate, they will need to make a transaction that spends some amount from each of the anyone-can-spend outputs that are still part of the reserve fees. Eventually, each of those outputs will get destroyed (multiple outputs converging to one), so I think a rising hashrate is good for destroying the extra UTXOs, and only 1 extra transaction is needed per block. The size of the transaction can be reduced by limiting the time window for such a smart contract to finish (would take a long time to dissolve the reserve if hashrate is only slightly increasing/decreasing). In the case of a falling hashrate, the anyone-can-spend outputs will split into many outputs (users getting their money back) for each block that is relevant, and that would require more block space than with miners getting paid, so maybe pay users only once the reserve is finished (i.e. contract is over), and make sure the time window for the contract is limited (like 2016 blocks for example). If the contract ends before the reserve is finished, the remaining reserve can be split evenly between miners and users, or some other specified rule.

35% increase of total hashpower is not the same as a single miner increasing their hashpower by 35%.

Looking at Bitcoin's current hashrate distribution per pool, the proportions don't seem to have shifted much [1]. Distributed evenly, a 35% hashrate increase merely means that attacking the network via hashing power just got harder.

[1] https://www.blockchain.com/en/pools?timespan=24hours



I know too little about sidechains to give an educated opinion, but what brings you to the conclusion that merge mining helps decentralization? I'm only thinking of Namecoin right now, so I might have missed some recent development in this area.




In theory, yes. In practice I think this is much harder to achieve in a robust, nearly side-effect free way than one may imagine. Prime example is the mess that was BCH's EDA. That is not to say that solving this problem is impossible. I just think that it's a harder problem than it looks -- moreso with a crypto the scale of Bitcoin.



I've also been thinking about how the decreased currency issuance rate could absorb part of the price drop. However I think the negative price pressure would be larger for two simple reasons:

1) Historically speaking, decreased currency issuance rate (ie. halvings, in our case) took a couple months to be reflected in Bitcoin's price

2) Low confirmation times and increased fees put a lot of negative short-term price pressure that could turn into mid- to long term price pressure in case of a downward spiral




I think the subtle attacks that Peter Todd was talking about where political attacks similar to the BCH / B2X dramas we saw in 2017. That's just my guess though.

@Heretic says:
I want to revist this scenario, assuming no merge mining. First, I think a price drop will be slightly offset by the lower rate of coins being mined. Also, confirmation times will get longer: Both the time to get a block will increase and the number of confirmations needed to have enough work done on the chain so that your transaction is considered safe. The fees would likely rise and this would increase rewards to miners, especially in a fee-market dominated future. It would be nice to write this up in terms of mathematical equations to see exactly what would happen.

Anyway, I am proposing just to modulate the fees (not the fixed subsidy). I think a good way would be to let users choose how their fees are used. If a user wants, they can say: "I am paying f h/p to the miner", where f is the nominal fee, h the hashrate of the past period (current hashrate), p the peak hashrate. So the miner who mines the block with that transaction will only get f h/p, and f-fh/p will be kept in reserve and can slowly be released to miners as the hashrate approaches the peak. For example, if once the current 144 block period is over, it is calculated that h2 > h, then h2/p-h/p will be released to miners who mine the blocks in the next period (perhaps spread evenly over that period). Like this each user can choose more precisely how they want their fees spent, and it makes sense that they would care about the security provided by blocks coming after the transaction they make, instead of just caring about the immediate block they get their transaction on.

Can this sort of thing be done easily with a soft fork or some kind of smart contract between users and miners? I don't know, I am thinking about it.

@Heretic says:
Also revisiting this...I think I should add another category of attacks that I am trying to prevent: subtle attacks that are profitable and don't significantly affect the price of Bitcoin. This could be block withholding attacks (mining pools wasting each other's resources), networking attacks (to mess with other miners' connectivity), physical attacks (like purposely selling defective hardware and for yourself mining with the good hardware). I think this is what Peter Todd was talking about in the Reddit post about "other subtle and more effective attacks", and he (and others) likely don't want to lay them all out to give attackers bad ideas. Even EMP attacks on general electric devices can be considered "subtle" as it can be done to look like just an attack on general devices, while really it is targetting an area dense with honest miners. The selfish mining attacks and collusion attacks (the other categories) can also be done quite profitably I think, but with Internet anonymity still immature, they are less practical (as Peter Todd also indicated). In general, the point of my proposal is to disincentivize miners from driving out the competition. With the same reward for a lower hashrate, it is profitable to drive out competiton (lower overall hashrate) as that gives a bigger share to the attacker, and the same reward. If someone knows other ways to achieve this goal, then please let me know. This is one simple way that I think would work.

This is very true. The situation in that hemisphere would be dire, and reverting, at least in the short term, to a very primitive level.

However, remember that bitcoin is a global network, and barring complete annihilation of all electronics worldwide, and electronics manufacturing facilities, the internet would return again to the areas where it was wiped.   

A more interesting question for the remaining part of the network is just how badly the hash rate was affected, and how long it would take of the 10 minute average block time take to be re-established.   It might be wise for bitcoin to adopt one of the more sophisticated diffalgos which were developed for alt coins  suffering from wild hash-rate swings for this reason: the unexpected disappearance of substantial hash rate. Unlikely, yes, but impossible, no.

@Heretic says:

Yes of course attackers don't care so much about the value provided by the block rewards, though they do to some degree, and if miners who do care are incentivized to work at peak, the effect of an attack will be smaller. It's like putting shock absorbers on a car. You may hit a rock, but with shock absorbers it will be smoother.

@Heretic says:

That's where merge mining (another shock absorber) would be useful in my opinion, but we can save that for another thread

Look, we just had a sudden 35% increase in hashpower recently (from what I read in the news), that's enough for a selfish mining attack, so to trust in the decentralization of Bitcoin mining is a bit of a shaky argument I believe, and I don't think what I am suggesting is urgent, but should carefully and smoothly rolled in, without much complication.

There have been other core developers also concerned with the decentralization of mining, and even planning for a PoW change in case a 51% attack happens. I think other technologies like sidechains and merge mining will strengthen decentralization and hashpower attack prevention in the future also.

@ranochigo says
EMP attacks are attacks that are protected with physical security protocols, not Bitcoin, which is a software protocol. I also suggested a one year period for measuring the peak hashrate to allow for time to adjust to changing environmental conditions. The user @TeamBitmark is a troll from another thread I participated in so I will not directly answer him, unless someone echoes his question.

Possibly more than half of the hashrate would be gone. Anyhow, I honestly doubt the others would have enough resources to outpace the remaining network. There are only that many ASIC machines and I doubt any other entity would possess that much machines without using it at all, the sheer cost of it would be astounding. The block interval is likely to be twice as long without any further attacks. It would surely drive people off of Bitcoin.

But the more important question is; Why would you care about Bitcoin when literally everything that is electronic has been taken out? Bitcoin should be least of your worries when the infrastructure of your country is wiped clean

An air-burst EMP weapon could neutralize all electronics in a large area, say the size of the continental United States or China.
What kind of effect would the gutting of a large part of the planet's networking and hashing infrastructure have on hash rate ?
Of course what would be left would be a fraction of the recent peak.   This could happen, it's  possible (although we want to think, also improbable). And it would have nothing at all to do with miner collusion or game theory.

Anyone willing to waste their resources on mounting a 51% attack on Bitcoin will do so regardless of whether we try to tweak the incentive structure in one way or another. Assuming such an adversary exists, selfish mining or covertly aggregating (unused) reserve hashing power would be the least of our worries.

It is also worth noting that covertly aggregating (unused) reserve hashing power would not even be the most effective strategy in this case. Given Moore's Law an adversary able to attain enough hashing power to successfully mount a 51% attack would want to do so as soon as possible, lest their hardware becomes obsolete before they even scratched the blockchain.

Either way it all breaks down to: If someone is able to gain Bitcoin's majority hashrate and is willing to attack it, Bitcoin's fucked. But that's neither something new, nor something that can be easily fixed with currency issuance tweaks.



Obviously one possible outcome is the one you describe -- miners try to keep the hashrate at current levels or above.

Another imaginable outcome however would be a negative feedback loop, with miners either leaving Bitcoin for a competing blockchain or being taken offline as profitability plummets.

With the current system, as soon as Bitcoin becomes less profitable to mine, miners drop off and difficulty is reduced, with the hashrate finding a new equilibrium. If the mining reward is reduced with a drop in difficulty, Bitcoin becomes even less profitable to mine, with more and more miners leaving as block reward is further and further dynamically reduced, creating the very pool of "spare" hashing power that the difficulty-dependent-block-reward is trying to avert.

From what we've seen so far, miners already have the implicit incentive to keep adding hashrate. Adding complexity to a system that works just as good, if not better, with simpler rules, rarely works out well. Especially if it depends on miners working together for the common good (ie. "let's keep the hashrate growing or else the block reward gets reduced") rather than doing what is most profitable for them.

Well, they obviously could be possible, but they won't be viable and probably extremely costly. The miners that didn't conspire will find themselves with a proportionally larger share of the network. = more profits. As stated above^ -- Which means that you'll need a 51% attack to cut them out to really have any efffect.

A 51% attack ( which would be needed to mine at a smaller cost with less energy consumption efficiently will probably also be significantly more difficult for the involved parties (As they removed 50% of their hashpower in this hypothesis. - Right?)) and doing so is basically burning your own fingers -- since the price of bitcoin will probably drop enormously if there were to be such an attack = reduction in profits. I doubt that the money which is spared in using less energy/electricity covers those losses.

I simply don't see how you could ever make a profit doing this when you have (bought) so much hashing power. (100.000's of Antminers). Unless you were somehow able to short bitcoin itself for billions.


Doing so would effectively destroy the eco system and thus their mining equipment in which some of them probably invested billions. This would be driven by malice, not by trying to make a profit.

@HeReTiK you have good points, but it still doesn't show that these attacks are not possible, and what if suddenly we find ourselves operating at 50% the hashrate of peak hashrate of the year, what do we do? Wouldn't that be suspicious that not all miners are making use of their resources and there is some spare mining power ready to deploy an attack at any time. If your hypothesis is right that miners are always mining close to peak, then we wouldn't have to worry about the effects of such a protocol change because it would only take effect if hashpower is significantly less than peak. So I think it's worth an analysis.

My feeling is that without such a rule the pressures miners to stay at peak hashrate, they will get a bit lazy, use less of their energy on Bitcoin, and provide an opening for selfish mining or (33%) or 51% attacks. And it can take just one such attack to damage the reputation of bitcoin, and that would be a snowball effect that lowers the hashrate more (because of lower price) and makes more such attacks possible. Better to close those holes in my view, but I can post it to the list to see what others think.

Cooperation is only a viable strategy if no one defects.

Looking at PoW, anyone who agrees to not increase their hashrate further will get fucked over by those that are either (a) not part of the agreement or (b) part of the agreement but decide to increase their hashrate covertly.

PoW, pretty much by design, does not reward cooperation. It rewards putting as much hashpower as possible on the network, especially as economics of scale kicks in. It rewards securing the blockchain instead of attacking it, by means of opportunity cost.

The optimal strategy gets a bit wonky in systems with increased block reward variance (eg. post-block-subsidy Bitcoin), but that's a different discussion altogether.



Global markets don't work that way though. Price fixing barely works under totalitarian communism on a national scale, let alone within a capitalistic free market on an international scale.

Governments are barely able to figure out trade agreements. Fiat currencies fluctuate in relation to one another. Many -- if not most -- power plants are privately owned.

Even if 99% of governments would manage to arbitrarily increase electricity cost, the remaining 1% of governments would simply get rich by all the mining operations moving there.



Peak hashrate is being pushed as is, because keeping "spare" hashrate is simply wasted capital that could be put to work instead.

http://seclists.org/fulldisclosure/2012/Feb/0

I revert to this OLD post regarding exploit that could have allowed something like this to occur.

A powerful attacker could definitely exploit this; timestamps in the future are rejected and Bitcoin won't generally accept a version of history in which time goes backwards, but otherwise a 51% attacker can choose whatever timestamps they like and can delay releasing their version of the chain to meet the "less than 10 seconds" requirement.  (note screenshots up to 45 sec)

It's a very expensive attack but far from impossible.

I cannot find where this change was made to allow timestamps in the future.  
But it was never allowed in the early versions of the software.

More funny commits i guess.

*edit*  https://github.com/bitcoin/bitcoin/commit/b14bd4df58171454c2aa580ffad94982943483f5

@MagicByt3 says:
A few seconds into the future is normal. Clocks aren't perfectly syncronized to the second and the Bitcoin Core software accepts blocks up to 2 hours in the future. Timestamp attacks are a different issue from selfish mining I believe, and there's various strategies. When you measure the time from block 0 to block 2016, you are just using 2 blocks to measure the time so if there are a few blocks with 2 hour in the future timestamps in between, they will get canceled out. There are also strategies (I don't think yet implemented by Bitcoin) to measure initial and final times (for purposes of difficulty adjustment) using "median time past" i.e. the median time of the past 11 blocks. This diffuses the effects of timestamp attackers even more.