There has been proposal to change the PoW in case of potential 51% attacksfrom malicious miners during a fork. But such a change in PoW rendersmulti-billion-dollar of ASIC into worthless. which hurts economy so muchand the average innocent mining users. I would propose, instead of PoWchange, we could change the system to the same double sha256 PoW but mix itwith PoS features. Such a PoW+PoS system has several advantages:* It protects existing multi-billion dollar investments from innocentmining users,* A malicious miner cannot launch attacks and rewrite the blockchain with51% or even more hashrate,* If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute blocktime span, that solves the long confirmation time problem,* We'll suddenly have 5 times of block space, that solves the scalingproblem,* The PoS blocks only mine transaction fees, so the 21M cap remains,* With careful design, the PoW+PoS transition _might_ be able to deploywith a soft fork.

Post by Wang Chun via bitcoin-devThere has been proposal to change the PoW in case of potential 51% attacksfrom malicious miners during a fork. But such a change in PoW rendersmulti-billion-dollar of ASIC into worthless. which hurts economy so muchand the average innocent mining users. I would propose, instead of PoWchange, we could change the system to the same double sha256 PoW but mix it

You have to specify what you mean by "PoS" - there's dozens of variations.Equally, existing pure PoS schemes probably don't make sense as a "bolt-on"add-on, as once you introduce PoW to it you should design something that usesthe capabilities of both systems.

FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure PoSand are now trying to design a PoW + staking system instead.

To be clear, you mean such a scheme would protect the multi-billion dollarinvestments non-malicious miners have made in SHA256^2 hardware by ensuring itremains useful, right?

Post by Wang Chun via bitcoin-dev* A malicious miner cannot launch attacks and rewrite the blockchain with51% or even more hashrate,* If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute blocktime span, that solves the long confirmation time problem,

Note that if those PoS blocks are *pure* PoS, you'll create a significant riskof double-spend attacks, as there's zero inherent cost to creating a pure-PoSblock. Such blocks can't be relied on for confirmations; even "slasher" schemeshave significant problems with sybil attacks.

The scaling problem is one of scalability; PoS does nothing to improvescalability (though many in the ETH community have been making dishoneststatements to the contrary).

Post by Wang Chun via bitcoin-dev* The PoS blocks only mine transaction fees, so the 21M cap remains,* With careful design, the PoW+PoS transition _might_ be able to deploywith a soft fork.

As a sidechain yes, but in what you propose above the extra blocks wouldn'tcontain transactions that non-PoS-aware nodes could understand in abackwards-compatible way.

All the above aside, I don't think it's inherently wrong to look at adding PoSblock *approval* mechanisms, where a block isn't considered valid without somekind of coin owner approval. While pure-PoS is fundamentally broken in adecentralized setting, it may be possible to mitigate the reasons it's brokenwith PoW and get a system that has a stronger security model than PoW alone.

FWIW there's some early discussions by myself and others about this type ofapproach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so.

Here is the text of a post to reddit from Feb 2017, discussing a similaridea, and wondering if it could reduce the incentive to delay broadcast ofsolved blocks:

# How an anchored Proof of Stake Sidechain can help the Bitcoin main chain

# Steps:

1. Soft fork Bitcoin to enable side chains

2. Create a side chain that is secured with Proof of Stake. Call blocks onthis chain "POS-blocks." The original chain is made of "POW-blocks."

3. Side chain mints one POS-block after each POW-block on the main chain,and contains the hash of the POW-block, and the hash of the previousPOS-block. See diagram [here.](Loading Image...)

4. Side chain Minters must make a deposit in order to mint. If they mint aninvalid POS-block, they lose the deposit.

5. Side chain blocks are small enough to broadcast and validate quickly(e.g. 100 - 300 KB).

6. Soft fork a new rule into Bitcoin that encourages POW-blocks to includethe hash of the prior POS-block. Specifically, penalize POW-blocks which donot point to the prior POS-block by doubling the difficulty necessary forthem to be valid. Call POW-blocks which do not point to the prior POS-blockbut are valid because of their very high POW "hard blocks."

In the following diagram POW2 and POW4 are valid because they point to theprior POS-block and also satisfy the difficulty requirement. POW3 does notpoint to the prior POS-bock, but is valid anyway because it contains proofof work at twice the normal difficulty.

1. Allow people who do not control ASICs to influence which transactionshappen.

2. Allow people who do not control ASICs to influence which chain getsextended.

3. Reduce the incentive to selfish mine. Once a miner discovers a block,they should broadcast it immediately in the hopes that a Minter will buildon it, because that is the most likely way their block will not go stale.Miners will also immediately start trying to build a hard block. (Maybestatistics could tell us what is the proper range for the HardnessMultiplier. I guessed 2 would be good.)

4. Reduces the effective block interval while reducing the incidence ofstale blocks, empty blocks and SPV mining. After a POW-block is mined, itis immediately broadcast to the network, seeking a qualified Minter toextend it. Minters have a deposit, which they will lose if they mint aninvalid block. Pointing to the hash of an invalid POW-block would producean invalid minted block, so Minters have a strong incentive to completelyvalidate the POW-block before they mint on top of it. After validating,they mint a block and broadcast it. While the Minter is validating theprevious POW-block, competing miners also have time to fully validate theprevious POW-block. By the time the Miners receive the POS-block, they knowwhat transactions they can and cannot include in their own block, becausethe Minter only processes transactions on the side chain. There is lessreason to mine empty blocks, because there is adequate time to update themempool before mining the next soft block begins, and because hard blockstake a long time to produce. The risks involved with mining on anun-validated POS-block can be made small by the fact that there is adeposit that will be destroyed if the POS-block is invalid. POS-blocks canbe validated quickly because they are small.

5. Unlike a pure POS system, a cabal of early Stake holders cannot cheaplyhatch an alternate history. Much less imperative for nodes to go to atrusted peer and ask whether the chain they are being fed is legitimate.

6. After step 6 above, the side chain would have essentially the samesecurity characteristics as the main chain, and could be usedinterchangeably.

7. No hard fork required, and this soft fork could be deployed even if theminers do not consent to it. Some hybrid POS system would be myrecommendation as preferable to simply changing POW algorithms in the faceof miners abusing their power.

8. Users can opt into the POS sidechain, and it can fully prove itself inproduction before there is any attempt to anchor the main chain back to it.Even if consensus cannot be obtained to execute step 6, the mere existenceof such a chain could deter tomfoolery on the part of POW miners, lest theygalvanize the community into throwing the switch.