If Core had to hard fork and use another mining algorithm, what would it be?

[ChromaticStar]

I don't have much technical experience and I've never mined before. From everything I've been reading on the technical forums, the 2x chain is not in any way "Bitcoin." At this point, with a fork almost inevitable, would it be worth it to buy a GPU miner, learn to use it and support the Core backed chain when the network splits in November?

It's a bit of a financial gamble at this stage, as the change of algorithm isn't set in stone.  If there are any GPU-mineable altcoins you wouldn't mind accumulating as a fallback, then go for it.  But if you have your mind set on Bitcoin, wait until the change of algo is confirmed.  GPU miners don't really touch the sides as it were while the ASICs are still in play.

I'm sort of under the assumption that a change in the algo must occur. With so much hashing power on the miner backed Segwit2x chain, it is in their interest to ensure that their chain survives. Therefore, they must 51% attack the Core chain to kill it. The only way the Core chain can survive is if they change to an ASIC proof algo, which Maxwell has stated he will support if he has to. Is this correct?

[1713558733]

1713558733

[1713558733]

1713558733

[Searinox]

Whatever it would be, it should be geared towards ASIC resistance and promoting a more even playing field between entities of different computing budgets. I'd wager a variant of bcrypt or scrypt would be it. I remember Vertcoin tried something of the sort. I think their variant was called Lyra.

[ChromaticStar]

Whatever it would be, it should be geared towards ASIC resistance and promoting a more even playing field between entities of different computing budgets. I'd wager a variant of bcrypt or scrypt would be it. I remember Vertcoin tried something of the sort. I think their variant was called Lyra.

Yes, I've been think of moving into VERT for this very reason, but if core is going to switch to an ASIC-proof chain, then VERT effectively becomes obsolete.

[DooMAD]

I don't have much technical experience and I've never mined before. From everything I've been reading on the technical forums, the 2x chain is not in any way "Bitcoin." At this point, with a fork almost inevitable, would it be worth it to buy a GPU miner, learn to use it and support the Core backed chain when the network splits in November?

It's a bit of a financial gamble at this stage, as the change of algorithm isn't set in stone.  If there are any GPU-mineable altcoins you wouldn't mind accumulating as a fallback, then go for it.  But if you have your mind set on Bitcoin, wait until the change of algo is confirmed.  GPU miners don't really touch the sides as it were while the ASICs are still in play.

I'm sort of under the assumption that a change in the algo must occur. With so much hashing power on the miner backed Segwit2x chain, it is in their interest to ensure that their chain survives. Therefore, they must 51% attack the Core chain to kill it. The only way the Core chain can survive is if they change to an ASIC proof algo, which Maxwell has stated he will support if he has to. Is this correct?

The big question is if all that hashing power actually does support 2x, or if some of the pools are just waiting to see who blinks first.  Many here are still predicting a domino-effect where one big pool drops their support and then others swiftly follow.  Or, if it ends up like BCH did, where the miners were just pointing their hashpower at whichever chain happened to be more profitable at any given moment, the hashrate could be more evenly split.  In that situation, there may not be adequate surplus hashrate to maintain the 2x chain while simultaneously performing the 51% attack.  There are still quite a few permutations on how this could all play out. 

But yes, if a significant majority of hashrate really does turn out to be supporting 2x and the SegWit-Only chain is struggling to propagate, an algo change would indeed be a wise choice.

Whatever it would be, it should be geared towards ASIC resistance and promoting a more even playing field between entities of different computing budgets. I'd wager a variant of bcrypt or scrypt would be it. I remember Vertcoin tried something of the sort. I think their variant was called Lyra.

The other thing for everyone to bear in mind is that 'ASIC-resistance' will only ever be temporary if there is still sufficient incentive to mine the SegWit-Only chain.  There's no such thing as 'ASIC-proof'.  The reason Vertcoin's ASIC resistance is currently a safe bet is because Vertcoin isn't as big a draw as Bitcoin.  Let's be frank here, a sub-$40 million market cap and barely being in the top 100 coins simply doesn't attract the same level of hardware related research money.  So naturally there will be less funding towards developing dedicated chips for that Lyra algorithm.  Whichever algo the Core devs select will be thrust into the spotlight and the money will come flooding in to develop chips for that algo (again, providing there is still sufficient incentive to use the SegWit-Only chain).  Hence my thinking it might be in idea to use more than one algo, just to slow ASIC development as much as possible and keep the playing field level for a bit longer.

[ChromaticStar]

I don't have much technical experience and I've never mined before. From everything I've been reading on the technical forums, the 2x chain is not in any way "Bitcoin." At this point, with a fork almost inevitable, would it be worth it to buy a GPU miner, learn to use it and support the Core backed chain when the network splits in November?

It's a bit of a financial gamble at this stage, as the change of algorithm isn't set in stone.  If there are any GPU-mineable altcoins you wouldn't mind accumulating as a fallback, then go for it.  But if you have your mind set on Bitcoin, wait until the change of algo is confirmed.  GPU miners don't really touch the sides as it were while the ASICs are still in play.

I'm sort of under the assumption that a change in the algo must occur. With so much hashing power on the miner backed Segwit2x chain, it is in their interest to ensure that their chain survives. Therefore, they must 51% attack the Core chain to kill it. The only way the Core chain can survive is if they change to an ASIC proof algo, which Maxwell has stated he will support if he has to. Is this correct?

The big question is if all that hashing power actually does support 2x, or if some of the pools are just waiting to see who blinks first.  Many here are still predicting a domino-effect where one big pool drops their support and then others swiftly follow.  Or, if it ends up like BCH did, where the miners were just pointing their hashpower at whichever chain happened to be more profitable at any given moment, the hashrate could be more evenly split.  In that situation, there may not be adequate surplus hashrate to maintain the 2x chain while simultaneously performing the 51% attack.  There are still quite a few permutations on how this could all play out.  

But yes, if a significant majority of hashrate really does turn out to be supporting 2x and the SegWit-Only chain is struggling to propagate, an algo change would indeed be a wise choice.

Whatever it would be, it should be geared towards ASIC resistance and promoting a more even playing field between entities of different computing budgets. I'd wager a variant of bcrypt or scrypt would be it. I remember Vertcoin tried something of the sort. I think their variant was called Lyra.

The other thing for everyone to bear in mind is that 'ASIC-resistance' will only ever be temporary if there is still sufficient incentive to mine the SegWit-Only chain.  There's no such thing as 'ASIC-proof'.  The reason Vertcoin's ASIC resistance is currently a safe bet is because Vertcoin isn't as big a draw as Bitcoin.  Let's be frank here, a sub-$40 million market cap and barely being in the top 100 coins simply doesn't attract the same level of hardware related research money.  So naturally there will be less funding towards developing dedicated chips for that Lyra algorithm.  Whichever algo the Core devs select will be thrust into the spotlight and the money will come flooding in to develop chips for that algo (again, providing there is still sufficient incentive to use the SegWit-Only chain).  Hence my thinking it might be in idea to use more than one algo, just to slow ASIC development as much as possible and keep the playing field level for a bit longer.

I get the feeling that if Core were to change the algo to stop the ASICs, that would pretty much kill their authority to rule BTC ever again. Who would ever invest in an ASIC miner with the threat of an algo change that can render it useless? I don't care if someone builds an ASIC miner, but it is the public/users that should have authority over BTC, not miners.

It is really hard to say how it will all turn out. Without replay protection, both chains are vulnerable. A number of miners will probably just mine the most profitable chain, but I hope Core has contingency plans built in to change the algo right away and we'll be back to GPU mining.

Would an algo change provide inherent replay protection?

[DooMAD]

I get the feeling that if Core were to change the algo to stop the ASICs, that would pretty much kill their authority to rule BTC ever again. Who would ever invest in an ASIC miner with the threat of an algo change that can render it useless? I don't care if someone builds an ASIC miner, but it is the public/users that should have authority over BTC, not miners.

It is really hard to say how it will all turn out. Without replay protection, both chains are vulnerable. A number of miners will probably just mine the most profitable chain, but I hope Core has contingency plans built in to change the algo right away and we'll be back to GPU mining.

Would an algo change provide inherent replay protection?

Well for starters, Core don't have the "authority to rule BTC".  It's almost a given that users would be open to a change in algorithm if the alternative was having stuck transactions due to an overall hashrate too low for the current difficulty.  Users would therefore be happy to run the new code, so it's not a case of the Devs ruling over anything and the decision would be equally influenced by Devs and Users.  And the very notion of a change of algorithm wouldn't be on the table unless it was absolutely necessary.  Developers wouldn't be pushing it on an unwilling community just for the sake of it.

I think it's safe to say that the entire idea behind the change in algorithm is to deter ASICs and render them useless.  It's very much a 'nuclear option' and last resort.  But that's just indicative of how far things have escalated in this dispute.

//EDIT:  I realise I've probably misinterpreted that first part.  You meant the miners' supposed ability to rule over BTC.  But I'd argue equally with that stance too.  Miners, Users and Devs all generally have an equal share in the balance of power in that one can't accomplish much alone without the others.
//

If it were implemented early enough, it would indeed drive a firm wedge between the two chains and provide inherent replay protection, but it remains to be seen how quickly the change of algorithm would be activated.  I think everyone will want to tread carefully considering the magnitude of the change.

[manselr]

Well for starters, Core don't have the "authority to rule BTC".  It's almost a given that users would be open to a change in algorithm if the alternative was having stuck transactions due to an overall hashrate too low for the current difficulty.  Users would therefore be happy to run the new code, so it's not a case of the Devs ruling over anything and the decision would be equally influenced by Devs and Users.  And the very notion of a change of algorithm wouldn't be on the table unless it was absolutely necessary.  Developers wouldn't be pushing it on an unwilling community just for the sake of it.

I think it's safe to say that the entire idea behind the change in algorithm is to deter ASICs and render them useless.  It's very much a 'nuclear option' and last resort.  But that's just indicative of how far things have escalated in this dispute.

//EDIT:  I realise I've probably misinterpreted that first part.  You meant the miners' supposed ability to rule over BTC.  But I'd argue equally with that stance too.  Miners, Users and Devs all generally have an equal share in the balance of power in that one can't accomplish much alone without the others.
//

If it were implemented early enough, it would indeed drive a firm wedge between the two chains and provide inherent replay protection, but it remains to be seen how quickly the change of algorithm would be activated.  I think everyone will want to tread carefully considering the magnitude of the change.

Well for starters, you are assuming a lot of things that "users" would want. Would users want a centralized network due big blocks? don't think so.

In any case, do users have big blocks already? Yes, they have BCash. Are users moving from BTC to BCash? Nope, no one uses that shit, even if the transactions are very cheap, it's not worth it because the developers are retards and all the smart people are working in Core, and when it comes to money, you want the smartest people to be developing the software that is the backbone for the network you are depositing your money at, not to mention BTC is now very cheap to transact with segwit and no Roger and Jihad spam. And if there's a way to test what users want, is to see if they want the big blocker fork and they do not, so stop assuming everyone using Coinbase or whatever are supporting the segwit2x scam when they don't even know about it.
Let's see if they like how the segwit2x scammers crash the market in November due causing yet another unnecessary fork as holders suffer from it.

[DooMAD]

Well for starters, Core don't have the "authority to rule BTC".  It's almost a given that users would be open to a change in algorithm if the alternative was having stuck transactions due to an overall hashrate too low for the current difficulty.  Users would therefore be happy to run the new code, so it's not a case of the Devs ruling over anything and the decision would be equally influenced by Devs and Users.  And the very notion of a change of algorithm wouldn't be on the table unless it was absolutely necessary.  Developers wouldn't be pushing it on an unwilling community just for the sake of it.

Well for starters, you are assuming a lot of things that "users" would want. Would users want a centralized network due big blocks? don't think so.

I think my misinterpretation is snowballing.  I thought ChromaticStar meant they were worried that Core were overstepping their boundaries by proposing an algo change, but I understand now that it's not what was meant at all.  I was saying that users would be happy to support the change of algorithm if it came to it, not increase the blocksize.  That remains to be seen.

[d5000]

You don't get it, you're thinking in snapshots. The moment when some group of upstart ASIC producers make a Scrypt miner is not somehow frozen in time forever.

I wasn't talking about new Scrypt miner manufacturers but about a new manufacturer of a new ASIC developed for a "fancy ASIC resistant algorithm". This player could ensure a competitive advantage for a long time, and if it accidentally happens to be Bitmain, we have won nothing.

ASIC makers, irrelevant of their size when they begin their business, have an incentive to gouge their prices to bestow their own personal mining operations with an unassailable competitive advantage.

The actual solution is to choose a PoW hashing algorithm for which no-one has an ASIC design, thereby allowing regular users to use standard equipment to compete more effectively against warehouse scale mining operations. Algorithms that allow regular people to use standard, non-specialised equipment are the key to decentralising the hashrate.

I actually agree here - that would be a nice Utopian vision - but I think it is not realistic. It's a matter of time when the first ASIC will be produced, regardless of the algorithm, because the potential to get the first mover bonus is too high. And once that happens, then we have all the problems you see with Scrypt, but even worse because the first mover will have an extremely big advantage and could impose his agenda at will.

OK, one could do an analysis of the Scrypt miner market (I didn't do it, maybe I should ) and if the dominance of Bitmain in this sector is too strong or there is another mining hardware manufacturer with a near-monopolic position in that market, then that may be a point against Scrypt.

Actually, it would be ideal to choose an algorithm where there are already ASICs available but none of the current big hardware producers (Bitmain etc.) have a dominant position. I am, however, not sure if such an algorithm does exist.

[Carlton Banks]

*sigh*


I think using a series of hashing algorithm that alternates randomly from a larger set is probably the way to go. There's no feasible ASIC for that, although I guess FPGA rigs could be introduced that could be re-programmable to the latest series size/combo might be feasible. Hard to see how that setup would be as flexible as just using a standard PC, but there are processing efficiency gains still. Maybe anyone doing that should pray that a random length of time for the hashing series switching interval isn't introduced too


So there is no manufacturers advantage, given that changes to the PoW hashing scheme are carefully thought through (in before some other smart mouth says "that sounds too complicated, confidence etc". If it's too complicated for you, go home, you came to the wrong place already)

[d5000]

Okay, I thought about that solution too. As far as I understand the matter, the set of hashing algorithms would have to be large enough to make it unfeasible to produce ASICs for every single algorithm of that series. Such a "PoW concept" surely could work for some time, but I think even then it would be a matter of time until at least for some of the algorithms ASICs are developed, and some miners would set up specialized farms to mine only the blocks of the algorithm they have hardware for. That may be, however, less efficient for them (considering hardware manufacturing costs) than simply to use FPGAs.

Maybe the algorithms could be changed regularly to newer ones, that would dis-incentive ASIC development.

[Skylake]

im still not understand, why bitcoin need separate the network? its just to make more money? just for creat new altcoin then the holder bitcoin will get extra money from forking chain?
for me bitcoin (pure bitcoin from nakamoto) is enough to handle current transaction

[Carlton Banks]

Maybe the algorithms could be changed regularly to newer ones, that would dis-incentive ASIC development.

And maybe the interval between the changing of the hash series could be randomised. Keep thinking though.

[manselr]

Maybe the algorithms could be changed regularly to newer ones, that would dis-incentive ASIC development.

And maybe the interval between the changing of the hash series could be randomised. Keep thinking though.

Randomized algo changes seems like the way to go. I've seen this mentioned before and considered by reputable devs. If there is ever a bitcoin hardfork (a proper one, not one driven by scammers like Jeff Garzik) I would like to see that. It seems like the only way to avoid massive monopolies. One would need to invest so much money on research and stacking of every single algo to keep being the leader ever under several different algos, that i think it's unlikely the same player would always have the advantage.

[d5000]

Maybe the algorithms could be changed regularly to newer ones, that would dis-incentive ASIC development.

And maybe the interval between the changing of the hash series could be randomised.

You seem to propose to have a large set of algorithms in which randomly sub-sets are elected, and from this sub-set every block the algorithm is chosen. What would be the advantage to simply elect one from the entire set in every block? Perhaps it could be more efficient? (Serious question.)

What I meant here is that every couple of years the set is updated manually by the developers, including newly developed algorithms, and "banning" algorithms where ASICs have been developed. That cannot be done automatized until we have a (un-gameable) super-AI that elects the new algorithms for us . Probably, however, that would mean more hard forks. The intervals between these hard forks could be randomised, but would that really make a difference?

[Carlton Banks]

No


A series of hash algos, the size of which is not fixed, is used for PoW.

The interval between the changes is random, whereby the constituents of the series, and it's size, are changed (within some sensible set of bounds).


A hard fork is needed to do all this anyway, so simply make the amorphous PoW definition a part of Bitcoin consensus. If PoW changes are part of the protocol, it's not a hard fork to follow the prototcol. You seem a little confused by the whole concept, frankly.

[d5000]

Now for me it's the turn to *sigh* ...

What you're saying here is the concept we were talking about, yes - pre-defining a set of algorithms which then are randomly used as PoWs (with random intervals, if you want). If I remember right there are many altcoins already using something like that.

But I suggested, as an improvement, to sometimes change the whole set of algorithms to dis-incentive the development of ASICs for some of the algorithms used in the set, and "ban" algorithms where already ASICs are available.

That is what only can be done manually, with code changes and (probably) only with a hard fork. It's only a suggestion, maybe it's unfeasible because of the necessity to hard fork the chain every couple of years.

(I know you didn't mean that, but: There could be a way to implement even this kind of algo change without hard forks, making such changes be "part of the protocol", but miners then could simply introduce their own favoured algorithms and we have the same problem than now, so I would discard this solution from the start.)

[Carlton Banks]

Well, I see what you mean there.


But it's likely to be a rare occurance. Randomised changes to the set and randomised series size are very severe deterrents to ASIC development anyway.

Smoothing out the problems with different hashing ASICs working in series would not be difficult, all that's needed is a way to make systematic implementations difficult. You're starting with sinking money into development of every single hash algo that's chosen for the hash set, and a modularised design to chain them together for when the series changes. This really causes problems for large mining operations, as the need for storing unused hashers multiplies by the size of the hash set chosen for the series. And any design decisions taken to make a modularised interconnect for hashing units more difficult will surely be taken. And for every (randomly intervalled) change to the hashing series, the hashers need to be physically reseated, lest valuable space in the infrastructure situated mining centers gets wasted. All only until the random interval changes the series again.

That's a far more difficult development problem than a hashing ASIC, and a commensurately significant investment. And clearly difficult to operate at all efficiently. And your point kills the idea off altogether, ironically; why limit changes to just the hashing algos when you could make other changes that cause further problems with the design of modular interconnects. There's nothing to stop periodic updates to the scheme to force the specialists to innovate an even more difficult design.

[BenOnceAgain]

I am most decidedly an outsider in these discussions, but I wanted to share my thoughts having read through this thread and some of the other discussions regarding this somewhat imminent issue.

I strongly believe that the Bitcoin Core team should do what it feels is best to advance its software.  Their track record speaks for itself, Bitcoin is the de facto standard in crypto for a reason -- sound decisions made by those in control of the code.  I think it's apparent that the user base has supported their vision for the currency as can be seen in the outcome of the recent BCC fork.

The idea to introduce added resilience to the standard by variable PoW algos is certainly a bold change.  From what I gather, part of the reason for doing so is because of a minority of actors, that represent a majority of the hash rate, being intent on forking over the 2x proposal.  It seems clear to me that they are only interested in their self-interest from a financial perspective.  While I can certainly understand that, I do not support decisions that solely take their own self-interest into account.  As a member of the Board of Directors of a few organizations, I often have had to make decisions that disadvantaged me from a personal/business perspective, but were the best decisions to make for the entity I was asked to make the decision for.  Not everyone can be selfless in this way, but it is part of the job when you accept a fiduciary duty to another organization.

I think if a change in algo is inevitable due to the circumstances, by all means make it as resilient as possible.  A programmatic approach to swapping algos, or a random use of multiple as is being discussed here, is a great idea in ensuring that a wider pool of users can practically participate in mining.  Of course, nothing is "ASIC-proof", but Carltons comments about the ASIC producers gouging prices for their own benefit is certainly the case if you look at the costs involved in producing the devices and the R&D resources, etc.  In some ways, the large concentration of mining power in so few hands, especially when those hands, in essence, control the means of production of the currency could be looked at as a form of "counterfeiting".  Not that their blocks aren't valid, but control over the most efficient means of production of the currency is a single point of failure/control over what is supposed to be a freer system.  The current system gives disproportionate control to a minority of entity.  As can be seen by this threat to fork the currency.

Whatever is decided should be done so transparently as possible and should be communicated to the user base as widely and as early as possible.  The impact of a decision of this magnitude has over the ecosystem is quite large.  From my perspective, it feels like it might be necessary to go this route.  If that is what the Core developers decide, its very important to communicate this clearly to users that are not as "tuned in" as others.  Without that, others will attempt to control the message and that will cause FUD.

For Bitcoin to remain the standard, it must sometimes make bold decisions that are in the best interest of long-term resilience.  I believe that this may be one of those times, and from reading what I've been able to about this issue, I am confident that the right things are being discussed and considered.

Thank you for putting those interests first.  I think it speaks volumes as to the integrity of your team.

[Wind_FURY]

With all the talk of "ASIC resistance" in the thread, here is a thought provoking question. Is the mining "industry" that was built around Bitcoin beneficial for its sustainability and longevity?

Like the crude oil industry, the whole world will not be able to drop it if it wanted to that easy because it is already embedded in the economy and has become a big part of society. Is Bitcoin going to be in the same position in the cryptocurrency world through the industries built around it?