Changing POW to Equihash (or other)

[HostFat]

Can "someone" (even anonymously) make a new branch of Bitcoin Core / Classic / XT / Unlimited with the POW changed to Equihash and then release it (the binaries and source code)?

It should be compatible with the current Blockchain of Bitcoin, but after the block X (like 2/3 weeks after the public release) it should be accept only blocks with Equihash POW.

I repeat, I'm not asking to change the todolist (Core / Classic / XT / Unlimited) and their long term goal, but only a single wild release, and see what will happen.

 

[freetrader]

I'm busy preparing a release which will use a modified Scrypt, based on the unmaintained satoshisbitcoin POW code. Does that count?

You will be able to compile a POW and a non-POW (no change) version from the same codebase.

 

[HostFat]

I was proposing Equihash because it is more botnet resistant (it is more difficult to hide because the large use of memory)
And Scrypt there are already the ASICs.

The idea is recreating the current situation (with the same history/blockchain), with all the forks, but on a more decentralized POW.

 

[freetrader]

I'm open to changing POW to Equihash (or something else) after the initial release, or even a regular basis. Others have suggested UTXO commitments or other schemes, which I'm not able to implement in short order.

That said, I'd be surprised if satoshisbitcoin's modified scrypt code has existing usable ASICs. Have you read the original discussion thread by @largerblocks / @rocks on this forum?

https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/

particularly the POW discussion from here on:

https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/#post-13838

 

[HostFat]

No I didn't read it, I'm going to.

Anyway, I think that it can be interesting to see if Equihash is even more ASIC resistant than even a modified Scrypt.

 

[freetrader]

P.S. if you are able to critique satoshisbitcoin's POW code (pow.cpp changes), I am very keen to hear comments. I put out a little request for review a while back, and didn't hear almost anything. I've not been able to spend time myself doing archaelogy of the code vs. the original scrypt sources from Colin Percival.

If you don't have time or interest, I understand as well.

 

[HostFat]

Maybe I can find the time, but I haven't the right knowledge
Whatever can limit ASIC and botnets is good!

 

[satoshis_sockpuppet]

I repeat myself, but an PoW using the UTXO set would be best imho.

Second best is @freetrader 's approach for now I think. And I'm already looking forward to mining Bitcoin

 

[Cconvert2G36]

I’ve generally opposed these things, but in light of recent events… I think we may be approaching the only time it would be worth attempting. Pursuing the fork should only happen upon hearing the news that miners are going to activate SFSW without any hard guarantee (in code) that a HF max_block_size increase comes with it.

It should activate at the moment that SFSW goes live on the network. [It will (maybe) consider segwit tx to truly be anyone-can-spend, lol.] The PoW should be as ASIC-resistant as possible, GPUs are the desired hardware, for now. It should be a spinoff, obviously, all balances held at the time of fork would be held on both chains. It should have a user/miner configurable soft-limit on max_block_size for generation, and a scheme similar to BU for decentralized block acceptance parameters. No attempt to thwart replayed transactions should take place at the protocol level, those who take action on the 1MB chain should have a (however economically slight) chance of being impacted by their decision on the forked chain.

I hate the idea that we’ve fallen this far down the rabbit hole (it wouldn’t be possible without the absolute intransigence employed by the centralized development team that Mr. Pair credits with good leadership).… The window of opportunity is vanishingly small, the stakes are gigantic. All other avenues have failed, key channels of communication compromised and poisoned by our own… we may never have the chance again, to see satoshi’s idea become a reality.

 

[freetrader]

@Cconvert2G36: I'm going to speak for my planned fork only here, ofc.
I consider activating prior to SWSF an important goal of my fork, but I will not attempt activating at the exact same time. We have considered activating at a certain "safety margin" w.r.t. SWSF, but it would require me taking more current BIP9 code onboard (I'm currently based of older 0.12), and the mainnet deployment parameters for SWSF are still TBD in BIP141, making it a guessing (rather: waiting for Core) game.

It also feels unnecessarily risky to make the forking contingent on precise SW activation, although I think I understand the motivation. My view is that those who wish to live on a SWSF-free fork will be prepared to fork off a little earlier, this can be achieved using a predictable block height that prevents risk and complexity. I think the key here is advance information - a good timeline between release of the fork code and its activation (again: speaking about my particular fork)

No attempt to thwart replayed transactions should take place at the protocol level, those who take action on the 1MB chain should have a (however economically slight) chance of being impacted by their decision on the forked chain.

This is an interesting POV - from my earlier discussions on this forum I got the impression that support for a protocol-level "clean fork" preventing replay attacks was very high. Indeed if not implemented at protocol level, I think that replay attacks would effectively destroy the market mechanism of fork arbitrage. Presumably you think that is not a bad thing, but I'd like to know more about your reasoning, and what others here think about this topic and the pros/cons.

One con that I can come up with against a fork which does not prevent replay attacks is that the additional risk that you mention will deter trade, i.e. harm existing economy. If people can rest safely in knowing what will happen when they make a trade on either chain, I think that's good for Bitcoin overall.
And it perhaps brings the reduces exposure to legal claims, in that you're taking active steps to limit the impact of your fork, and you can more accurately describe the behavior of the resulting system.

 

[Cconvert2G36]

@Cconvert2G36: I'm going to speak for my planned fork only here, ofc.
I consider activating prior to SWSF an important goal of my fork, but I will not attempt activating at the exact same time. We have considered activating at a certain "safety margin" w.r.t. SWSF, but it would require me taking more current BIP9 code onboard (I'm currently based of older 0.12), and the mainnet deployment parameters for SWSF are still TBD in BIP141, making it a guessing (rather: waiting for Core) game.

I should have prefaced by saying it was only my personal opinion of how, when, and why something like this could possibly be successful. I fully admit the possibility of being wrong. As I’m not coding it up, I’m in no position to be making demands as to its parameters, again, just imho.

It also feels unnecessarily risky to make the forking contingent on precise SW activation, although I think I understand the motivation. My view is that those who wish to live on a SWSF-free fork will be prepared to fork off a little earlier, this can be achieved using a predictable block height that prevents risk and complexity. I think the key here is advance information - a good timeline between release of the fork code and its activation (again: speaking about my particular fork)

Not at the trigger block when it’s locked in, but when it goes live, a substantial enough warning period. If ETH has offered a lesson… you can’t just fork at a random block height and have a credible movement, it needs to be done for a reason… That reason is the surreptitious and dramatic “soft” change to the underlying protocol of Bitcoin, without full node consent. The reason becomes a reality when SWSF goes live.

This is an interesting POV - from my earlier discussions on this forum I got the impression that support for a protocol-level "clean fork" preventing replay attacks was very high. Indeed if not implemented at protocol level, I think that replay attacks would effectively destroy the market mechanism of fork arbitrage. Presumably you think that is not a bad thing, but I'd like to know more about your reasoning, and what others here think about this topic and the pros/cons.

One con that I can come up with against a fork which does not prevent replay attacks is that the additional risk that you mention will deter trade, i.e. harm existing economy. If people can rest safely in knowing what will happen when they make a trade on either chain, I think that's good for Bitcoin overall.
And it perhaps brings the reduces exposure to legal claims, in that you're taking active steps to limit the impact of your fork, and you can more accurately describe the behavior of the resulting system.

Those at the forefront of fork arbitrage would split their coins, anyone concerned about the issue would split their coins before moving them to a key outside their control. They could keep them both. From my vantage point, the hubris of the ETH chain wrt to replay has only served the interests of the ETC minority chain. Those who care suffer no losses, those that ignore it are at risk, and those just peacefully hodling are hodling them both. I could be wrong here, but you aren’t trying to peacefully coexist with 1MB4EVA soft fork salad Gregcoin, you are trying to supplant it if necessary and desired by the market. I understand your point about deterring trade... but this isn't about being convenient or clean, it's more of a [Break Glass in Case of Emergency] option.

 

[freetrader]

Thanks for clarifying, I thought you meant SegWit's exact lock-in trigger. I didn't take your thoughts as 'demands', btw, this thread is a general one and anyone is free to make general suggestions of any kind at any time. I just went into more detail about our thoughts because my decision-making related to that had previously been restricted to private conversations (as far as I can remember, I don't feel like searching past threads).

Those at the forefront of fork arbitrage would split their coins, anyone concerned about the issue would split their coins before moving them to a key outside their control. They could keep them both.

The ETH fork has shown that this is difficult and error-prone. I don't see what's wrong with making it easier for everyone to exercise their will in this regard. The exchanges seem willing to help it along, and they should, since they make money off trading.

From my vantage point, the hubris of the ETH chain wrt to replay has only served the interests of the ETC minority chain.

With this I fully agree, although I don't know if it was hubris or negligence.
IMO they could and *should* have avoided the negative light that some can now cast on their fork.

Those who care suffer no losses, those that ignore it are at risk, and those just peacefully hodling are hodling them both.

This still holds when there is fork arbitrage, as far as I can tell. Am I wrong?

I understand your point about deterring trade... but this isn't about being convenient or clean, it's more of a [Break Glass in Case of Emergency] option.

I think we can have a clean fork AND keep confidence in the mechanisms of the protocol.
A 'Break Glass' situation to me would be a Fee Event / death spiral situation or some other such event leading to a catastrophic decline in Bitcoin reliability and price.
Under such a circumstance I would not issue such a request but directly release:
https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/page-9#post-25830

you aren’t trying to peacefully coexist

Just to clarify this point - I see a clean hard fork as the basis of a peaceful co-existence.
It is not an aggressive act, but an act of evolution.
Someone on Reddit compared it to cell division in an organism.
It's the basis of life, death (the extinction of a cryptocurrency or chain) is already a present factor and hard forks don't change that fact. I do find the soft-fork salad unpalatable, but much more the political strategies employed by the current stewards at Core/Blockstream to bring about their vision of Bitcoin as a settlement layer. They lost my mandate at that point, it's back to Satoshi and his vision of scaling and forking.

 

[HostFat]

I think that it can be bit more interesting with this:
The fork will start accepting blocks with the new POW after the block X, BUT ... if the client will start receiving blocks with an higher size then 1MB, then it will not trigger the acceptance of the new POW.

On this way, current bitcoin miners will have the possibility to avoid the release of this new fork on the market.

Maybe the X block should be like 1 month after the binaries release, so that they will have the possibility to enter in the Bitcoin Classic activation time. (so, all the current Classic nodes will be compatible)

I know that someone can simply change the code to enable the new POW anyway, but still "maybe" this other fork will not have the support of freetrader

 

[freetrader]

@HostFat : A valid and helpful suggestion, but I'm not keen to go along with that. Here's why:

On this way, current bitcoin miners will have the possibility to avoid the release of this new fork on the market.

Avoidance will not the objective anymore, once I put out this fork.
The big miners have avoided sending a positive signal for BIP109 for far too long.
Notable exceptions are KNC and pool miners that took the opportunity to vote, through e.g. Slush.

If the big miners wish to continue mining on SHA256, they will either put out their own software or choose among what the community offers. In my case, there will be a SHA256 version of the fork, so if they choose, they CAN continue to put their equipment to good use.
When KNC announced bankruptcy, I already lost much hope for a SHA256 fork. It's only because the initial commitment of my fork was non-POW, that I am still going to put it out there for the market to decide.

if the client will start receiving blocks with an higher size then 1MB, then it will not trigger the acceptance of the new POW.

I am NOT willing to give the big miners an opportunity to further dictate minimalist on-chain scaling terms through a mechanism which could easily be gamed. They could easily placate such a fork with an insignificantly larger block (1.1MB) and then what - we'll call it a day? Mission accomplished? No...

I would not be able to set a reasonable minimum block size, and neither would I want to, actually.
So I would view such a strategy as - unintentionally - putting control back in the hands of the few instead of the hands of the many.

Maybe the X block should be like 1 month after the binaries release, so that they will have the possibility to enter in the Bitcoin Classic activation time. (so, all the current Classic nodes will be compatible)

I understand the wish to give miners a chance to finally activate a BIP109 fork through an existing client (this would have been my preference until now). I was honestly disappointed that nothing much happened except for KNC and Slush up to now, even though none of the promises of the HK agreement have been met yet.

My plan outlined in the post below foresees quite a long period between initial source release for testing and final binaries release. Giving miners plenty of time to reflect carefully on their further action.
https://bitco.in/forum/threads/announcement-bitcoin-project-to-full-fork-to-flexible-blocksizes.933/page-9#post-21603
Once the final trigger binaries + source are out, there is a concerted fork effort, and no amount of pleading will be able to stop it.

The miners might be able to pre-empt it through some other plan they could put forward. Let's see what they propose on August 1.
I will weigh further options regarding fork deployment at that time.

 

[HostFat]

I am NOT willing to give the big miners an opportunity to further dictate minimalist on-chain scaling terms through a mechanism which could easily be gamed. They could easily placate such a fork with an insignificantly larger block (1.1MB) and then what - we'll call it a day? Mission accomplished? No...

I think that yes, it can be considered it as a goal reached (even with a 1 byte over the 1 MB), because it will be an abandonment of the Core build
It will be enough to move to a new phase of the Bitcoin history.

Just to be clear, I'm far certain that it's likely impossible that over 51% of the mining power will try to block the the acceptance of the new POW creating larger blocks, but I will be quite happy that they will know that any future things will be the result of their not-action.

 

[freetrader]

Would you, as a miner, run a piece of software that contains a trigger for mining code which is incompatible with your hardware (even if it is triggered only under a remote condition)?

I guess if I knew that, I wouldn't even do it as a small miner. Instead, I would mine using software I know is definitely compatible with the chain I choose to mine.
This leads me to prefer a clean separation between the POW / non-POW clients.
The situation could be vastly different in future if ASICs and a specific POW are not such a dominating factor anymore.

As for the big miners, I suspect they are going to roll their own, if anything.
They've had plenty of time to modify Classic or BU to suit their needs, or get inspired in their multiple meetings with Core devs.

Apologies for drifting off-topic from the subject. Once again, my opinions are only speaking about the fork I'm planning to put out. Of course anyone can take it and modify it, or put out a different fork including such an idea

 

[HostFat]

Would you, as a miner, run a piece of software that contains a trigger for mining code which is incompatible with your hardware (even if it is triggered only under a remote condition)?

No
But this is the reason that I said that it should be compatible (have enough time before the block X) with the Bitcoin Classic activation time.

This means that miners will be able to mine with Bitcoin Classic to even stop the trigger of your fork. (on all the possible online nodes/miners)

Anyway, I know that this is all fantasy, but I thought that it was a funny way to put directly in the fingers of the miner the trigger

EDIT:
But I also know that it's better to start the pow fork before segwit, so maybe it's already to late to do this.

 

[HelloGuy]

Any change of PoW will get you only an altcoin, which is a split from the Bitcoin network. If you can provide a PoW altcoin with UTXO as the same as Bitcoin, anyone with a entry-level programming ability will be able to release one. You will get nowhere. In the end, you will be able to hire someone to help you to create such a "bitcoin" with one bitcoin fee.