Bitcoin Forum
May 12, 2021, 12:30:44 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Solving Selfish/Colluding Mining  (Read 605 times)
onelineproof
Member
**
Offline Offline

Activity: 100
Merit: 14


View Profile WWW
September 08, 2018, 06:51:28 PM
Last edit: September 09, 2018, 09:19:25 PM by onelineproof
Merited by vapourminer (1)
 #21

Quote from: HeRetiK
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
Would be good to see how that pie chart changed before the rise and after (August 25 and August 27)

Quote from: HeRetiK
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.

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.

Quote from: HeRetiK
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 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.

The uncorrupted Bitmark protocol: https://github.com/bitmark-protocol/bitmark
Email <my username>@gmail.com 0xB6AC822C451D63046A2849E97DB7011CD53B564
1620822644
Hero Member
*
Offline Offline

Posts: 1620822644

View Profile Personal Message (Offline)

Ignore
1620822644
Reply with quote  #2

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

Activity: 100
Merit: 14


View Profile WWW
September 09, 2018, 10:49:12 PM
Last edit: September 12, 2018, 08:29:21 PM by onelineproof
 #22

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.

The uncorrupted Bitmark protocol: https://github.com/bitmark-protocol/bitmark
Email <my username>@gmail.com 0xB6AC822C451D63046A2849E97DB7011CD53B564
funkenstein
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


Khazad ai-menu!


View Profile WWW
September 13, 2018, 04:02:23 AM
 #23

With 50% of the hashrate you're not Selfish Mining anymore; you're effectively able to take over the network since you now can outrun the other miners indefinitely.
I totally agree and that's why this kind of attack is not really a viable threat, because if you need 50% hashrate you can do whatever you like.

I found this realistic model of selfish mining (as opposed to hypothetical theoretical models):


Source: https://medium.com/@ProfFaustus/the-caner-that-is-the-selfish-mining-fallacy-ed65c20a6ce7

where we can see that the selfish miner revenue (orange line) surpasses the honest miner (blue line) revenue very close to 50 percent hashrate.

If that's so, no point even discussing this kind of attack.



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

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


"Give me control over a coin's checkpoints and I care not who mines its blocks."
http://vtscc.org  http://woodcoin.info
onelineproof
Member
**
Offline Offline

Activity: 100
Merit: 14


View Profile WWW
September 15, 2018, 06:39:20 PM
 #24

With 50% of the hashrate you're not Selfish Mining anymore; you're effectively able to take over the network since you now can outrun the other miners indefinitely.
I totally agree and that's why this kind of attack is not really a viable threat, because if you need 50% hashrate you can do whatever you like.

I found this realistic model of selfish mining (as opposed to hypothetical theoretical models):


Source: https://medium.com/@ProfFaustus/the-caner-that-is-the-selfish-mining-fallacy-ed65c20a6ce7

where we can see that the selfish miner revenue (orange line) surpasses the honest miner (blue line) revenue very close to 50 percent hashrate.

If that's so, no point even discussing this kind of attack.



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

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



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.

The uncorrupted Bitmark protocol: https://github.com/bitmark-protocol/bitmark
Email <my username>@gmail.com 0xB6AC822C451D63046A2849E97DB7011CD53B564
dioncodot
Member
**
Offline Offline

Activity: 61
Merit: 10


View Profile
September 15, 2018, 08:05:36 PM
 #25

With 50% of the hashrate you're not Selfish Mining anymore; you're effectively able to take over the network since you now can outrun the other miners indefinitely.
I totally agree and that's why this kind of attack is not really a viable threat, because if you need 50% hashrate you can do whatever you like.

I found this realistic model of selfish mining (as opposed to hypothetical theoretical models):


Source: https://medium.com/@ProfFaustus/the-caner-that-is-the-selfish-mining-fallacy-ed65c20a6ce7

where we can see that the selfish miner revenue (orange line) surpasses the honest miner (blue line) revenue very close to 50 percent hashrate.

If that's so, no point even discussing this kind of attack.



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

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



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.
Sounds like it is enabling powerful individuals to dominate the market...Yet another reason not to use shitcoincash
fyff
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
September 16, 2018, 02:20:43 AM
 #26

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

Activity: 100
Merit: 14


View Profile WWW
September 17, 2018, 04:56:59 PM
 #27

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.


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.

The uncorrupted Bitmark protocol: https://github.com/bitmark-protocol/bitmark
Email <my username>@gmail.com 0xB6AC822C451D63046A2849E97DB7011CD53B564
funkenstein
Legendary
*
Offline Offline

Activity: 1064
Merit: 1022


Khazad ai-menu!


View Profile WWW
September 18, 2018, 07:54:16 PM
 #28


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

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



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.

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.   

"Give me control over a coin's checkpoints and I care not who mines its blocks."
http://vtscc.org  http://woodcoin.info
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!