Topic: Is Bitcoin infrastructure too Chinese? What should be done technically? - page 3. (Read 1126 times)

Smart move, though I don't believe in hypes regarding magical power of ASIC designers to crack every algorithm. A well designed memory hard algo won't be an easy piece of cake to bite, imo.

Well said.

It's not good to have an exact algorithm planned out, since then someone could make an ASIC for it in advance.

Current consensus seems to be that in case of a miner attack, something based on SHA-3 would be used, since it's very similar to SHA-2 and therefore a minimally-significant change. There's an old sample pull request. It should be modified slightly at the last minute to ensure that there are no stockpiled ASICs for it, though; for example:

That's just an example of how you'd try to do something a bit different to ensure that nobody has any stockpiled, maybe-somewhat-configurable ASICs hidden up their sleeves.

It'd be nice if there was a defined procedure for selecting one quickly. The exact algorithm isn't that important as long as nobody knows it in advance and it keeps the necessary properties for a PoW, but you don't want to waste time arguing about it. Maybe you'd have the interested devs write down their suggested algorithms, confirm that they all look reasonable, select two using verifiable randomness, compose or mash-up the two selected, and then fill in any random constants in the algorithm with new verifiable randomness.

Some have proposed automatically generating new PoWs, but then it's still possible to design ASICs which can adapt to the general random scheme. For example, you could have the PoW be sha3(concat(random_salt, sha3(in)) where random_salt automatically updates every year or whatever based on the hash of a block 1000 blocks deep, but then people would just design an ASIC which can accept a configurable random_salt.

Preparedness could be a lot better. I especially advocate for the creation of a clear set of criteria which indicate miner abuse so that they don't get away with something very incremental like freezing "obviously stolen" coins.


I've heard that before, maybe on the mailing list. Not a bad idea IMO. IIRC it can also be done as a softfork if miners are cooperative.

Obviously, we are not aligned.

I afraid your argument is vague and in complete contradiction with bitcoin axioms. If centralization is inevitable, then the whole cryptocurrency agenda is doomed. It has always been and should be considered an anti-bitcoin discourse and sounds like some ideological point of view rather than a concrete technical perception.

Bitcoin is in the first stages of its journey, I strongly believe that after the upcoming hard fork evidences that now temporarily support your claims will be cleared out and we will have another decade of glorious developments until the next fork, perhaps in 2030 which is highly possible to become necessary for newer challenges that we have no clue about them right now.  

If Chinese are the ones who create the ASICs and the ones who run the biggest mining farms, then of course they are the ones who more power over the coin, but i don't see it as something bad, i mean, at least someone needs to do it. The bitcoin mining complexity grows day by day and it was a challenge for the engineers to create those mining machines with more than 10Thz of mining power.

So, the mining will not stop, and if China doesn't take the control of this business, someone will do it, that's a fact.

I absolutely support this argument.
Although rationally calculated self-interests of players is a vital theoretical support for security of bitcoin, we should be aware of complexities involved.
Things change so fast and, as the paper correctly has established it, adversarial incentives are getting stronger while centralization of mining is reducing the collusion costs to dangerous thresholds. SO, WE SHOULD BE PREPARED.

Miners would go after their profits if bitcoin mining scene was decentralized and it is possible to improve this factor significantly. We need ASICS for at least  next 2-3 years and I don't think we are in a deep antagonistic contradiction with miners, it is rather about pools and pools, my friend, should be extinguished..

My suggestion is a double attack simultaneously being triggered against pools and ASICs but with different approaches regarding each of them:
Pools should be eliminated from the very first day of the fork but ASICs should be retired with a very small sleepness.

Elimination of pools, sets a huge amount of mining power free and distributed and ready to choose their profits against politics,  they should not be slaughtered by a preemptive anti-ASIC fork, instead I suggest a long term mutual co-existence of both algorithms using a double algorithm/double difficulty system which in long term is biased against ASICs, strictly defined by a constitutional rule.

How about start by prepare guide/reference client in-case hard-fork is needed? Reflecting from Bitcoin-Qt 0.8.0 accident (which is accidental hard-fork due to different DB version), that would help community/developer where to start solve the problem.


I think that won't happen since IMO Chinese miners would rather connect to pool outside China rather than let block orphan happen which could hurt many pools and potential FUD/price crash due to high block orphan.


ProgPoW already exist (https://github.com/ifdefelse/ProgPOW) and looks like developed well from commit/contributor number, but the hardest part is making sure existing miners won't do anything crazy such as boycott or attack network knowing MAD situation.

@theymos, thanks for the contribution (and the merits by the way). I'm seriously delighted seeing prominent bitcoin figures are so much concerned about this issue.  

Actually, I was somewhat disappointed and confused if not frustrated about why the situation with ASICs and pools is simply overlooked or its severity is underestimated at best.

As I understand you are more concerned about ASICs and although I share a lot in this regard with you,  I'm sure you know far better than me how sophisticated would be an Anti-ASIC hard fork:

From a pure technical view point, unlike what most people in bitcoin ecosystem are used to say, implementing an Anti-ASIC algorithm and integrating it into bitcoin, is not impossible or that hard. We have ProgPoW and a few talented people who could offer even more effective alternatives. But for bitcoin such a transition is not feasible overnight. Nobody would be happy, security will drop, price will drop, ... a lot of chaotic consequences are predictable and should be addressed. Nobody is interested in following the path bitcoin Gold went through.

I have this idea for a long time, a 2-way concurrent PoW algorithm with a 2-3 years smooth migration from ASICs to the alternate cpu/gpu PoW method e.g. ProgPoW. I'm thinking of starting with a 10:1 ratio in favor of sha2 ASICs and a gradual transition to 1:10 ratio against them.

But as we have already experienced with SegWit reaching to a consensus and adopting above or any other hypothetical solution raises another challenge: Pools.

I have written too much about pools, among them in An Analysis of Mining Variance and Proximity Premium flaws in Bitcoin, I have mathematically proved that as long as we are trapped in bitcoin's winner_takes_all approach to mining the resulting Bernoulli distribution pushes miners toward pooling.

Pools are evil but when they are concentrated in China, you have serious problem. I have drafted a framework for improving this situation, Proof of Collaborative work (PoCW), based on a new implementation of PoW which is no longer winner_takes_all.

Conclusively speaking, I believe we are able to fix the issue with Chinese by a double attack: getting rid of pools and imposing a gradual transition to an ASIC-resistant algorithm.

I have translated a similar and more complete response by theymos in the local Portuguese board.
If anyone ia interested. This is the original https://www.reddit.com/r/Bitcoin/comments/7zvit8/cobra_miners_are_evil_we_need_to_get_rid_of_them/dus9tuq/

And the translation
https://bitcointalk.org/index.php?topic=5047678.new#new

This runs both ways though. With the majority hashrate presumably being located in China it may very well be that using increased block weight as a weapon would merely lead to an increased orphan rate in Europe and the Americas, further strengthening China's position.



Is there any agreement on how such a PoW change would be implemented and what code of conduct would be followed? For example how a new PoW scheme would be selected. I presume some thoughts has already been put into it, beyond merely considering the option.

Skimming it, it seems like a good summary of stuff that's been discussed around here for years.

AFAIK a lot of mining has moved out of China geographically due to Chinese government crackdowns, though a lot is still owned by Chinese companies. That said, the specific country doesn't matter much: I don't distrust the Chinese government all that much more than the EU in this area, for example. The main issue is geographical centralization and mining centralization in general.

The location of the physical mining hardware is more important than pool management location, since miners can change their pools. I don't know much about the distribution of mining hardware, though.

If a majority of mining power tries anything, then the only correct response is an immediate hardfork to change the PoW. I don't think that anyone disagrees with that.

Some notable people have long advocated changing the PoW preemptive to any actual attack because of too much centralization already. However, there is no known long-term solution to mining centralization. (This has been discussed to death on the forum and elsewhere.) It's not clear that an anti-ASIC algorithm is possible, and even if it is, that'll probably just allow for different monopolies (eg. Intel, botnet operators, or others). Changing to a different ASIC-friendly algorithm may well increase centralization after a while, since the big mining companies (eg. Bitmain) are big because they're the best at making mining chips, so they'll probably end up having a first-to-market advantage on new ASICs. You can prevent trustless pooling, but that'd mostly just force people to use even-more-centralized trusted pooling, which isn't preventable AFAIK. So preemptively changing the PoW will temporarily fire the current miners, but at best it'll make the problem no better long-term, and it'll almost certainly result in a persistent fork which will do a lot of damage to Bitcoin.

Currently we have a sort of mutually assured destruction situation. If there's a preemptive PoW change, then that'll make a huge, not-worthwhile mess (though survivable). But if miners do an attack, then there will be an immediate PoW change, firing them and at least forcing them to start over from scratch hardware-wise. This MAD situation could maybe be considered quite solid if all actors were rationally self-interested, though authoritarian regimes can get in the way of rational self-interest. Still, I think that this is reasonably stable, and the best we can do for now. To strengthen the MAD and prepare, I encourage people to be as ready and threatening as possible in case an immediate PoW change becomes necessary: for example, I've said several times (and I mean it) that if the Bitcoin Core devs fail to respond adequately to a miner attack, I'll propagate the necessary hardfork myself. But I oppose a preemptive PoW change unless there's some sort of new long-term solution.

I still think that my 3-way hybrid PoW could work, but a lot of people disagree.

@ETFbitcoin, appreciate your comment (and the merit by the way), let's wait a while and have more ideas shared by other guys, obviously I have a few too 

As of your last comment, yes, I read as much as I could find, especially when it comes to critical issues, no choice.

Hi,
I just read this academic  paper, authors are suggesting that Bitcoin is in danger of being compromised by Chinese government because of ASICs and pools.

I have been championing against ASICs and pools for a while and as of my experience when it comes to any serious improvement to bitcoin and it has to be done by a hard fork an army of 'legendary' shills are ready to make it almost impossible to discuss anymore.

But we have hard-fork-wishlist, discussing an issue won't fork the chain, actual forking does! So, I politely ask these guys to give us a break and let us to have a productive discussion about whether or not we could do anything, any technical improvement obviously, to deal with what the authors are pointing out?